Benefits Realization

Why have a method for a Benefits Realisation?

Won't we get the improvements happen anyway, if we develop the project do as we intend to?

There are many steps between the original envisioning of the benefits that a change could achieve, and finally confirming that those benefits actually were achieved.

Let's face it - we've all been on projects where the work was done, a new system put in, and yet, nothing really seemed to change. Or worse, where a system was created, and put in, and then not actually used.

This partly stems from the fact that the vision may well stem from the process users' management, but the project is implemented by a separate team who are advised by the process users themselves, who then hand the new system over to the process users once ready.

The process users who are handed over to may well be different to those that advised (or formed part of) the project team, and they may well have different management by the time the project completes.

Even within the project team, there may be changes in the project leadership over time. All of these things can lead to a mutation of the vision. Often the benefits of realising the vision are left implicit.

So... this method starts at the 'good idea' stage, (wherever this happens), and seeks to ensure that the benefits intended are documented, and that this stays a live, controlling document (albeit a brief one) throughout the project's development life, and beyond.

This method sits as a wrapper around any project management method you use.

The top level process outline is:

As the project starts-up:

1) Identify the benefits you want to gain

2) Develop the approach you're going to take

Then, once the project is running

3) Keep validating project against the intended benefits

4) Keep the benefits statement current, if the intentions change

As the project goes live,

5) Pass on the responsibility for achieving the gains

Once the project has gone live

6) Reap those benefits

Is this a criticism of process user's interfering with the initial plan, that the original "good idea" should be the only "true" goal. Who is it the software is supposed to aid? Is it the career path of managers and programmers, or is it that the product is UsefulUsableUsed? Who knows better about usefulness than the process user?

CategoryMethodology