InformationWeek published a fantastic article detailing the 5 reasons technology projects fail.
- Technology ROI numbers are mostly fiction.
- ROI rarely drives the technology investment decision.
- There’s rarely any long-term accountability in technology.
- Detailed plans are the enemy.
- Bringing in the big outside guns only ensures that someone will get shot.
I’ve copied the entire article here to make reading easier, but please at least click on the original article link at the bottom of the page to let them know you read their fantastic content.
Also, InformationWeek is a free weekly publication which they mail to you at zero cost. Think about it!
Today’s IT groups make too many ROI guesstimates and have too little accountability, says this financial industry IT exec, in his debut column for InformationWeek.
By Coverlet Meshing, InformationWeek
April 08, 2013
Depending on which consultancy you ask and what they’re ultimately trying to sell you, the failure rate for technology projects is anywhere from 37% to 75%. I especially like the 37% — not 35, but 37 — because those extra 2 percentage points give the kind of false precision that suggests authenticity.
If managing technology pays your mortgage, you usually explain away those failures by pointing to your gray world: gray requirements, gray resources, gray planning, gray risks. The only vibrant color in your life is the brilliant hue of overly optimistic project scheduling.
But that’s not the whole story. Here are five unspoken reasons IT projects fail as often as they do, drawn from my two decades as an IT manager and executive in the financial services industry.
1. Technology ROI numbers are mostly fiction.
The most complex variable in the ROI equation — one that’s usually ignored — is the cost of the business re-architecture required to consume a proposed technology. If you take away nothing else from this article, know that technology demands business transformation, and that’s usually the largest hidden cost.
The rule of thumb for calculating the risk of rolling out new technology is this: the higher the buy-or-build price, the larger and more expensive the required redesign of your business processes.
Rethinking your processes is just one disruptive element. Think about all the non-tool-based training your company needs to do before introducing a new tool, and think about all the cultural changes it needs to make to pave the way for new technology adoption.
As soon as you bring culture into the equation, determining the potential cost of an IT engagement becomes exponentially more difficult. ROI analysis will necessarily enter gray country, leaving the comforts of hard science and treading into the imprecision of social science.
It’s not impossible to get the calculation right (or close), but here’s the kicker: No matter how solid or technically sophisticated an ROI analysis may be…
2. ROI rarely drives the technology investment decision.
In most companies, determining the potential costs and benefits of a tech investment is neither art nor science. Rather, it’s an elaborate and often dishonest marketing exercise (upward and outward-facing) aimed at persuading senior stakeholders that one HIPPO should win out.
Having worked for both tiny startups and massive multinationals, I’ve learned that the larger the company, the greater the chance that what drives tech investments isn’t what’s best for the business, but what’s best for the decision-maker’s career. And in large companies, those two factors rarely align.
At my previous employer, a large financial institution that has gone belly up, I attended a great many senior management off-sites. One particular exchange with a senior exec has haunted me for more than a decade. During a breakout session, a midlevel manager asked what he should do if he were competing with his internal peers for funding when he knew that their functions and ideas were more important to the bank. The answer from the senior exec: Treat your role as the most important and do everything you can to win that funding fight. In other words, putting yourself first is in the best interests of the company.
The unintended consequence of this kind of thinking was the financial community’s spectacular collapse. The unintended consequence in IT — and this isn’t unique to my former employer — is that project funding more often goes to mildly technical marketers and shameless salespeople, not to hardcore engineers and scientists who let the data drive.
Rare is the executive who puts the company’s interests before his or her own (financial stability, career progression, personal brand building). And that kind of behavior isn’t exclusive to executives; it’s pervasive from the boardroom to the mailroom.
That’s not the only unlearned lesson of the banking crisis of 2008….
3. There’s rarely any long-term accountability in technology.
Multi-year projects are repeatedly green-lit with an implicit understanding that most of the current decision-makers will have moved on or up by the time the project is set to deliver.
The handover of the project’s reins to the next-level-downs actually helps the brand of the people moving up. Project failure can conveniently get recast as a failure of execution by the original decision-makers, most of whom are now more senior and no longer directly responsible. If only they hadn’t answered management’s higher calling. This phenomenon, the dynamic behind “failing up,” is endemic to all corporate life, not just technology.
It sounds insidious (and it is), but what’s driving the cycle is pretty human. Most people want to see career progression with or without the requisite blood, sweat and tears. In technology, where product lifecycles are usually three to five years max, staying in the same job for more than two or three years signals a lack of drive, ambition, skills.
The message: Change jobs or be considered irrelevant. Upgrade or be upgraded. So there’s a structural incentive for career mobility. Long-term projects are consequently damned if you move and damned if you don’t.
The usual response to this short-term culture, a three- to five-year vesting period for bonuses, doesn’t actually encourage long-term thinking. Not when internal mobility is involved and definitely not when there’s market- and industry-level competition for talent.
It should never come as a surprise when “too big to fail” stumbles, and spectacularly. What should be a surprise is when project planning contributes to that failure. What’s missing in the business and/or IT project plan is agility, the organizational ability to act quickly and decisively. Because the opposite of big isn’t small; it’s nimble. It’s culturally porous, focused on transparency. It’s responsive and adaptive.
Helmuth von Moltke got it only half right when he said: “No plan survives first contact with the enemy.” He should have said…
4. Detailed plans are the enemy.
They’re rigid, set too far in advance and take up so much management time that long-term planning is itself a risk to be mitigated. Project plans that extend past 90 days are as accurate as TV weather predictions.
The challenge if you’re big is that it takes you longer than 90 days to get out of the bathroom every morning, which means that your business conditions — the most important context for your IT projects — change faster than the project. It’s why users often reject technology that gives them what they asked for: By the time the technology is delivered, it’s no longer what they need.
When the world outside is changing rapidly, IT projects should be forced into redefining themselves — and often. Scope creep should be mandatory. Without it, IT’s relevancy comes into question. With it comes the adoption of any new deliverable.
The institutional response to the need for speed is to bring in outside accelerators — the IBMs if your company can afford them or the TCSs if they can’t. The surprising part of that decision is that…
5. Bringing in the big outside guns only ensures that someone will get shot.
It’s the corporate equivalent of keeping a loaded .22 on your nightstand. There are two truths in that analogy. The first is that the only solid advantage outsourcers provide is that they’re easy targets. The second is that .22s do more wounding than killing. They just make a mess that you have to clean up yourself.
The legitimacy that the big-name onshore outsourcers add to a project has less to do with increasing time-to-market and mitigating execution risk and more to do with the arcane calculus of career risk mitigation (see Reasons 2 and 3).
The cost savings that the offshore outsourcers promise are rarely realized and come at the price of increased project complexity. It’s already difficult to speak in terms of cultural transformation. Now imagine having to merge and change four massive cultures: your corporate culture, their corporate culture, your national culture and their national culture.
Finally, bringing in outsiders keeps your workforce dumb. It locks you into a vendor interested in getting you hooked on its proprietary black box, the corporate equivalent of a gateway drug.
Outsourcing does transform IT: Engineering as a core competency gets replaced by the cult of sigma; technical leadership gets replaced by scientistic project management. Eventually, the organization has no internal decision-makers with any depth of technical experience. They have no choice but to snort the IBM salesman’s lines.
And when the business eventually loses its competitive advantage and starts to become obsolete, it has no choice but to focus on cost reduction; no choice but to light the TCS pipe.
Original Article: http://www.informationweek.com/global-cio/interviews/why-tech-projects-fail-5-unspoken-reason/240152282
Leave A Comment