Many BAs have experienced analysis paralysis at least once in their career. This phrase describes the situation when you keep thinking/analyzing a problem, doing more research, documenting what you have learned, and then repeating the activities. Think, research, document. Think, research, document. It is the BA's equivalent of an infinite loop in programming. We get stuck in this cycle and can't seem to get out. There are many reasons that this phenomenon occurs. But how do we stop ourselves and get out of the infinite loop? Post your comments and suggestions and let's help each other.
August 20th, 2007 at 11:52 am
That’s funny, I was actually right in the middle of this ‘paralysis’ when I saw this posting in my feed reader. I’m working on a rather large project and it seems like every time I think I have a handle on it, I talk to the stakeholders and new details come up which throw me off again.
My usual methods are:
- Talking about the project with another colleague
- Scope control. I have to get back to thinking: what is the scope of this project? How is what I’m doing help serve the needs of the scope?
August 22nd, 2007 at 2:06 am
Hi Barbara,
Another way to describe “analysis paralysis” is when the analyst does the same thing over and over again but without significant return on effort (investment).
In one of my blog entries I talked about the same issue from the requirements gathering perspective. We keep interviewing, we keep documenting, we keep analyzing, but how do we know when we are done with the requirements?
- Adrian
August 22nd, 2007 at 4:05 am
[…] Analysis paralysis - how do you prevent it? […]
August 23rd, 2007 at 8:51 pm
I am with Tom- we have to get out of the trees. I am guilty of this also. I had a very sage mentor that gave me this visual metaphor that really helps me. Think of yourself in the valley doing all these things surrounded by trees and mountains on either side of you. You feel safe but trapped and cannot see anything over the thick trees, except the mountains on either side. Suddenly a helicopter swoops down and picks you up and carries you above the mountains. You can now see the valley clearly, and you can look over the mountains and see what is on the other side. Every time I get bogged down in analysis I send my imaginary helicopter in to pick me up so I can get out of the trees and regroup. I have to think of the big picture. I ask myself is what I am doing now really adding value? What is the risk if I stop now? Sometimes I just need to remind myself to have confidence that I have uncovered what needs to be known and move on. Like many BAs I am a very curious person and I love analysis and could do it forever! Thank goodness there is a schedule!
August 24th, 2007 at 10:27 am
Barb:
One of the tendencies of any creator is to try to make the creation a piece of art. As BAs, we have to limit our “art” to the process of creation, and not try to make the created thing “art.”
I like Angie’s analogy of the helicopter. Another business analogy is silos. We tend to get myopic when we’re thinking about our own “thing”, but we need to pull our head out of it from time-to-time, and take a look around.
This is true as well for usability experts or programmers, whose focus can be laser-like in adhering to the latest trends, but missing sight of what works with users/SMEs historically. Part of our jobs as BAs can be to help them overcome their own silo-think as well as our own.
August 27th, 2007 at 3:53 pm
As for knowing whether you have ‘enough’ requirements: from my short experience, I’ve learned that you NEVER will. Just amass as much as you can within a timeframe, get the solution going, and you’ll find a good 20-60% of your requirements during user testing.
I know the BA role is supposed to somewhat minimize those near-production ’surprises’ but I really find there’s no way around finding a lot of requirements out once you get into a staging environment.
August 30th, 2007 at 1:02 pm
I appreciate all the previous posts. A few methods I've found useful to break the cycle, in addition to the techniques already mentioned include: 1. Change the medium: Instead of poring endlessly over standard documentation, I jot down key points, processes and ideas on sticky notes and then throw them up on the wall. This allows me to easily rearrange and organize them. I also try creating thought maps, freewriting and whiteboarding. 2. Switch roles: Get out of the BA mindset, at least for a while, by donning another hat. Come at a requirement or set of requirements from the perspective of a developer, end user, DBA, network cop, Bugs Bunny - anything other than the mindset in which I'm trapped. 3. Focus on something else: Sometimes just dropping the piece of the puzzle that's got me running in circles and moving on to something else for a while works wonders. Later, when I get back to the difficult requirement or set of requirements, I see things from a fresh perspective.
August 31st, 2007 at 1:03 am
How do you prevent analysis paralysis? That's the question Barbara opens up for discussion on the Business Analyst Blog. The answer is somewhat simple. You stop as soon as you believe you have something that reasonably covers the goals (or use cases) that you are trying to address. When you have requirement completeness, you move on. This answer is both naive and enlightened- especially when you consider the benefits of an agile development process.
October 28th, 2007 at 3:54 pm
Thanks, Scott; this makes excellent sense and points out the importance tracing from goals to use cases. Personally I prefer a more formal approach which stores project artifacts in a data base and creates physical links that can be used in queries.
This allows you to answer questions like:
Which goals have no use cases that achieve them?
What are all the use cases that achieve a given goal?
List all goals that are partially achieved by a given feature?
There are many tools on the market that support this sort of thing but lacking that, MS Access can be used effectively. Note that Excel, despite its popularity, is not a good tool for tracking system artifacts because linking and queries are not well supported.
I have drifted slightly off topic so I will stop here.
James
October 31st, 2007 at 6:58 am
Hi Most of us face this problem in a volatile enviorment of requirements gathering. Things I do: 1. Every time before going to meeting read the "project scope," though boring, it helps. 2. Similar to helicopter veiw, just remember you are not there to solve every problem, if you don't think that way you become part of the problem. Just absorb the situation for some later time. 3. If the stakeholder is consistely going outside project scope or you are not able to focus/bored of analysis, ask your stakeholder (if possible) to go for a stroll/coffee to new place, just break the monotony. 4. This works the best - Go home that day be creative and try out-of-the-usual routine, do what you love to do other than business analysis. As for me I treat my self for every bad/lull day at work.
December 15th, 2007 at 1:27 pm
very interesting, but I don’t agree with you
Idetrorce
December 17th, 2007 at 5:21 pm
idetrorce,
What don’t you agree with? Inquiring minds want to know!
December 18th, 2007 at 8:03 am
Especially because there are a lot of "yous" in this post