10 Warning Signs Your Education IT Implementation is Failing

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.