Moneyball is especially interesting when read with an eye toward trying to change long held beliefs on how IT should be managed.  Out of this fable of baseball made better by people willing to buck the status quo, we can glean some lessons to help us keep the faith as we work against the crushing inertia of IT’s status quo.

• "I do not start with the numbers anymore than a mechanic starts with a monkey wrench.  I start with the game, with the things I see there and that people say there.  And I ask, is it true?  Can you validate it?  Can you measure it?  How does it fit with the rest of the machinery?  What is remarkable to me is that I have so little company."
• "Baseball gives you meaningful things to count, and by counting them, you can determine the value of the people who play the game."
• "Statistics are not pure accomplishments of men against other men, which is what we are in the habit of seeing them as.  They are accomplishments of men in combination with their circumstances.  The failure of management to acknowledge this fact in their statistics has led to exactly the sort of operational corruption that, in creating them, they sought to eliminate."
• "When numbers acquire the significance of language, they acquire the power to do all of the things which language can do:  to become fiction and drama and poetry…And it is not just baseball that these numbers, through a fractured mirror, describe.  It is character.  It is psychology, it is history, it is power, it is grace, glory, consistency, sacrifice, courage, it is success and failure, it is frustration and bad luck, it is ambition, it is overreaching, it is discipline.  And it is victory and defeat, which is all that the idiot subconscious really understands."
• "Our cause is bigger than fielding statistics.  Our cause is the systematic search for new baseball knowledge."

• "The system is the star.  The reason the system works is that everyone buys into it.  If they don’t, there is a weakness in the system."
• "The individual star is less important than the organization as a whole, and the organization as a whole functions well only if it is uniformly disciplined."
• "Three rules:  (1) Every batter needs to behave like a leadoff man, and adopt as his goal getting on base.  (2) Every batter should also possess the power to hit home runs, in part because home run power forces opposing pitchers to pitch more cautiously, and leads to walks and high on-base percentages, (3) To anyone with the natural gifts to become a pro baseball player, hitting is less a physical than a mental skill.  Or at any rate, the aspect of hitting that can be taught are mental."

• "No matter how successful you are, change is always good.  There can never be status quo.  You have to always be upgrading."
• "Think for yourself among rational lines.  Hypothesize, test against the evidence, never accept that a question has been answered as well as it ever will be.  Don’t believe something is true just because some manager says it is true."
• "Managers tend to pick a strategy that is least likely to fail rather than pick a strategy that is most efficient.  The pain of looking bad is worse than the gain of making the best move."
• "He had, in effect, to take an intellectual stand against his own organization in order to do what was right for the team."
• "The fuss was that the rubber had finally met the road, and for putting it there, he deserved a lot of credit.  Intellectual courage was his contribution.  He’d had the nerve to seize upon ideas rejected, or at least not taken too seriously, and put them into practice."

• "The inability to envision a certain kind of person doing a certain kind of job because you’ve never seen someone who looks like him do it before is not just a vice.  It is a luxury.  What begins as a failure of the imagination ends as a market inefficiency: when you rule out an entire class of people from doing a job simply by their appearance, you are less likely to find the best person for the job."
• "What gets me really excited about a guy is when he has warts, and everybody knows he has warts, and the warts just don’t matter."
• "Discipline can’t be taught.  Actually, it can be taught, but we’d have to take people in diapers to do it."
• "He claims there is no point in trying to change people, and then he goes ahead and tries to change them anyway.  He knows most of his players better than he would every allow himself to be known by them."
• "He had a gift for making players want to be better than they were."

• "Every deal you do will be scrutinized by subjective opinion.  To do this well, you have to ignore the naysayers."
• "Know exactly what every player is worth to you.  You can put a dollar figure on it.  Know exactly what you want and go after it.  Never mind what they say they want for it."
• "The day you say you have to do something, you’re screwed.  Because you are going to make a bad deal."
• "There is a difference between trading stocks and bonds and trading human beings.  There’s a discomfort.  Don’t let it affect what you do.  Think of players as pieces in a board game.  That’s why you can trade them so well."
• "He wasn’t looking to be your buddy.  Seldom did a player see him socially, away from the clubhouse.  He kept his distance, even when he was right in your face.  Nevertheless, he was a presence."

6.       But to be successful managing change, you have to be passionate about what you do

