Project Management in IT: Projects and Programs
I’ve recently noticed several discussions about the viability of using a project-based approach in IT. I want to counter the “haven’t seen it work, it never will” narrative with a few things I’ve learned from experience. This is the first in the short series of posts on this topic. If you are a vehement believer in the inherent evil of projects though, and nothing could ever change your mind, then feel free to close the tab. You already have the answers. There, saved you six minutes.
Levels of governance
Let me quickly set the context. As a rule, projects do not exist in isolation. The way project managers are taught separates three layers of governance. At the highest level, you have a portfolio. This is where money is allocated across various initiatives in the organization to achieve strategic business objectives. The next level is a program, which consists of one or more projects, and focuses on achieving specific business outcomes (sometimes referred to as benefits). And the third level, as you probably already guessed, is a project, which focuses on outputs (often referred to as (work) products). Although project managers do also learn about product management, it rarely receives significant focus.
In the context of this article, when we talk about projects, we talk about initiatives that have a defined start and a defined end. Projects are always temporary.
Every organization needs to decide whether they would benefit from having a full-blown portfolio-project structure, with all those teams (and meetings, and reporting) in place. A smaller organization might not get the full benefits of a corresponding organizational hierarchy, but they would certainly benefit from answering the strategic questions each of these levels poses.
Most of us who have worked in IT have seen projects fail — often spectacularly. There are many things that can contribute to project failure, and in my experience, it’s rarely the project team, working within the constraints that have been set for them, who “hasn’t done their job”.
Are you sure you know why you’re doing this?
A project should be initiated only when it is clearly known why it is required. This might sound simple enough, yet not having a clear answer to this is one of the most common reasons for project failure.
What we usually see defined for a project is what outputs it needs to deliver, how quickly, and for how much money, with additional constraints around expected quality. These constraints — scope, time, and cost — form the ‘project management triangle’ which, when managed poorly, can become a triangle of death for any project. The oft-made mistake is focusing only on these three aspects when explaining the reasons for initiating a project. In truth, understanding these can only answer the “what”, not the “why”, yet it is not uncommon to see (painfully lengthy) business cases with a lot of focus and detail on this “what”, but justified only with “We plan to do X because X is needed”. Raise your hand if you’ve ever seen one.
The most common missing aspect in unsuccessful project management is a lack of understanding of, and focus on achieving expected business outcomes. Every project that has been assessed, approved, and initiated needs to contribute to achieving business outcomes. The problem is that very often, the project team does not know what these outcomes are supposed to be, and this poses a significant challenge for successful delivery.
Throughout the life of a project, various decisions and trade-offs need to be made to navigate the uncertainty of the project environment. There’s always a pressure on the timeline, and on the budget, while the scope creep makes sure it never gets boring. Yet none of this is even relevant if it has become unlikely for the project to support expected business outcomes. How would we know?
The missing layer
The tolerances for time, cost, and functionality for a project can and should be agreed at the outset. These will contribute to an ongoing re-assessment of whether the project is still a reasonable investment. But, having only these as the assessment criteria will make it very difficult to close a project (or seriously intervene) when circumstances have changed, and the agreed outputs of the project are no longer needed. It is important to assess whether the project is still likely to contribute to the expected business outcomes — and this is not necessarily the project manager’s job to figure out.
It is program management, as a layer of governance, that is responsible for ensuring that specific individual projects contribute to expected business outcomes. While keeping to the project schedule and scope and not exceeding costs could deliver a product as expected, the “point” of that product is understood in the context of a program.
If that level of governance is weak, then in the world of IT, it becomes nearly impossible to deliver a successful project — it’s almost like you can’t win. When the tolerances have not been agreed, the project either spins out of control for cost, time, or scope, or will be effectively ground to halt as every change to the cost, time, or scope has to be reviewed by a committee. And when the expected business outcomes are not clear, then even if the project keeps to the ‘triangle’ constraints, it delivers an output that will not be used as expected, if at all. And in these cases, the project’s success criteria are often linked to the hastily “defined” outcomes, and the goalpost for success is retrospectively moved way beyond the reach of the project team. Fail/fail.
Focusing on business outcomes
If you have experienced similar situations, then in terms of governance, it means that there is effectively no program management in place. There might be a number of ceremonies that are grouped under something that is officially called ‘program management’, but in these cases, a program usually just refers to a number of projects, and does not talk about expected business outcomes. In these situations, ‘program’ essentially becomes a collective noun to describe a group of failed business decisions.
An organization does not necessarily need to have a discrete layer for program management, but if the burden of delivering to both expected outputs and expected outcomes is on individual projects, this needs to be made clear before the projects are initiated. There also have to be mechanisms in place to continually assess and re-assess the viability of the project against both the ‘triangle’ and the most recently stated expected business outcomes, and a way to close projects based on this information, if required.
This combined approach (i.e. making individual projects responsible for delivering expected outputs and expected outcomes) can be tricky, because with many projects, the outcomes can only be achieved over time, sometimes long after the project has been closed — which leads to an awkward phase between project work and ‘maintenance’, where several teams could be considered accountable for the success of the project at once. It also takes an overly deterministic view of the relationships between one project and the success, in terms of business outcomes, of a group of initiatives, which might produce comforting reports, but reveals little about what really happened.
If any of this sounds familiar, and you have been struggling with projects in IT, then I suggest you check who is tracking the achievement of expected business outcomes, and how do projects currently fit in that model. You personally might not be in a position to directly steer the strategic portfolio-level decisions, but if you work as a project manager, make sure the “what” and the “why” are both answered for all your projects. Win/win.
