Click here to view the complete list of archived articles

This article was originally published in the Summer 2006 issue of Methods & Tools

---

Project Failure Prevention: 10 Principles for Project Control- Part 2

Tom Gilb, www.gilb.com

Copyright © 2005 by Tom Gilb. Published and used by Methods & Tools with permission.

P2: PAY FOR RESULTS: The project team must be rewarded to the degree they achieve the critical product objectives.

What do we do for the project team when they fail to deliver the specified requirements, or when they use more time and money thanbudgeted? We reward them by continuing to pay them.

Now, if being out of control on performance and costs was entirely beyond their powers, then ‘payment for effort’ might be areasonable way to do things. But I believe that we would be much better off ifthere were clear rewards for reaching targeted performance levels within budgeted resources. And lack of reward, for failing.

Figure 3. The design engineering process depends on the quality of the requirement specification. The standard for the requirementspecification can be set partly by the specification rules, and partly by thedefect density tolerance (that is, how seriously the rules are taken as measuredby a quality control process). The standard processes and tags (for example, ‘Rules.GS’)refer to the standards published in the CE manuscript (Gilb 2005)

We would, of course, have to make it a ‘fair’ game. The project team would have to voluntarily agree that the performance goals were infact realistic, in relation to the resources they have, or can get, to deliverthem. We would also need to resist the temptation to dictate work processes orto specify designs, which in the view of the project team, would stop them from achieving the project goals.

Of course if we still cannot specify the performance goals quantitatively, then no amount of motivation and freedom will get a project teamto move in the right direction. They don’t even know what that direction is.

P3: ARCHITECTURE FOR QUALITY: There must be a top-level architecture process that focuses on finding and specifying appropriate design strategies forenabling the critical product objectives (that is, the performance requirements’ levels) to be met on time.

If you do not have a clear quantified set of top-level critical requirements, then an architecture process is bound to fail. Thearchitect cannot compare their design idea’s expected performance andcost attributes with the clear performance and cost requirements, they need to have for clear judgements about design ideas.

Even if the requirements are perfectly quantified and clear, that is not sufficient. The architecture designs themselves must be specified insufficient detail to enable an judgement that they will probably provide the necessary levels of performance and cost impacts (See Figure 3).

Figure 4. An example of a real draft design specification that attempts to both have necessary detail, and to make some assertions and estimates about the effects of the design on requirements. Much more could be specified later.

P4: CLEAR SPECIFICATIONS: Project specifications should not be polluted with the usual dozens of defects per page; there needs to be specification quality control (SQC) with an exit condition set that there should be less than one remaining major defect per page.

I regularly find that any requirement specification given to me by a new customer, even if it is approved and being used, has between 80 and 180 ‘major’ defects. This is normally a ‘shock’ for the people involved. How can there be so many? We measure them by asking colleagues of the specification author, and often the author too, to check a sample ‘logical’ page (that is, 300 non-commentary words) of a requirements specification, and count any violations of these simple rules:

• Clear enough to test;
• Unambiguous to the intended readership;
• No unintentional design in the requirements.

I then ask participants to evaluate if each rule violation (defect) is serious enough to potentially cause delays, costs, and product defects. They are asked to classify any that are serious, as ‘major’ defects. The range of majors found per sample page, in about 15 minutes of checking, is usually from 3 to 23 per person. I find that small groups of 3 to 4 people typically find about double the most defects found by a single individual. For example, if the greatest number of defects found by one person is 15, then a small group would have about 30 unique majors to report. But these 30 are only one third of what is actually in the spec right now. The checking process is about 30% effective. Consequently there are something like 90 major defects present in the page, of which the small group can find only a third in about 15 minutes.

Most people immediately agree that this is far too many. It is. And it is unnecessary! How polluted a requirements specification would you think is acceptable? If you are professional you will finally set a limit of no more than one remaining major defect per page before you release the specification for use in design or test planning. 

Total Defects M+m	Majors M	Design (part of Total and M+m) Design
41	24	D=1
33	15	D=5
44	30	D=10
24	3	D=5

Table 1: An example from a 30 minute checking of real project requirements at a Jet Engine Company by 4 managers. The sample page was called‘Non-Functional requirements. By extrapolation the team found about 60 of atotal in the page of about 180 major defects. The ‘M+m’ is majors and minors. The ‘D’ numbers are the number of designs in the requirements

My experience (since 1988 working with aircraft drawings in California) is that if you set such exit conditions (max. 1 major/page) and takethem seriously, then individuals will learn to reduce their personal injectionof major defects by about 50% for each SQC cycle they go through. Within about 7cycles, the individual engineer will be able to specify such a cleanspecification that it will exit first time. Some people can achieve this with fewer cycles.

The conclusion is that because we do not carry out even simple inexpensive sampling measures of specification pollution, and we do notset a limit to the pollution, we live in a world of engineering that is normally highly polluted. We pay for this by project delays, and poor product quality.

Page 1    Page 3    Back to the archive list