Benefits Management

Last week I was contacted by a man who wanted me to help his company write better requirements specifications. I suggested that writing better specifications probably would not help, but that there were other things they should try. This was not a very smart thing to say. When you are trying to improve something, the last thing you want to hear is that you are trying to do the wrong thing better…

A couple of days later I listened to a talk by Joe Peppard about Benefits Management. Joe is a good speaker and argued compellingly that the most important thing to do before starting a project is to define what benefits you are aiming to achieve. A new system is worthless until you actually put it into use in a meaningful way. Once the stakeholders in a project agree on the benefits that are going to be pursued, it is possible to follow up that the project actually realizes these benefits. Unfortunately, Joe was not very familiar with agile development. He seems to see the development of a system as an isolated event that can be managed with traditional methods such as Prince 2. This is a mistake since one of the biggest advantages with agile is the ability to incrementally put things into production and thereby get early feedback on whether planned benefits will be achieved.

And then there are unplanned benefits, or positive side effects if you will. Joe mentioned these and stressed that one should try to identify and take advantage of unplanned benefits. Again, an agile approach allows you to identify unplanned benefits earlier. In some cases unplanned benefits can be so important that you end up focusing later development more on these benefits than some of the benefits that were in the original plan. This incidentally is just one of the reasons traditional requirements specifications are so harmful. When everyone is focused on fulfilling a requirements spec, unplanned benefits will often be seen as a nuisance.

Niklas Björnerstedt

Posted on 2014.09.11 at 12:30

Comments are off for this post.

2 Responses to Benefits Management

  1. allan kelly says:

    Yes.
    Since reading the Benefits Management book I’ve tried to replace “Value” in my vocabulary by “Benefits.”

    Benefits Management deserves to be better known in the Agile community. And the Agile Community deserves to be better know in the Benefits Management movement.

    The book is well worth reading but is also frustrating because of the underlying – and repeated – assumption that delivery is more or less a simple matter of coding and something like Prince2 is perfectly adequate.

    In reality delivery and discovery are interconnected, we simply don’t know the problem we are solving until we start to understand the solution. Benefits Management needs to be applied all the way through the delivery effort with requirements and specification constantly challenged for benefit!

  2. smalltalk80 says:

    Yes, I agree completely. The agile and benefits management communities should see each other as complimentary.

……….

About Niklas

Born in Sweden, grew up in New York, lives in Norway. Yes, I have problems with identity, but I do think that my background helps me see things from a different perspective.

Read more