|
Software Development Magazine - Project Management, Programming, Software Testing |
|
Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban |
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 4
Tom Gilb, www.gilb.com
Copyright © 2005 by Tom Gilb. Published and used by Methods & Tools with permission.
P8: EARLY VALUE DELIVERY: The stakeholder value should be delivered early and continuously. Then, if you run out of resource unexpectedly,proven value should already have been delivered.
Projects may fail because they run out of time or money and have delivered nothing. They can then only offer hope of something, at the costof additional money and time – and note that this addition is typicallyestimated by the people who have already demonstrated they do not know what they are promising.
| Contract | Supplier | Motive | Architect | Parts Used | Sum %Impacts |
Requirements | ||||||
Performance | ||||||
Quality 1 |
0% | 100% |
50% |
30% |
-20% |
160% |
|
Quality 2 |
100% |
50% |
0% |
20% |
50% |
220% |
|
Costs |
||||||
|
Investment Cost |
5% |
10% |
1% |
10% |
110% |
136% |
|
Operational Cost |
5% |
50% |
20% |
1% |
10% |
86% |
|
Staff Resource |
10% |
20% |
10% |
5% |
0% |
45% |
|
Performance to Cost Ratio |
100/20 |
150/80 |
50/31 |
50/16 |
30/120 |
|
Table 2: An Impact Estimation table structure simplified example that helps us consider cost elements, while looking at the performance impacts. Consequently we can see the performance to cost ratio. The % estimates refer to % of meeting a performance level target, or to % of a budgeted cost
The smart management solution to this common problem is to demand that projects are done evolutionarily. That means there will be consciously-planned early (first month) and frequent (perhaps weekly, or 2% of budget) attempts to deliver measurable value to real stakeholders.
Most people have never been subject to this discipline, and they have not learned the theory of how to do it in practice. But there are decades of practical proof in the software and systems engineering world that this works. (Larman and Basili 2003, Larman 2003).
P9: AVOID UNNECESSARY DESIGN CONSTRAINTS: The requirements should not include unnecessary constraints that might impact the delivery of performance and consequent value.
It is all too common for projects to focus on a particular technical solution or architecture, and not to focus on the actual end results they expect to get from the technical ‘design’. They end up locking themselves into the technical solution – and rarely get the results they expected. Remember the high failure rate of projects?
The primary notion in planning any project, and in contracting suppliers to deliver all or part of it, is to focus entirely on the top few critical results. The critical results have to be quantified within the requirements and made the subject of contract conditions (such as, ‘No cure, No pay’).
Figure 8. Conceptual view of delivery of stakeholder benefits early and cumulatively. From Kai Gilb’s book Manuscript (Gilb, K. 2005)
|
Technology Policy
|
Figure 9. A technology policy the author suggested to one of his clients, a major electronics telecom organization
P10: VALUE BEFORE BUREAUCRACY: The project should be free to give priority to value delivery, and not be constrained by well-intendedprocesses and standards.
There was a time when software and IT were ‘Wild West’. Anybody who could program, did things as they knew best. Sometimes, we are notfar in many places from that model today. However in other places, the need toget higher consistent standards of professionalism, has swung the pendulum toofar the other way. Processes and standards like the Software EngineeringInstitute Capability Maturity Model Integration (CMMI 2002) are thorough andwell intended. But almost no such recommended frameworks and processes encourageor permit focus on the main results of a project. Consequently there is agreat, inevitable, danger that this results focus will be lost inpractice. Everywhere I look, I see that result – no results focus –worldwide – with or without the distraction of CMMI and the like. Thisincludes the Agile Methods (Larman 2003). My recommendation to attempt to refocus is outlined in Figure 10.
A Simple Evolutionary Project Management Method
Project Process Description 1. Gather from all the key stakeholders the top few (5 to 20) most critical performance (including qualities and savings) goals that the project needs to deliver. Give each goal a reference name (a tag). 2. For each goal, define a scale of measure and a ‘final’ goal level. For example: Reliability: Scale: Mean Time Between Failure, Goal: >1 month. 3. Define approximately 4 budgets for your most limited resources (for example, time, people, money, and equipment). 4. Write up these plans for the goals and budgets (Try to ensure this is kept to only one page). 5. Negotiate with the key stakeholders to formally agree the goals and budgets. 6. Plan to deliver some benefit (that is, progress towards the goals) in weekly (or shorter) increments (Evo steps). 7. Implement the project in Evo steps. Report to project sponsors after each Evo step (weekly, or shorter) with your best available estimates or measures, for each performance goal and each resource budget. - On a single page, summarize the progress to date towards achieving the goals and the costs incurred. - Based on numeric feedback, and stakeholder feedback; change whatever needs to be changed to reach goals. 8 When all goals are reached: "Claim success and move on" (Gerstner 2002). Free the remaining resources for more profitable ventures Project Policy for Simple/Agile Evo Projects 1. The project manager, and the project, will be judged exclusively on the relationship of progress towards achieving the goals versus the amounts of the budgets used. The project team will do anything legal and ethical to deliver the goal levels within the budgets. 2. The team will be paid and rewarded for ‘benefits delivered’ in relation to cost. 3. The team will find their own work process, and their own design. 4. As experience dictates, the team will be free to suggest to the project sponsors (stakeholders) adjustments to ‘more realistic levels’ of the goals and budgets. For more detail, see (Gilb 2003, Gilb 2004). |
Figure 10.
Acknowledgements
Article edited by Lindsey Brodie, Middlesex University. London
References
Bahill, A. Terry and Henderson, Steven J., "Requirements Development, Verification and Validation Exhibited in Famous Failures", SystemsEngineering, Vol. 8, No. 1, 2005 pp. 1-14
CMMI, Capability Maturity Model Integration, Carnegie Mellon SoftwareEngineering Institute, 2002, http://www.sei.cmu.edu/cmmi/ [Last Accessed April 2005].
Gerstner, Louis V. Jr., Who says Elephants Can’t Dance? HarperCollins, 2002. ISBN 0007153538.
Gilb, Kai, Evo, 2005. Draft manuscript at http://www.gilb.com
Gilb, Tom and Graham, Dorothy, Software Inspection, Addison Wesley, 1993.
Gilb, Tom, "Software Project Management: Adding Stakeholder Metrics to Agile Projects", Novática, Issue 164, July-August 2003. (SpecialEdition on Software Engineering - State of an Art, Guest edited by Luis Fernández-Sanz. Novática is the journal of the Spanish CEPIS society ATI(Asociación de Técnicos de Informática.) See http://www.upgrade-cepis.org/issues/2003/4/upgrade-vIV-4.htmlIn Spanish: http://www.ati.es/novatica/2003/164/nv164sum.html
Gilb, Tom, "Adding Stakeholder Metrics to Agile Projects", Cutter IT Journal: The Journal of Information Technology Management, July 2004,Vol. 17, No.7, pp31-35. See http://www.cutter.com.
Gilb, Tom, Competitive Engineering: A Handbook for Systems Engineering,Requirements Engineering, and Software Engineering using Planguage, 2005, Elsevier Butterworth-Heinemann. ISBN 0750665076.
Larman, Craig and Basili, Victor R., "Iterative and Incremental Development: A Brief History", IEEE Computer Society, June 2003, pp 2-11.
Larman, Craig, Agile and Iterative Development: A Manager’s Guide, Addison Wesley, 2003. See Chapter 10 on Evo.
Morris, Peter W. G., The Management of Projects. London: ThomasTelford. 1998. ISBN 072771693X. 358 pages. USA: The American Society of Civil Engineers.
Neill, Colin J., and Laplante, Phillip A., "Requirements Engineering:The State of the Practice", IEEE Software, November/December 2003, pp. 40-45.
Related Articles
Quantified Objectives: A Fundamental Advance in Managing Software Development Projects
Adaptative Project Management Using Scrum
Related Resources
|
Methods & Tools Testmatick.com Software Testing Magazine The Scrum Expert |
|
Browse a selected list of upcoming Software Development Conferences |
Copyright © by 1995-2024 Martinig & Associates |
Privacy
Follow Methods & Tools on
