How do you know when you’ve done enough?

The other day someone asked me an interesting question:

How do you know when you’ve done enough analysis?

I’m not really sure how to answer that one.

Sometimes you are forced to stop when you run out of time. But if time is your only guide you risk ending up  with something too vague to be implementable. Which means someone has to make quick and dirty decisions about how to implement it. And that’s a fast route down a short road to a lack of business buy-in. A short road too many of us have been forced down by sponsors who care more about delivery than quality or by project mangers who confuse analysis with planning on the one hand and specification on the other. No bitterness here, then.

The perfectionist’s answer is that you stop when you’ve nailed down every last detail. But that way another kind of madness lies.  Over-specification produces inflexible processes which cannot accommodate the unexpected. Remember those early web forms which required “Zip Codes” to be numerical, and therefore couldn’t be used by people outside the USA? Over-specification also infantilises the people using the process, which may or may not be a good thing. And it can give you processes or requirements that are just plain wrong unless the detail has been provided by practitioners.

But it’s usually lumpier than that because there’s never time for infinite detail. The bit that’s easy ends up being over-specified but the hard stuff is still vague, as exemplified by my favourite systems diagram:

Good work - but I think we might need just a little more detail right here

Good work - but I think we might need just a little more detail right here

This of course is why we use tools like use cases and swim-lane diagrams to impose standards, drive out that ambiguity and ensure we have detail where we need it, but not where we don’t.

In the end it’s a judgement call. You use your tools, consult the business, trust your developers, empower your users, and deliver on time.

In the words of Albert Einstein:

Make everything as simple as possible, but not simpler.

Make everything as simple as possible but not simpler. Albert Einstein.

The song that’s been driving through my head as I type this is Don’t Stop Till You Get Enough, which is eerily appropriate in so many ways. The difficult thing, as Jackson himself illustrated so clearly, is to know when enough is enough.

Advertisements

5 responses to “How do you know when you’ve done enough?

  1. I showed this post to J – because I thought he’d find it interesting, being heavily involved in the planning stages of a huge construction project.

    He’s just introduced me to Pareto Analysis. Interesting.

  2. I’m a big advocate of the right process of analysis – using the tools you mention to drive creativity and consensus. I have seen them work time after time. Most of all they are a lot of fun, which helps, I think.

    What I am not a fan of is the Requirements Spec, particularly in the absence of discussion, where the analysts simply pass the spec over to the users, get their thoughts on what the system needs and then before the user realises, all is cast in stone without any take-backs. This approach happens all too often.

    Also testing approaches should be considered here. Do you create a huge monolithic requirements spec, design and implement the lot, then pass it over to the testers when all is done? Or do you design in chunks and easily digestible modules, allowing the testers access to the results as early as possible in the project? You can imagine which is my strong preference.

  3. SonofRojBlake

    Designing, implementing and testing in chunks would be nice, and for some things is probably even possible. I wish I could do my job that way. The reality tends to be a hazy requirement specification, a hard-and-fast budget set by someone with no idea of what the requirement is, much less the design, no design time, a ludicrous delivery requirement date, and when I pull a Montgomery Scott and deliver the apparently impossible within the deadline, I discover that no, while they are prepared, grudgingly, to admit that yes, they SAID they wanted Warp Factor 2, that was *several minutes ago* and they now need Warp Factor SIX, with the emphasis on the NOW, and will the engines take that?

    One of the grim satisfactions of my job is that because I don’t work with “systems” or “software” or “accounts” or any of those fictional, arbitrary constructs, but with the real, uncompromising and very objective universe, I can, very occasionally, turn a withering look on someone who does work with those imaginary things, and who is asking for the literally impossible, and say, with just a *hint* of a Scottish accent… “Ye cannae change the laws o’ physics.”

  4. Thanks for passing the post on, Teuchter. I worried slightly that it was a little too Business Analysis-y for what’s turning into a fairly general blog.

    The debate over what is the right form to capture and record requirements is an interesting one Colm. Ultimately we’re talking about how to avoid the law of unexpected consequences in a world where most people have never had to do any systems thinking. In fact, I think that might be the role of the BA in a nut-shell.

    If I’d had any sense I’d have become an engineer, SoRB, simply SO that I could look at someone and say – with authority – “Ye cannae change the laws o’ physics.”

  5. Great article. We have a blog about software requirements and business analysts.
    http://requirements.seilevel.com/blog/

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s