The Art and Science of Grouping Projects into Programs

groupingI 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, 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, 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!

About these ads

Why a Good Business Case or ROI Analysis Doesn’t Ensure Value Realization

business-case-mouseI find that most companies I work with nowadays are pretty good at insisting that business requests for IT solutions are accompanied by a robust business case that surfaces all the costs (including total life cycle costs), expected return on investment (ROI), risks, mitigation strategies, and so on.  They have good business case templates, and often associated tools to facilitate the development of effective business cases with a consistent ‘look and feel.’

Beyond the Business Case

These things are all necessary, but are woefully insufficient to drive value realization.  In fact, they can be a trap, creating a false sense of security.  “We’ve done a solid analysis of the business case, so now we can just blaze ahead with the system and the results will naturally and inevitably follow!”   Wrong!!! It’s quite likely that the results that do follow bear little, if any, relationship to the business case.

Seven Steps to Value Realization

There’s a level of analysis, engagement, measurement, control and accountability here that is essential to driving business value and that does not automatically come along with business case development.  So, here are some techniques I recommend to help ensure value realization, not just project approval.

  1. Be deliberate and explicit on the language of ‘business case’ versus ‘value realization.’  Whether you use those terms, or other terms, differentiate between things you do/artifacts you use to analyze a project’s or program’s merits and risks, versus those things you do to drive value realization.  They are both critical to success, and many more people do the business case well than do value realization effectively, which is a shame – leaves lots of money on the table!
  2. Get really clear on costs and value and accountabilities for each.  Each accountable party should be a party to the value realization plan, and sign up explicitly for their part.  See my earlier post, Lack of Accountability – Who’s Dirty Little Secret?
  3. Don’t limit value realization to financial return.  Get explicit about the “value system” at play in your organization.  ‘Time’ may be an important value (e.g., this will reduce new product time-to-market from 6 months to 4 months through…). Quality may be an important value (e.g., this will reduce defect rates from 1% to 0.25% within 12 months enabled by…)  Employee engagement may be an important value (e.g., this will increase overall employee engagement scores as tracked in our annual engagement survey from 85% to 95% within 12 months due to…)  As long as it is an important value, and can be quantified in terms of degree and time frame, and can be measured, it is meaningful to value realization.   Even if you can’t predict with accuracy or precision what a 10% increase in quality is worth, you can measure it and learn the relationships between intermediate outcomes and financial implications over time.
  4. Figuring out the value system and the outcomes and intermediate metrics and goals is not easy.  Therefore, it is a great opportunity to engage a broad audience of stakeholders in figuring the metrics out.  This not only ‘spreads the load’ but engages stakeholders in the value realization conversations.  Sometimes, it surfaces problems and opportunities early on, while there’s time to do something about them.  For more on this, see my earlier post on Measuring the Business Value of IT – Where You Can Win by Simply Trying.
  5. Once you’ve figured out the outcomes and intermediate metrics, create the measurement plan and document it as part of the program.  I don’t favor post-implementation audits as the primary vehicle for value realization assessment.  Audits are good for lessons learned, but value realization is so important, it is better if you can build the instrumentation into the implemented solution.  The difference is like designing cars where you have to get out every now and again and dip a stick into the fuel tank to figure out how much gas you have (bad), versus designing a fuel gauge into the car (better) versus designing a widget that tells you how many more miles you can travel and that sounds an alarm when you are 50 miles from empty (best).
  6. Implement the measurement plan, and take measurement seriously!  Get a senior executive sponsor who’s going to pay attention to this.
  7. Ideally, find ways to ‘close the loop’ between measured realized value and individual and/or group rewards and recognition.  This need not be money in someones back pocket – there’s tremendous power in an internal newsletter or collaboration hub celebrating the success of value realized through a system, and congratulating those associated with the program.

If all this sounds simplistic, it is – deliberately so.  I find people obsess over false precision and accuracy, rather than see this whole exercise as on of learning and growth – of driving the right conversations to increase understanding of and commitment to value realization.  Keep it as simple as you can, especially to get started.  Once you’ve got some momentum going, you can get more sophisticated if you feel the need (and the value!)

You’ve Got Information Technology Questions? We Have Answers…

athinaAs an IT professional or IT leader, do you find yourself with questions or issues you’d like to get opinions about?  Of course you do.  As a consultant, researcher, educator and author, I get questions all the time.  For me they are my oxygen.  If the questions ever stopped, well, I frankly don’t know what I’d do!

