So what exactly is “analysis paralysis disorder”? If you Google the term, you won’t get a hit (unless it’s a link to this article). You will, however, find lots of links to articles and web pages about analysis paralysis and how to overcome it. You’ll also find that it’s not unique to Information Technology (IT), but applies to all facets of life. Just about everyone experiences an episode of over-thinking a problem to the point where it’s impossible to make a decision – paralysis by analysis.
Have you ever been on one of those IT projects where the requirements work never seems to end? When it seems like the business analysts are inventing new requirements just to keep the engagement going? It’s not quite a zombie project because development hasn’t started. But all of the effort is going into requirements as the “go live” date slips farther out.
Does this sound like analysis paralysis? Or is something else going on?
Let’s assume that the business analysts are led by a seasoned professional. If they are contractors, we’ll also assume that your contracting shop has done the due diligence and didn’t hire a fly-by-night outfit because they were the low-cost bidder. What could the problem be?
Before making a rash decision, the best move is to meet with the business analysts to understand the situation. The two most likely culprits behind this situation are ill defined solution scope and unexpected complexity.
Ill Defined Solution Scope
The solution scope describes the boundaries of the system – what data, features and functions will be delivered in the system and what won’t. It’s possible that the business analysts are reacting to the subject matter experts adding scope. This should be an easy fix. Just take a pause and work with the stakeholders to clearly define the solution scope. Make sure you have the project sponsor sign-off on the updated scope and communicate it to the stakeholders.
Note that I’ve italicized should. A fuzzy solution scope is a good indicator that project sponsorship needs some beefing-up, too. That could be an organizational issue beyond your control, especially if you don’t have the clout to correct it. If that’s the case, now’s a good time to dust-off that resume and start looking for a new project.
And while I’m at it, good luck with dealing with the stakeholders if the requirements defined so far exceed the new, “reduced” solution scope. Stakeholders will see it as having something they were expecting taken away, which can damage your team’s credibility.
If the solution scope isn’t the problem, then it’s like that the requirements are more complex than expected. You can reduce the solution scope (and possibly alienate your stakeholders as described above) or extend the schedule to complete the requirements work.
By the way, if you decide to extend the schedule, you should review and revise any estimates based on the earlier assumptions. Your project sponsor might have to ask for more time to redo the business case, especially in cases of unexpected complexity because it could affect your acquisition strategy.
There’s a third option that should be avoided, but often isn’t because it comes from the Project Management Office (PMO) in your organization. After reviewing the situation (if they review it at all), the PMO may decide to stop the analysis work and proceed directly to development. You should be highly suspect if the PMO cites analysis paralysis as the reason for this change in plan.
In the more than a dozen system acquisition projects I worked on over the years, I never had one project that was paralyzed by never-ending analysis. I did experience two projects where the PMO (not the same PMO as this was in two different organizations) swooped in and either terminated an ongoing analysis effort or outright prohibited analysis from starting at all, launching the project straight into development.
Both PMOs were suffering from analysis paralysis disorder. The sources for this disorder originated from the PMOs and not the stakeholder organizations. But the actions of these PMOs helped to increase project risk, add to the total acquisition cost, and damage the stakeholder organization’s ability to manage user expectations. Along the way, the root causes of the “analysis paralysis” was never addressed meaning it can happen again on the next big project.
Symptoms of Analysis Paralysis Disorder in the PMO
There are two symptoms of analysis paralysis disorder exhibited by a Project Management Office:
- PMO over-involvement in the project
- Inexperienced PMO staff
A PMO may exhibit one or both symptoms. I’ll expand upon these symptoms below.
PMO Over-Involvement in the Project
Who owns the projects in your organization? Are they owned by the business line (or program office in government-speak) sponsoring the project or by the PMO?
Most often, it’s the business line (program office in government speak) that owns the project, funds the project, and sponsors the projects. The PMO provides the methodological framework for managing the project (though one of the PMOs in the example didn’t have a project methodology). It might also require periodic reporting of project data for monitoring project performance and reporting this information to the chain of command. Some PMOs even provide the project managers to manage projects.
In my experience in the projects above, the project manager to sponsor relationship devolved into a worker-manager relationship where the stakeholder sponsor acts more like the project manager’s supervisor. The project manager still had the PMO supervisory chain to deal with. In effect, the project manager had two bosses.
Another effect from having PMO supplied project managers is that it can really wreak havoc with workers in the sponsoring organization. Let’s say the PMO project manager depends on personnel from the sponsoring organization to work on the project as team members. You’ve just setup those unfortunates with two supervisors – their normal supervisor and the PMO project manager.
Serving as a team member in this situation is not a lot of fun for the team members, especially when the project manager and the supervisor have a difference in opinion. If the project manager directs you to do something your supervisor doesn’t agree with, are you insubordinate? How is your performance review handled? And so on…
Managing internal communications becomes more complex as well. Theres’s one channel snaking up from the supervisory through the sponsoring organization’s chain of command and another from the PMO project manager through the PMO chain of command. Both ultimately converge high in the organizational food chain. How do you rectify differences in communications between the PMO and the sponsoring organization channels?
I witnessed one example when an executive who had authority over the PMO and the sponsoring organization commented that a ingenious utility the project team had been working on would be the “death of the project”. It turns out that a new PMO manager came to this conclusion without consulting the technical experts in the sponsoring organization. Several years worth of work was immediately thrown into doubt, staggering the project team. Eventually, development of the utility was allowed to proceed, but with reduced functionality specified by the PMO that impaired its usefulness.
As the PMO was housed in a staff reporting directly to the executive mentioned above, its opinions were above reproach. Even though the stakeholder technical experts had more direct experience with the technologies involved, the PMO’s opinion always trumped. And it really affects team morale when it comes from out of the blue like the example above.
Lastly, having a PMO supplied project manager makes it easier for the PMO to assume ownership of the project, effectively taking the stakeholder project sponsor out of the picture if the sponsor lets the PMO do it. Depending upon the organization and its management dynamics, the sponsor may have to defer to the PMO when issues like the one I described above happen, thus institutionalizing dysfunction.
Inexperienced PMO Staff
By inexperience, I don’t mean that the PMO personnel have little or no experience working IT projects. You certainly wouldn’t want key PMO staff minimal project experience. What’s almost as important as years of project experience is the type of projects, or project experience, of the PMO staff.
Consider requirements. If most of the projects the PMO staffer worked on involved minimal requirements work (say the requirements were plainly stated in the standard operating procedures or a regulation), then that’s what they are used to. For example, let’s say the PMO staff has lots of experience working on small, short-term projects where the requirements are well-known and the resulting systems were not that complex. When a complex problem does come along, the PMO may not have the experience for effectively dealing with it.
The problem is compounded if the business case underestimated complexity. If the expectation in the PMO was that requirements would take three months (because that’s the assumption the business case used based on a faulty complexity assumption) and it’s now going on nine months, then the PMO might be inclined to stop requirements and move to development. What this really does is pass on the requirements work to the development team who will have to figure it out while they’re building the system.
Preventing analysis paralysis disorder is difficult because it isn’t manifested with every project. A PMO may have a stellar record delivering less complex systems on time and budget with acceptable quality. It’s the projects that don’t fit nicely in the PMOs experience – the tough ones – that tend to get away.
You can avoid the effects of analysis paralysis disorder on a project if your organization is willing to listen to dissenting opinions that contradict the PMO. If experienced staff are saying one thing and the PMO something different, perhaps invoking a more formal conflict management/resolution process could be useful. One agency I worked with had a dissenting opinion process that would have worked nicely (though it wasn’t applied to IT and should have been).
How does a project recover from analysis paralysis disorder?
If you are lucky, everything might work itself out and the system will turn out OK. That could happen, but the system will most likely be delivered late at a significantly higher cost than estimated in the faulty business case.
As the project blows-through delivery milestones and consumes more resources (money and people), it takes on the characteristics of a zombie project (described in this article.) There are three tactics for ending a zombie project. I described the first tactic the in the previous paragraph – keep throwing resources at the development project until it’s done. The other two options are to restructure and relaunch the development project or, if possible, terminate the project and put it out of its misery.