Change Is About People, Isn’t It? … Well, Partly …

There I was, in charge of my first large systems organization. It was the early 1980’s. The group was in a lot of trouble. That’s why I got the chance.

The CEO was fed up with the lack of delivery on the part of the existing IT management team. I was doing some consulting work for him, helping his financial forecast group learn how to better use financial planning software to do their work.

The CEO was relatively new to the organization. The CEO and I had worked together before at his previous company just a year or so before. He knew that I had worked in Information Technology for 15 years. Although I had never been a CIO, the CEO was also aware that I had extensive experience consulting with large systems organization on performance improvement.

So he took a chance on me. He called me into his office, described the situation, and concluded with “So, are you just an advice giver, or can you actually do?” That one sentence totally hooked me. I have never forgotten the slightly mocking tone with which he stated those words.

The CEO announced that I was the new head of IT for the company the following morning. It took us several weeks to work out all the compensation details, mostly because I was so immediately involved with the challenge he had set me. Let me illustrate with a few facts.

1. When I started as the CIO, no one in the company really understood what anything in the systems organization cost. The IT leaders just approved the bills and let the accounting folks summarize the results into a monthly and yearly total. The only breakdown of costs was the lines on a single departmental ledger for Systems (hardware, salaries, benefits, etc.).
2. There was no hardware or system software inventory. I had to ask my vendors to supply me with equipment lists and bills of materials to support their next set of invoices to compile the first one.
3. The definition of an IT project was the work load that 1 person could handle in a year.
4. Prime time availability of the application and time-sharing computer environment was less than 80%. (I thought. The internal business clients were calling me when they could not access the system. That was the only real data that I had at first. So I put a screen in the corner of my office and set it up so that it echoed the main control console. That way, I knew right away when the system was down. The operations guys were scandalized that the CIO would do this. They thought that I wanted to play lead operator. I never touched the keyboard attached to this terminal. I just wanted to know when the system was down as soon as my client base.)
5. The business application portfolio contained a few custom built applications. It included a home grown general ledger. The CEO wanted to add new structure to the code of accounts. But the GL was built on an 80 column punch card concept. All of the columns were in use. The systems organization leadership told the CEO that it was not possible to add any more digits to the account fields.

Four years later, things were vastly different.

1. The application portfolio contained several dozen business applications, some custom built and the rest software package based.
2. Charge back for IT services was in place. Line business leaders now knew their cost for the automation services they were using to operate their section of the business.
3. The internal IT financial and operating management reports showed measured unit costs for each section of the IT organization. Our IT unit costs were decreasing on a year over year basis, even through the aggregate use of (and budget for) automation in the corporation was increasing each year.
4. A consistent project management process and tooling set was used for both internal IT projects and for application development projects done for clients in the business. Robust processes, supported by automated tools, existed for production scheduling and operations management, change management, charge back, and IT financial / operational management.
5. We had effectively absorded three external systems organizations as a result of the CEO’s business acquisitions.

The IT organization acted like a proactive internal service organization, rather than a defensive technology group.

This change was accomplished without an initial dramatic increase in IT funding provided “on faith” by the CEO. In the first year, we rationalized our hardware acquisition and system software licensing costs. The dollars made available by these negotiations funded most of the internal IT change for the next two years. After that, funding for IT growth came about by securing a budgeted charge back commitment from my “inside” business clients for each next fiscal year.

I was lucky. I had a CEO who knew how to drive business value from technology. His previous organization had depended heavily on the use of capital intensive transportation technology. He translated this experience into his personal approach to getting value from IT.

He held the IT leadership (me) accountable for reducing our service delivery unit costs on a year over year basis. He insisted that we implement charge back for IT services. We translated our unit cost reductions into decreases in our unit prices for the IT services delivered to internal business clients for the next fiscal year. The growth in volume demand for our services always exceeded the incremental volume funded by this price decrease.

