See the thin, black line down the middle of the table below? That’s the Business Analyst Tightrope. For wider appeal we could as easily call it the “Good Enough” tightrope.
If you’re an analyst, it represents the line you tread when trying to balance the risk of missing requirements against that of paralyzing the project until “everything” is known.
Not very wide, is it?
The trick to staying on the “good enough” tightrope is to learn and apply some important principles:
- “Good enough” requirements are not perfect, but they are sufficient to allow design to proceed with an acceptable level of risk. (Thanks Mr. Wiegers!)
- “Good enough” requires time, planning, good communication and cooperation from stakeholders, both in the business and in the factory. Hopefully it goes without saying that it also requires an analyst that does a good job of eliciting and analyzing those requirements!
- You will miss important requirements if you don’t have the above.
- You won’t produce a “perfect” requirements model/spec upfront even if you do have the above – no matter how long you decide you are going to spend on it.
To quote another of my favorite reads:
Knowing that perfect communications are impossible relieves you of trying to reach that perfection. Instead, you learn to manage the incompleteness of communication. Rather than try to make the requirements document or the design model comprehensible to everyone, you stop when the document is sufficient to the purpose of the intended audience.
- Alistair Cockburn from Agile Software Development
Now, I know the table above isn’t complete, and there is a lot more I could say on this topic. But you see, I have probably 20 or so blog posts that have been sitting in draft mode for up to a year. Why have I not gone ahead and published them? Because they weren’t perfect!
Obviously, I need a dose of my own prescription (as is usually the case with my more “prescriptive” posts), so I’ll start today. I didn’t want to let the imperfection of this post keep me from sharing what I think is a useful idea for BA’s, so here it is in its “good enough” state.
I’d love to add more to the table, though. If you have any more ideas on items that fall on either side of the missed requirements/analysis paralysis tightrope, please comment or contact me with them. I’ll continue to update the table with your contributions and mine as I think of them.
To keep up with the latest on Practical Analyst, you can subscribe to the RSS feed, follow Jonathan on Twitter, or view his profile on Linked In.
Latest posts by JB (see all)
- Jim Rohn – February 20, 2014
- Elicitation Tip: When the Stakeholder Asks for a Specific Implementation – February 19, 2014
- Paul Oldfield – February 11, 2014