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)
Are you ready to lead your I.T. department to become more valued, relevant and responsive? If so, 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 "project fast tracking" is a streamlined project management process, specifically used to overcome the most common types of project obstacles, including insufficient time, resource shortages, budgetary deficiencies and stakeholder conflicts.
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.