Featured Product
This Week in Quality Digest Live
Quality Insider Features
Don’t underestimate the power of telling your story
Oak Ridge National Laboratory
Hafnium oxide key to novel applications
William A. Levinson
Deciding whether you need CAPA or a bigger boat
Matthew T. Hughes
Two engineers explain how heat waves threaten everything from cars to computers

More Features

Quality Insider News
To be unveiled during PACK EXPO Las Vegas at the Hiperbaric booth, No. N-10857
Educating the next generation of machinists with state-of-the-industry equipment
In a first, researchers have observed how lithium ions flow through a battery interface
Air-extend/spring-retract moves probe out of the way
Precision cutting tools maker gains visibility and process management across product life cycles
Expanded offering includes Smartscope E-series for 3-axis video measurement
Accelerates CAM programming time 80% to make U.S. manufacturers more productive
Pioneers new shape-memory alloys
A Heart for Science initiative brings STEM to young people

More News

Tripp Babbitt

Quality Insider

The Information Technology Conundrum

New methods and thinking for failing IT projects

Published: Wednesday, November 2, 2011 - 13:31

Information technology is failing us. Service organizations the world over have been left to sift through the carnage of IT projects that have failed. Undeterred, they seem to quickly embrace the next IT project before the last is given a proper burial.

The research and evidence on failed IT projects is undeniable. A study by the Saïid Business School on 1,500 IT projects worth $245 billion found that the larger the project, the larger the cost overrun—IT projects that turn into money pits are called “black swan” projects. The book, Dangerous Enthusiasms, by Robin Gauld and Shaun Goldfinch (Otago University Press, 2006), notes that 20 to 30 percent of IT projects are abandoned completely, and 30 to 60 percent of them don’t work properly or have cost overruns.

More evidence

In Indiana, the Family and Social Services Administration (FSSA) secretary came into government with a firm political ideology and passion for privatization. Getting knowledge and evidence wasn’t just overlooked; it was ignored. The result was a 10-year, $1 billion project awarded to IBM and partners during which contact centers, scripts, interactive voice response (IVR) systems, and new IT systems replaced the old manual system. However, the project was scrapped because the move from case workers to high-tech contact centers created an inability to determine petitioners’ eligibility for service. The governor cancelled the project, and IBM and the state of Indiana are still suing each other.

In 2004, John Seddon, founder of Vanguard Consulting, predicted that the £12 billion National Health Service (NHS) IT project would be a failure, and it was scrapped in 2010. The project was already £700 million over budget.

But this trend is not just in government: Levi Strauss, Kmart, The Hershey Co., Auto Windscreens, and many others companies have paid a heavy price for IT projects that have gone wrong.

I know of no study on IVR systems, but I have never stepped over a threshold of a company where they work. IT suppliers always claim cost savings, but when I do an analysis, I always see increased total costs. The IT suppliers point to lower transaction costs and always miss the cost of failure demand (i.e., demand caused by a failure to do something or do something right for a customer, according to Seddon). When customers have to call back to get answers, you are not saving money because transactions increase and revenue is lost from customer frustration.

Websites and internal portals are no better. I recently worked with a company that used an internal portal to get IT requests. When we studied the system, we discovered that almost every user that requested service through the portal had to be called back for clarification. This led to delays and frustration for users.

In health care, organizations frustrated with health care costs are turning to health information technology (HIT) in the form of electronic medical records. A new term has arisen to describe the failures of HIT—“e-iatrogenesis,” which are unintended errors from the design of health care information systems as users interact with systems differently than anticipated. About 25 percent of medication errors—in whole or in part—involve HIT.

Flawed “fixes” for IT problems

The research and evidence are overwhelming. So how do organizations try to overcome their IT problems? Consulting and internal entities present a number of “fixes.” They include:
• Better planning and management of scope
• Better governance
• Better contract management
• Capability maturity model (CMM) or capability maturity model integration (CMMi)
• Better project management
• Better testing
• Better documentation
• Agile

Most of those bullet points are costly and require more nonvalue-added activities. For instance, having management focus on managing scope, project management, and contracts requires time and resources spent away from value-creating software development. It’s true that the agile method does things faster; however, it does the wrong thing faster.

