Metrics Portal Blog

Crisis of Confidence in IT

Across industries, companies are struggling to bridge the gap between what their businesses need and what their IT groups are able to deliver.  IT is frequently branded as naval-gazers who are out-of-touch with the marketplace, and no matter what changes they effect, can’t seem to get past a deep-rooted lack of confidence.  CIOs and their managers have been given the mandate to do whatever it takes to build the platform that will take their company to the next level.  And yet the gap continues to widen.

Where is IT missing the mark?  Consistently, business managers have expressed five sets of concerns with their IT organizations:  (1) failure to understand business needs, (2) too many, too complex systems, (3) lack of fiscal responsibility, (4) inadequate bench strength, (5) poor delivery track record.  This crisis of confidence is forcing companies to confront some tough questions about where IT is falling short:

• Why is IT isolated from the rest of the business?
  
• Why are systems so unreliable?  Why so many bugs?
  
• Why doesn't IT have better control of its financials?
  
• Why isn't IT making the investment to strengthen its organization?
  
• Why does IT have such a poor track record delivering on commitments?
  
• Why is IT seen as unresponsive and lacking urgency?

Bridging the gap between the business and IT requires more than extra spending and longer hours alone can deliver.  The problem is usually not one of skills or motivation, but one of alignment.  Those companies that have built effective IT operations create a culture around five principles.

       I.   Accountability to the business
      II.  Doing more with less
     III.  Fiscal responsibility
      IV.  Building bench strength
       V.  Accelerating delivery processes

Improving in these basics areas—communicating better with the business, eliminating unnecessary activities, reporting clearly on performance, recruiting top talent, and delivering projects more reliably—can go a long way toward reestablishing IT’s strategic position in the company.

Principle I:  Accountability to the Business

At the heart of the matter, for many organizations, is an across-the-board failure to take accountability for the quality of the technology platform.  Silos have been built-up that are having a deleterious effect on IT's ability to deliver what the business needs. 

For example, take a typical software development cycle.  Users (1) submit requests to Business Analysts (2), who hand-off requirements to Application Managers (3), who work with Infrastructure Engineers (4) to build-out the environment, and Programmers (5) to develop the code.  Technicians (6) then deploy the code to various environments for Testers (7) to test and ultimately for users to use.  Testers and users call the Help Desk (8) when they have issues, who contact Production Support (9) to get these issues resolved.  In all, as many as nine distinct groups may be involved in the initiative.  This would not necessarily be a problem if the nine groups were working together in a collective manner.  But each group has put in place its own procedures, documentation, budgets, project plans, etc., not so much to facilitate the delivery process, but to secure an audit trail should things go wrong.

One need only look at the crush of relationship and project managers to see the waste created by boundary effects between the silos.  An unfortunate misuse of scarce managerial talent, and yet witness the real waste that occurs when roadblocks pop-up.  People spend so much time arguing about who is to blame and covering their tracks that they lose sight of the prime objective—namely to deliver a serviceable, reliable platform to the business.

Tearing Down the Silos

Accountability to the Business means no longer letting organizational structure undermine success.  Business Managers, Analysts, Developers, Testers, Infrastructure Engineers, and Production Support folks form a symbiotic relationship in which none can succeed without better cooperation from the others.  Everyone in the delivery process needs to accept accountability for the success of their systems.  There can be no “us vs. them” in an accountable organization.  When results end up being less than expected, managers need to suppress the urge to affix blame,

• Why didn’t you do what I told you?
  
• I did my job, who didn’t do theirs?
  

and instead ask themselves,

• What could we have done differently?
  
• How can we ensure this doesn’t happen again?
  

Successful organizations are those that can to move beyond the myopic, parochial views ingrained in their culture, and become true collaborators with the business.

Principle II:  Doing More With Less

In an uncertain environment, sometimes less is more.  Less complexity, more transparency; fewer meetings, less administrative overhead; better planning, more accurate data, faster decision-making; fewer handoffs, shorter delivery times; more testing, reduced variability, better results. 

However, as with Linus and his security blanket, IT seems to have a visceral reluctance to shut down legacy systems or cancel long-running projects.  This “separation anxiety” runs throughout the culture—half-a-dozen administration systems here, scores of overlapping data marts there, hundreds of unused budget codes, thousands of extra desktop computers, millions in sunk costs for projects that haven’t been delivered.  All are taking resources away from more strategic initiatives, and businesses can ill-afford to wait 12 or 18 months for new projects to get through the development backlog. 

Well-run IT organizations must learn to prioritize their efforts and do fewer things better.  Studies show that productivity falls sharply as the number of projects any given resource is working on increases; above three projects, the percentage of time spent on value-added activities decreases, as more time is lost to transition activities, such as coordinating, remembering, and tracking down information.  It is imperative that managers curtail unnecessary activities that are draining IT's capacity to deliver.  Some initiatives may have to wait—and some scrubbed altogether—to make room for those activities most important to the business.