At the same time, the CEO held his line business leaders accountable for showing that they were using automation to increase revenue or to reduce their operating unit costs. He required them to make and to live by these business cases. IT needed to support them preparing the case, but was never required to make the business case for the use of new business applications. Business leaders did.

The CEO constantly weighted these two types of commitment against one another. When both were occurring, he was prepared to let the aggregate systems budget grow. Over the five years that he was CEO, and I was CIO, the overall IT budget increased significantly on a year over year basis. At the same time, the gross revenue and the net profitability of the overall corporation increased enormously.

The CEO had another effective way of “checking” the growth of the systems organization. At the end of my first year as CIO, he and I had a crucial conversation. We were flying back together to head office after a very successful business trip. He ordered us both single malts, and said that he wanted to “muse” a bit about systems with me.

The CEO started by stating that our corporate total head count was just then under 2000. Then, sipping his Scotch, he looked me square in the eyes and said the following.

“You know, you are starting to show that you can make IT work in this place. As a result, I am beginning to see what I think will be an unquenchable appetite for more computer systems in the business folks. If I let them have their way, the systems department would grow in head count each and every year. But I am not going to let than happen. I figure that your total head count should never be above 5% of the total number of heads in this place. So your job is to figure out how to deliver more each year, with the same number of people. After all, information technology is supposed to be about increasing productivity. If you can’t figure out how to use it to improve your own, how the hell can I depend on you and your folks to do this for the rest of the corporation.”

That was it. He checked to make sure that I had understood what he had said. Then he moved to other topics.

I credit him with forcing me to learn one of the most crucial lessons of my career. He focused me on productivity, not just concrete results.

At first, I thought that the way to meet his challenge was simply to get better people and to work them harder. That naiveté did not last very long. In the early 1980’s, every one was competing for IT talent. There were just not enough systems folks in the marketplace. I quickly learned that I could not just turn over staff. As well, I rapidly realized that expecting people to work 80 hours a week was a sure way to encourage them to move onto more reasonable employers.

It took me a year to learn an even more important lesson. The new folks I hired did not know our business. The folks who had worked for IT for a while did. It took time to build up this business knowledge. I hired some smart new people, whose IT technical knowledge far exceeded that of many of my internal systems folks. But I still took some major productivity hits. I began to understand that technical knowledge had to be combined with business knowledge. This business knowledge was key to creating and to maintaining effective working relationships with key players in the line business. These relationships were as crucial to the delivery of systems services to our internal clients than the new technical skill that I was hiring.

It took me six months of confused trial and error to get this. During this whole period, my unit costs were creeping up. That worried me. I finally realized that I need to blend the old with the new. I needed to make my existing systems folks more productive, not simply replace them with new bodies. I began to realize that the key to improving my overall productivity was “leaders, process and tools”.

I needed better leaders in my direct reports. I needed folks who could inspire others, motivate them, develop them, build them into teams, and coordinate them across my various working groups: new business application development, existing application maintenance and operations based delivery of application based services to the line business. I let most of my existing direct reports go. I brought two new leaders from the outside. But even importantly, I found some real talent inside, talent that had been suppressed by the previous IT management team.

I took a chance on these inside folks. I promoted them against the advice of other senior insiders. To manage my risk, I put in place coaching relationships for them with experienced external individuals that I knew and trusted. I made sure that both the individuals and the coaches knew that the coaching relationships were “private”. I did not expect the coaches to report the details of their conversations with their “coachees” to me. Instead, I focused my interaction with these individuals on how I would measure their performance – the results that I needed them to deliver. I wanted that these individuals would take the opportunity to ask their coaches “how do I do this”, whenever my performance pressure on them exceeded their experience base. I hoped that they would make their learning mistakes in “words” – in dialogue with their coaches –not in their actual performance. By and large, I think that this worked.

But I knew that just replacing the leaders was not enough. We needed new process: – an application development methodology, a project management process, effective production scheduling and operations change management. We had none of these.