• "He was one of those people whose personality was inextricable from his performance.  His personality was necessary for his performance."
• "It was hard to know which of his qualities was most important to his team’s success: his energy, his resourcefulness, his intelligence, or his ability to scare the living shit out of even very large professional baseball players…He might as well wear a sign around his neck that said: 'I’ve been here, so don’t go trying any of that big league bullshit on me.'"
• "His compulsion to make himself at home in the game, to slow the game down, to make it come to him, to make it his game."
• "The pleasure of rooting for Goliath is that you can expect to win.  The pleasure of rooting for David is that, while you don’t know what to expect, you stand at least a chance of being inspired."

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.

Near-term, CIOs should instead focus on bringing operational discipline to the organization, and squeezing whatever they can out of their existing toolkit.  Although not the nicest way to get from Point A to Point B, “that old IT jalopy” just may have a few more miles left in it.

Here are some suggestions for making the most of what you got.

Eliminate ‘Human Spackle’

Once the systems map for your organization has been created (see “Mapping your IT Ecosystem”), the next step is to identify where there are gaps in the operation, i.e., either discontinuities in the development process, or unfilled voids in the platform where manual effort has taken the place of proper tools.  Some questions to ask:

• Where don’t you have the right tools for the job?  (Excel and e-mail don’t count.)
• Where are multiple tools doing essentially the same thing?
• How does data flow between the tools?
• How do you trace an activity from beginning to end?  (E.g., change tickets, application groupings)
• Where do people abandon the tools when urgency demands quick action?
• Where is “human spackle” filling holes in the process?

In particular, you want to keep your eyes open for “human spackle”—those pockets of administrative personnel doing manual pre- and post-processing to get data in and out of the tools.  Useful when tools are new and users require extra support, these folks quickly become an unnecessary (and wasteful) crutch that may be limiting the organization’s ability to move forward.

With titles like Reporting Administrator, Change Librarian, Quality Analyst, or whatever—important roles if they’re doing what process dictates rather than plugging holes that should be fixed systemically—they can be notoriously difficult to pinpoint and eliminate from the process.

Identify where you have “human spackle” and you will find many of the priority gaps in your platform.

• What activities are they performing?  E.g., data cleansing, data entry, extracts, analysis, reformatting, graphs, report generation, etc.
• What audience they are serving?  What does the audience do with the stuff they generate?  What triggers their work?
• Which if any of the tasks could be done automatically with present functionality (possibly requiring an upgrade), simple enhancements, or better interfaces?

Unfortunately, people in this role are not the right ones to step back and design new processes, as they’ve been too close to the details for too long, and will find ways to make up new work if they fear their jobs are on the line.  It is important that they be reassigned to other useful roles as soon as analysis is complete and automation opportunities have been realized, or they will continue to exert an influence that could bottleneck others from adopting the new tools and processes.

Define an IT Domain Model

An end-to-end domain model is the foundation on which your ERP for IT strategy will be built.  Without a domain model, you will have difficulty tying together processes and data from different systems and will not achieve the end-to-end visibility needed to improve your IT operation.

Using data that you’re already getting from existing reports and feeds, identify those elements that represent similar activities or concepts, regardless of how each tool defines them.  Look for commonalities that can be used to link together related processes, e.g.,

• Department or SBU
• Application Name
• Team or Individual
• Process Step, Activity Type, or Phase
• Change or Requirements Ticket #
• Source Code File Name
• Physical Platform (vendor and version)
• Physical Location
• Root Cause
• User Base
• Budget Code

Your domain model provides a framework for pulling data from the different tools and combining them into an end-to-end view of the operation.  By abstracting a handful of elements up to the domain model, you create a crude fabric that threads together like steps across fragmented tools and databases.

For each tool, you’ll need to map that tool’s definition of common elements to categories in the domain model, and then create a set of master lookup tables that spans all tools.  Here is where you will find just how dirty your operational data is, especially where user-defined (free-form text) fields have been used in place of properly locked-down menus.  In one example, analysis of SDLC phases in a project management system uncovered more than 20 variations of the “Requirements” option, including “Business Requirements”, “Bus. Requirements”, “Bus. Rqmts”, “Scope and Requirements”, “User Requirements”, “BRQ”, and so on—all of which had to be mapped to the domain model categories.

Lock Down the Master Tools

When your systems map and domain model are complete, you’ll want to determine which tools can serve as master for each set of processes.  Master tools should be chosen from those with the best all-around functionality and data structures (obviously).  But selection will likely be hindered by organizational fiefdoms that force the decision to be “win/lose”.

