It's disturbing and a little scary. It's that all-too-common point in technology implementation projects when control is lost, yet everyone remains in denial, rejecting the possibility that the worst-case scenario could happen–or has already happened: Your project is up in flames.
Yet projects don't just suddenly get into trouble. For instance, every project has some lag time built in, says Steven Fink, vice president of technology at the University of Nevada, Reno. “If you've run through that lag time early in the process, that's a surefire sign that things aren't running smoothly,” he says.
The telltale symptoms are lurking behind eaten up lag time, missed deadlines and deliverables. The key is to have a process in place to spot these symptoms early so you can avoid a project disaster.
Ten Telltale Symptoms of a Project in Trouble
The road to a project disaster is often lined with good intentions. “The number-one problem with any tech project is scope creep,” says John Campbell, assistant vice president for technology at Purdue University. “The later that changes are introduced, the more off-schedule the final deliverable will be.”
The following symptoms often appear when good intentions turn to uncertainty for project team members:
1. Changing requirements (aka Scope Creep): Find out if requirements are changing, being replaced or have just been added. And be sure the individual making the changes understands what is really needed.
2. Lacking or missing deadlines: Project deadlines may be missed for multiple reasons, such as unforeseen events. But if your team is missing its deadlines repeatedly, or if there are no deadlines, that illustrates a lack of discipline.
3. Final decisions not being made: Some critical decisions require answers early in the project life cycle, such as what the final product should look like and how many defects are acceptable. A lack of clarity upfront results in a lot of rework later in the project.
4. Project completion is stalled at 90 percent: Projects have a tendency to remain in the “90 percent done” state. Often, this completion estimate is arrived at by imprecise calculations or gut feelings. The complexity of the remaining 10 percent may be unclear.
5. No problems being reported: All nontrivial projects will encounter some sort of problem. If no problems are being reported, then either the team has not dug down deep enough or information is not being communicated.
6. Lack of management reporting tools: An absence of management reporting tools almost guarantees that problems are not being reported or are not being communicated to the extended project team. It also usually means that telltale signs are neglected until it's too late.
7. Lack of key project deliverables: Key project deliverables or milestones are needed to ensure a smooth conclusion. If team members are uncertain of their specific scope of responsibility, it's impossible for them to deliver what's expected.
8. Interpersonal problems: Interpersonal problems may be unavoidable. However, if they are not managed well, that can lead to low employee retention, poor morale and other issues, including missed deadlines and poor quality work.
9. Excessive quality problems: During normal development phases, the lack of quality may be obscured by explaining that the factors not currently present or not currently working will be delivered in the future. Nevertheless, at some point in the project, you must draw the line: Either hit the rescue button or accept the fact that the problems are within expectations.
10. Unknown factors: You can't anticipate, predict and mitigate every variable–at least not without a substantial increase in the project's cost and timeline. But regular review of high-impact and high-probability risks will help the extended project team understand the expected behaviors when a risk comes to fruition. Any events that cannot be accommodated in the project plan should trigger a project rescue.
Knowledge Isn't Always Power
Even if you're aware of the warning signs of project failure, suppression factors–such as fear of blame, looking foolish, laziness or unwillingness to admit error–could prevent you from recognizing the true status of a project and taking action to correct the problems.
When symptoms indicate that you have reached a project break point–the point that signals an inevitable downward spiral toward project failure–you need to decide: Will you rescue the project or continue operating within the same boundaries and assumptions that led to the project break point? (See “Seven Steps to Success .”)
While it may seem counterintuitive, the process of formalizing progress and status reports–combined with keeping project managers out of the technical details and designating those tasks to IT staffers–can keep projects on track.
If a project requires a restart, you may want to change the project manager. One primary reason why major systems upgrades or architecture overhauls fail is that a relatively inexperienced project manager is at the helm. An inexperienced project manager might take advantage of the informal reporting structures and provide status updates while passing colleagues in the hallway. A rigid reporting structure, however, makes it easier for the project sponsor to understand progress and delays.
Many management experts believe that the project manager–a key player in keeping a project on track–should not take on technical tasks. That may violate the operating procedure of campus IT shops, but the separation of duties is worth considering on major projects.
The most unpleasant choice–canceling the project–might be appropriate in some situations. However, a well-planned and well-defined project rescue can reverse the downward spiral by challenging the status quo and enabling project team members to make the difficult decisions necessary to salvage the initiative.
Most projects are well into the development phase (and some are even in the testing phase) before a case can be made to formerly launch an intervention. However, by spotting the telltale signs early on in the project life cycle, you may be able to salvage much of the original scope of a project that is failing.
For a project intervention to succeed, don't assign blame. Instead, zero in on what's hindering success and how to move forward without running into the same problems again.
• Admit you have a problem: This is undeniably difficult to do. People will plead, “I just need one more month. I'm so close.” But, in many situations, that last month never delivers. You cannot spend your way out of an unsalvageable project, so cut your losses.
• Pause the project: By continuing unchanged, you burn more hours and costs against the project–spinning your wheels because you really don't know where you're going. Taking a break gives your project team a chance to regroup, defuse and make a new plan.
• Conduct a project audit: A project audit will help you find the root cause of why things are going wrong. From my experience, the primary reason a project spirals downward is that the project manager is relatively inexperienced for the project's size and/or scope. The audit will also reveal whether team members understand their scope of responsibilities, deliverables and dependencies.
• Assess the effort to complete the project: Realistically, what will it take to finish the project? Review the project and determine how long it takes your team to complete tasks. Don't assume things will proceed better or that tasks will take less time.
• Validate the return on investment: Someone had a reason to implement the project in the first place. Figure out if the business-case benefits still make the project worth continuing. The project's business owner and key stakeholders need to be consulted.
• Review for relevance: Does it still make sense to pursue and fund this project? Compare the value of this project to other IT alternatives and initiatives. A different project may have become more important.
• Restart the project: Relaunch the project with new plan, cost and delivery estimates. Beware of roadblocks, such as apathy and disbelief, which may stall your rescued project. People take their cues from the leader, so tell people the project is important and then act as though it is.
Joseph J. Zucchero is CIO of General Parts in North Carolina. Additional reporting by Lee Copeland.