What We Liked
This may sound like fun stuff with acronyms, but behind it all is the serious issue of "How can any investment decision be made, on a quantified basis, unless there is at least some sense of what value awaits a successful outcome?"[10] Indeed, Stephen might have added "or even what constitutes a quantified successful outcome?" Later, Stephen answers his own question by observing "There are thousands of corporate organizations that depend on projects for more than 90 percent of their revenues. Yet, other than intuitively, they have no way of tying the projects they do to their profits."[11]
Even under traditional project management, an absolute minimum data for each project in a portfolio should be the expected monetary value, the current completion date, and the cost estimate to complete.[12] Actually, having worked for respectable real estate development companies, we can state that these concepts are well known to them. However, having also worked with software development organizations, it appears that these metrics are not only rare but tend to be foreign to proponents of the latest forms of
software development project management.
Under Stephen's TPC approach, the data required is even more profound. In a portfolio of projects, it should consist of:[13]
- Project Name
- Expected Monetary Value
- As of (i.e. Current reporting date)
- Current Completion Date
- Loss per Week Late (%)
- Gain per Week Early (%)
- New Expected Value
- Cost Estimate to Complete
- Simple DIPP
Note the addition of the time value of being ahead or behind schedule, not in terms of project overhead costs but in terms of gain or loss in value of the product to the organization. Stephen provides many examples of his approach, although not all calculations are explicit.
Stephen wades into the assembly of work breakdown structures, and CPM scheduling to illustrate his theories. On the question of how do you plan the work scope, he suggests:[14]
"Each type of project is different, and each project is different. It is therefore difficult to set hard-and-fast rules for assembling scope documents. The best idea I have found is to
- Start with the benefits you want to achieve,
- Incorporate them into a business plan,
- Then move as rapidly as possible to a concrete image of the thing that will provide those benefits."
This is sound advice [The bullets are mine, by the way.] On the matter of estimating, Stephen offers more sound advice:[15]
The person who is going to be responsible for the work should be the one who generates the estimates. This is probably the most important contributor to accurate estimates. The reasons for this are:
- This person will be a subject matter expert, trained in the discipline necessary for the particular work.
- This person is the only one who will know precisely how he or she plans to do the work.
- He or she will usually have a vested interest in meeting his own commitment, and establishing the reliability of his or her own estimates.
Unfortunately, the practicality in many cases is that, (a) the contributors don't know how to estimate, (b) they don't want to estimate, and (c) if they are really busy, they don't have the time to estimate. Still, it does suggest that estimating ought to be a part of production skills.
10. Ibid. p xix
11. Ibid. p8
12. Ibid. p9
13. Ibid. p12
14. Ibid. p63
15. Ibid. p105
|
Book Structure
