What We Liked
How to Measure Progress to Plan
Author Glen Alleman starts out this section with the observation: "Measuring progress is difficult on many projects."[9] He observes that some simply measure money spent relative to budget, while others measure the passage of time relative to scheduled completion. But these, either separately or together, "are far from sufficient in support of the 'Five Immutable Principles'. None of these measurements speak to what was actually done on the project in terms of our movement towards 'done'."[10]
Glen goes on to say: "The key principle here is 'planned progress'. ... Preplanning progress is the basis of 'performance-based' measurement for both project processes and technical products." We heartily agree. Note the distinction between "project processes", that is to say the processes involving the tools and techniques of project management, and "technical products", which refers to the work involved in the "maturing" (or evolving) final deliverable, product or outcome.
With these words, Glen effectively disentangles Project Process Management (project management) from Product Development Management (technology management).[11] While it might seem obvious, this is an important distinction. Many arguments surrounding project management issues arise due to the failure to recognize this difference.
So what is the definition of "done", or the definition of "success" in a project context? Our author suggests:[12]
"Let's ask the questions for the Five Immutable Principles again in a slightly expanded form and examine what credible answers might be:
- Do we know what 'done' looks like in units of measure meaningful to the decision makers?
Done needs to be measured as the capabilities provided to the buyer. These capabilities provide the business or organization with the 'ability' to do something new, something in support of its strategy."
A framework for the Five Immutable Practices
Glen states that:[13]
"Each of the Five Practices, guided by the Five Immutable Principles, performs a specific function in our efforts to increase the Probability of Project Success (PoPS). Like the principles, the practices are not a cafeteria-style approach, from which you can pick and choose what to apply to the project. Each practice contains specific steps needed to produce measurable outcomes to increase the PoPS."
And adds:
"This actionable information is the feedback information needed to keep a project under control and on track. These control processes are not impediments to progress; they are the tools needed to increase the probability of success." (Emphasis added.)
"The customer doesn't actually buy features and functions. The customer buys a capability to do something of value."
"Without knowing what capabilities we need at the end of the project, the requirements, and everything else around managing the project has no home, no reason for being, and no connection to the goal of the project."
"Instead of starting with requirements, we need to start with capabilities that describe 'done' in Measures of Effectiveness for the outcomes of the project, not just delivery of solutions derived from the requirements."[15] (Emphasis added.)
Glen then describes how this should be approached, how to identify the Requirements Baseline, how to establish and execute the Performance Measurement Baseline, and how to perform Continuous Risk Management. These provide the backdrop for deploying the better-known processes necessary for actually executing the work of the project. Glen lists these in another "set-of-five" as follows:
- Organize the project
- Plan, schedule, and budget
- Execute project accounting
- Execute project performance analysis
- Record revisions and maintain data
We would much prefer the traditional version of "Plan, Organize, Execute, Monitor, and Control" but perhaps Glen's version is more specific in today's environment.[16]
9. Ibid, p55
10. Ibid.
11. Ibid — see also Figure 6.3 on p177 and Figure 6.4 on p179
12. Ibid, p59
13. Ibid, p69
14. Ibid, p70
15. Derived from the definition of management, first developed by Henri Fayol circa 1916 in his work Administration Industrielle et Generale
16. Performance Based Project Management, pp101-102, developed in detail in pages 102 to125.
|
Book Structure
