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.

14 letters and 5 weeks later, my friend had conclusive evidence of how the process worked, along with a set of recommendations on how to improve it.

This approach is definitely not new and is used extensively in other forms. Mystery shoppers simulate real customers. And for something closer to home, ‘dog-fooding‘ is often discussed in the software development community.

Before all you process people throw your hands up in protest, I do admit there are some shortfalls to this method: it is best suited for customer-facing processes; it doesn’t cover all scenarios; it’s anecdotal rather than statistical – you won’t know if what you experience is the most common process. However you will certainly uncover gaps that need further investigation in the traditional way.

What you get is a real-life view of what your customers go through when dealing with your company. If you can record the process you’ll also get an artifact – physical letters, emails, recorded phone calls, screen captures – that you can transmit to your colleagues in a high-impact way. You’ll end up closer to the reality, than to the process that people thought existed. You’ll find out if your welcome letter arrives after the product, or your service takes months to get up and running. Can you handle the truth?

What’s your social style?

Based on research by psychologists Dr. David W Merrill and Roger Reid, with help from Dr. James W. Taylor, this tool assesses your assertiveness (whether you ‘ask’ or ‘tell’) and your responsiveness (whether you ‘control’ or ‘emote’) and puts you in one (or more) of the 4 boxes below.

Social Styles matrix

The analytical ones are precise and cool, but get bogged down in those pesky details – your typical techy. The drivers make things happen, but sometimes in an aggressive, bullying way. The expressives are great at drawing us in and selling the story – but will they stick to the story themselves? And the amicables – weak and wishy-washy, we try to make everyone happy.

Sure, I didn’t put the usual, positive spin on these categories, but you get the idea…

I could immediately identify people who fit into each of these categories. And not surprisingly, being an Amicable, the ones I find hardest to get along with are the Drivers – diagonally opposite, and most dissimilar to me.

So where do business analysts fit in?

Good question… surely they are Analytical – I mean, it’s in their job title! But then, they often have to organise people and get things done, so perhaps they are Drivers. Some might use their convincing Expressive skills to get buy-in. But a rough survey of the room told us that the majority were Amicables.

This really does make sense when you think about it. Contrary to popular belief, a business analyst’s main job is to communicate (oh, I do like to harp on about this ;). Not to draw pictures or write documents, but to communicate. And for this you need to be people-oriented. You can’t often use force or power to get stakeholders to bend to your will.

Does this grid really help?

For me, when I gain an understanding of different ways people think, it helps me to work with them better, often because I realise why we’ve been conflicting (apparently it’s not just because they’re an idiot). For Analyticals, be precise and build their trust. With Drivers, stick to the point and forget the small talk. With Expressives, go along with the big idea and fit yourself into it. And the Amicables… just remember to be nice to us!

The bigger, the better?

According to closely-held tradition, developers produce code and working software; BAs product documents. Documents demonstrate to the outside world that yes, we have been doing work, as well as chatting. The bigger the document, the more work it looks like we’ve done.

But when you have a spare 30 minutes, try reading a document your colleague wrote. Or pull out a document you wrote a year ago. Even with hyperlinked cross-references, concise summaries and systematic tables, it will take a whole lot of mental re-arranging before you gain a decent understanding of the software (if you don’t have a document handy, you can bang your head against the wall repeatedly, to get the same sensation).

Software is complicated. It has rules, interfaces, data and more; and business analysts have an understanding of how it all holds together. Putting our understanding into a document that caters to different audiences invariably results in large, unwieldy documents that no one wants to read.

The record of a journey

There’s no question that the typical BA-produced document is the outcome of hard work. But it can’t be allowed to remain the defining work a BA does. Instead, I suggest the documentation should be the BA’s personal record of their journey. I say personal, because there is no ‘one correct way’ to document and these documents depend on the writers’ background, skills and understanding of the software.

