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.
Oops. Where I wrote “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.”
I really meant:
“At that point, our client was faced with a tough political situation: Admit that the money spent on those docs was wasted and spend more money to redo the requirements. – OR – Build a solution based on requirements documents that were known to be incorrect and hope to fix it on the fly in some magical way. Neither path was a winner.
Scott — Brilliant article. I’ve been in all 4 of these situations, and at the time, each of the flawed 3 were clearly wrong, though I couldn’t put my finger on exactly why. It especially clarified for me how throwing more documentation at at unclear problem won’t make it more clear, which is something I think a lot of people don’t really understand.
Thanks Jeff! I’ve been in the same boats. I’m also finding parallels in trying to socialize messages across an organization. One of the things I had to learn, starting out as an engineer and then a developer, was how to share ideas without being too verbose. I knew that I had to know “too much” in order to understand, and I always found myself trying to communicate everything I knew.
It is the elegant message that resonates.
This is so obvious! Unfortunately 80% of the business analysts can’t see the point. Developers are getting tons of documentation with so many details that are irrelevant for the implementation of the solution.
Thanks, João! Welcome to Tyner Blain, I think you’re spot on.
And hopefully, you mean “obvious” as in “Eureka!” not “well, duh!”
Obvious as in “Eureka” :) because now I understand why after the product manager put in my hands a 400+ pages documents, I keep asking them: what the solution should solve? Their answer: “it’s all in the spec.” WHERE? I reply. :)
Nice article.
It is the whole precision vs. accuracy discussion again. (With a small twist).
What is the point of giving a very precise answer, if the answer is not accurate?
Example:
Question: What is the value of PI?
Answer A) 3.14
Answer B) 3.15209265
Answer A is not very precise (as in number of significant digits), but is it is accurate (correct to the level of significant digits).
Answer B is very (or at least more) precise but not accurate (as in wrong!).
In my job I am dealing with huge documents containing way too much detail but without the required understanding. It’s sad, but true. One thing is of course to identify the problem, but how do you propose to change the world of bad requirements specifications? I encounter a “this is how we do it here” answer when I bring this problem up in my organization.
Cheers
Mikkel
Eye opening but
I wonder, how time spend in requirement gathering plays any role in level of understanding and level of detail.
Personally, I think time spent correlates positively with understanding. But I believe that the incremental benefit of additional study rapidly decreases – at least until you reach a point where you start to gain spontaneous insights. When doing requirements work, I don’t believe most people reach that level – it comes from years of practice within a domain, while studying other domains.
Each individual will reach the point where additional study is more expensive than “doing stuff” – and each person will reach it at a different time.