4. Manage it closely. Even the most minutely detailed consulting agreements can’t cover everything, especially as changes or clarifications are needed. Consultants can be very useful, Price says, but you need to state in no uncertain terms what you want them to do, and manage them very closely.
Scenario 2: The incredible expanding IT project
Three years ago, a major West Coast tech services company decided to roll out a Web-based content management system to handle its internal communications. But inexorably, the features list began to grow. Could they use the same system for customer support? Sure, said the systems integrator. How about selling research reports to clients? No problem. The budget for the project rapidly climbed to $100 million.
The catch? The systems integrator was also the software vendor who’d built the content management system. The vendor had never met a problem their software couldn’t solve -- for millions in additional development fees, naturally.
“By the time they contacted us, the company had spent closer to $280 million, and the percentage of test cases that actually worked was zero,” says George Kondrach, executive VP of Innodata Isogen, a content supply chain consultancy. Innodata recommended scaling down the project and bringing in third-party software to handle jobs the content management system wasn’t designed to do. Kondrach says Innodata could have fixed the problems for about $10 million, but that would have meant the client would have had to admit failure. Instead, the client continues to spend millions each year trying to make the system work.
How do you keep a project from spiraling into unfathomable depths?
1. Be vendor agnostic. Hiring an integrator with a vested interest or one whose expertise is limited to a single vendor’s products is a recipe for disaster, Kondrach says. Any proprietary solution can limit options later.
2. Know thy software. Understand the difference between a software feature and a new product category. Don’t try to use one system to do the work of five different applications.
3. Don’t bury your mistakes. Admitting failure early is one the best things you can do. “Don’t euphemize a project that’s failing as ‘making progress’ or ‘iterative development,’” says Kondrach. “It’s better to acknowledge that your initial design decisions are not workable.”
4. Know when to give up. “Don’t throw good money after bad,” says Patrick Gray, president of Prevoyance Group, a New York-based consulting firm. “It’s painful, but it’s still better to waste $100 million than $200 million.”
Scenario 3: The hacker from hell
Last year, the Web site of a large financial services firm was hacked. Acting quickly, the company took down its primary site and brought a duplicate one online with virtually no service hiccups. But what the firm didn’t know was that the attacker had planted malicious code on the site months earlier -- enough time for his backdoor to be propagated into all the site’s backup sets. So when the second site came online, the hacker continued accessing user accounts. The firm had to go completely offline for several hours while it identified and fixed the problem.
By relying on a single application or platform for core business functions, you create a single point of failure, says John Pironti, principal security consultant for Unisys. In this case, the same flawed code was used in the firm’s primary and backup Web sites -- which the hacker happily exploited.