Level 3 Management
  The
developmental cycle is central to the Level 3 Management controversy. You only
really understand the project parameters after you are well into the investment.
With this, in typical applications, it is very difficult to anticipate the final
cost and schedule position and even the final configuration of the product. The
art of the possible will either be discovered or the quest becomes too expensive
and the project is cancelled. This is a normal aspect of Level 3 management. This
uncertainty becomes particularly arduous where developers are required to provide
a firm price a bid, as one would rightfully expect at Level 2.
However the project becomes established, the key to success is rarely in any
of the formative documentation provided to Stakeholders as the basis for approval
to proceed. Rather, a "Project Leader", a senior officer above the station of
the Project Manager, oversees the trajectory of the estimate at complete. Trying
to establish a sense of "Earned Value",[1] attempts are made to see how the investment
is proving out. From this, an Estimate-At-Completion is calculated to guestimate
the final figures.
 The Program
Manager can then reflect on the mission importance of the initiative and decide
whether the organization can afford to continue with it. Killing the project will,
obviously, save project costs but at the expense of foregoing the intended functional
outcome. Part of the judgment is realigning subcomponents, perhaps by eliminating
cost bearing functional components or by reducing technology to one that is tried
and proven technology.
An often understated, and easily discarded, dimension of intrigue in this regard
is the implication of relaxing requirements when nature "forces your hand." Keeping
sights trained on the end user's minimal requirements is also a key constraint
on how the project manager "plays the game."
Regarding Earned Value, the concept is good; the regime behind it is not so
good. Earned Value assessments in their initial incarnation entailed a detail
accounting exercise, the rigor of which was upset by the dynamic complexities.
Imagine highly detailed accounts, painstakingly compiled in a detail complexity
database, only to then be changed like sand on a beach with the first wave of
change. Successful Earned Value calculations require experience-based parametric
estimation.
When to Re-baseline
|
Learning quickly and getting this prediction correct as soon as possible can
make the difference between a viable outcome and a cancelled project. See Tao
Teh Ching quote.[2]
|
|
"Deal with things in their formative state... .
...before they grow confused"
-Tao Teh Ching
|
|
Deploying resources in pursuit of an unachievable outcome is a necessary casualty
of learning. Letting the problem fester unnaturally is a waste of opportunity
to take corrective action.
The analogy of baking a cake applies. Through the process of buying your ingredients,
mixing them, getting them into a pan and finally to the oven, the ability to change
trajectory — make a different shaped or a different flavored cake —
decreases exponentially as you progress through the process.
1. "Cost/Schedule Control Systems Criteria, The Management Guide to C/SCSC", Fleming, Quinten, Probus Publishing Company, 1988
2. "The Teachings of Immortals Chung and Lü", Shambhala Publications, 2000
|
Chapter
8: Level 3 - Program Management 
