Poor communication between business and technology managers is certainly not the only culprit in failed IT projects. But it is, in fact, a major reason why more than 80% of such undertakings are late, over budget, short of expectations or simply undelivered. That’s according to a multiyear study by Stamford, Conn.-based research firm Gartner.
The disconnect can happen when an overenthusiastic business side does not involve IT in initial planning, or when IT managers don’t make an effort to participate. A good example, says Parker, is General Motors’ and Ford’s rapid move to start Covisint, an electronic business-to-business exchange for the automotive industry.
“If you ask functional managers at those companies off the record, they’ll tell you it’s been a huge failure,” says Parker of the struggling initiative. “There was no previous discussion of the investment. If the CIOs had been involved, they would have said, ‘We’re not ready.'”
The business side failed to bring in the technology department, but the fault falls as much on CIOs for failing to gain the ears of the CEOs, he says.
The wrong kind of communication, on the other hand, can be as bad as no communication at all. Reacting to issues without keeping strategy in mind, for example, leads to tasks masquerading as business goals. The point solutions that often result—such as multiple local databases on different platforms—often conflict with the approved architecture and incur high support costs. Parker advocates a more holistic approach to technical project planning, in which executive teams place the company’s IT goals within the larger strategy of the business.
Poorly communicated goals may also focus too much on the “how” and too little on the “what.” Business—as well as IT—managers often have preconceived notions of how to achieve what they want and, as a result, micromanage the technical details.
Endless examples of this particular error can be found among business-to-consumer e-commerce projects, says PricewaterhouseCoopers consulting partner Shanker Ramamurthy. With the technical approach of the dot-coms as their example, many business managers placed specific technical demands on their IT teams in order to match online competitors, or pushed for quick deployment to be a “first mover.” The result was systems that couldn’t be easily tied into the corporate IT architecture or were unsustainable.
“Unfortunately, people tend to focus on a specific set of financial constraints or a specific technical goal,” says Ramamurthy. The dialogue should instead strive for impartiality, with business and IT seeking solutions and goals that balance financial efficiency with technical capabilities.
Three Questions to Ask Before Starting a Project
Who’s paying?
It’s a good rule to question projects with little or ambiguous corporate backing. A good indicator of support is financial investment—especially when the money comes from multiple divisions.
How does it help the company?
Every business plan should have a document that lists each project goal alongside the corporate goal it supports; though tedious, such an exercise is invaluable in charting progress. This is typically the business owner’s responsibility, but the goals should be clear enough for you to create the document if it doesn’t exist.
What happens if it fails?
Of course, this happens only to other people, but it’s a good idea to know a project’s point of diminishing return. Which goals are critical? Is there a deadline after which the benefit no longer outweighs the cost? If the new system goes down, will the old or an alternate system be available as a backup?
Background Reading
IBM’s Advanced Business Institute offers conferences and workshops to help close the IT-business divide, at www.ibm.com/abi.
