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.