Project Lifestyle

On several occasions recently I have had to help customers come to terms with their project lifestyle choice and convince them of the values of program management.

In describing the difference between projects and programs I find it pays to use language the business folks readily understand. My favorite way is to use a metaphor.

Managing a project is like flying an aircraft. Managing a program is like running an airport.

Projects, like aircraft, come in all sizes: big and small. Depending on size you may have more (or less) people and technology onboard to help you with the flight. Unfortunately when you crash, the bigger you are the more people can get hurt (including you sometimes).

Programs are more like airports, with aircraft (projects) taking off and landing all the time. But you have a lot of supporting organization and infrastructure to look after as well.

I find the metaphor works very well to draw attention to the unifying purpose of programs as well as their open-ended nature. What do you think?

In any event it pays to remember this truism from the world of aviation: “When a flight is proceeding incredibly well, something was forgotten.” For more wisdom consider these other flying truisms.

Of course to the purist PM’s out there who might be offended by such a simple comparison, here are the formal PMI PMBOK definitions:

Project. A temporary endeavor undertaken to create a unique product, service or result.

Program. A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually. Programs may include elements of related work outside of the scope of the discrete projects in the program.

Think about it when considering all of parallel initiatives you or your customer is trying to manage. Maybe is it is time to consider a program to get to grips with the project lifestyle.

I’m happy to take comments, as ever. Here or email me at andrew.sparks@oracle.com

I am busy working through by backlist of material that I have published internally over the last 5 – 8 years. I thought I might note a few of the planned posts as a trailer.

I have listed them in no particular order.

I would like to draw attention to an external professional community for project and program managers working in the IT industry. Go and check out Gantthead.

Subscribing is free, including a newsletter straight to your inbox.

One professional hazard that PMs are very susceptible to, is getting too isolated from what is going on out in the wider world of project management. Membership and contributing to professional communities is one way to combat the isolation.

One of my colleagues called me about the airport metaphor post.

He is prepping a workshop with a customer in Denmark to discuss their
proposed ERP consolidation & rollout plans. He found this an ideal place to
use the metaphor to help them understand the project lifestyle that they would
be getting themselves into.

Better yet he found a great image (I hope it was Photoshopped!) to
illustrate the metaphor.

Here is
the link to the original source (the article is interesting as well…)

What is escalation and why do many Project Managers put a lot of time and effort into avoiding it?

I was reflecting on this after yet another request had come into my team to go and provide some remedial services to a project that had gone into "escalation".

My opinion is that escalation, like alcohol, is good when used moderately.

I look at it as just one of the tools from stakeholder management a PM can employ to resolve an issue or get a decision made.
By escalating, raising awareness or getting help from higher levels in your own organization (or the customer's), you can make progress before the situation gets out of hand. 
Escalation in a project is like driving a car with manual transmission.
You can drive everywhere in second gear, but it is bad for the engine, makes a lot of noise and it's just plain inefficient.
Changing gear up or down at the appropriate time delivers a smoother ride for everyone.

Likewise with a problematic issue in a project. You can keep working the issue harder on your own, or with the resources you have available.
But, timely escalation gives the project stakeholders the opportunity to contribute to the project with a decision or resource at a time when it will help, rather than when it is too late.
Unfortunately this is what usually happens. Senior stakeholders are asked for help too late to avoid a significant impact on the project and when significantly more resource or time is needed to get back on track.


I thought I might have a closer look at why escalation is such a taboo subject in the world of Project Lifestyles.

A Multiplayer Game

Many of our customers are employing a multi-supplier strategy when looking for IT consultants and  each consulting supplier brings their own methodology into the picture as the way to run the project.

While multiple sourcing is fine as a strategy for managing one element of your project costs, it can lead to a situation where you are managing your project portfolio with a patchwork quilt of supplier-specific project frameworks and methodologies.  Is this a bad thing? What can you do about it?