We gain our understanding through long workshops, painful negotiations and endless conference calls, then distil this into something orderly and logical. But the real value of our work is our understanding, not the document itself. Looking at it from this perspective, it’s rather egotistical to expect people to gain the same understanding from our travel notes.

Dusty notes in a strange script, or bi-lingual speaking guide?

I am not advocating doing away with documentation – there is no doubt it is necessary. But when your target audience is not yourself, make sure you are communicating in the best way for them. Don’t simply point at your dusty travel notes. You are not answering questions by pointing ever more vigorously!

Currently I communicate with developers and users through a combination of conversations, diagrams, screenshots, spreadsheets and automated acceptance tests – whatever illustrates my point best. And I build up a record on a wiki page of everything I learn. It is publicly accessible, but not publicly advertised. I know where to find anything on my wiki page, but I don’t expect others to. It’s all organised and recorded so it can be picked up by someone else, but this should be treated as an emergency ‘hit by a bus’ situation not the norm.

When a developer asks a question, it’s tempting to direct them to the documentation. Yet that is like handing a foreigner a map to find your local pub, instead of just walking with them around the corner. Less time and effort for you, but a lot, lot more effort for them to get an adequate level of understanding.

So let’s concentrate on the understanding – and leave the writing to the real masters.

Inconsistency

When your solution in one area is inconsistent with every other area in a domain, it’s a clear warning sign that you may be over-engineering. This is a problem because software users rely on consistency to make sense of what goes in the black box that is their computer. When they hit a button, they know an action will be taken. When they go to a new page, it will have the same layout. When a calculation is done, it will be done in a similar way to other calculations. Inconsistency has its place, but you should be aware that it may leave your users in confusion.

One scenario focus

Often these complexities are the result of only looking at one scenario in detail. One of the most useful skills of an analyst is the ability to look at all the scenarios a piece of software ’should’ cover, then to abstract a way of covering 80% of them. If one calculation is much more complex, then it most likely gives priority to one scenario above all others. In my example, the solution solved a scenario that happens once in a year – it’s an important scenario, but it has overshadowed slightly less important, but more frequent situations.

Harder to work with

In my example, the ‘different’ calculation requires additional processes and integration points to the other calculations. Firstly, this creates much more work for the developers. (We’re lucky to have smart developers, so it’s all possible). It also makes the system harder to work with once development is over – special consideration is required when you are adding, changing and maintaining features. Even with a range of super-automated-tests, the fallability of humans (magnified by the fallability of my memory) makes errors more likely in the future.

But what if all this extra complexity is required and just wasn’t thought about enough to begin with? I agree that this is completely valid, just that you need to be sure that the impact to users, developers and all others is considered.

The problem with the way most templates are used is that a single template is designed to encompass a humungously broad range of vaguely related scenarios. Matching this vast, vague template beast to any specific focused software development project I have ever worked on is a painful exercise both for the writer and the reader (on the off-chance your audience tries to read it). Software projects vary substantially: one project may be process focused; another may revolve around the UI; and, yet another may involve purely back-end processing. Sometimes people forget that templates are intended as a starting point, a guide or cue and should never become a rigid exercise of filling-in a form without regard for the purpose of the writing in the first place.

A much better approach is the (seemingly) lazy one – document the least amount you can survive with. Despite stereotypes about business analysts, we don’t have endless amounts of time to write tome after tome, so if no-one will read it, I’m not writing it.

So how do you know what is enough? For me, this depends on the content and the people I’m writing for. To describe a process, a diagram is often sufficient. For complicated business logic, written (or executable) rules may be more effective. When my target audience is a team of senior web developers, I’m not going to detail obvious web validation, it’s a given.

I was recently asked by a developer if I could provide two wireframes for each screen. One ‘clean’ one which showed the controls, the other also showing the controls, but annotated with rules and validation. I have no problem with this. For me it doesn’t make much difference if I am communicating these rules in a table, as notes or verbally. As long as my audience gets the picture, I’m happy.