Project Failure Prevention: 10 Principles for Project Control

Project Failure Prevention: 10 Principles for Project Control

Tom Gilb in his article describes that a lot of projects fail, no matter if they are engineering projects or software engineering projects. He describes 10 principles for project control that if used wisely, can save a lot of projects. Here is a summary of those principles:

P1 – Critical Measures
This principle states that the critical product objectives need to be stated in a way that they can be measured. The project needs to have a well-written set of top-level requirements which include the critical product characteristics with a set of measurements for those characteristics. For example, in the objectives one can say that the firm needs state-of-the-art security, but it is much better to state that the firm needs 99.89% reliability.

P2 – Pay for Results
This principle states that the project team has to be rewarded to the degree the project achieves the critical product objectives (described in P1). The author states that project teams when do not deliver specifications or when schedule is not met, usually management gives them more money or more time to finish the requirements. Team are being rewarded with more money or more time when results are not good. The author suggest the contrary to “punish” them when requirements are not met.

P3 – Architecture for Quality
This principle states that there is a need for a top-level architecture process that will be the guiding parameter for the whole project. That top-level architecture process has to specify design strategies to enable the critical product objectives. This principle is concerned in building good foundations for the project.

P4 – Clear Specifications
This principle states that the specifications have to be super clear. The specifications have to be clear enough that they can be tested, they have to be unambiguous to the intended readership and that there should not be any unintentional design requirements. The specifications have to be easy to read for any kind or reader.

P5 – Design must meet business needs
This principle states that the specifications have to be carefully reviewed to see if the designs meet the business needs. Again, designs should be well written and easy to read. After reviewing the design, an analysis has to be made to see if the business requirements are going to be fulfilled with the design. Detail is needed so there is no confusion in latter parts of the project. The design has to have resource estimates.

P6 – Validate Strategies Early
This principle states that high-risk strategies have to be validated in early stages of the project. Those high-risk strategies are the ones that will impact the levels of performance and cost. Also those strategies are the ones that can ruin or make a project fail. To validate strategies, project teams can build pilots, trails, experiments, prototypes, etc. This principle is the one related to Risk Management.

P7 – Resources for Designs
Resources like money, human effort and calendar time have to be allocated carefully to meet the required design. Each design and each project have specific characteristics, and good resources are not necessary good in some situations, so the resources should be allocated according to the design, they have to be allocated to enable the design.

P8 – Early Value Delivery
This principle states that the stakeholder value has to be delivered as early as possible. The author suggests that projects have to be planned in an evolutionary way. The most basic requirements or objectives should be done first, and around those, the new phases should be built.

P9 – Avoid Unnecessary Design Constraints
This principle states that requirements and specifications should not include unnecessary constraints that could impact performance and value. This principle suggests that the designs and solutions should impact business needs instead of being done to satisfy technical designs. The author suggests that projects should use the technology to satisfy requirements, not the other way around.

P10 – Value before Bureaucracy
This principle states that “the project should be free to give priority to value delivery and not to be constrained by well-intended processes and standards”. (Gilb, 2005). Bureaucracy can impact project performance if it delays decision making. Project management should have the power to make fast high impact decisions.

Reference: Tom Gilb. Copyright 2005-2006 by Tom Gilb. Published and used by Methods & Tools with permission. www.methodsandtools.com