Where you find overlapping systems competing with the target masters, ask the users:

• What is wrong with the master system?
• Besides administrative control of the tool, what else is missing?
• What would you need functionality-wise to get you to use the master system?

Where you find true holes in the systems map, identify which (if any) of the tools could be used to fill them.  Commercial tools typically have more functionality available than is being used, and even though this functionality may not be best-in-class, the value of an integrated, single-vendor solution almost always outweighs the costs and risks of integrating different products.

A quick way to bring structure to the master toolset is to lock down user input fields (via menus, buttons, drop-downs, etc.) for key domain elements.  Likewise on the output side, you’ll want to build adapters that map existing reports and feeds to the domain model, rather than rewriting the feeds themselves.  Locking down inputs and outputs forces people to use a common set of variables, and reduces the burden of having to scrub the data every time you want to run a metrics report.  You might also consider initiating a one-time cleanup effort at the database level to migrate local variants of the key fields to their new locked-down values.

Once the inputs and outputs for each system have been mapped to the domain model, your ability to track related activities as they move from tool to tool, process to process, even organization to organization, will be greatly enhanced, simply by allowing you to join the separate data tables on their common field definitions.

Build a ‘Metrics Portal’

Finally, having identified pockets of manual overhead, created an end-to-end domain model, and locked down your master tools, you’ll want to add a metrics layer to give better visibility into your IT ecosystem.  The objective of this layer is to glue together the tools with minimum system modification and minimum disruption to IT operations.

The “Metrics Portal” becomes your vehicle for collecting and disseminating IT metrics throughout the organization.  With the data cleansed and presented in a proper light, few people will be shocked by how much things have deviated from their intended course, and they will be encouraged to:

• Start using the tools as they are supposed to be used
• Improve data quality, both inputs and outputs
• Manage their processes better via data-driven decision-making
• Reduce administrative overhead and refocus resources on more value-added work

If you are unable to build a metrics portal right away, there is still value in consolidating the “human spackle” functions into a central reporting group, to reduce the administrative overhead and force data consistency across the teams.

You can go far by squeezing more out of your existing platform.  However, as with any renovation project, you will ultimately run up against systems that are just too dilapidated for your go-forward strategy.  When this happens, the time will be right for investing in a new set of tools.  And thanks to the knowledge of your operation that you gain from this exercise, you will be better prepared to take advantage of all that your new ERP for IT platform has to offer.

The IT operational platform is a complex set of tools and processes that are indigenous only to IT.  This ecosystem, sometimes referred to as “ERP for IT”, has evolved without the benefit of a master plan, resulting in a hodge-podge of disjointed workflows, databases, and untapped functionality spanning multiple physical platforms and multiple vendor products.

Those companies fortunate enough to have established a level of consistency in their IT platform enjoy shorter delivery times, faster issue resolution, and efficient flow of information throughout the systems lifecycle.  With admiration, we tip our caps to these “Masters of their IT Domain”.  For the rest of us, building an enterprise-class operational platform for IT should be a top priority.

Generally speaking, IT management systems can be grouped into five categories (link to “Conceptual Map of IT Ecosystem”):

• Project and Portfolio Management:  tools for defining IT strategy, planning and resourcing projects, and tracking implementation
• Software Delivery and Quality:  tools for managing the SDLC process from requirements through development, testing, and deployment
• System Operations:  tools for managing system configurations, data center operations, and user support
• Organization:  tools for managing IT human resources
• Administration:  tools for managing financials, assets, and performance metrics

Vendors like IBM, Computer Associates, HP, Oracle, BMC, and countless others offer products to suit the requirements and budgets of any size organization.

Our business partners, too, are beginning to recognize the need to manage IT with the same rigor and discipline as other operations, and are more willing to invest the necessary funding to upgrade these tools and processes.  However, before you embark on a multi-year effort to forklift out the current tools in favor of something new, you should consider exploring what you already have to see if there might be some life left in it.  Your current tools are a treasure trove of historical information on the IT operation, and analyzing this data will provide you with a better understanding of how the organization has been performing, where processes and systems are lacking, and where you should prioritize your IT improvement efforts.  These tools might also have untapped functionality that could be unleashed at far lower cost and disruption to the organization vs. installing something new.

Taking Action

