CIO view: Three truths that bridge the great divide
Photo credit: "Conversations in Silos" by Michael Krigsman
Update 1/20/12: Thanks to Carlos Francavilla for translating this post into Spanish!!
This post summarizes my remarks to a group of senior government leaders embarking on an innovative and ambitious plan to improve health care delivery in their state. A key issue is fostering communication and collaboration between business stakeholders and IT.
Statistics tell us that almost 70 percent of IT projects are late, over-budget, or fail to deliver expected value (the worst fate of all). Numbers like these make clear there is a pervasive issue in the world of IT delivery.
Despite the glaring statistics, virtually all projects start with good intentions; after all, no sane team intends to fail. Although politics and self-interest sometimes push individuals to undermine team goals, most organizations that invest in technology expect positive results. Despite these good intentions, failures occur with striking regularity and few organizations take steps needed to prevent failures from arising.
For example, no one expected a meltdown when the state of Maine went live with a new Medicaid claims processing system that allowed medical providers to submit claims over the Internet. But meltdown is precisely what happened when unanticipated errors caused the system to handle claims incorrectly. Original project cost: $25 million. Additional work required to fix errors after going live: $30 million. Hassle caused to medical providers and lost credibility to state of Maine health administrators: priceless.
Similarly, everyone surely expected success when Minnesota’s Department of Human Services (DHS) started developing its HealthMatch program, "an automated system designed to match Minnesota residents with appropriate state-run health programs, based on eligibility." Nonetheless, the state eventually spent $41 million and settled a lawsuit with the software developer before deciding to shut down the failed program. Despite HealthMatch being a total loss, one enterprising Minnesota lawmaker subsequently introduced a bill directing the Department of Human Services to start over with a new external contractor.
As these examples demonstrate, good intentions and an honest soul are not sufficient to create successful IT projects. Many organizations simply lack the skills needed to navigate complex relationships between technology and business holders in an organization.
To avoid these problems, every CIO, project owner, and business leader should understand three basic principles:
1. Put strategy before technology
It may sound obvious but many organizations do not fully consider business strategy before deploying technology.
A prevailing view assumes that IT's primary role is managing technology. However, this limited perspective obscures a more profound truth: technology's highest value is helping the business achieve benefits such as driving innovation and competitive advantage, lowering costs, increasing market share, and so on. For those who love jargon, call this "IT enabling the business."
Projects fail when organizations perceive IT as folks who "keep the lights on." When business process owners and stakeholders do not involve IT with planning and strategy, they create mutual co-dependence with their IT counterparts. Eventually, IT itself completes this unhealthy relationship cycle by not taking sufficient time to understand and engage lines of business in a meaningful way. For those who love jargon, call this pattern "mutually assured self-destruction."
The technology must work or you're screwed »»
2. The technology must work or you're screwed
Strategy and higher value aside, flawed technology management creates its own nightmares.
Going back to Maine's Medicaid failure, CIO Magazine explains that the project failed due to lousy management and poor technology choices (emphasis added):
With 20/20 hindsight, they can now look back and see where the project went wrong. Hiring a vendor, CNSI, that had no experience in developing Medicaid claims systems was the first mistake. And that was compounded by the decision to build a new and relatively unproven technology platform for the entire system rather than, as other states have done, integrating a Web-based portal with back-end legacy systems. Thirdly, IT switched over to the new system overnight with no backup system in case something went wrong. And making matters worse, no end-to-end testing or training was conducted before the switch over. Indeed, the story of the Maine Medicaid Claims System is a classic example of how not to develop, deploy and manage an advanced Web services system.
Unproven technology also plagued Minnesota's HealthMatch program. A program assessment (PDF download), said the underlying technology had "features that are incomplete, error prone, and not always efficient to use." In the commercial sector, a customer of ERP vendor Epicor recently filed a lawsuit against the vendor, saying the software performed so poorly, "it was impossible to conduct comprehensive system testing." Moral of the story: although strategy is important, if you select the wrong technology then you're screwed.
3. Communication and collaboration enable function
Innovation means solving problems in novel ways. In enterprise technology, innovation often requires figuring out new ways to collect and route data than in the past; these new data flows are particularly valuable when they connect different parts of organization, to create unified business processes that cross departmental boundaries.
Building these unified business processes requires stakeholders on all sides to collaborate with IT, enterprise architects, and even themselves. Effective communication among these groups can result in data structures and systems that reflect needs and recommendations from all sides. Great systems are created when this type of cross-boundary collaboration happens.
Conversely, lack of communication results in systems are not useful to stakeholders and cause failed IT projects.
Once again, Maine's Medicare project offers an instructive example of communication done poorly; from CIO Magazine:
[T]he system’s problems could be laid at the door of poor project management and worse communication among the HHS IT staff, contractors and business users. For instance, programmers for the state and those working for CNSI would work on parts of the system without telling each other what they were doing.
When lines of business are unsatisfied with the value that IT delivers, lack of communication is a likely culprit.
STRATEGIC ADVICE
The challenges described in this post create "negative leverage" that can spiral out of control and cause expensive and unanticipated failures. To fight these negative effects, consider this advice:
- Establish formal and informal processes to encourage cross-boundary communication and collaboration. Be sure to include groups from line of business stakeholders, enterprise architects, technologists, and policy makers.
- Prioritize the issues. Technology-related projects involve broad strategy decisions and many technical details. Your decision-making must incorporate the ability to prioritize where to focus effort and investment of both time and money.
- Hold systematic, regular communication sessions and avoid being completely reactive. There are no set rules for how much communication is needed, but the goal is getting folks genuinely on the same page. Use a combination of email, face-to-face meetings, phone, instant messaging, and online collaboration spaces -- in short, use whatever tools will work.
Most important, learn to own and control your project. In the end, the success or failure of your project is in your organization's hands. While external consultants and system integrators are often necessary, never forsake your responsibility by passing ultimate accountability to them.