Gojko Adzic

I recently came across two books that fit the Building software that matters theme perfectly, and deserve to be read by anyone managing a software project, running a development team or generally serious about delivering software. Both books tackle topics so difficult that development teams often just push the responsibility for them to the customer, expecting some kind of magical resolution.

Developers prefer to talk in terms of value generation without developing related revenue projections. Business stakeholders usually don’t realize that delivery sequences and architectural options have a significant impact on project level ROI. Clearly, software development requires a more financially responsible approach […]. This situation clearly calls for a close collaboration between developers and business stakeholders.

The previous paragraph pretty much sums up the basic idea of Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. Iterative delivery and fast roll-out to production makes perfect sense and I do not think that anyone can doubt that, but can you actually put a value on it? Can you compare two alternative delivery plans for the same project? Denne and Cleland-Huang set to do exactly that. By developing a financial model to evaluate and compare delivery plans, the authors show how to make an informed decision about prioritisation on a project so that it maximises the desired financial effect, either reducing risk, optimising cash-flow or return on investment.

Denne and Cleland-Huang explain how to identify and evaluate the financial impact of Minimum Marketable Features, including “intanglibles” such as brand value or customer retention. Then they develop a system of heuristics that combines this information with technical and architectural constraints, prerequisites and timing constraints to come up with the best possible delivery plan, depending on what you want to achieve. Through several case studies, they show how just choosing the next most important thing isn’t as nearly as effective as considering the financial impact of the entire delivery plan. Somewhere in the middle, they also come up with a way to estimate the financial impact of the project by forces other than black magic which helps us answer a key question: should we do this at all or should we do something else?

Effect Managing It, by Mijo Balic and Ingrid Ottersten, deals with things that happen even earlier in the process – coming up with a list of features to achieve the desired business effect. Instead of focusing on functionality, Balic and Ottersten look at software projects as agents of business transformation. The authors argue that the ultimate goal of software projects is to achieve a business change, and that one of the key reasons for failure of so many projects is that the focus is often on the wrong things. They explain a model of structuring requirements analysis in a way that ensures achieving the desired business effect. That focus on business impact, not functionality or technology, is what they call “Effect Managing”.

Effect Managing shares many key ideas with behaviour-driven development and agile acceptance testing, but deals with things that are much earlier in the development cycle. Balic and Ottersten base their model on first considering who can deliver the desired change (stakeholders in the BDD lingo), then thinking about how these people can deliver it and what the software needs to do to support that that. Organising all these ideas in a hierarchy which they call an “Effect Map”, this model provides visibility similar to the Goals-Features-Requirements model, but in my opinion much more effective because it is visual. After trying out effect maps on two projects, I’m astonished how they open up a discussion and provide structure to the process of selecting the features for a project and probably equally important throwing away features that are less important.

Be warned, though, that both books are relatively hard to read. Although they are short, less than 200 pages each, the flow of ideas in both books is a bit hard to follow. Effect Managing IT at times reads like a literal translation (from what I understand, the original book was written in Swedish) and Software by Numbers is full of financial tables and formulas. Nevertheless, I think that both books have such great value that getting through them is well worth it.

Get notified when I post something new - subscribe via RSS or Twitter!

Trackback URI | Comments RSS