Principle III:  Fiscal Responsibility

Operational metrics point the compass that guides improvement efforts and measures performance, tying outputs back to the inputs that can be controlled.  Numbers are the language of business, and should IT managers ever hope to earn a meaningful seat at the table, they need to know their numbers cold.

Unfortunately, fiscal responsibility has never been IT's strong suit.  Companies have not been rigorous at holding IT accountable for its numbers, and have thereby lost sight into how the operation works.  Here is the classic scenario of the cobbler’s children.  IT spends millions to build data warehouses for the business functions, but skimp on the same tools that could help them manage themselves more effectively.

Six Sets of IT Metrics

Better visibility into the IT function starts with a deeper understanding of cause and effect.  Technology operations can be characterized by the following six sets of measurements:

• System Operations – reliability, availability, performance, consumption (utilization)
• Project Delivery – scope, schedule, time-to-market
• Quality – change management, testing, defects (bugs)
• Organizational Development – staff development, recruiting, performance management, turnover
• Business Value – various measures of utility and value
• Financials – budgets, actuals, and the reasons for variations

Like their counterparts in Sales, Finance, Manufacturing, and other departments, IT managers need to learn their numbers, analyze them for insights, and act upon this knowledge for the betterment of the company.  The key is to get this information into the hands of those who can influence performance, and to make fiscal responsibility part of the day-to-day requirements for all levels of management.

Principle IV:  Building Bench Strength

Strengthening IT demands a hard look in the mirror to see which skills are present and which are lacking.  Ironically, whereas IT managers put a lot of effort into systems development—defining requirements, writing project plans, developing code—they rarely follow the rigor when it comes to people development.  More often than not, they use effort as a measure of contribution, and reward those individuals who step-up when short-term circumstances require extra work.  This encourages a heroics-based culture built around “fire fighting” rather than “fire prevention”—something that is just not sustainable over the long-haul. 

It doesn’t help that, in many companies, IT is isolated from the rest of the business and formed a tight-knit community that has a vocabulary and a culture all its own.  Managers wanting to re-integrate their teams will need to confront difficult culture changes.  In particular, what was once considered acceptable performance may no longer be sufficient by business standards, and some individuals that have loyally served the company may no longer have what it takes to succeed going forward.

Eliminating Single-Points-of-Failure

IT’s reliance on the accumulated knowledge of a handful of individuals—you know, the ones identified by the question, “What would happen if ‘so-and-so’ got hit by a bus?”—represents a risk as great as any infrastructure single-point-of-failure that threatens the stability of the platform.  Building bench strength is to organizational development what disaster recovery is to infrastructure.  It requires much more than rote compliance with company policy on training and performance evaluation.

Wherever depth of talent is lacking, IT managers have an urgent responsibility to eliminate these workforce-based single-points-of-failure through better succession planning, documentation, and transfer-of-knowledge.

Principle V:  Accelerating Delivery Processes

Few IT departments have a stellar reputation for delivering systems in a reliable and timely manner.  Projects are seen as slow to market, producing buggy code that costs too much and doesn't quite deliver on what was promised—a reputation immortalized in the oft repeated criticism, "We don’t spend enough on technology, and we don’t get enough for what we spend."

If not for lack of funding or senior-level support, why does this perception persist?  For one thing, there is a fundamental gap between business expectations and the natural process of technology delivery—a “development paradox” that stems from the fact that what constitutes good development practice is directly in conflict with what constitutes good business management.

From IT’s perspective, there is a lot of foundational work (e.g., requirements, architecture, infrastructure) that happens behind-the-scenes before usable functionality can be delivered.  The value delivery curve for a project might follow the shape in the figure below, where perhaps 90% of the schedule and budget will have passed before even 20% of functionality becomes visible. 

Conversely, the business perspective is more incremental and more urgent.  When a decision is made to invest in a new system, it is usually in response to a specific threat or marketplace shift.  Expectations follow a linear progression, where x% of the project is expected to deliver x% of overall value.  It is easy to see where the business’ sense of frustration comes from—everything “seems to take 12 months or more” because of the long gap between when a project is launched and when the first deliverables are ready.

Breaking the development paradox means finding a way to leverage IT's talent for incremental enhancements, by decomposing larger projects in manageable pieces that can be delivered faster and more reliably than the traditional “big-bang” approach. 

 

With these smaller releases, IT can provide the business with a useful, albeit incomplete, platform, months or years earlier than they could have done in the past.  All while respecting the natural process of technology delivery.  Better yet, by managing projects in a more iterative manner, companies can simultaneously reduce delivery risk and improve overall return-on-investment.

Which brings us full-circle to the first principle, Accountability to the Business.  The smaller companies can make each iteration, the faster they can learn what the business needs most, and the better they can tune subsequent releases to improve quality, stability, and usefulness of their platform.