At the risk of coming across as arrogant, after 15 months of blogging and 166 posts, I sometimes find myself opening up my blog and entering a search term in which I’m interested in the search box in the banner, and using my own blog to remind myself what I’ve written about, or that others have commented on regarding that topic.  Often, the search comes up with some useful information – sometimes with some helpful link or insight.

So, here’s a suggestion – next time you have a question, or a topic of interest related to IT organization, governance, value realization, architecture, ITIL, CMMI, or emerging leading practices, give my blog a chance.  See how it holds up as a repository of useful nuggets.  Let me know – if it works for you, or if it let’s you down.  Let me know how to make this blog a more useful resource for you.

How Many “Top Priorities” Does Your IT Organization Have?

flowersA recent client experience reminded me how IT leaders in lower maturity shops love to show off their extensive project lists – it’s almost like a badge of courage!  The bigger the list, the better!  It’s as if, “The busier we are, the more we are doing for the business.”  I’ve found over the years that the busier the IT shop seems to be based on the size of the project queue, the less satisfied tend to be IT’s business partners.  While IT leaders tout their extensive project lists, the business partners complain that “IT costs too much and delivers too little!”  How can this be?

There’s several things wrong with the picture characterized by long project lists:

  1. First, long project lists typically reflect an IT organizational tendency to think in terms of “projects” rather than “programs.”   Projects reflect an IT-centric view, focused on work effort, budgets and schedules. Programs, on the other hand, at their best represent packages of interdependent projects that collectively deliver business outcomes of importance – programs represent a business view, one that is more oriented to value delivered rather than the typical project orientation work effort, budget and schedule.
  2. Long project lists typically do not lend themselves the to clear alignment with business strategy and strategic intents.  Programs stand a far greater chance of achieving that.
  3. I’m always suspicious of huge lists (often hundreds) of projects as a representation of the work of the IT organization.   They often reflect a “everything is top priority” mindset, and from my experience over years of consulting, are symptomatic of a confused management agenda.

Hopefully, one of the by-products of the current recession is that IT organizations will have every reason to get focused on “the few really big things.”  How does your project list look?  Would your business partners recognize how it aligns with top business priorities?  Does it make your organization simply feel busy?  Or, does it make it feel valuable?

The “Unwritten Rules” of Project, Program and Portfolio Management


Among the most popular posts on this blog is that of October 15 on Project vs. Program vs. Portfolio Management.   Less popular (but give it time…) have been my posts of the last couple of days on Unwritten Rules of Business-IT Maturity.  I want to use the latter to illustrate the former, and some of the dysfunctionalities common to Level 1 and Level 2 Business-IT Maturity

I’ve argued before that Project Managementis a ‘foundation discipline’ primarily concerned with producing agreed deliverables, according to an agreed time-frame and within an agreed budget.  (I know this is an extreme simplification, but bear with me – there are more important points to make than nitpicking the details of project management practices.)   I’ve further argued that Program Managementbuilds on this foundation discipline that is primarily concerned with managing groups of inter-dependent projects in order to deliver agreed business outcomes.  As such, program management is outcomes focused, rather than deliverable focused, and is concerned with project inter-dependencies.

So, here’s an example of Unwritten Rules that drive Project Management behavior, but not Program Management behavior:

  • “Whatever you do, make sure you deliver on-time and within budget, and you will do well.”
  • “You’ve got to balance scope, time, resources and quality – to be successful in this organization, never let time or resources exceed budget, and don’t drop quality.  If something is going to give, let it be scope!  You can always fill in missing scope in a later release.”
  • “Installing the software is our job – keep focused on that – anything else is a distraction, and is beyond your control.”
  • “Never let a project fail – it will be the end of your career here!”

Let’s compare these rules with the kind of unwritten rules that drive behavior in an organization with a strong focus on program management:

  • “The business outcomes determine scope and define success – if you partner with the business folk, and work towards achievement of those outcomes, you will be successful and will be recognized for it!”
  • “If you believe that the program you are leading is not set up for success – i.e., is not going to deliver on its business outcomes within the available budget and resources, you have to speak up and confront the program sponsor.  Silence is not an acceptable behavior.  Meeting deliverables deadlines and budgets is worthless if we are not realizing the business outcomes!  Killing a program that is not going to deliver on its outcomes is a valued behavior here!”
  • “Everyone understands that project estimating is an uncertain activity.  Don’t take shortcuts to meet unrealistic deadlines.  The business outcomes are everything, and if the program is sponsored properly, and you have frank and open dialog with the sponsor and the team, and raise issues as soon as they are recognized, then estimates can be legitimately revised in the light of experience.”

