11 signs your IT project is doomed
By Roger A. Grimes,
InfoWorld |
Aug 8, 2013 6:00 AM
PT
No senior buy-in, minimum spec targets, a 'nothing can go wrong' mentality -- here's how to sense demise before your IT project meets its ignominious end
The IT world is no stranger to projects that go down in flames. 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.
Whether you're looking to avoid being saddled to a dud or to steer a doomed rollout out of the ditch, you must recognize the signs of imminent failure well before a project comes apart at the seams. It can be a career-saver.
We’ve 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. Your career depends on it.
Here's how it usually happens: A strong personality in the company has a "terrific" idea and plans meetings and allocates 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 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's going to cost until the project is underway.
Project-planning software can be complex and frustrating. 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 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 detailed project plan. If you’re presented with a project that doesn’t, 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 "best guesses" or gut feelings.
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 time before scheduling meetings to learn the calendars of important attendees. Find the common availabilities and pick a time slot. Don't go too far in allowing participants to vote -- this can lead to bad feelings from those whose proposed time slots get turned down. Instead, be authoritative and pick a time you know everyone can live with. Adjust afterward if necessary. Also, publicize your team's standing meeting times so others don't accidentally schedule over it.
Everyone taking even a basic IT class in college is taught to involve users early when launching any project. That's why it’s so surprising to see large, complex projects nearly complete before users are brought in to provide advice. I've seen many large, evolving projects 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 from the get-go. You cannot have them in too early. The more involvement they have, the greater your chance of success. If your project covers multiple departments, make sure to have user representatives from each. Also be sure users feel they can voice their real opinion.
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.
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), it 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, and testers should understand expected outcomes and be expected to report all deviations.
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 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.
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. It's often the sign of a good leader. Just don't do it compulsively. And if you go against recommendations and the outcome doesn't work, don't blame the consultant.
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.
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.
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.
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.
-
White Paper
-
White Paper
-
White Paper
-
White Paper
-
White Paper
-
White Paper
