Bob is managing five projects. Each of those projects support a different aspect of a specific enterprise application. Several of those projects are pretty advanced in execution and have entered a deployment stage. Other projects have just barely gotten off the runway and are still onboarding their staff. One of Bob’s projects is still in the early proposal stage and hasn’t had any serious funding authorized. Every week, Bob’s management asks him to fill out a single status report for this program. Every week, Bob looks at the “Stage” drop down option in his status report and has no clue how to fill it out. He eventually closes his eyes, spins the mouse wheel not unlike the arm of a slot machine and randomly selects whatever stage sounds good at the time.
Anyone who’s ever tried to shoehorn a collection of projects into a single workflow has gone through the realization that programs require their own lifecycle, effectively serving as a macro version of the lifecycle for each project. If I am building a pipeline, I might split the pipeline into multiple sections. Each section would have a planning, permitting and construction stage. Some sections might require horizontal drilling. Other sections may include relatively even terrain. Each of those sections will be managed by a different project manager and may be built in sequence or in parallel.
The question then comes up….what stage is the overall program in? Is it in planning? Construction? Permitting? None of the answers make sense because the question doesn’t make sense.
A Simple Program Lifecycle
The solution is to step back and look at the program lifecycle. In the PMI standards, that’s depicted as a simple three stage model – a starter workflow, if you will.
- Planning – where we define the program goals and how those will be tied to the authorized projects.
- Execution – where we identify, authorize and execute the work. Note that this is a catch all stage that rolls up many of the standard project lifecycle stages.
- Closeout – where we identify if our program met its goals and whether or not we achieved the anticipated benefits.
A More Nuanced Lifecycle Model
Clearly, this lifecycle wouldn’t work for all programs. What about the open ended programs such as Health Safety and Environment (HSE) initiatives? An organization will charter an HSE program and staff it with resources looking for ways to continually improve and maintain HSE performance by limiting the number of reportable incidents. These are the sort of programs that never really end, they just keep going on and on and spawning an endless series of projects.
So how does one come up with an appropriate program lifecycle? I don’t have all of the answers, but it seems to me that the correct approach would be to start at the end. What is the end goal of the program? Once that’s identified, we can work backwards from there to create a management model.
In my world, that pretty much means we have the following potential program lifecycle models:
- Asset Lifecycles
- Continual Improvement Lifecycles
- Contracted or Defined Lifecycles
- Product Development
An asset lifecycle is pretty much our standard lifecycle in the IT domain where an asset is almost always defined as a service, which is then supported by applications, which are then supported by infrastructure. Projects either add or remove elements from this asset, and operations ensure the asset performs its functions. In this model, the end of the asset dictates the end of the program, hence the projects and priorities spawned by the program will vary based on where the asset is in its lifecycle and investment analysis on when to improve the asset. As near as I can tell, wells and drilling platforms follow roughly the same model.
I see continual improvement lifecycles more in the business domain, where we might have continuing initiatives to increase efficiency, or reduce HSE incidents. These lifecycles will almost never end and often have (or should have) clearly defined metrics of success that were identified during the planning stages.
Contracted or defined lifecycles include definite ends. Our goal is to decommission this site, or to develop a complicated solution to a pressing problem. These programs may also exist as subprograms within an overall program framework.
Finally, we have the product development lifecycle, which takes a product into the market and then sustains it while it’s in the market. This lifecycle might perhaps be considered a subset of the asset management lifecycle insofar as there are a number of similarities, but there are also a significant number of differences related to the relative newness of the product’s underpinning elements and the challenges of supporting a market of external consumers as opposed to a more controlled group of internal consumers.
That’s not intended to be an exhaustive list of program management lifecycles – more an off the cuff analysis of the ones I come into contact with most frequently.
The Context Provides the Purpose
What do we do with this knowledge? The next time you’re forced to answer the question of “which single stage are all five of these projects in?” take a step back. Look at whether or not these projects are all related. If someone’s asking you that question, chances are that they are, in fact, related. Then look at what program goal these projects are supporting. Finally, develop an appropriate lifecycle for the program.
Only after you’ve done that, can you then begin to assess the reporting requirements of your individual projects, and provide that information in a meaningful and relevant manner.