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.
-
Recent Comments
- Jinesh Parekh on Who performs business analysis work in your organization?
- Shiva Prasad on Why Identify Business Processes and Use Cases?
- Kupe on How Technical Can You Go?
- Declan Chellar on COTS, anyone?
- Tom Miller on How Technical Can You Go?
-
Blog Categories
- agile (1)
- analysis (1)
- BABOK (1)
- BA Certification (16)
- BA Tips (74)
- business analysis profession (1)
- CBAP Exam Q & A (6)
- COTS (1)
- CRM (1)
- customization (1)
- exam (1)
- General (1)
- IIBA (20)
- Industry News (36)
- job titles (1)
- package.ERP (1)
- PM (1)
- Requirements (50)
- Testing (2)
- Training Update (1)
- user request (1)
-
Blogroll
-
Authors
7 Comments
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?
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
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!
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.
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.
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.
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.
One Trackback
[...] Analysis paralysis - how do you prevent it? [...]