After data has been collected, analyzed, and delivered to the organization, you must reinforce the effort with training, visibility, and incentives.  Graph-by-graph, table-by-table, example-by-example, it is every manager’s responsibility to make sure people understand how they are being measured, and to give them tools to track and improve their performance.

Training

Training addresses two areas where the organization is likely to struggle with the metrics:  (1) What does the data mean to them, and (2) What should they do about it? 

Keep the message simple, and be careful not to spend too much time on the theory.  As cool as the analysis may be, many will fail to grasp the mathematical concepts and will tune out.  (If the math were so simple, wouldn’t they have been doing it already?)  Instead, leverage whatever attention span you get to teach practical uses of the data, so that the audience will understand how to apply the metrics to improve their work.

As you introduce new ideas to the organization, don’t underestimate the value of repetition.  Although your materials may seem stale to you, don’t forget that your audience is hearing it for the first time, and they are the ones who get value from the training, not you.  Experience shows that people have to see or hear an idea five times before they begin to internalize it.  So when people say “enough already, we get it”, they probably don’t.  When people start acting on the data and providing insights or suggestions for improvement, that’s when you’ll know they really get it.

Visibility

Visibility means closing the measurement loop and giving feedback on how the operation is performing.  Without feedback, it is difficult for those who control the inputs to adjust what they are doing for better output.

You want to make the metrics as visible as possible, in as many places as possible.  Hang a scorecard on the wall outside the cafeteria; email spreadsheets to each team leader; post results on the company’s intranet site; add custom queries to the data warehouse that anyone can use; build a real-time monitoring dashboard.  Manual or automated, any method will do as long as it engages the right people who can affect performance. 

“Sunlight is the best disinfectant; electric light the best policeman.”  (Brandeis)

Expect the organization to be resistant initially, as no one wants to see their shortcomings made visible.  However, the more openness and transparency you can introduce into the metrics process, the quicker people will engage in making the data, and more vitally the underlying operation that produces the data, better.

Incentives

A well-designed balanced scorecard can have a big impact on the organization, making absolutely clear the link between output and compensation.  Most important are performance-based incentives that put teeth behind the metrics.

“What you reward is what you get…By not aligning measurements and rewards, you often get what you’re not looking for.”  (Welch, Winning)

Incentives should follow a multi-level structure that reflects the drill-down nature of the metrics.  Even better if you can link specific metrics to units of output or business value.  Where meaningful, incentives should be mapped to team or individual performance if you have granular enough information.  But don’t overdo the slicing-and-dicing below that which is relevant, since you want to make sure individuals are contributing to the success of their team and not trying to maximize their own performance even if detrimental to the organization.

Summary

When organizations don’t know what they’re looking for, or can’t seem to find it in what already exists, they do what all frustrated creatures do—they move on to something else.  New reports, more data collection, perhaps a benchmarking study. 

The solution will come not by widening the analytical lens, but by sharpening it.  I.e., doing more with what you already have and not becoming de-focused with too much superfluous data.

“If I ever go looking for my heart’s desire again, I won’t look any further than my own back yard.  Because if it isn’t there, I never really lost it to begin with.”  (Dorothy Gale, The Wizard of Oz)

Scorecard initiatives typically fail for two reasons:  (1) Metrics that are too complex, (2) Management that fails to stay the course.  With metrics, there is no “absolute truth”, only approximate statistics that each person will interpret differently.  No scorecard is perfect, no metric completely accurate, no silver bullet answer for improving the organization.  So keep it simple, stick to the facts—objective, relevant, understandable measurements of how the organization is performing, and where it needs to go—and steadfastly follow-through on objectives, day-in and day-out.  You will start seeing results before you know it.

While decision-makers have access to more data than ever before, the problem of turning that information into an actionable plan that drives performance still remains.  Data alone will not help managers make sense of where production is lacking, nor will it motivate the organization to change its behavior.  Translating operational data into action is a three-step process centered on closing the measurement and feedback loop for managers and their teams.

These three steps must be done together as an end-to-end process, and must be supported with training, increased visibility, and performance-based incentives if lasting value is to come out of the effort

• Data Collection alone will do little to help managers make sense of their operation.  Few organizations are lacking sufficient data; in fact, most are drowning in too much.
• Analysis alone won’t encourage people to change their behaviors.  Without meaningful presentation, even the best insights will go unheeded if people don’t know about or understand them.
• Presentation and Delivery alone will simply make the data more available, but won’t help managers filter through the raw data and get at insights buried within.

