Your department—information technology—has just played a starring role in blowing a multimillion-dollar enterprise software project. The intense glare from the CEO, CFO and other business leaders is squarely focused on the CIO, VP of applications, project managers and business analysts charged with making sure that this didn’t happen.
Of course, IT is never 100 percent at fault for any massive project—whether an ERP or CRM implementation, mainframe migration or networking upgrade. The business side usually plays its part (think: “Best Supporting Actor in an IT Debacle”).
But the unfortunate and unfair fact is that because these initiatives are considered “technology projects,” the business will most always look in IT’s direction when there’s blame to be tossed around.
That’s just a fact of life in IT, says Chris Curran, who’s both a consulting partner at Diamond Management & Techonology Consultants and its CTO. Curran has seen plenty of IT carnage over the years: CIOs who resist against changing implementation methods—holding firmly to the waterfall when agile is the best option—and killing projects and their careers; multi-vendor and system integrator “teams” that backstab each other and submarine IT’s credibility; and project managers who get “splattered” because an implementation goes off the rails, Curran says. (He says with some wonder that failures never seem to affect the vendors involved: “It’s never their fault,” he says, “and the vendors tend to keep above the fray.”)
Curran mentions one insurance company CIO who was betrayed by warring integrators and vendors working on a project and was relegated to “managing IT,”—and the CFO took the project reins. “The CIO was on the glide path to leave after that happened,” Curran says. “They spent two more years on that project, and it went belly up.” (To get the CFO on your side, read “How to Win CFO Friends and Influence Business People.”)
In this instance, Curran says, the “CIO didn’t have the credibility with senior leadership team [to show] that he could manage through rocky vendor issues.”
The “Alignment-Accountability” Paradox
No sane executive would dismiss the strategic importance of IT today. And most don’t: An IT Governance Institute study, consisting of more than 250 interviews with executives of both large and small companies in a variety of industry sectors, found that half of the respondents said that IT is “very important to the enterprise,” and three-quarters stated that they align IT and business strategies.
When it came to IT project accountability, “executive management” was identified as the group held accountable for IT governance in 71 percent of the enterprises.
That’s all well and good.
But when it comes to walking the walk with technology projects (and presumably when the ‘you-know-what’ hits the fan), non-IT executives appear to fall back on familiar rhetoric. In a similar 2009 survey of more than 500 IT professionals by ISACA, a nonprofit trade group focusing on corporate governance, nearly half of respondents said “the CIO is responsible for ensuring that stakeholder returns on IT-related investments are optimized,” notes the survey report.
Just 20 percent stated that the responsibility lies with the board, the CEO or the CFO. “The business is delegating ownership of value to IT,” notes Robert Stroud, international VP of ISACA in the report, “when generally accepted IT governance guidance recommends that it should remain with the business.”
Curran takes those results a step further. “Business investments need to have business accountability,” Curran says. “But when a project goes south, especially high-profile ERP implementations, IT gets blamed—but it’s not an IT project.”
In addition, Curran is pessimistic that CIOs and senior IT leaders can do enough “damage control” after a problematic project. “I’ve never seen any cases where a CIO just moved along like, ‘Everything’s fine,'” he says. “Often, they’re eventually demoted or pushed off into some operational role. Once you have a high-profile project that has your name on it and it fails, I don’t know if you can recover.”
What IT Can Do to Prevent Failure
CIOs who enter into $200 million Oracle ERP projects know the stakes, Curran says. “These large programs—the multi-hundred-million-dollar, multiyear projects—they just create such a peak to fall from,” he adds. Even worse is when project teams set concrete, seemingly perfect expectations with the board and Wall Street about project cost and length. “But they don’t know squat about what’s going to happen tomorrow,” he says.
Curran’s advice for such massive undertakings, which CIOs and analysts talk up but many don’t follow, is practical: Think bite-sized project chunks and set proper expectations.
For instance, CIOs and program managers should say: “We know Company A spent $300 million on a similar project. Company B went two years over budget and spent half a billion. And Company C spent a $100 million,'” Curran says. “We know it’s going to be somewhere in this neighborhood, but we’re going to do it in chunks so that we can stomach it.” (For Curran’s views on project “influencers,” see “How a CIO Can Influence Project Success.”)
He also advises his clients and their IT shops to embrace change and transparency—even if it hurts at first. “The corporate culture—the status quo—tends to be: ‘Everything’s good. We don’t talk about problems until they are near unrecoverable, because we know people don’t like bad news,'” Curran says. But there are always going to be problems—vendor issues, or architecture, compliance or performance problems.
Curran says that the critical change in mindset has to be this: Problems and issues are good as long as we manage and talk about them.
“For some reason,” he adds, “we haven’t learned as an IT industry about driving incremental planning and change, which, in my mind, would help to mitigate the high rises and high falls of project failures.”
Do you Tweet? Follow me on Twitter @twailgum. Follow everything from CIO.com on Twitter @CIOonline.