For all of the Project Management training, certification, investment in sophisticated tools and Project Management methodologies, the Unwritten Rules first listed above are the ones I see most frequently, leading to poor project performance, low realized value from IT investments, and a generally weak relationship between IT and the business it serves.  Where I’ve seen the second set of Unwritten Rules – those more commonly associated with Program Management behavior, I’ve seen an organization that is either at, or is heading towards Level 3 Business-IT maturity, and enjoying high realized value, and a mutually productive and satisfying business relationship.

Take a moment – talk to some of your more experienced project leads, have them read this post, then ask them candidly (anonymously, if necessary) to describe the “Unwritten Rules that drive project behavior.”   Are they what you would want?  Are they what your CEO would hope for?  Would they delight your CFO?

I’ll take a similar look at IT Portfolio Management in my next post.

From ‘Supply Constrained’ to ‘Value Constrained’ Business-IT Model

One of the difficult paradigm shifts that tends to trap IT organizations in Level 2 Business-IT Maturity is the notion that business demand must be constrained by IT supply.  Demand always exceeds supply for IT capacity, so the idea (part of the Level 1 experience) is to set a limit on IT supply, then figure out some way of prioritizing demand against that supply capacity.  Sometimes the the constraining mechanism is IT budget, other times it is IT headcount – either way, the net effect is the same – a bunch of work that the business wants won’t get done, and we hope the prioritization mechanism works sufficiently well that the “right” demand is flowing through and getting address, and the “wrong” demand (low business value) is not.  I’ve rarely seen this work well.

If there is a single line of business, at least demand can be prioritized across the business line, and the mechanisms to achieve this are not too hard to implement.  Typically, however, there are multiple lines of business, and while the mechanisms in each business line may work ok, there are rarely effective mechanisms across lines of business.  This leads to all sorts of dysfunctionality, especially as the enterprise matures and shifts towards more of an integrated business, with common and shared process, compared with the more functional and stove-piped model typical at Level 1.

For example, IT resources get “walled off” against business units – sometimes actually being embedded in the unit.  There’s nothing inherently wrong with the embedding – certainly some IT capabilities (such as Relationship Management) work most effectively when they are really close to the business).  However, when analysts, designers, developers, testers, etc. get “walled off” for given business units, they are no longer available to be shared across the enterprise – they creates all sorts of inefficiencies.  And, from my experience, with the best will in the world, and with competent, well meaning people both in IT and the business, demand will fill that available “walled off” supply no matter what.  A result is that lots of relatively low value and non-essential demand gets filled, while high value demand, both within the business unit with the walled off resources, and in the other business units sits in a backlog (at best) or, more typically, just does not get surfaced because people know there is no hope of getting it filled.  A symptom of this is an IT organization with literally thousands of active projects, mostly small, and with a general sense that IT costs a lot of money and delivers little value.  Such an environment presents all sorts of challenges to real business-IT strategic alignment.

The big breakthrough comes somewhere in Level 2 where there is a shift from this supply constrained model to one that is value constrained.  Let me first describe the theoretical end state of the value constrained model – we will explore the practical realities of moving to this model later on.  At the theoretical end point, IT supply is treated as an infinite resource that can flex its capacity on demand – ramp up to meet high value demand, ramp down when that demand goes away.

The key enablers to move to this model (once the paradigm shift is understood and desired) are to:

  • Prioritize demand based upon business value (which has all sorts of implications for business cases, cost and value accountability, value measurement, portfolio management, etc.)
  • Create an agile and flexible supply capability (which typically means there is a robust global sourcing strategy and management model, key partnerships with global sourcing entities are in place, and the IT organization has become focused exclusively on “core” IT capabilities – usually encompassing relationship management, demand management, value realization, business process improvement, innovation, program management, portfolio management and global talent sourcing.)
  • Add an IT Program Management layer over IT Project Management
  • Add an IT Enterprise Portfolio Management layer over IT Program Management
  • Elevate IT Architecture to Enterprise Architecture
  • Implement an effective business-IT governance model to facilitate cross enterprise and cross business-IT decision making.

I will explore each of these enablers in subsequent posts.

Project vs. Program vs. Portfolio Management

I mentioned in the last post the shift from project management to program management as one of the many important shifts in business-IT maturity that typically take place around the middle of Level 2 (in a simplified 3-level model).  I want to explore that in greater detail in this post, and connect it to Portfolio Management which I see as a key discipline in getting to Level 3, and to extracting high, visible business value from IT investments.

