Governance

Rules for business cases

I spent a couple of days this week hearing from Tom Gilb about defect prevention. Here is just one small thing from that which intrigued me… rules for business cases.

Defect prevention is quality assurance in its true form. Testing to discover defects is too late — you really need to make sure there are no defects in the first place. Doing this is far less expensive than building in a defect and then doing the rework to take it out again.

Tom’s consistent experience is that projects run into problems because of ambiguity in earlier stages. For example, a system might be required to be scalable, but if the precise nature and extent of the scalability is not defined then the architects can easily spend an awful lot of time investigating solutions that address the wrong kind of scalability, or enable it to a degree which is not worthwhile to the business.

Even more significantly, if a project has many critical success factors which are not clearly distinguished in their relative value, then it’s far too easy for the development team to invest their time poorly.

So, ambiguity and a lack of clarity seem to be at heart of these problems. And since the earlier we pick up problems the better, we need to look out for that fuzziness at the very earliest stages… the business proposal, the requirements document, the design document, etc.

(For any Agilistas reading who shudder at the thought of a “requirements document” I would ask you let your imagination roam a little more freely. If your team is anything more than three or four people, and if your company is more than a dozen or so staff, then it’s very likely that someone is going to write down some kind of requirements to guard against people forgetting what’s been agreed from one day to the next. And those written-down-requirements are a “requirements document”, regardless of their precise physical form.)

Now I’m very used to having templates for proposal documents: standard headings, a standard cover sheet, and maybe even a standard font. But these are things designed to help the writer, and to make sure the information is complete. They are not designed to ensure the information is useful or clear to the decision-maker.

Thus the idea is to use rules for these documents. Here are some easy examples of rules…

  • All statements in the document must be consistent
  • Every statement must be unambiguous.
  • All statements must be in their most elementary form.

I hope we can agree those look sensible, and they should be easy to stick to. But take a look at a business case from your company and go through it sentence by sentence. If the author isn’t consciously trying to adhere to the rules then it’s very easy to fall foul of them… sometimes several times per sentence.

Now here are some tougher ones:

  • Evidence must be backed up by sources.
  • All quality requirements must be quantified.

That last one is really tough. It means you can no longer just say “it must be much more user-friendly than the current system”. Instead you have to define unambiguously what user-friendly means (number of clicks to perform a given function? Number of people who abandon the process before the end?), you have to know what the current level is, and you have to know how much of an improvement you really want.

If that seems like a near-impossible demand, then take a look at Tom’s unambiguously-titled paper, “Quantifying management bullshit” [PDF]. Doug Hubbard’s “How to measure anything” is also entirely focused on this one issue, and is something I’ve written about before.

And here’s another rule to try out:

  • Don’t put design ideas in the requirements document.

Tom’s example is that of passwords [PDF]: The business proposal (the business requirements) may ask for the system to be password-protected. But do they really want it password-protected… or do they want it to be secure? Because those are not necessarily the same thing, depending what “secure” really means. And the wrong design decision (i.e. implementing passwords) will lead to the wrong business outcome.

That last example also highlights another feature of document rules: different documents need different rules, depending on their purpose and audience. Clearly that “no design ideas” rule isn’t appropriate for a design document.

And finally… you’ve got the rules, you’ve received a business proposal… what next? Well, you review the business case against the rules, and if you find any violation of the rules then congratulations: you’ve found a defect. And finding defects at this early stage is going to save you a lot of time and money. Fix it now, and run it through the process again. When you’ve got an unambiguous business case you’re half way to a successful project.

Advertisements

Discussion

Comments are closed.