The IT world is no stranger to projects that go down in flames. In fact, anyone who has had the unenviable pleasure of participating in a failed IT effort likely sensed its demise well before the go-live date. That sixth sense is invaluable in a competitive field like IT -- but only if it is acted on promptly and professionally.
Whether you're looking to avoid being saddled to a dud or to steer a doomed rollout out of the ditch, you must be able to recognize the signs of imminent failure well before a project comes apart at the seams. It can be a career-saver.
We have gathered 11 red flags to look for in assessing IT project health. Be proactive whenever you encounter one -- or if you can, simply walk away. You career depends on it.
Red flag No. 1: The project has launched without senior buy-in
Want a surefire recipe for IT project failure? Dig in before you get top-tier buy-in.
Here's how it usually transpires: A strong personality in the company has an absolutely "terrific" idea or solution and begins to plan meetings and allocate resources without waiting to see if senior management agrees. Many of these projects proceed, until the point where real money must be spent; then they collapse completely. Often everyone on the project, except its originator, doesn't even know the project hasn't been approved, nor that budget hasn't been allocated.
To avoid being saddled to such a project, always ask who in senior management is a sponsor and what the budget allocation is. Don't accept answers claiming no budget has been allocated because people don't know what it is going to cost until the project is under way.
If you're a consultant being pulled into the project, make sure that significant budget has been allocated before you attend the second meeting. You don't have to know the final budget figure, but you need to know that senior management is serious in its support for the project and has some clue about the eventual cost. I've been on large projects that were obviously going to cost millions of dollars to solve, but management was thinking more in the few thousand-dollar range. Don't get stuck working on that project.
Red flag No. 2: No detailed project plan exists
Project-planning software can be complex and frustrating to use. The only thing I hate more than architecting a detailed project plan is being involved in a project that doesn't have one. Formal project plans force the project manager, and everyone involved, to consider all the necessary phases and steps, and the order in which to proceed. To paraphrase an oft-quoted line, "Failure to plan is planning to fail."
Any project with an estimated timeline longer than two weeks should have a solid, detailed project plan. If you are presented with a project that does not, create your own. Besides forcing everyone to consider all the tasks and tactics, doing so will force them to come up with realistic timetables. A detailed project plan is far better than your "best guess" or a gut feeling.
Red flag No. 3: Meetings have been scheduled without concern for team member availability
When a project or team leader arbitrarily schedules meetings that are in conflict with other important, already standing meetings, you know your project is doomed. Doing so ensures that vital team members will be absent, thereby undercutting the purpose and effectiveness of your meeting.
The solution is simple: Spend a little time before scheduling project meetings to learn the current calendars of important attendees. More important, find the handful of common availabilities, and pick a timeslot. Don't go too far in allowing participants to vote between multiple timeslots -- this can lead to bad feelings from those whose proposed timeslots get turned down. Instead, be authoritative and pick a time you know everyone can live with. You can adjust afterward if necessary. Also be sure to publicize your team's standing meeting times so that others don't accidentally schedule over it.
Also, hint to the wise: Schedule meetings before lunch, if possible. People are generally more productive and more likely to show up earlier in the day. Meetings after lunch often have to fight the slugglishness of full bellies and compete with the priorities and dramas earned during the first half of the day. Meetings held just after lunch or at the very end of the workday can be the least attended and least productive.
Red flag No. 4: Users have had little (to no) early involvement
Everyone taking even a basic IT class in college is taught to involve users early when launching any project or decision-making process. That's why it is so surprising to see large and complex projects almost entirely completed before users are brought in to provide their advice. I've seen many large, evolving projects completely derailed because users tell leaders that a particular process hasn't been done that way for a long time and the new process doesn't work either.
Make sure real users, or their advocates, are invited to the project from the get-go. You cannot have them in too early. The more involvement you have from users, the greater your chance of success. If your project covers multiple departments, make sure to have a user representative from each department. Also be sure the users that have been invited to participate are open to the project's objectives and feel they can voice their real opinion. Involving users earlier typically results in faster and better acceptance if problems develop or unpopular process changes are necessary.
Red flag No. 5: The project targets the minimum specs
Nothing kills project success like buying the bare-minimum hardware.
Vendors are notorious for trying to keep the cost of a project down by underselling the hardware necessary for optimum results. Vendors often offer a "bare minimum" spec and the recommended hardware buy. Smart project leaders will go beyond even the recommended hardware specs; if something happens, at least the vendors and your customers won't be pointing their fingers at penny-wise, pound-foolish hardware purchase decisions. Also, make sure all purchased hardware and software is compatible and tested with each other. You don't want either side pointing fingers early if something goes wrong.
Sometimes the devil is in the details when it comes to purchasing technology. For instance, if a vendor says it has great experience with MySQL running on Linux, be careful about requiring MySQL to run on Windows. The vendor may say they can do it, but may not have much experience in doing so. If you deviate from what the vendor recommends, make sure you get the vendor's acceptance in writing. Plus, it never hurts to check with past customers who shared a similar configuration to learn the good and bad of how things went if they deviated, even slightly, from the recommended specs.
Red flag No. 6: Testing is an afterthought
Testing is essential to project success. Whether it is unit testing (which tests one facet of the system) or integrated testing (which tests all components, including existing interfacing systems), testing should be done by current employees along with a testing script. The testing script should include all inputs, step by step, that testers should make. And you should detail, ahead of time, what all outputs should look like.
Testing data and processes should vet all scenarios, including good and bad data. Sometimes results from known bad data are more interesting than those of a desired outcome. Testing should include load tests to see how the system and network respond under heavy utilization. Testers should understand expected outcomes and be expected to report all deviations.
Red flag No. 7: No recovery plan is in place in the event of failure
Despite our best efforts, plans don't always go as expected. Every project leader needs to know what go-live success looks like -- and when it's time to admit failure and begin again another day. Every project should have a go-live backup plan in case failure becomes the only option.
Too many go-live events are driven by the belief that "nothing can go wrong." Leaders of these projects often fail to make sure good backups are taken and verified. They don't develop protocols for defining success, nor outline what a failure looks like ahead of time. They don't prepare the team for what to do in the event of a go-live crash. Many brand-new projects hit a fatal stumbling block only to find out they can't go backward. This is poor planning.
With few exceptions, projects should plan for failure and, when the pain is too much, allow for failure back to the old system. Sure, failure is embarrassing and no one wants to plan for it. But not being able to recover during an extended service outage is usually career-ending.
Letting senior management know that you had a backup plan and followed it to a tee when the turds hit the fan is a way to win accolades. Letting an extended downtime event go on and on as you explain to management that there is no way back and the forward path isn't looking so pretty is a much different conversation. Plan to succeed, but have a plan for failure as well.
Red flag No. 8: Expert recommendations have been rebuffed without testing outcomes
There are people who ask for expert advice and listen, then choose a different path -- every time. Then they complain when something doesn't work right.
Don't be that person. Don't let that person make big decisions on your team. It's all right to ask for expert advice, only to do something different. That's human nature, and it's often the sign of a good leader. Just don't do it compulsively. More important, if you go against recommendations and the outcome doesn't work, don't blame the consultant.
Deviating from vendor or consultant recommendations means testing the results of your change before go-live. Even if the vendor or consultant agrees with your deviance from their recommendation, make sure the change is tested. Many projects have failed because project leaders "made a few small changes" that left vendors and consultants shaking their heads in the background. You'd be surprised by how many experts remain silent in the face of a very strong customer that seems to know better than the experienced consultants. Everybody wants to be friends. Everyone hopes it works out.
Don't hope. Test. And listen to your experts most of the time.
Red flag No. 9: The go-live date is a weekend or holiday
Many project leaders plan go-live events for the weekend or holidays because of lower chances of service disruption to employees or customers. While laudable, these windows also tend to be the times when tech support is harder to reach. You may have your primary vendor onsite, but third-party tech support may be closed or on call (and not returning calls in a timely manner), and the same may be true of your team. Talking to your best database troubleshooter over the phone while he's on vacation with his family is never optimal.
Red flag No. 10: Expectations have not been set
When a new system is going in to replace an old system, it's helpful for everyone to understand the new expectations. How is the new system going to act? How are transactions and transaction times different? Who do end-users call if they have problems? How long is the go-live troubleshooting team going to be onsite? A new system will always frustrate people, but if you set realistic expectations and give people accelerated support options, problems tend to go away faster and you end up with more satisfied customers sooner.
Red flag No. 11: Skimp on training
I can't tell you how many project leaders will pilfer the training budget when faced with a budget overrun. Usually it is a smug, supersmart leader who claims the system is so easy that users don't really need all the training. If you hear, "Heck, we'll train every other person with half the classes and they can train each other," or "Our users are pretty good at figuring out things; they can figure this new system out in a few days," you know you're in for failure. It's not just users who need training, but project leaders, troubleshooters, and help-desk staff, too. Be ready to delay the project if appropriate training is not given.
This story, "11 signs your IT project is doomed" was originally published by InfoWorld.