So, where should the focus be?

Technology vendors focus largely on profit. They believe that to make this profit, they must sell software. The solutions will always involve software. There is nothing wrong with profit, but it should come from being able to add value to customers. This is something Toyota understands or at least used to understand.

For software customers, it is easy to identify your IT vendors’ interest. If they are constantly pointing to the contract and managing scope, they are focused on the wrong things. The relationship should be to create value by working together. Cooperation is always better.

Three stages to improvement

Cooperation requires a different method. Improving the design and management of work is paramount to sustainable improvement.

The first stage is to “get knowledge.” This means to understand your organization as a system. The system is comprised of everything: processes, work design, technology, measures, management roles, structure, procedures, and much more. When you study your organization outside-in as a system, you will discover that how management thinks about the system drives both the design and the performance of the organization. Unfortunately, much of how management thinks is based on assumptions and not evidence or knowledge. Information technology vendors perpetuate assumptions with best practices and standardized software.

When you study your organization as a system, many counterintuitive things are discovered. The aforementioned company that turned off its internal portal discovered that a standardized IT system that users submitted requests into could not absorb the variety of demands from users. What you can learn in your organization about management assumptions is dependent on studying your organization end to end, as a system, from a customer perspective.

Stage two is to improve your system before you bring in IT. You are just kidding yourself if you believe you can improve by ignoring the design and management of work. Roles, measures, and methods of doing and managing the work will all need to change in the system before IT can make improvement efficient, effective, and sustainable. Not addressing management thinking problems and the design of the work will lead to disappointment in what you get from IT.

Stage three is then to involve IT and the many good things that IT can bring when you have a well-designed system and management thinking based in fact rather than assumption.

The consequences of not taking this three-stage approach are stark. Project overruns, costs increase, entrapping technology for workers and customers to navigate, unsustainable improvement, and the disappearance of bottom-line profits.

Failing IT projects are a product of management thinking. Armed with assumptions, management lays the foundation for failure. The way to successful IT projects is better work design through improved thinking, which comes through knowledge outside-in, from a customer’s perspective, as a system. Doing this can eliminate the need for a new IT project or require only very small IT changes rather than huge boat anchors that provide a drag on the organization.


About The Author

Tripp Babbitt’s picture

Tripp Babbitt

Tripp Babbitt the managing partner for The 95 Method - Executive Education and Advisors. The 95 Method is about giving organizations a method to use new theories to grow business.  Babbitt can be reached at tripp@the95method.com. Reach him on LinkedIn at www.linkedin.com/in/trippbabbitt

Tripp also has a podcast and YouTube channel called, The Effective Executive.


First the System, then the technology


In a system, processes are only one component

I tried not to mention the word lean or systems thinking in this article as it has become divisive.  Deming didn't call it TQM and Ohno didn't call it lean.

Process improvement falls short of doing what needs to be done.  Changing the design and management of work is more than process.  It means our thinking has to change too.  I when I say thinking, I mean management thinking.  The industrialized, economy of scale, functional separation of work, etc. thinking of yesteryear is holding us back.  Every assumption that we have about design and management has to be challenged before technology is put in place.  Otherwise, we are only doing the wrong thing, righter.


First the Process, then Technology

Tripp is right. Having developed software for mainframes, minicomputers and microcomputers for the last four decades, the most common problem is trying to automate a broken process full of rework loops and workarounds.

First, simplify and streamline the process using Lean; then automate the process. Otherwise you are "hard coding" mistakes, errors and inefficiencies into the software which is much harder to change than a manual process.

Too many companies try to rewrite existing systems rather than fix the 4% of the software that's buggy or enhancement prone. As Frederick Brooks pointed out in The Mythical Man Month, 4% of IBM's 360 code had 64% of the defects. The same is true of all systems that have been around awhile. 4% of the code is buggy; fix it. 4% of the code requires most of the enhancements; fix it by moving flexible things into data tables.

To find the 4% causing most of the mistakes and errors, use the Dirty 30" process for Six Sigma software