I just received a comment on an old post, Project vs. Program vs. Portfolio Management. This has been a popular post since it was written back in October 2007. The comment read:
I’m doing a research on how do organizations group their projects into programs, please tell me how do they go about doing that. e-mail me as soon as possible.
First off, this is an important question. Second, my blogging philosophy is that if a question is worth answering by email, it’s worth offering on the blog, so others might get into the discussion and benefit from it. Mostly, I reply to a comment with a comment, but when a question is as important as I believe this one is, then I think it deserves a post of its own.
What is Program Management?
Wikipedia covers Program Management well (as usual!) Their simple definition is:
Program management or programme management is the process of managing multiple interdependent projects that lead towards an improvement in an organization’s performance.
Wikipedia goes on to say:
Projects deliver outputs; programs create outcomes. Program management is concerned with doing the right projects, whereas project management is about doing projects right.
These are key distinctions, and begin to get at the heart of the reader’s question above.
Another great reference is from IBM and their white paper entitled Program management: Different from project management. In this, IBM says:
Many enterprise IT organizations are tackling large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers are finding that “traditional” project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects.
This description, like the Wikipedia definition, provides clues to the question posted as a comment in my earlier blog entry.
Beware the Language Traps!
A caveat here – organizations tend not to be rigorous (and certainly not globally consistent) with their use of terminology here. So just because you use the term “Program Management” does not necessarily mean you are doing it. (Nor does the fact that you use the term Project Management mean you are doing that, or that you have Project Managers mean you are actually doing good project management practice!) By the same logic, you may actually be doing great Program Management, even though you don’t use the term. (I have to say, I have never seen this, but it’s possible).
Another language complication is that the term Program Management may have already been adopted by your organization – perhaps with accurate and appropriate usage, but perhaps not. I’ve worked with aerospace and defense companies where the term “program” has a very specific meaning related to government procurement. This is a tough issue, because they are not going to throw out that terminology, so you really need some other terminology to distinguish between those sub-units of work that focus on deliverables, timeframes and budgets (project management) and those collections of mutually dependent projects that collectively produce business outcomes.
So, How Do You Group Projects Into Programs?
This is part art, part science, and frequently involves both top-down and bottom-up planning approaches. The key element is wrapped up in the notion of a business outcome. A business outcome is a measurable result – both in terms of time and quantity – that is significant to business leaders. “We will increase the results of cross-selling our services by 15% by the end of 2009” is a business outcome example. Note, it is specific as to degree and timing. It is also of value to the business – sufficient to drive change, and relatively easily turned into one or more financial impacts.
So, how will be achieve this increase in cross selling?
- We will implement a Customer Relationship Management solution
- We will re-engineer our customer acquisition process
- We will reorganize our sales force
- We will change our sales compensation, reward and recognition model
- We will retrain our sales executives
- We will realign our service portfolio to make it easier and more logical for our customers to buy additional services that cross traditional boundaries.
These changes might involve technology, organizational change, change in HR practices and compensation, training and development, changes to the service portfolio, and changes to our marketing approach. All in all a complex set of changes that are collectively necessary to achieve the outcome. In this case, the program is likely to be the “Cross Selling Enhancement Program” or something similar.
The underlying projects that will be grouped into that program are typically defined by organizational units and their primary responsibilities. The technology changes will be owned by IT, and may include software, data base, and workflow projects (or analysis, design, implementation projects as a different way of breaking things down.) The sales reorganization and process changes will be owned by Sales, the HR changes will be owned by the HR organization, and the service portfolio changes owned by product management. The overall program might be owned by Sales and Marketing, or there might be an Enterprise PMO, that could be part of the IT organization, or a separate entity.
The process I’ve outlined about is essentially top-down – start with the outcome, and decompose into component parts by organizational impact or specialization, form into projects and connect together in an overall program plan. This is ideal. Often, however, things happen much more organically and chaotically. A sales VP gets on a kick about cross selling, but after a few months talking about it and hoping it will happen, decides they don’t have the right tools. She reaches out to Salesforce.com, but fairly quickly realizes she’s going to need help and support from the IT organization. And, as the onion gets peeled back, new layers of complexity and new issues occur, and the number of projects spawned by the desire for more cross selling mushrooms.
Unfortunately, these individual projects have little or no sight into the original outcomes – increase the results of cross-selling our services by 15% by the end of 2009! So, the projects loose sight of the goal (and therefore miss it). They also attach their own “pork” or “earmarks” (to put this in the context of the latest US political debates). “While we are creating our partnership with Salesforce.com, let’s experiment with their platform to bring some social networking capabilities to bear.” “While we are training the salesforce in cross-selling, let’s also teach them solution selling.” While we are cleaning up our customer relationship data base, let’s build a data warehouse to support our business analytics.” And so it goes. All potentially worthwhile ideas, but none of them may be essential to achieving the original business outcome, and may potentially derail or de-focus us from achieving that outcome.
Anyway, in the bottom-up case just discussed, the program may be created by recognizing a growing collection of projects that need to be better connected, coordinated and shaped to meet an outcome of importance. That might mean killing some projects and re-chartering others.
A Question of Governance
So, how do you group projects into programs? Above all, based on the business outcomes you are trying to achieve. Ideally, this is a top-down planning exercise, then a bottom-up governance and control exercise to keep the projects collectively on track to achieve the outcomes. In a less than ideal world, it is first and foremost a governance exercise – you need a mechanism that produces visibility into all the projects going on. That mechanism also needs visibility into the enterprise and business units strategic intents and desired business outcomes, so that it can recognize opportunities to synchronize, coordinate, refocus, delay or even kills projects that are consuming time and resources, but may not be moving the enterprise or business unit towards its stated goals. And, by the way, just as Projects group into Programs, so do Programs group into Portfolios. But that’s a topic for another day!