Just finished Effect Managing IT by Ingrid Otterson and Mijo Balic, a deceptively long read (for its 102 pages). Its dry style makes it feel like it’s been inspired by university textbook writers and it’s a little too prescriptive for me (it provides an agenda for a steering group meeting!), but it has some great points that are worth considering.
What it says
After some standard definitions, it hits on the interesting idea that the ‘effect’ or ‘benefit’ of an IT investment depends on how much the product is used x how good the product is. Implicit in this is that IT projects can deliver less (or I suppose in an hypothetical world more) than estimated depending on these two factors. I think it’s definitely true that IT projects try to focus on the latter point, while quite often disregarding the former point (at least in a B2B world – they’ll use it because they have to!).
I also think that the authors are right to say that IT products are expected to deliver benefit in themselves, without really thinking about what these benefits really are. And that’s where effect maps come in…
With effect maps, you work out your:
- Aim – the why, which is linked to business goals and sensibly, includes measurement points (aka metrics)
- Target groups – the who, which are people grouped by the way they’ll use your product (not just your standard segmentations)
- Usage goals – the what, which define what each group wants / needs / must be able to do (the book provides more detail on the difference between these)
- Actions – the how, which may cover both the IT and the organisational change to accompany it
There’s then a whole chapter on how to structure your teams and your work. But I really liked the three points it focused on under ‘Project work’, as these are quite often overlooked. The first is ‘target group analysis‘ or studying your users. Really useful, as what people really do, is often not what they say they do. The second is ‘interaction design‘. This is all the more obvious in B2C work, but the need for it becomes blindingly obvious when you do ‘usage tests‘. Steve Krug opened my eyes to these and I am still surprised at how silly users are much you can pick up from watching someone use your software for the first time.
As is often the case, the example (why is it in the Appendix?) really brings these ideas to life and stops it being just another framework in a textbook. And as is often the case, the map itself isn’t really that impressive, it’s more about the thought process that goes into producing it.
Does it work?
We tried this exercise at work but used mindmaps instead, and within an hour it provided a lot of clarity. You could clearly see the goals, how they would be achieved and then with some basic prioritisation – based on how well they contributed to the goal, then how long they’d take to build – you’d have iteration goals defined for you.
In summary
It’s definitely not the most engaging book I’ve read, but it does make you think about the wider effect your software is having. Many thanks to Gojko for passing it onto me.
Tags: book review, requirements