A story of too many tools

A story from a large IT shop not too far from here…

Bill and Sandy were having lunch in the cafeteria. Bill was in the IT financial planning group, and Sandy was from the project office.

Bill said, “It seems like we go through this every year, and it’s gotten much worse since the tech bubble popped. We just can’t explain nearly well enough how we support the business!”

Sandy pointed out, “Well, in terms of project funding it’s pretty clear – the business sponsors sign up for what they want, and we deliver it.”

Bill: “Yes, that might be the one area we’re doing somewhat right. But what I’m more concerned about is how foggy everything gets when the system is in place and running for a while. We don’t have good visibility into the total cost of ownership.”

Sandy: “Well, can’t you get reports out of the operations side of things?”

Bill: “Yes, that’s the problem. There’s several different areas and they don’t report on the same things, or even look at the environment the same way. It’s all on spreadsheets and in people’s heads.”

Sandy: “You know, that’s similar to what I hear from the project managers. They are always complaining that their teams don’t have the information they need to fix, enhance, or integrate systems.”

Bill: “Well, maybe we need some systems of our own.”

Bill and Sandy weren’t the only ones feeling the pain. That year, the IT executive committee authorized an unprecedented $15 million for internal systems just to run the IT organization’s business processes. This caused some raised eyebrows on the business side, but the CIO made a persuasive case that this investment would result in far better bang for the IT buck.

The money was allocated out among various stakeholders.

John in enterprise architecture purchased a leading enterprise architecture tool and started building functional, system & information models.

Jeff in the engineering group purchased a sophisticated discovery tool and started mapping the as-is connections of deployed technologies. Chris’ operations group continued to work with a major management framework, receiving some incremental investment to start using it as a configuration management tool, and Terry running the help desk continued to use an old but powerful mainframe-based tool for their day to day operations.

Jane in the project office purchased a portfolio management tool and started defining IT portfolios. However, the time tracking was still done using a legacy system.

Joe in the Asset Management office purchased a dedicated asset management tool and started entering all the servers, licenses, and so forth.

In the meantime, Sheila in the data group had been running a metadata repository for about ten years, but had never quite been able to get the funding to fully populate it, nor the buy-in from the other IT areas to contribute to & leverage it – it was always seen as a “data dictionary” although it was capable of representing virtually every element in the IT environment.

Project managers were deployed across the board to drive all of the initiatives to completion. While there were a few hallway conversations in which people started to wonder about the possible redundancy of these projects, the timeline-focused project managers always said “out of scope” and discussions were quickly halted.

When these projects were completed, reports started to filter up to the senior executives. While each area seemed to have made some progress, the meetings were increasingly spent in unproductive “spreadsheet wars.” In particular, even though the concept of “total cost of ownership” for the enterprise’s systems was a key issue for the CIO, it wasn’t something anyone really seemed to own. Joe said, “Well, I can tell you how much we’re spending on servers and licenses, but the support costs would have to come from the time tracking system.”

The CIO said, “Joe, in your Asset Managment report, you have all your hardware expenses rolling up to Engineering. Don’t projects actually pay for that?”

Joe: “Well, we discovered we need an interface from either the portfolio system or the time tracking system for all the project definitions that we didn't scope into our project plan, and now we're out of money.”

Jane said, “And aren’t some servers shared across projects? Can your system handle that?”

Joe: "Actually, I think it only can track an asset against one project. The vendor is tracking this as a future enhancement. That requirement got by us; our RFP process was a little rushed and these integration requirements actually came up pretty late."

The CIO said, “I’m still not hearing how we get to TCO. Servers and software bought by projects are all very well, but what about maintenance and support? We’re spending half our dollars there. And are we talking TCO for a project, or something else? It seems we need to be tracking things by system, but some of these tools think it’s all about the project. I know for example we had three separate projects to put in the various modules of PeopleSoft HRMS, and the Apex project last year actually delivered two different systems. What about the help desk?”

