A common distinction made between projects and programmes is that projects deliver outputs (things) whereas programmes deliver outcomes (benefits). I think this is a dangerous separation, particularly in digital projects and programmes today.
The view is most evident in the Managing Successful Programmes (MSP) approach, which has been long advocated by the UK government. But it’s not just confined to that—you can read this blog post from the APMG, too. Wikipedia says:
According to the view that programs deliver outcomes but projects deliver outputs, program management is concerned with doing the right projects. The program manager has been described as ‘playing chess’ and keeping the overview in mind, with the pieces to be used or sacrificed being the projects.
The problem with this approach is that it makes the assumption that the world moves slowly, and it sanctions long feedback loops. In other words it assumes that you can decide that a particular project makes the right contribution to the programme, set it in motion, and then reap the rewards when it delivers its outputs. But this view is hardly acceptable now that our context is much more global, and the most successful companies and individuals respond and react much faster than they did 20 or 30 years ago. It is no longer acceptable to set a project in motion and passively measure the benefits at the end. It is not even acceptable for the programme manager to continually track how the project aligns to the benefits.
Instead it must be central to the project. We need to ensure that those running our projects are working towards the end benefits (the value), even if they are doing it by means of delivering a particular output. By having that context—and indeed that accountability—those involved in a project can continually make well-informed judgements that produce the best outcome for the programme as a whole.
Here’s a concrete example. Some time ago I was talking to a project lead who was aware both of the outputs she was supposed to deliver and the benefits expected. The output was a set of products; the benefits were around saving money. She said this: “I’ve heard a lot more recently about delivering all the products, and not much about making the savings. If I was really going to focus just on delivering the products I’d be lining up very different work.”
Her point was that either way she would deliver the products, but they would look very different if she had to aim for “more products” (or “better-used products” or “more fully-featured products”) than if she was going to aim for “a product set which saved the most money”. If she didn’t know better she would deliver a successful project and—as a result—fail the programme.
Unavoidably projects—and programmes—need to produce things. But the purpose—the value, or benefits—of those things need to be front and centre at all times. Only then can we we maximise the chances of delivering the benefits, and minimise the chances of discovering too late that we’ve missed some opportunities along the way.
niksilver.com 