Too much information about requirements or too little? Too much documentation or too little? Use the NICE framework to get it just right.
How Much to Understand and Document?
One question that plagues many analysts is “when do I stop?” People justifiably fear analysis paralysis. You can spend forever trying to figure out the the perfect solution, or craft the perfect document. The risk of delivering the wrong product makes it hard to stop analyzing or stop documenting. There is no magic answer – we can’t write 1.25 paragraphs per function point, or have 2.3 reviews per requirement.
Kiran Garimella wrote an article on BPM and ROI where he introduces us to Roger Burlton’s (of Process Renewal Group) NICE framework. Roger’s NICE framework can be applied to requirements management, and help us think about how we approach our work as business analysts and product managers. [Note: I could not find any articles about the intended uses of Roger's framework, but our unintended use is interesting.]
The NICE Framework
The framework presents itself as a Venn diagram, as Kiran describes it – the two axes are “Level of Understanding” and “Level of Detail.” The first axis is a representation of how much we understand about the domain of the problem, and the second represents how much information we have documenting the domain. There are two categories for each axis – “Little” and “Lots.” Lovely alliteration.
- Level of Understanding (Little or Lots) – How much insight do we have into the domain?
- Level of Detail (Little or Lots) – How much detailed information have we captured about the requirements?
The four squares in this diagram are mapped to the NICE acronym.
Is It Five O’Clock Yet?
- Little Understanding
- Little Detail
Naive Requirements. When you don’t have sufficient understanding of the domain, and you don’t document requirements in detail, you are capturing a naive view of the world. Imagine an out-of-touch manager who joins the meeting late, interrupts the discussion and says “All we need is social networking for our [spare-parts-resale] website, because word of mouth is what drives business.” He demonstrates a lack of understanding, and provides no detail.
How successful do you think that project would be?
A Whole Lot of Nothing
- Little Understanding
- A Lot of Detail
Incomprehensible Requirements. An overwhelming pile of documentation cannot overcome an absence of understanding. If anything, it causes more problems than naive requirements. At least when you don’t share what you don’t know, people don’t waste time figuring out that you haven’t said anything. We had to “clean up” for a client after another consulting firm had done a very large, very expensive analysis of part of their business. The firm produced a couple inches of documentation. Among other things, they created a spreadsheet with ~1500 “requirements” that made little sense, and had no traceability back to the sources of the requirements. The requirements could not be evaluated, because they lacked explanatory context.
When exploring and validating a sample of about 10% of those requirements, we found that they demonstrated a significant lack of understanding of the domain. Over 2/3 of the requirements we sampled were either replaced, discarded, or corrected. We lost confidence in the rest of that documentation.
At that point, our client was faced with a tough political situation: admit that the money spent on those docs was wasted, or spend more money to “redo” the requirements. Neither path was a winner.
You’ve Got To Be Kidding
- A Lot of Understanding
- A Lot of Detail
Complex Requirements. You have an analyst who understands the domain, the stakeholder’s needs, the right solution approach, and the value of everything. Perfect. You are exactly where you want to be. You have insight and understanding. You’re positioned to make excellent decisions.
And then your analyst writes everything down. And keeps writing. And writing. The level of detail is overwhelming. You have a 5-gallon problem, and a 10-gallon spec. The problem here is that your analyst has documented too much. You’ve created a mass of information for the implementers to consume. The print-outs of those documents generate their own gravity. Time slows in their presence. At least it seems like it, when trying to review the docs.
You’ve also now invested a lot of time and money in the documentation. The more detail you document, the longer it takes, to create, review, correct, and consume the documents.
Imagine you’ve death-marched your team through reviews of the documents, and the team has started implementing. The requirements now change. They always change – at least a little. How do you let your developers know that they have to find the changed needles in a stack of needles? The larger and more complex the documentation, the harder it is to ferret out the changes.
The more detailed the documents are, the more impact changes have.
The Porridge is Just Right
- A Lot of Understanding
- A Little Detail
Elegant Requirements. There is clarity that comes from writing concise requirements. A picture can be worth a thousand words, and a well-placed diagram within a requirements document can have the same impact. When you combine a keen understanding of a domain with clear and effective documentation, you set your team up for success.
This does require additional skills – not only can you gain understanding, but you need to impart it as well. You can gain understanding by exploring and absorbing the “next level of detail” – which leads to insights. Then you have to leverage that understanding to express clearly what needs to happen and why – without all the details of how you reached that conclusion.
Conclusion
Strive for understanding to avoid writing the wrong requirements. And strive for elegance in your documentation, to avoid costs, save time, and make it easier for other people to consume your docs and reach understanding themselves.
Latest Articles
Comments on all Articles
