I’ve been told hundreds, maybe thousands, of times in my life, “Roy, just let it go”. Usually I hear this line in the context of me vigorously holding onto a concept in the face of either ambivalence or outright disagreement from a person or group that is less passionate about the subject matter than I. The way I interpret the “let it go” line is someone is tired of the debate and wants it to end, without actually conceding the point. I don’t really like hearing this line because it means I wasn’t sufficiently persuasive, or I’m not understanding the counter view, or someone doesn’t see the importance in the subject like I do - none of these reasons taste good. So be warned, this posting is about one of those things.

I think one of the fundamental reasons many companies struggle achieving value from IT investments (or from any investment for that matter) is a lack of clarity between what is a Program and what is a Project and how the two are managed differently. I see it all the time. The terms Program and Project are interchanged as if they were nothing more than synonyms. When challenged about the difference, most folks seem to settle on Programs being bigger than Projects and add that Programs actually consist of multiple Projects. In essence, they perceive Programs as “Big Projects”.

I agree that Programs often do consist of multiple Projects, but you can’t stop there as so many people do. All major business initiatives have two management needs that are in tension with one another: First, there is the need to be innovative, to discover new and better ways, to be creative, think out-of-the-box with the desire to create additional value for the enterprise. Second, there is the need to be predictable, reliable, meet expectations, do what you say you’re going to do, be on-time and on-budget. These are very different needs. Some organizations just give up on one and focus on the other. Other organizations demand both, achieve neither, and blame their people for being incompetent project managers. But both management needs can be meet by clarifying the difference between a Program and a Project:

• A Program is the unit of management for conceptualizing and ultimately achieving the desired outcomes of a major strategic initiative. A Program usually eventually encompasses multiple projects and lasts for long periods of time. Business justification and executive review occur at the Program level on a continuous basis.
• A Project is the unit of work for creating a specific, predictable deliverable. Whereas a Program may have some ambiguity at its outset and during its life, a Project should have little. A Project is a Project when Project managers clearly understand what is to be delivered and have the knowledge and ability to accurately estimate the resources required to get the job done.

These definitions may sound simple and obvious, but the differences are subtle and important. At the heart is a key difference in purpose: The purpose of a Program is to achieve business outcomes; the purpose of a Project is effective execution of work to create a specific deliverables. A Program is all about conceiving, justifying, creating, and realizing business value. A Project is all about predictable execution. Over time, Programs typically comprise multiple projects with mutual dependencies that collectively achieve the program’s outcome.

Programs Manage Value-Realization

Most opportunities for creating significant business value cause disruptive changes in processes and in organizations and therefore require significant investments of resources and capital. Usually the more valuable the initiative, the more organizational units that are affected. As a result, the roadmap for realizing value from initiatives is typically complex and interdepartmental.

It would be great if all major initiatives could be undertaken based upon an indisputable business case that is not only used to justify the initiative, but also sets up the key metrics that will be tracked when the initiative is completed to determine how well it is achieving its forecasted benefits. But the reality is that not all variables are known at the outset of many initiatives and business cases evolve during the journey. Management has to make choices between initiatives that have high potential but come with high ambiguity versus initiatives with lesser potential but clearer value. In some cases they may elect to try to reduce the ambiguity of a high potential initiative before committing to all the work necessary (i.e., a “proof-of-concept”).

So a Program is the unit of management of an important initiative. Its purpose is to realize business value. It is usually complex and often interdepartmental. At its core is a business case that evolves over time as uncertainties are reduced or eliminated. It may begin with some ambiguity, which may need to be reduced before the clarity of the business case reaches a point that decision-makers can invest in it confidently or at least with an eye to risk and risk mitigation. Whatever ambiguity a Program experiences should be associated with activity out in the longer-term horizon. In contrast, activity planned in the near-term of a Program should be well-defined and more predictable.

A helpful characteristic of Programs is that they are comparable at the level of investment decision-making. You can compare business cases, level of business risk, intensity of resource consumption, and anticipated business value. You can compare these things at any stage of a Program’s lifespan. This characteristic makes Programs an excellent consolidation point for governance and executive oversight on a continuous basis. Comparison at the program level is also more manageable in terms of sheer volume. Imagine an executive governance body having to weigh decisions and priorities among 150 projects versus 10 major programs.

Projects Manage Predictable Execution

Whereas a Program may have some ambiguity or uncertainty at its outset and during its life, a Project should have little. A Project is a Project when Project managers clearly understand why the project exists (its objectives), what is to be delivered by the project (its deliverables) and have the knowledge and ability to accurately estimate how the deliverables will be produced and the resources required to get the job done (the work-plan). For this reason, Projects should be structured to form, execute, and disband in highly defined periods of times (months, not years) while requiring a small number of identified resources (a few, not dozens). A Project that takes multiple years and dozens of resources is not a predictable construct. Something that is predictable is capable of being estimated, which implies that estimating heuristics are captured and available in our collective knowledge. Projects are estimated based on proven statistics, not guesses that include massive “fudge-factors” to masquerade as logical estimates.

Projects that are predictable improve the health of the enterprise in several ways. First, accountability for execution is well-established to someone that has the ways and means to be successful (e.g., a Project Manager). Second, portfolios of activity and resource allocation can be better managed when costs and dates are consistently met. Third, pride-in-workmanship becomes a constant motivator as team members move from one success to another. A virtuous cycle is created that fuels itself as individuals grow through success rather than rationalize failure. Finally, predictable Projects remove the otherwise implied necessity for constant review and oversight at the Project level. With predictability comes trust in Project execution, and that trust allows management to focus on the bigger picture: achieving the optimal business value from a portfolio of investment options.

So, are Programs a lot more than just Big Projects? Or should I just let it go?