« Critical Chain Method (CCM) - A Short Definition
Key Roles in Project Management - Project Sponsor »

How Do You Group Projects Into Programs?

June 7, 2009 | Author: PM Hut | Filed under: Program Management

How Do You Group Projects Into Programs?
By Vaughan Merlyn

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!

Vaughan Merlyn is a management consultant, researcher, and occasional author. His primary focus for the last 35 years or so has been and continues to be the use of information and information technology (IT) for business value creation. Vaughan is an Executive Vice President with nGenera. In that role, he participates in multi-company research projects, consult with Fortune 500 type companies, and provide Executive Education. His blog can be found at http://vaughanmerlyn.com/.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Sunday, June 7th, 2009 and is filed under Program Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

1 person has left a comment

Vaughn I agree with you that top-down is usually the way to go. I have always thought of a program or initiative as a set of projects that roll up to a common set of goals, with common evaluation criteria, which I think of as a kind of portfolio. You provide a teaser to the solution to the disconnect between the projects that commonly happens when you don’t treat them as a portfolio and you stress the need for a common view of all the projects.

Pradeep Bhanot wrote on June 10, 2009 - 3:41 am | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories