Delivering business goals, not just software features

Commercial organisations across the European Union lost 142 billion EUR on failed IT projects in 2004 alone, mostly because of poor alignment with business objectives or business strategies becoming obsolete during delivery. This is roughly the cost of the International Space Station programme, including all flights, or almost twice the cost of the entire Apollo programme, which achieved six manned landings on the Moon.

Software is everywhere today, and countless software products and projects die a slow death without ever making any impact. Clearly, current practices in the IT industry for managing project goals and communicating requirements fail to deliver business outcomes horribly. This is not a problem only in IT. Studies of military commanders and tank platoon leaders in the US Army show that giving answers to ‘what’ and ‘how’ does not prepare individual teams for reacting to unforeseen problems. Yet this is exactly what most software requirements models communicate. Explaining ‘why’ and ‘watch out for’ is much more important in a fast-moving landscape such as software delivery.

Impact maps facilitate this process, taking it even further. Instead of just connecting features to goals at the start of a project, impact maps allow us to maintain a dynamic roadmap that changes with our learning, keeping the goal in mind and making features and scope secondary to it. We visualise assumptions, which allows us to change direction once these assumptions are proven or discarded.

The online gaming system example shows that the purpose of semi-automated invites is to support players inviting their friends. We assume that delivering that feature will change players’ behaviour. Once the feature is delivered, we can track if the assumption was true or not. If players invite friends, we can keep investing in that branch. If not, we should stop, analyse the situation, and try to do something else about invitations.

The map also shows a higher level assumption. If players send out invitations, we assume that their friends will actually come to play our games. After each deliverable is shipped in the invitation area of the map, we can measure if new players are responding to invitations at expected rates. If yes, we should continue to expand that area. If not, building more ways for people to send out invitations would be wrong. We should re-think our strategy, find a way to improve invitation results or perhaps do something else.

Finally, by mapping deliverables to a business goal, impact maps strengthen the case for limiting the number of business goals and impacts we work on at any given time, in line with the idea of limited work in progress from lean development methods. I ask people to select only one impact at a time and focus on it until it is delivered.