As you plan your measurement initiative, the hard part will be getting people to think about how they want to use the new information.  Four questions can help focus your efforts:

1. What questions do I have about the operation, and what metrics will help answer them?
• Any form of metrics will do, as long as they are actionable
• ­Don’t wait for perfect data; make assumptions, state the assumptions and put the data in use
2. What data do I currently have available, and how accessible is it?
• ­Any source system will do, as long as it provides fair representation
• ­Rarely will you find that you don’t have enough to get started
• ­You don’t need more data…you need better data
3. How can I collect data with minimal disruption to the operation?
• ­Bias will be introduced if people are forced to modify behavior to support metrics
• ­Start with “loose coupling” (e.g., extracts, queries) vs. building real-time links
4. What information do I want to deliver?
• ­What data and analysis will have the most impact on performance?
• ­Triangulate using multiple views of the same activity          

Here we present a framework for translating operational data into a set of actionable metrics that can be used by managers to measure and improve their organizations’ performance.

• Part 2:  The Measurement Process:  Data Collection, Analysis, Presentation
• Part 3:  Taking Action

(Please continue to next posting, "Translating Data into Action, Part 2")

• “What gets measured, gets done.”  (Some famous general)
• “Measure twice, cut once.”  (Some famous carpenter)
• “If you can’t measure it, you can’t manage it.”  (Peter Drucker)
• “To measure is to know.”  (Lord Kelvin)
• “One accurate measurement is worth a thousand expert opinions.”  (Adm. Grace Hopper)

It’s so trite, so shopworn, so cliché.  And yet, still a nagging problem for IT organizations across the spectrum.

When a business manager approaches his or her IT department about a project, there is an assumption that some form of systems development will be done.  There is an assumption that the business manager has already measured their operation, done the reengineering, and is ready to take it to the next level through automation.  There is an assumption that the main thing holding them back from exceeding all expectations is the lack of systems support.

Maybe, maybe not…

Jumping right into an automation project without first measuring and reengineering the current operation is a surefire recipe for disappointment, because:

• It is usually more complicated than envisioned
• It takes longer than planned
• It costs more than budgeted
• It requires more involvement, from more people, than managers are able to commit
• It disrupts the status quo more than people are willing to stomach
• It is just another example of how IT can take a simple idea and overcomplicate it

Why do IT managers get themselves into this kind of situation time and again?  Why do companies commit to large-scale development efforts to redesign or replace their operational systems when a more incremental reengineering solution could deliver much of the value for less money?

When people don’t understand why something is or is not working, they can only make decisions on what they do understand—the inputs and outputs to what is essentially a “black box” system.

They see results (output) that aren’t what they expect or desire based on the effort (input) they are giving.  They make assumptions as to why this is happening, and adjust their inputs using trial-and-error to get to the results they’re looking for.  When such results are not achieved, or prove different than expectations, they snap on pre- and post-processing systems to manipulate inputs and outputs in a manner that was not part of the original design.

Instead of modifying core processing logic and maintaining system integrity, they try to control individual variables (x=g(w), z=h(y)) outside the core, and begin to destabilize the end-to-end system.  Processing complexity grows beyond the first-order (y=f(x)) functionality the system was designed for, and it becomes difficult to model or predict behavior.

• Future development is more complicated as each enhancement requires multiple changes
• Operational processes need to be restructured to account for systems limitations
• Errors increase as the system’s ability to handle new or unexpected events diminishes
• Maintenance costs grow thanks to all the minor tweaks necessary to keep the system running

No wonder it seems the only option is to rewrite the system from the ground up.  And although further analysis may prove that a rewrite is the best option, without better understanding of how the core system is supposed to work and why it isn’t performing to spec, any rewrite efforts will prove as fruitless as those that led to the current unacceptable situation.

“Measure First, Reengineer Second, Automate Third” is a mantra to remind IT managers and systems designers to resist their natural tendency to try and automate everything.  (We are engineers, after all…)

(View Image:  Measure First Table)

Technology’s role early in the process should be one of measurement, data mining, and simple modifications to support operational changes.  Only after reengineering efforts have borne fruit can technology play a truly transformational role.  By striving to squeeze out as much as you can from non-programmatic improvements, you will go a long way toward reducing complexity of the end-to-end operation.  Often, the right solution is smaller, simpler, and less costly than was originally thought.