Hello,

On the April the 1^st , the Belgian XP user group is organizing the Mini XP Day Benelux 2011 in Mechelen.  One of the sessions I certainly can recommend is “Agreeing on Business Value with Systems Thinking” … because I followed the try-out last year (26/10/2010) at a XP.BE User Group meeting and liked it very much. It was even hosted at Capgemini Diegem  and facilitated by Pascal van Cauwenberghe . You can even look at some of the our results on Pascal’s blog.

“ Getting the “business value” for a feature as good as possible and communicating this value in, for the organization, understandable way.” Hence the title of the session “Agreeing on Business Value with Systems Thinking”.

But what is business value? It became clear during the presentation and exercise that is not always that easy as it might seem at first hand. It’s multi-dimensional and not always easy to express. The key lies in the measurability of things. In order words: How do we know if we are successful with a new capability in our “system”, that we “envision” in order to tackle a problem or dissatisfaction or to “cash” in on an opportunity? How do we know that we get “value” out of it?

The “Business Value Model” is a technique to set the context of the “big” why and communicate this across the organization (small or big). It is build around the concepts we are mostly familiar with ( and borrowed from other techniques); Stakeholder, goal, Capability, Measurement, Risk. The latter is maybe not want you think; It formulates what the risks are when we succeed in delivering the value. Pascal gave an example of a company that wanted to make their billing more understandable and detailed. The identified risk was that maybe some customers would discover that they have been paying too much in the past.

In order to build the “Business value Model” there are number of step (or guidelines) that you use to “connect” the dots. Identifying goals (sub-goals), How to achieve them, who benefits from them, How to measure them, determine which measurements can only be determined late in the game, which can be acquired earlier in the project. The “Systems Thinking” part comes into play to discover relationships between goals, capabilities, stakeholders and measurements and risks. When you turn a knob here, something will happen on the other end…

The exercise that we did to get a feel for what a “business Value Model” can represent took the case of a mobile phone company that needed to get their porting in and porting out capabilities in order to comply with government regulations. Although the exercise only latest 30 minutes and each step was very time-boxed, the different groups produced something. The output needed to be very visual , so we only worked with paper and post-its. This enables the group to move things quickly around and also show the dynamics of the process. A business value model is not carved in stone. You must always evaluate if what is described (or better drawn) in the model actually reflects reality.

This visualization is important for communication but even the process of doing the value exercise can be an eye-opener for the people in the project and/or organization. Pascal gave an example of a session held did where the CEO after the exercise was a little bit disappointed. There was nothing new for him. The other participants where very satisfied: they didn’t know that that was the value strategy of the company. All the knowledge was in the head of the CEO. The exercise “communicated” it to other people.

The “Business Value Model” should also be the origin for all user stories and /or epics (of features, uses case, or whatever artifact you might use that specifies the capabilities). Actually the terms stakeholder, value, capability can easily be mapped toward the user story syntax. Instead of a “vomit of user stories” where maybe too much and potentially unnecessary features are presented, the true value-generating capabilities are more easily spotted and back-up by the sponsors. Pascal gave an example of project he worked on where the initial pack of specs contained 60 user stories. But after the exercise they identified 4 missing that where crucial for the success of the project and most of the identified users stores didn’t provide (much) value.

It is not uncommon to lose track why you are investing in a project. The why is not always explicitly communicated in organization and/or project. The business value model is way to show the “why” of a project and always remind us of it in our decisions and work. So next time you’re wondering why you doing something think about the “why” (Repeat it preferably 5 times  :- ). If you cannot answer this, it’s maybe time to make a business value model for your project.

Thanks for reading,

Alexander

XP