10 Nov Your IT Vendor Just Imploded. Now What? Recovering from IT Project Failures.
It project failures happen all too frequently. What do you do if it happens to you?
An Unpleasant Meeting
Jane Doe grimaced as she walked to her next meeting. As CEO of a mid-sized company she had lots of meetings, but the one she was about to attend held a special place in her list of miserable experiences.
It was the meeting where she and her team had to yell at their information technology vendor.
A Brand New Solution
Jane’s CIO John had hired the vendor over a year ago. “We need a new CRM,” he had said, “and this vendor called Credulous is an official partner of one of the biggest platforms out there. They’ll come in and make it do whatever we need it to do.” John’s team had put together a detailed request for proposal, had vetted several other platforms and vendors, and had settled on Credulous. They were expensive, but their reputation was golden, and they promised they could have the company up and running in seven months. Jane had given John the go-ahead to hire them.
Credulous had come in and spent six months getting their system up and running at Jane’s company. In the seventh month, they brought in the first group of users for training. The problems and complaints started immediately. Users found the new system slow and unintuitive. Several of them complained that it was a step backward from their existing home-grown system. John found that the vendor had been a bit optimistic in how it presented certain capabilities.
After the first disastrous week of training, John pulled the Credulous project manager aside. “We can’t deploy it like this,” he said. “The users will have my hide. We need to address their issues ASAP.” The project manager agreed. “We’ll take their list of issues and start fixing them right away.”
John reported back to Jane. “We ran into some issues during training, so out of an abundance of caution we’re going to address those and delay deployment by two months.” Jane wasn’t thrilled, but a couple of months delay for such a major system wasn’t the end of the world.
The Never Ending Story
The Credulous team went to work, attempting to address each of the issues brought up by the users. They tweaked screen designs, added fields, and moved menus around. One month turned to two, then to three. By this time the team had burned through the time allotted for customization and deployment, but the users were still unhappy. The Credulous team kept working, burning through the support time that had been built into their original contract. Each month they had another session with a key group of users. After each month the list of issues and changes got longer and longer.
On the project’s first anniversary, the Credulous account manager came to John with bad news. “We’ve burned through all of the money we originally charged you for this project, and we’ve absorbed quite a bit of cost ourselves. Your users keep changing the requirements, and some of the things they want are things that this system was never meant to do. We can’t keep working for free.” John scrambled and found some money in another budget, enabling him to extend the contract for three more months. The team kept working. “This is all I’ve got,” John said, “so we need to have this up and running next month no matter what.”
Hit Me With Your Best Shot
Another month passed, and John announced that the system was finally ready for deployment. There were still some issues to be resolved, he claimed, but the system was good enough to use. The in-house team would resolve those issues over time.
Deployment Day came, and the system rolled out to all of the users. They responded with a distinct lack of enthusiasm, and in some cases they responded with outright anger and hostility. “It takes me half a day to do what I used to do in ten minutes!” complained one angry sales rep. “How am I supposed to make my numbers like this?!” Other users complained that changes they had been promised had never materialized, or that the Credulous team had misunderstood and botched the change requests.
John tried to soothe the user community. “I know it’s tough at first, but give it some time and we’ll keep working to fix the issues. New systems are always a little wonky at first.”
A week later, and the complaints were even worse. The VP of Sales was livid; his team was missing their numbers for the first time all year, and they blamed the system. That’s when Jane got involved. John asked her to call the Credulous CEO and see if they could work something out.
And that’s what brought them to this meeting.
The Final Countdown
Jane walked into the conference room. John was already sitting there, as was the Credulous project manager and his CEO, Dave. John looked subdued, but Jane was angry. She sat down and launched into her opening salvo.
“Thank you for coming today. We started this project well over a year ago, and today my company’s staff tells me that this system is a mess. It doesn’t do the things it was supposed to do, my people can’t get their work done, and we’ve paid your organization a lot of money. What are we going to do about this?” Jane leaned forward, looking at each person at the table in turn.
John and the project manager looked down and squirmed uncomfortably, but Dave looked Jane in the eye and replied calmly. “We delivered exactly the system that you asked for. Once the users saw it, they asked for literally hundreds of changes, all of which we graciously accommodated. When the changes kept coming we absorbed dozens more at our own expense. We’ve been underwater on this project for months, but in an attempt to make your organization successful we’ve kept working. Now that it’s in deployment, the change requests are coming even faster. Why did you even choose this platform if it doesn’t meet your needs?”
We Told You So
Jane looked around at the CIO, who was quietly listening to Dave. She raised an eyebrow, and John got the hint. “Well, when we put out the RFP we were very clear about the features we required, and you told us that the system could do all of those things.”
Dave rolled his eyes and produced his copy of the RFP. “You did list a bunch of features, and we were honest and correct when we told you that the system could do those things. The problem is you asked about features, not how the system could enable the way your business works.”
Jane didn’t like the way this was going. “Regardless, we’ve been waiting months for a system and now it doesn’t work and my business is suffering.” She looked pointedly at Dave, her voice becoming more strident. “It’s your responsibility to solve this problem, and I want to hear how you’re going to do it and how quickly you’re going to fix this mess.”
Dave motioned to his project manager, and the two of them stood up. Dave replied in a conversational tone. “As far as I’m concerned, we fulfilled our end of the bargain and then some. It’s not our fault you don’t understand your own business, and we’re not bleeding anymore on your behalf. If that doesn’t satisfy you, I’ll see you in court.” With that, the Credulous team left the room.
Jane and John looked at each other. Now what?
IT Project Failures Happen
Many IT projects end in tears or lawsuits or both. IT project failures happen a lot. Depending on whose statistics you use, anywhere from 60-80% of IT projects fail. In fact, 17% of IT projects fail so badly that they threaten the very existence of the company. 75% of executives feel that “most or all” of their projects are doomed from the start.
The business needs a system, so it puts together an RFP and sends it out. Vendors claim they can meet all of the requirements, and they offer cheerful visions of quick deployments and happy users. Once things start moving everything is harder than it should be, costing more money and taking more time. Eventually one or both sides get sick of dealing with each other and everything implodes.
Why does this happen? And when it does, what can you do about it?
The Root Cause
Because technology is so expensive and complex, most IT teams and vendors focus on the technology as the most challenging part of any project. But in reality, it’s the people who are complex and poorly understood. Project managers gather minimal information about how the business operates or how internal processes function, and instead focus on generic, useless requirements like “must be fast and easy to use” or “the system must support Microsoft Outlook.”
The truth is that no packaged software or cloud vendor understands the intricacies of your business, and they’re not particularly motivated to learn those intricacies. They sell one-size-fits-most software, and generally speaking they rely on you to know whether or not that software will meet your needs.
When you don’t take the time to understand the needs and wants of your users the results will be tears, unemployment, or both. IT project failures happen when the system isn’t aligned to the needs of the business; you must build the system around the needs and wants of your users. If you’re fortunate, off-the-shelf software may be an important part of that system. If you’re not, you’ll try to shove it down their throats anyway.
The solution isn’t magical: focus on understanding the intricacies of your own business processes, how your people operate, and what obstacles exist that can be gracefully addressed through technology. In a successful software project, communication is the magic that makes everything work.
And don’t assume that the same team that keeps your infrastructure running is the right team to perform this task. Just because they know how to operate computers doesn’t mean they know how to perform a detailed requirements analysis and architect a new system. If you don’t have the expertise in house, go get it; the cost of a skilled project manager or analyst isn’t cheap, but it’s a lot less expensive than a failed project.
One of the great challenges is that acquiring and/or building the correct solution may cost one or two orders of magnitude than buying and deploying the wrong solution. Don’t fall for the false promise of a cheap solution; if you don’t have a thorough understanding of your users’ needs and wants you’ll end up paying for the same system two or three or four times.
So Now What?
You may find yourself in a situation like the one I’ve described above. If you’re in John’s role, you have some serious apologizing and re-work to do. If you’re in Jane’s role, you need to figure out whether you handed the job to the wrong person. In either case, you really need to start over with a clear understanding of what your users do, need, and want before you spend another nickel on development or deployment. Worse yet, you need to re-engage your angry users and make up for foisting a crappy system on them.
Creating great IT systems isn’t rocket science, but it is people science. Make sure you understand the people first.