Inside Extreme Scale Tech|Saturday, August 2, 2014
  • Subscribe to EnterpriseTech Weekly Updates: Subscribe by email

The Visible IT Organization: Status and Metrics Reporting 

A manufacturing company, whether small or large, is only as good as its IT department.  And one of the hallmarks of a good IT department is how well it is aligned with corporate objectives. 

Paul Ingevaldson has been involved in computing since 1965, ending his corporate career in 2004 after 25 years of service at Ace Hardware that culminated with his running the IT department and Ace’s international business.  It was a very good IT department, and, after retirement, Paul has been teaching, writing, and lecturing on the many lessons he has learned over the years. He is contributing editor to the Digital Manufacturing Report.

The 9 ½ Secrets of a Great IT Organization, published this year, is one of the results.  The book is available on Amazon.com, Barnes & Noble, and via Kindle or Nook.

We presented a chapter from the book last August. Here’s another – this time on the all-important topic of metrics and IT visibility. 

As Kathleen Melymuka, Paul’s former features editor at Computerworld, comments on the book jacket, “Reading Paul Ingevaldson is like listening to an old friend who just happens to be an exceptional CIO and a great teacher.  Pay attention!”


Many users feel that the IT department is a black hole that things go into but never come out of. Substantiating that perception are the many IT departments that like it that way and believe that the less scrutiny, the better. That is very dangerous for the modern IT organization. If IT wants to be a great enigma, then it should be willing to accept the consequences that follow. This mentality justifies receiving a lack of respect, mistrust of intent, and difficulty in entering into the mainstream of the company. Instead, IT must try to open itself up, show itself off and be accountable for its actions. IT must be equally willing to accept praise when it is successful and accept blame when it is at fault. In short, it must start acting like other departments in the company.

The best way to eliminate this veil of secrecy that has fallen over most IT activities is to develop a reporting methodology that communicates the status of projects to everyone in the corporation. This is Secret #9.  In my company, we published a report every month listing the projects that were approved, those that were completed, those in process, and those yet to be started. In addition, we included the original cost estimate for each project, an estimated completion date (if in process), and any changes that caused these initial estimates to be adjusted. We then justified any variations from the original estimates by indicating errors by IT in the initial estimate, new requests by the users (sometimes called scope creep), or new findings during development that changed the estimate.

We then published this report on the corporate Intranet for everyone to see. We highlighted every major change in yellow so no one could miss it. Any major changes would be discussed in detail at the next officers’ meeting. This way there were no surprises on major projects, and the officer group could discuss any ramifications that may occur due to the delay of any major implementations. As a result, discussions of IT progress became a routine part of everyday business. In addition, users across the company became very familiar with the major projects and their status. No one could ever say that they were blindsided by delays in project completion.

We did something else that enabled us to be more successful in meeting deadlines and budgets. We began to pay IT practitioners an incentive if they were successful in completing projects on time and within budget. It was amazing how this small step got projects done on time, eliminated a lot of scope creep requests from the users, required fewer changes in each monthly report, and began to give IT a better reputation on getting the job done.

This report was also the basis for each IT Steering Committee meeting that we held throughout the year to discuss status of projects. Based on issues, we would hold such a meeting quarterly or more often as needs required. At these interim meetings, we would discuss project progress, any significant cost issues raised by the new projects, and any other IT issues that rose to the level of the officers’ concerns.

At some meetings, we were required to modify the project prioritization due to a change in the business, government requirements, legal issues, or changes in in-process projects that had the potential of significantly changing the ROI. This could be caused by changes by an outside vendor, requirement changes by the user that would significantly change the deliverables of the project, technical problems found during development, or any of a myriad of other issues that affected the completion and/or the cost of the project.

This process also kept the officer group engaged in the IT agenda and partly responsible for its actions. Since users ultimately own the IT projects, this is the proper way to do it in the modern corporation.

Metrics are an important step in the maturation of any IT department. Numbers are the language of business, and knowledgeable executives always know the key numbers that are critical for the company. However, there are many IT executives who speak in generalities about their department, and really haven’t tried to document the critical numbers that should point out to others the successes of the IT department.

IT leaders should:

  • Know the average response time for critical online systems.
  • Know the mean time to resolve any online problems for users.
  • Track disk utilization and processor utilization on the mainframe/servers in order to anticipate upgrades.
  • Be aware of the cost of IT as a percentage of revenue, and they should be able to talk to their CEOs about the return on investment that IT has achieved over the past year.
  • Be aware of how much enhancement/maintenance work the department does relative to new development, and also be aware of the size of their actual and potential development backlog.

Suffice it to say, a CIO who can quantify his/her operation in business measurement terms has a much better chance of being accepted by the company establishment that thrives on this kind of information. It will make IT look much more like an actual department rather than a group that relates more to its technology than to the corporation.

 

 

 

 

 

 

Add a Comment