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.

It’s a workflow kind of month, and I figured I’d post this quick article on how to leverage UMT’s Project Essentials 2012 with Project Server 2010 to generate a no-code archive process.

In this case, the goal is to close the project out, and then create a report that will notify the administrator to archive the project at a later date. Now, exactly what that archive process looks like is kind of up to you, as I find many organizations vary widely on definitions of the archive process and when they decide to trigger it.

First, I see up a couple of stages to move the project between.

Then I create a security group containing the folks who are required to archive a project.

Now we go into Project Essentials and generate a simple workflow. I won’t walk you through step by step, but it’s pretty self explanatory once you open up the wizard.

The only real nuance is that I am adding a manual submittal requirement and an approval step for the Closing step. This will require the PM to submit the project to be archived, and will send a notification to the members of the Custom Archive Approvers group to do so.

I link the workflow back to a project type, and run a project through the process.

When I get to Closing, I require the PM to manually approve it – or perhaps require the PMO to submit it. That kicks off a workflow request that gets logged in the Workflow Task List.

One more step and we’re there. Let’s create a new view of the Workflow Task List and modify it to filter only on those tasks exiting Closing and entering Archived.

I now have a screen which time stamps the date the project was closed, and gives the administrator an overview of which projects need to be archived. As a project typically hangs around for 6-12 months before being archived, the administrator can review this list on a quarterly basis to identify candidates for the archive process.

Even better, add a simple workflow to the Workflow Task List to send an e-mail to the administrator 6 months after the workflow task has been created.