A recent post, Programs are More than Just Big Projects, by colleague and friend Roy Yougman in his blog inspried me to discuss Program Management as a critical link between Project and Portfolio Management.  In a simplified sense, project management deals with a single project (be it small or large) with a focus on producing agreed deliverables, to an agreed schedule and budget.  Program management deals with multiple projects that collectively produce an agreed business outcome – i.e., they have inter-dependencies (e.g., impact the same group of stakeholders, each contribute to achieving a business outcome, and depend upon each other to do so).  It is the management of these inter-dependencies against the delivery of the agreed outcomes that distinguishes program from project management.  I have to acknowledge that the terminology here, though well defined in the project management literature and sources such as Wikipedia, is not universal or used consistently.  In the aerospace/defense industry, for example, programs have a different connotation more related to funding.

If projects can be thought of as the bottom of a hierarchy, programs sit above them in the middle of the hierarchy and address a related set of projects, then things get to be most interesting at the top of the hierarchy – the portfolio management level.

My favorite source on IT Portfolio Management are Prof. Peter Weill and his co-author, Marianne Broadbent.  Their first book that addressed this topic was Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology.  There are various IT portfolio models around – the reasons I like Weill’s are:

1. It differentiates the IT investment in common, shared infrastructure (broadly defined).

2. Weill has years of benchmark data showing how portfolio allocation varies by industry, and how it reflects business performance.

As I get personally closer to retirement, like many boomers, I give increasing attention to my (meagre!) personal investment portfolio, which makes personal investments and portfolio theory a great analogy for IT investments.  My portfolio goals have changed over time as my circumstances have changed (e.g., putting a kid through college, getting closer to retirement).  Whatever those circumstances, I’ve had the discipline (thanks to an investment advisor) to annually re-think my portfolio strategy, to be explicit about it, and to monitor the performance of my portfolio against that strategy, and adjust periodically.

In the IT portfolio domain, the same is necessary.  How much of our IT spend should be leveraged across the firm?  (By the way, a common challenge is the funding mechanisms for common infrastructure are often weak – another Level 2 trap is that funding in Level 1 and early Level 2 tends to be by the project, and for given business units – nobody likes to fund cross-business unit initiatives!)  How much should we be spending on “risky” but potentially high value initiatives?  How much on informational (business analytics/decision support)? 

Another Level 2 trap is that a firm’s earliest entree into IT portfolio management is typically limited to new spend.  However, the reality for most enterprises is that new IT spend represents less than 30% of total spend, so there is bigger value in applying IT portfolio management to the steady state services (bringing us back to Service Management mentioned in an earlier post)

My key points through all this are to get through Level 2 to Level 3:

1. You need great project management as a fundamental discipline.

2. You need great program management as a bridge to portfolio management.  You can’t easily go from project to portfolio – there are just too many projects, and projects are focused on deliverables, whereas program focus on business outcomes – which is what portfolio management needs to focus on.

3.  The biggest impact in terms of advanced IT practices comes from portfolio management (the IT investment strategy), and if you are weak in project or program management, you will never get the full potential of portfolio management.

More on the Sticking Point

As I get ready for a week’s vacation in Aruba (lots of Scuba diving and time with my family!) I want to explore a couple of more aspects of the “sticking point” that I see IT shops bogging down in as they mature from Level 1 business-IT maturity towards Level 3.  The sticking point is at the inflection point in the middle of Level 2.

I talked in the last post of the shift in Enterprise Architecture from an IT-out, bottom up perspective, to a business-in, top down perspective.  This is the type of shift that does not work by just “working harder at EA” or by throwing more resources at it – it takes a significant shift in approach.

Getting out of Level 1 into Level 2 is mostly about rigor and process discipline.  Process Management, CMMI and ITIL are the types of formal disciplines that bring order to the chaos of Level 1.  These all make sense – in fact, are essential (these, or similar process methods) especially given that much of the work of maturing from Level 1 is about cleaning up the IT infrastructure (“getting the trains to run on time” or “keeping the lights on” as the metaphors go) and implementing enterprise solutions (ERP, for example).

The trick in getting through Level 2 and to Level 3 is not so much to throw out the disciplines that got you out of Level 1, but to apply it in a much more selective and gentle handed way.  The types of business problems and solutions that are common in the higher reaches of Level 2 and dominate Level 3 are more about business experimentation, and less about rigorous formal specifications and requirements management.  While project management continues to be a foundation skill, program management and IT portfolio management become key in Level 2 and the Scientific method becomes an important alternative to requirements management.