None of this process was rocket science, even in then early 1980s. My vendors and external consultants claimed that they could supply what I needed. But I balked at their price and their approach. None of what they offered was integrated in any sense of the word. (ITIL, COBIT and PMI were still glimmers in the future in those days.)

I had enough personal experience architecting, building and delivering financial and operational management applications to know that I needed to integrate the data generated by these IT management processes in some simple way. I also needed to tie this data to the way we accounted for IT costs. This was essential to producing valid unit costs. It was also the key for running the IT charge back process on which my CEO insisted.

One of my first change mantras as the new CIO had been “do it to ourselves first”. If we as a systems organization could not use a new technology or an IT technique to improve the way that we delivered service to the business, how could we hope to help the business do so? If we could not build integrated databases that led to meaningful operating, financial and unit cost metrics about our business, how the hell could we ever hope to help our internal business clients solve similar problems in their areas of line responsibility?

So I funded the building of an IT data warehouse out of the discretionary funds I controlled as CIO. It integrated the data generated by the tools we acquired for project management, production scheduling and management, change management and so on. To this daily, weekly and monthly IT operating data, we added IT cost data extracted from our new company-wide general ledger. We used the resulting data warehouse to do two crucial things.

First, we developed unit cost measures for each of the services we delivered to our internal clients. Second, we used simple linear trending techniques to predict the future trends in these measures.

All of my direct reports got regular copies of these reports. Once this started, the tone of the conversation in my management team changed significantly. My direct reports focused on making the future happen, not explaining their past. They talked about how to correct inappropriate trends, or how to ensure that good ones continued to be “good”. They acted in ways that made the future we needed happen. They treated the past as something to learn from, not as something to spend large amounts of time explaining.

I lasted five years in my first job as CIO. Then the CEO left. The organization was acquired by new owners. The senior management culture and tone changed. The new CEO treated IT as a cost center which needed to be closely controlled. The new CFO argued that IT should really be reporting to him. The inevitable happened. I was invited to leave.

But what I learned in that first CIO job has stood the test of time. It now underlies my approach to enterprise transformation. It is easy enough to summarize, but not necessarily easy to do.

First, find the right people for key leadership spots. Don’t just hire or promote personally focused egos and technical wizards. Hire and promote people whose egos are gratified by working with others to turn their technical insights into results that are valued by everyone in the business.

That is not as easy as it seems. There are far more personally and power focused egos in the world than there are bright, mature results oriented people whose egos are gratified when they deliver results through others.

Second, put the right business processes in place. Make sure that when you do it so, you implement process that the majority of the folks working for you can do.

Remember that work is not the be all and end all for most of the people working for you. It is simply a means of acquiring the resources to fund the things that really count in their lives – their families, their personal interests and their friends. So the new business process that you put in place truly has to make their jobs easier to do in the long run, if you expect them to do more in a given unit of time.

If you and your leadership team succeed at this, people take enormous pride in the work that they do. Their pride in their successful delivery motivates them to learn how to do new things. They become more and more productive over time.

Third, support good process with “good enough tools”. Tools should make peoples’ work less onerous, once they learn how to use them. Make sure that you integrate these tools in a way that truly makes work easier for all of the folks that you have working for you. Ensure that the tools you put in place don’t contradict one another on an information or the process level.

If you don’t take care to do this, you will add work for your people, not make their lives easier. It took an IT data warehouse approach to do it for us back in the early 1980’s (at a time when the IT industry was just beginning to talk about data warehousing).

My CEO taught me a lot when he told me that he would always cap my head count. His intuition and experience told him that an IT group that was not constantly improving its own internal productivity could not do the same for the rest of his business. I have always thanked him for forcing me to learn this lesson.

I learned that people are crucial to successful large scale change. But organizational change is not just about replacing people. Changing the right people, coordinated with introducing effective processes, supported by building or acquiring tooling with makes work of these processes easier for people is the key to lasting, enterprise change.