There is no doubt that it takes a lot of "analysis and decision making" to deliver successful IT services, operations and projects. But this begs an important question -- when every major project, plan, decision, and solution depends upon the meaningful analysis of goals, requirements, alternatives and consequences, can there ever be too much analysis? The answer is yes. At some point, action must be taken or the "opportunity of the moment" may be lost. It's a fine line, but you can read on to learn when that line has to be crossed.
Once "analysis" crosses the cost/benefit line, it becomes counter-productive, impeding forward movement and tangible progress. In common terms, this is known as "analysis paralysis". According to the Wikipedia encyclopedia, analysis paralysis occurs when:
"... the opportunity cost of decision analysis exceeds the benefits. Analysis paralysis applies to any situation where analysis may be applied to help make a decision, and may be a dysfunctional element of organizational behavior...".
In the IT management context, analysis paralysis manifests itself through exceedingly long phases of project planning, requirements gathering, program design and modeling, with little or no extra value created by those steps. Per Wikipedia:
"In order to maintain forward momentum, and deliver required projects and services, "analysis" must serve a specific purpose, whether to aide a decision or produce a deliverable. Analysis related activities must be executed to move a project or process forward. Once in "paralysis mode", activities cease to contribute to the bottom line, becoming "empty and excessive".
Analysis paralysis is usually caused by a well-intentioned, but misplaced focus on "work instead of results", characterized by one or more of the following:
Analysis has a simple goal.... to reach the best conclusion possible, based on reasonable, verified information and informed consensus. How can this be achieved without excess? The first step towards avoiding, or at least minimizing, analysis paralysis is to define appropriate process limits and expectations. Analysis is not a deliverable in and of itself, it is a process used to create a deliverable, and as such, it must be defined by specific goals, tasks, deadlines and results. This can be achieved through the creation of an analysis framework.
The analysis framework is used to establish (5) defining parameters for the ensuing process, setting the stage for the work to be done. Using the framework, you can avoid the type of open-ended, undefined process inevitably leading to "analysis paralysis".
What is the driving force behind this analysis? Why is this analysis necessary and how will it add value to the project or issue at hand? What is the urgency? What are the risks if this analysis is not undertaken?
How will this analysis be used to influence the decision, plan or project at hand? Note:If the pending analysis cannot be tied to a specific need or result, it is time to rethink the whole thing. What are the expected results (deliverable) of this analysis?Note: Depending on the project, problem or issue at hand, analysis deliverables can include decisions, recommendations, plans and problem "plans of attack". What is the minimal amount of information required to reach the desired result? Can this analysis occur in "phases", to allow other work to begin even if all "analysis" is not yet complete? (Also See: Easy Ways to Define Project Scope).
Every analytical process should proceed along a defined timeline, with an established (and communicated) deadline.Without a firm deadline, analysis can become a never-ending cycle of "wait, here's some new information", or "let's have another meeting". Analysis should never be open-ended, it should always be tied to a specific goal and a specific deadline. Any and all changes to this deadline should be considered carefully, and allowed only when absolutely necessary.
How will this analysis process be executed? Who will be involved? What tasks are required for data collection, organization, analysis and deliverables production?
Success criteria will help you to set expectations and avoid "analysis" scope creep. Defined success criteria will also help you to respond when and if problems arise, and you are in need a "plan B". (Also See: Defining Realistic Criteria for Project Success)
About Us- ITtoolkit.com has been around since 2001. What will you find here? We have articles (covering a wide range of topics relating to our IT service strategy and project fast tracking methodologies). We have templates and whitepapers to download. We have our series of IT management infographics. And, we have our "Toolkit productivity packages", combining "education and execution" - with time-saving concepts, steps and templates packaged in digital downloads. Our current Toolkit offerings include the Fast Track Project Toolkit and IT Service Strategy Toolkit.
If you are, then you need the IT Service Strategy Toolkit from ITtoolkit.com! The Toolkit teaches you how to "add value" to IT projects and services -- using our time-saving "service strategy process". It's ready for instant download, filled with 400+ pages of steps, guidelines, practices and templates. Find Out More
Strategic fast tracking is a streamlined project management process, used to level the playing field when "project problems" get in the way of on-time success. Our informative "fast tracking" article series explains more:
Sign up for the ITtoolkit.com newsletter and be the first to know about our latest blog articles, templates, white papers, infographics, and special offers.
We won't overload your inbox and we don't share or sell subscriber information. Just enter your email address below.