This Guest paper was submitted for publication and is copyright to Mark A. Seely© 2016.
Published here April 2017

PART 3 | Editor's Note & Table of Contents | Chapter 7: Finding Levels 3 and 4
Chapter 8: Level 3 - Program Management | Level 3 Management | The Apollo Example
Chapter 9: Level 4 - Program Governance | Level 4 Governance | Performance
Chapter 10: Level 5 - Public Governance | Level 5 Governance | PART  5

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.

Chapter 8: Level 3 - Program Management   Chapter 8: Level 3 - Program Management 

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
 
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page