How to Know Your IT Project is Headed for Disaster
Failed IT projects are the stuff of legend. IT projects can derail for so many reasons, it’s a wonder they ever succeed. Yet, as with most areas of life, you’re unlikely to be blindsided with trouble if you’re on the lookout for the warning signs.
To help increase the likelihood that your project succeeds, we present seven sure signs of impending disaster you should address sooner—rather than later.
The project lacks executive support.
If key executives or stakeholders have competing priorities or do not support a particular IT project, you can bet that project is headed for trouble. Todd Williams, president of the project management consultancy eCameron and author of Rescue the Problem Project says that one of the first questions he asks when beginning work on a new project is, “Does the project align to the strategic goals of the company?”
Asking this question and uncovering its answer can be key to a turnaround, as was the case when Williams was hired by a Boston company. The Boston firm had recently purchased a northern Massachusetts company that was itself recently acquired by a Canadian company. Each business unit was interested in a different aspect of a project related to some software the Canadian company had developed – but in different ways. Until Williams sorted through the complicated priorities around the software project for each unit of the company, it was impossible to establish what were truly the strategic goals, and what priorities the executives were actually supporting.
People don’t agree on what the final project looks like.
A sure sign that a project is derailing or will do so in the near future is lack of concrete requirements. Samad Aidane, an IT project management professional who hosts the blog Guerilla Project Management and the author of the upcoming book The Neuroscience of Project Management, says that oftentimes this arises because while at a conference a customer “fell in love” with a product or a vendor, and pushed for the product without clarifying what it will be used for and how the new system will meet specific needs.
Aidane believes much of IT project management success—in all areas—rests on capturing agreements. “You’d be surprised how many projects move forward with just a sketchy understanding,” he says. “The first things I look at are what the existing agreements are and understanding what the requirements are.” All too often these are overlooked because someone is nervous to rock the boat or there’s pressure on the team to move quickly past planning to delivery.
If the project management team has a totally different idea of where the project is going, you’re heading for trouble, says Williams. He also points to the problem of “falling in love with tech” as being a main cause for this. For example, many companies install ERP systems but only use 40% of their functions, he says. People fall for bells and whistles and implement things they don’t really need. In these cases, requirements haven’t actually been defined; it’s a project putting the tech cart before the business-needs horse.
Management won’t heed warnings or objections.
Adequate planning is key to a project’s success, but sometimes projects rush forward without adequate planning or preparation. The timeline becomes more important than the outcome, warns Kevin Ciccotti, an executive and corporate coach who focuses on the human side of project management through his consultancy The Human Factor Formula. In other words, “you’re lost but you’re making good time.”
Ciccotti points to an ERP project for which he was a business process owner. He was personally invested in the project’s success. “It would impact everything that I would do and my team would do; everything was changing,” he says. Early on Ciccotti realized that some of the stakeholders’ concerns were not being addressed, but he was told, “Planning is over; we don’t want to reinvent the wheel,” by those at the management levels above. The problem began much earlier when the initial consultants were told about these same concerns, but the consultants had brushed them off saying, “We understand, we’ve got your area of concern covered.” As it happened they did not, says Ciccotti. “When we went live it shut the entire production facility down,” he says. Eventually, he says, “We pushed through and made it work, but not without a lot of pain and workaround from areas within the organization.”
Your “schedule” is meaningless.
Another common cause for project management derailment is an unmanaged or mismanaged schedule. To increase the chances of project success, Aidane says that although you may have a rough deadline to start, after you gather requirements and conduct other aspects of the planning stage you must revisit the schedule. “A schedule needs to reflect reality, or what the work will actually take,” he says.
Unfortunately, Aidane says, the schedule is far too often a map of unrealistic hope and team members suffer from the discrepancy. “It’s a difference between realistic perception, and being created to look like we’ll meet this deadline,” he points out. If a schedule never receives any official written revision, if the team is working in an ad hoc manner selecting priorities, or if the schedule is revised in such a way that it merely documents what you’ve just done, your project’s in trouble, he says.
Another sign your schedule—and therefore project—is off: People stop checking in, says Ciccotti. They ascribe to a “no news is good news” approach and use avoidance tactics. Of course, this is highly ineffective, he says, but it doesn’t stop people from using it. Whether they’re afraid to ask for help or they worry that the consequences of admitting they’re behind are too great, the motivations can be powerful.
The project requires late-stage customizations or a project lead insists on new changes.
“Scope creep” is another common cause for project failures. “Scope is very important and precedes everything else,” says Aidane. “Again, there needs to be agreement on what this project will entail, which in turn affects and puts boundaries around requirements and affect schedules.
One sign you’ve got “scope creep,” which can encompass a number of issues, is that a vendor’s or in-company project team’s assessment of what is “complete” is different than the customer’s or end user’s. (Clearly this is closely related to requirements as well.) For example, the customer believed that the software would interface with its financial system, but what he didn’t understand is that it requires third-party tools to work with the system. The vendor believes it works, and doesn’t believe the third-party tools were its responsibility. “One party considers the need for more to be scope creep; another thinks it’s what was promised,” says Aidane. A similar situation occurs when the customer genuinely does not understand the limits of what they can get or, all too often, that there is a limit.
Ciccotti encountered this situation far too often in dealing with one executive earlier in his career. A project would get close to completion and be put in the test bed, he recounts, and this executive would want to redesign aspects that would result in 9-, 12-, even 18- month delays. “‘Hey, it’s just a little bit of code’ was the exec’s take,” says Ciccotti. “We called it scope creep; he called it improvement,” he says. Even where such changes are improvements, management must be willing to adjust schedules; if not, the human cost is high and the chances for project failure almost certain, he says.
You can’t quite answer the question, “Who is the customer?”
Williams came into one company to save a failing project. In the first project management meeting he attended, he observed that team members did not want to talk with the project manager. Upon investigation, Williams found that one level up in management, no one was giving direction to this project because it had already failed three times—nobody wanted to touch it. At this point the project was running 17 months behind.
Why? The definition around customer was unclear, says Williams. The original customer had been defined as the customers of the company itself who would be able to access services, and who could enter and track different aspects of their information. The problem was, an internal operations group also wanted to access the back-end and get some of the functionality they wanted. Achieving the internal users’ piece of the puzzle involved completely different requirements than achieving what the company’s customer needed. The operations VP had inserted herself into what was originally meant to be a small and limited project and turned it into a huge and risky one.
When Williams brought this information to the VP’s boss, the president, he shut that portion of the project down. The application for the more-limited project was successfully shown eight weeks later.
Nobody’s talking about the human factor.
Overlooking people’s “softer” side is a huge factor in project failures. “When we’re working on teams, people are critical to success,” says Ciccotti. “Process only takes it so far.” In his work he often finds that people don’t want to acknowledge that emotions drive us outside of the workplace—and in it.
At the end of the day, emotions are our key behavioral driver. Communication is a key component of the “human factor,” and bad or poor communication is a sure road to project failure.
“You’d be surprised how many times I’ve come into organizations to work with their project managers and teams only to find that no one was really communicating much at all,” he says. “The only times people were communicating was in the regular team meetings or the executive steering committee meetings, but even then, it’s more about telling everyone what’s going well, and not about telling them what’s true.”
In other words, poor communication is rampant generally, but especially in projects gone wrong. “I have never worked on or with any project team that was ultimately successful when there was poor or nonexistent communication,” he says. “Communication is the lynchpin to success.”