The Ends Dictate the Means: Defining a Program Management Lifecycle

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.

The Ends Dictate the Means: Defining a Program Management Lifecycle

2 thoughts on “The Ends Dictate the Means: Defining a Program Management Lifecycle

  1. Andrew, you are clearly pointing out the reasons why EPM systems don’t add value, and why the data provided is useless. Albeit, vendors are turning in their beds wondering why pros like you come to think like old horses like me. Experience working with related EPM systems shows they add little, or no value, but do cost companies a lot: there’s NO ROI, but a huge burden, with a large expense.

    Many programs cannot be evaluated based on stages, or phases, or chunks: aggregating information from that perspective just doesn’t make sense, and the data shows nothing useful. Additionally, setting up a system to capture data for time reporting that way, is a complete waste of everyone’s time.

    Many programs, have projects with unrelated technical lifecycles, although the project lifecycles are exactly the same and should be evaluated on that merit, and that merit alone. If needed, summarize up to the program level, but don’t waste much time at that level, because it doesn’t provide an actionable view.

    To summarize, don’t roll-up information through a technical method phase, or stage, or up to the program level using project lifecycles, because the data context adds no actionable value. With that being said, you can use the roll-ups to provide some forecasting capabilities for funding.

    Don’t get wrapped around the EPM axle, add value at the project level: move projects, not data.

  2. Not that I entirely disagree with you, but you might be projecting a bit to draw that conclusion from this post. The main goal of this was really to emphasize that it’s important to understand the context within which the project is being performed to understand the metrics that need to be tracked and how they should be tracked. Failure to do so means that we collect the wrong metrics – which, in the end, means we don’t understand what “done” means. That being said, I think we’re in violent agreement on not rolling up technical lifecycle stages. There’s value in identifying lifecycle stages – primarily as risk mitigation IMHO, but rolling up data ain’t it.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s