Terry said, "Unfortunately our software is all structured around supporting the client. When a person calls the help desk they ask where the person is, whether they are using the mainframe or a distributed system, and keep refining from there. That master call typing hierarchy helps us get the job done, but it's not aligned with the kind of reporting you need -- almost every functional area uses the mainframe. What we need is to tie our call types into a master hierarchy of our systems, but this is going to be really tough on this legacy ticketing system -- maybe we should have put in for some of the capital money for a new one. We didn't think we needed it."

The CIO was pretty frustrated. He had come from a data warehousing background and had seen this same sort of thing on the business side: spreadsheets and reports filtering up to the senior level that just didn’t agree. “Do you mean to tell me we’ve done the same thing to ourselves we’ve been trying to fix for our clients for the past fifteen years?” he asked. “How could this happen?”

Some of the architects noticed that the discovery tool also presented itself as an enterprise architecture tool, but no-one seemed to have a very clear idea of how it related to the seperate tool the architects were using. There were significant differences -- the discovery tool didn't have a real modeling capability -- but the overlaps in the system description and decomposition space were troubling.

Each team seemed to think the other should be providing it an interface, and the vendors were no help – they could support interfaces going either way, but each vendor wanted its system to be primary, and neither could provide the all-important data mapping. A couple of software engineers looked at the problem on a technical level and were quite disturbed at the complexity involved; “this is like, the hardest interface requirements I’ve ever seen” said one very senior engineer. “Aren’t there some standards that could help here?”

The problems went on. The management framework’s new version had a nice service monitoring capability, but the engineering staff didn’t have a firm grasp of which business areas consumed what service, or even how to define something so nebulous. When the engineering team started having conversations with the business, the development executives stepped in, as they had always owned that relationship back to the business.

The enterprise architecture staff had a good understanding of what a service was and the overall relationship with the business, but didn’t have access to the management framework and were wondering why their enterprise architecture modeling tool couldn’t play a part here – after all, it was the system of record for systems and services. The relationship between the management framework, the discovery tool, and the enterprise architecture tool started to consume a lot of time and conversation, and no staff person or consultant seemed to have a clear vision as to how the tools might interoperate. The interim solution was dual (and in some cases even triple!) maintenance of quite complex system hierarchies and interconnections, which started immediately to have accuracy problems.

The vendors in the meantime were doing their best to increase the scope of their licenses. Lunches and rounds of golf helped entrench each IT area more into its chosen software.

Finally, a consultant was brought in. The CIO didn’t quite know where to look, so they asked around for someone with both the new ITIL credentials and also some deep ERP experience. Al was pretty in demand lately.

His first assessment: “You folks have bought way too many toys, and not spent nearly enough time working out what your requirements are. This is the same problem I’ve seen over and over again in HR and financials ERP efforts: the senior executives who need to define the requirements haven’t had the time to really focus, so their staff just goes out and buys stuff based on vendor interpretations of what the requirements are. The trouble is in IT, everything overlaps even worse than in finance or HR.”

He went on, “The other area that ERP projects fail on is in just getting building agreement among the stakeholders! When you’ve decided to essentially consolidate several systems into one, there are all kinds of politics baked into seemingly simple issues like how you are going to roll up your reports. Seems like no-one took ownership of this.”

The CIO agreed. “From what I can tell, no vendor emphasized the need for us all to agree on what the major ‘things’ were in the environment we’re trying to manage.”

Al responded, “That’s like setting up a financial system and not agreeing on the chart of accounts!”

CIO: “That’s a good analogy. Come to think of it, I’m not even sure who owns my definitive reporting hierarchies.”

Al: “Now we’re getting somewhere. You know, you could have started that piece of work in a spreadsheet – and it’s probably the most important thing!”

To be continued ... next installment

Comments

[Jeff Dahlberg]

Charlie,

Wonderful story. This appears to be a blend of shops and departments that I have encountered.

Stories are a great way to present a bigger picture than you could using a white paper or technical overview paper.

Keep up the good work and please never mention NIKU again. It gives me a sour stomach. ;-)

Jeff

[KK]

Charles

Your book and especially the content above has opened up a lot of thoughts in my mind. I run the IT Management Tools & ITSM Process practice for a large Indian IT Services Provider and we have been taking some cues from your insights and have put in a team to work on trying to address this challenge