Projects and Programs Luis Seabra Coelho November 21, 2014
Introduction Even basic notions are sometimes misunderstood and, at large, this is the case of the concepts associated to projects and programs. On one hand, there is a common understanding that programs are somehow bigger than projects and that you start as a project manager and then naturally continue as a program manager, once you’ve proven your professional value. On the other hand, some project managers are in fact managing programs without it being explicit to her/him, the sponsor or other main stakeholders. The issue about managing programs using the tools and the mindset for managing projects is that you’re bound for trouble. This is as simple as it gets: it’s just like using a screw driver with nails. In the end, what you need to manage a program is not just “more and bigger” than what you need to manage a project: it’s a different toolset, different skills and a different profile altogether. A nice analogy for this is the engineer and the manager: all too often a good engineer is promoted to a bad manager.
Is there a difference? Consider a project with a few subprojects. Is it any different than a program with a few projects? It doesn’t feel like there is any difference, does it? But there should be differences and that’s why they have different names and there are different certifications and different “books of knowledge”, different job titles and so on. Well, let’s start from the very basics then. If you take a look at the Project Management Book of Knowledge (PMBoK) of the PMI (Project Management Institute), you’ll find that they define project there as follows: A project is a temporary endeavor undertaken to create a unique product, service, or result. in PMBoK 5th Ed., page 3 This definition is not much different than any other you can find. As for a program, PMI defines it as follows: A program is defined as a group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually. Programs may include elements of related work outside the scope of the discrete projects in the program. in PMBoK 5th Ed., page 9
Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho, www.ahhamoments.net 1
If a program was defined just as “a group of related projects, subprograms, and program activities manages in a coordinated way”, then a project with some subprojects and a program would be pretty much the same thing. But then they add 2 things to the program definition: 1. To obtain benefits not available from managing them individually, and that 2. Programs may include elements of related work outside the scope of the discrete projects in the program. How is that managing the whole can bring benefits not available from managing them individually? And why do you need work not defined in any of the projects? In short, the first “program add on” refers to the program’s focus on the business benefits and the second refers to the lubricant needed to put all the pieces (or projects) running together smoothly not only the politics but all that the larger picture involves. These differences are compiled on the same book and a capture follows:
In PMBoK 5th Ed., page 7 Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho, www.ahhamoments.net 2
We’ll be disregarding portfolios altogether as they are not the focus of this paper. This is just to corroborate that in fact projects and programs have many differences.
Outputs and outcomes Some differences, like outputs and comes, are not explicitly in the previous table. But nevertheless, projects are supposed to produce outputs and programs are supposed to produce outcomes. Let me explain what these outputs and outcomes mean. The difference between output and outcome is a bit like the difference between hardware and software (in the sense of the joke “hardware is what you are able to hit and software is what you insult”). Outputs are the things that your project is going to deliver: it can be a house, an IT system or even a new process but it is always something that you can pinpoint and put your finger on it even if you can’t actually touch it. It is always the answer to “what?”. The outcome answers the “why?”: Why do you want the house for? Or the IT system? Or the new process? The answers will always be more difficult to pinpoint, but: ● You can have a house as an output because you’re having a baby and need some extra room (or because you plan to move town, or…) ● You can have an IT system as an output because your current billing system has no more support services (or because your current ERP system doesn’t perform well enough anymore, or…) ● You have a new process to approve invoices because you’re opening a new office in another town (or because you need to plan your spendings more ahead than you’re doing now, or…) At any rate, the outcomes are always much larger than the outputs and they’re always the reason why you want to outputs in the first place: because you’re having a baby you need a house that’s your root cause for getting a new house. Keep in mind that the outcome is always somehow larger than the output: having a baby and a new house is not the same thing! But having a baby can require a new house, amongst other things.
How much concrete does it take to make a happy home? An example should make this distinction between outputs (and projects) and outcomes (and programs). Consider the following scenario: you are building a new house for you family. What you really, really want is a happy home and in the end the options you’re making are the ones that you believe will help you have a happy home. For example, suppose you want a barbecue and a large table on your backyard so you get the entire family together for the weekends because you believe this will provide happy moments. Now your constructor needs to know how long and how much it will take to build your house, he really doesn’t need to know what you plan to do in your backyard he just needs to know what he will have to deliver, not why you want it. And this is the source of many of the problems that arise in such situations and it largely explains why it is expected that building a house will cost more than estimated. The problem is much like answering the question: How much concrete does it take to make a happy home? Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho, www.ahhamoments.net 3
Measuring success One of the key differences listed by the PMI on the previous table is about success. Success is always difficult to evaluate for any given project, right? Some just say “projects are successful if at end the customer is happy”, some say that “projects are successful if they are OTOBOS (on time, on budget, on schedule)” and so on. The timeline is also important: if you evaluate your project when you close the project you’ll probably get different results about its success than if you do it 3 months after you close it. But what is explicit on the table is that a project is successful on some criteria while a program success is measured by its business fit: if the program added business value then the program is successful. Please notice there isn’t a single word about schedule, cost or quality regarding the program success. So let’s think about a project largely not OTOBOS (there are a few tens of public recent examples of large projects that didn’t finish on time or on budget but I’ll go for an older one). Please consider the Sidney Opera House for a moment and before taking a look at the wikipedia try to answer this: was the Sidney Opera House a successful project? The fact is that the project: Costed
14 times more
Took
10 years more
This is not a close miss: the Sidney Opera House didn’t cost close to the initially estimated $7,000,000. It costed $102,000,000 that is over 14 times more! Now just consider this: have you ever missed project objectives regarding cost or schedule by this much? Do you actually know anyone who has? I’m betting you can’t recall nothing like this… Is this an oddity? By no means, no! The Suez Canal was even worst than the Sidney Opera House. The Concorde was pretty much as bad. And for any of these, you can easily double check them online. The thing is: if you’re missing your current project objectives by this much, you will probably be fired, right? So why weren’t these projects canceled? How can this happen to a project? Well, if you ask me, my answer is: these were not projects, they were programs. Why is the difference key? Because in a program your focus is not about being OTOBOS, your focus is on the business return. And, as far I know, the Sidney Opera House was, and still is, largely a business success and also a landmark and a national symbol. For a program, success is linked to the business benefits that it brings and that is a big difference.
Required skills Now, with all the information provided, do you still think that a project manager’s career path should make him/her a program manager? Are the required skills and knowledge of a program manager a natural development of the skills and knowledge of a project manager? Are program managers just project managers that are really, really good? Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho, www.ahhamoments.net 4
Provided the given context, the answer to all these questions is always no. The scenario is similar to the scenario where you have a really good engineer that you want to promote and so you give him a management position. In general, this a a great way to turn a good engineer into a bad manager: the skills required are just different. But what exactly are the skills required? Well, it’s a melting pot, really. But a project manager needs more focusing than awareness, more detail than overview, more technical than political skills, and so on: Projects
Programs
Focus
Awareness
Detail
Overview
Technical
Political
Tactical
Strategic
Objective driven
Business fitness
Analysis
Synthesis
What
Why
I insist than all these skills, if you can classify them as skills, are required both by project and program managers. But there’s no doubt in my mind that a project manager needs more analytical skills than synthesis skills and so on. Bottom line is that the balance I see as required is precisely as the above table.
Take aways Don’t stand taller than what you are There’s this Simpsons episode where Mr Burns checks himself on the mirror and sees a young man, tall, blonde and musculated. There’s this ad on anorexia where you see the reflection of a chubby young woman checking herself on the mirror but, when finally the camera is set on her, you see a skinny young woman (really just bones with skin around). We have this tendency to see things as you want them to be and not what they are. In a way, we’re all anorectic Mr Burns We project managers tend to find that project management should be a requirement for CEOs. We like to think that our career path may start as a systems engineer, it may takes us to be a project manager, a program manager and then we’ll be a CEO on some company. And in some cases, it does. Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho, www.ahhamoments.net 5
But I’m sorry to break it to you, this is not the general case. Of course some project managers will be outstanding program managers, but that will never be the general case. There’s a Portuguese saying that states that “each monkey has its tree brunch” meaning you should now your place and act accordingly.
Focus on what you should, not what you want Just because you’re told you have a project to manage that doesn’t mean that it’s true. Sometimes what you really need to manage is a program and yes, the same thing can be both at the same time, just like building a house is a program to you and a project for your constructor. Recognizing what you should really be managing is the first step to success: at least you get to choose the right tools. Failing to do this would result on using a screw driver for nails.
There is such a thing as a “2 weeks long program with a single project” If nothing else, I really hope that after reading this you’ll let go of the idea that “a program is a set of 2 or more projects”. In fact, programs that consist of just one project are more common that what you might expect. Programs are always somehow larger/deeper than projects but they can be just as short in time. I have managed quite a few really short programs, some as short as 2 weeks. The notion that a program is larger than a project is still valid as a program is never about delivering some output, a program is about getting some output to work in your organization in order to get some benefit. So next time someone knocks at your door and says “I’ve got a project for you” don’t start asking for its requirements. Before getting to that, find out what exactly are you expected to manage: is it a project? Or is it a program?
Part of the Conscious Software Development Telesummit 2014, Luis Seabra Coelho, www.ahhamoments.net 6
