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.
Good post Jonathan, though I’d love to work on a project where Analysis Paralysis was allowed! One architect actually said to me “Don’t talk to the Business, they’ll only give you requirements”.
Maybe needing to get the details right AND being able to let go is just another part of the Zen of Business Analysis. I feel a post coming on, or ready to be drafted anyway.
Ben
Good to “see” you, Ben.
The Zen of Business Analysis… I can’t wait to see that post! Just don’t let it sit in draft for a year like I do..
Nice post, Jonathan. I definitely have a lot to learn about letting go. If you realize that no matter how much you analyze, you'll probably never get it 100% right, it frees you up a bit to deliver good enough first and iterate from there. Allowing yourself to learn through the process is key instead of expecting yourself to do all your learning before delivery!
Laura
My recent post IIBA Interactive Webinar: The BA Career Path – Becoming, Being and Building