Friday, January 3, 2014

Projects and Programs Objectives

I'm usually responsible for the business benefits related to the projects I manage. This means that I have both to deliver whatever we're building in the project context AND to make sure that the business realizes the benefits the project was supposed to bring in the first place.
The thing is: why is this distinction so important between the project results and the business benefits? What are the impacts of one and the other? Which is best? And what should you do in your particular case?


So what's the difference between delivering a project result and delivering a business benefit? You can map these 2 to outputs and outcomes as in "The art of implementing ideas". In short, an output is something that you build and an outcome is why you want that output for. An example may make this distinction between outputs and outcomes more clear and easier to understand.
Suppose that your company needs to improve sales. Now, one of the things preventing this is the control over sales: although sales are budgeted, the actual sales are only known for the previous month, which is too late to take effective corrective actions. Even worse, the current company's ERP doesn't have the functionality to deal with sales budget so that information is in a spreadsheet that has to be updated with the sales information every month. But it gets even worse: as the information is stored in spreadsheets that are communicated mainly by email, each person involved ends up with her own version of the file - and the figures in those files are not always the same, so endless arguments on who has the right figures keep going on and on. Net result: besides having a large delay on the information, updating it is a decentralized process that is time consuming.
So what your company needs is to improve sales: improving sales is the business need (or the outcome). But in order to do it you have to improve the control over the sales budget. So you company decides to migrate to another ERP, one that covers all the functionality from the ERP that is currently in use in your company but that also has the functionality to deal with sales budgets. A project is about to start to deal with this ERP migration and naturally, the deliverable (or the output) is the new ERP.

The difference

There are several levels between what the project and the output is and why the business wants this project or this particular outcome, but there are always at least 2 levels:
On the side of the output you have simpler project deliverables (stuff that either works or doesn't work). For instance, a software migration. like in the previous example.
On the side of the outcome there's the business benefit of the outputs your organization is producing: why does your company need them, what will the business benefit from these outputs, how will they be realized and how can you be sure these benefits are in fact realized. Notice that when compared to this, migrating some piece of software has to be considered simpler, doesn't it?

Projects and Programs

So what is a program? The Project Management Institute, in their "Standard For Program Management" (3rd Edition) defines a Program as "a group of related projects, subprograms, and program activities that are managed in a coordinated way to obtain benefits not available from managing them individually".
So a Program can include:
  • Projects
  • Programs
  • Non-project related work
And the key for the distinction in terms of objectives is the "Non-project related work": why would you need it? The main reason is that you want to integrate the project outcomes into the business and make sure the business benefits from them!

Objectives again

It's just like safety: besides having low crime indexes, people have to feel safe. Now feeling safe has to do with other things than how safe people actually are. For example, flying is safer than car traveling, but people feel safer in a car. So in projects your concern is focused on crime indexes and in programs your concern is focused on how safe people feel. Does this make sense to you?
We could enter another level of discussion with this next example, but please consider for a moment cost reduction projects. Have you ever noticed that if you have to spend some money in order to save a lot of money seems less attractive than if you save same money with no spending at all?
The point is: when you deliver from a Project, you want to deliver safety. Outputs. Period. When you deliver for a Program, you want to deliver "feeling safe" on top of safety outputs. "Feeling safe" is your outcome. Huge difference!


Although you can be responsible for business benefits in a project, just like in my case, the truth is what you're doing is managing a "one project program". My argument? You always have to consider non-project related work in this scenario, even if you integrate in your project plan measurement of the business benefits and so on.
When you're managing a project, you're delivering outputs, simpler things. When you're managing a program you're integrating these outputs into the business, you're aiming for the outcomes. If you understand this difference than you're bringing project success closer to you, wouldn't you agree?

Posted by

1 comment:

João Virott da Costa said...

Very good article! Congratulations.