I do believe in the power of technology. I believe that technology has the potential to be a major catalyst of change and a source of competitive advantage. What we as an industry deliver however is somewhat different. As an industry we consistently fail to deliver against the expectations that we set. The statistics and evidence for this is everywhere. For example depending on the study you look at 30% to 70% of all projects fail. Most CEOs and senior non-technology executives believe that IS costs them too much and does not represent value for money and worse that IS is a drag on the organisation and slows change and agility!! Oh and to take perhaps a silly example has anyone seen the paperless office? I wanted the opportunity to deliver on the promise of IT and consistently add value to the organisation and indeed provide competitive advantage. I felt that by "changing sides" I would get this chance.
So full of the joys and hope of the world I set off to be a CIO. What I found was an IS organisation in disarray. There was no time or money to focus on driving competitive advantage because our systems didn't work or at least didn't work consistently. In the first 60 days in my new role our IS department had 62 priority 1 issues, issues that directly impacted our ability to trade, or buy and move inventory (which is a bit of a problem for a retailer) or meant that hundreds of people were stranded unable to work. Most of our time was spent fixing these systems. When we did get a chance to think about broader strategy issues and issues of competitive advantage no one wanted to listen!! The general feeling - don't talk to me about IS for competitive advantage please just make sure the systems work!!
The IS team hated that no one wanted to listen. They worked hard (some times all night to bring systems back up). They were smart. They held the keys to so much potential. They felt that no one understood them. No one valued them. As for me. I had a lot of empathy for my team, they were smart and they did work hard, but really I was on "management's side". As I looked at our department and our systems there was no way I would trust us to deliver major strategic initiatives. We couldn't even run our systems!!! We were nowhere near competitive advantage and the realities of corporate IT began to sink in. I began to ponder - how do we get from where we are today to be in a position to deliver value to our organisation and ultimately be a source of advantage??
I began to research. I read, books and analysts papers, I talked to peers I went to conferences and seminars. No matter how hard I looked however I couldn't find anywhere a consistent map or guideline of how to move from a dysfunctional under performing "anchor" to a team that was the source of advantage for our organisation (perhaps to complete the nautical metaphor the sails that provide the power to push the organisation forward)!! I found pieces. One important piece was a outline of what an IS department in a high performing organisation looked like. Surprisingly high performing companies generally had high performing IS departments!! These IS departments spend less on average than their peers but still manage to invest more in competitive advantage and (presumably) deliver the value of that investment. The implication - they are very operationally efficient (about 40% more efficient than average).
We weren't very operationally efficient. Based on some statistics I managed to put together I reckoned we were about 20% - 25% less efficient than average). So what to do?? I sat back and thought. Over time a few things came to mind.
Firstly if our systems don't work nothing else matters!! Our priority number 1 was do whatever we needed to do to make sure our systems worked. I couldn't believe that anybody was going to engage us in a strategic conversation if we couldn't get the systems working. I had used ITIL in a previous life and while not an expert it seemed to be a sensible framework to help us move forward, create a common way of running our systems and to improve system reliability. Also many members of the team talked about ITIL as something that they thought had value. So there we had our first key decision. Drive system reliability and use ITIL as an organising framework for everything we did and use ITIL methods as a way to improve system performance. Bringing this to a reality became the major focus for the majority of the IS team for the next 4 years.
The next thought came as I was reflecting on the teachings of Stephen Covey and the the 7 habits of highly effective people. Specifically I began to dwell on Coveys concept of the Private Victory and how the Private Victory needs to precede the Public Victory. Broadly speaking I interpreted this as meaning you need to sort your own shit out before you were in a position to effectively engage with others. That is you need to be independently healthy before you can effectively synergise with others. Now Covey's work was primarily directed at the individual however I could easily see parallels to our department and our business and I began to realise that before we could work with other parts of the organisation to drive competitive advantage we first had to be very good at what we were primarily charged to do. That is we had to be a very good IS department!! Only then would we have sufficient credibility with other departments to allow us to proactively work with them to help them improve their areas of the business and through this create competitive advantage. In hindsight this seems obvious. Why would anyone ask me to help them if they couldn't at least see that I was capable of helping ourselves and were good at our own job!! (Later came to realise that this was true for all parts of the business and that the way you work with a department who hasn't achieved the private victory is very different to the way you can work with one who has. Maybe I'll write more on this later).
So I began to turn my attention to answering two questions.
- what does a very good IS department look like? (I had some guidance on this from the high performing organisations work mentioned above) and
- what do you need to do to create a very good IS department?
I started researching maturity models. It seems that in and around IS we have maturity models for just about everything but I couldn't find one for an actual IS department!! Maybe I needed to make one up!! My mind fell onto Maslow's hierarchy of needs. I have no idea why or how this happened. While I was aware of the concept of the hierarchy of needs I wasn't really a great scholar of Maslow's work or psychology generally (this has changed over time and the more I study leadership, myself and people's reactions to the world and others the more the topic fascinates me).
Through the hierarchy of needs Maslow teaches us that when it comes to motivation some human needs are more important than others thus forming a hierarchy. For people the first basic set of needs relates to our physical needs such as the needs for food and shelter. While these needs are unmet nothing else really matters. If you are starving to death the only thing that is important is finding food. There is no room for anything else. Once these physical needs are met however then they stop motivating you and you move on to the next level of the hierarchy. In Maslow's case the need for safety. This compulsion until satisfied and then failure to motivate cycle continues until we reach the ultimate state of self actualisation. (for those who are interested wikipedia and Businessballs.com both have good summaries for Maslow's hierarchy as I'm sure do many other sites).
It seemed to me that Maslow's concept of a hierarchy of needs fitted very neatly with Covey's work of driving change from the inside out (ie private victory precedes public victory). I began to mess with these ideas and came up with the following IS hierarchy of needs:
The hierarchy of needs provides a basis for understanding what needs to occur in order for you to be able to deliver business model innovation and differentiation for your organisation. Further it explains what you need to focus on today to meet today's needs and provides an explanation as to why we do or do not have influence as a department or as a CIO within our organisation.
You'll notice that the first two layers of the hierarchy are internally focused and represent the private victory of IS becoming a high performing IT organisation. The top two layers of the hierarchy represent IS's ability to build synergistic relationships with all departments to create sustainable advantage. The reality is if you haven't shown your ability to operate a high performing IS department then the organisation will not trust you as a partner with issues of enablement outside of IS or with issues of enabling substantial changes to your business model.
One point of clarification. The IS hierarchy of needs shows where the IS organisation needs to focus. It does not say that innovative projects are impossible if your main focus is on for example cost effectiveness. It does however say that this innovation is probably at the request of the business rather than as a result of a true partnership between IS and the business as you are unlikely to have the credibility to effectively partner. In these circumstances clearly the projects must be done and they represent a great opportunity to do them well and further build credibility while still primarily focusing on the core need of cost effectiveness.
So let's look at the hierarchy in some detail:
Systems Reliability
The most basic need for an IS department is to ensure that the systems that you currently operate are running when the users expect them to be running. In today's world if the systems are not running then the organisation will not be able to complete its most basic operations and in the extreme will very quickly close down. At this level of the hierarchy the focus is not really on whether the functionality is any good just is it available and does it work? There are many things that you can do drive reliability. For us, with ITIL as our framework of choice, the emphasis was initially on defining services, measuring service levels, problem management particularly for major incidents and change and release management to ensure we were not introducing new issues to our production systems. As we all know ultimately there is a trade off between systems reliability and cost. It is important that you agree this trade-off with key people in the business. 99.999% is not always appropriate. It depends on your business. Initially I agreed service levels with my colleagues as an aspirational target. I had no way of meeting them but asked them to agree to the targets so I could begin to measure my team and their progress. For us this meant 90% compliance with SLAs (standard 4 hours for P1s, 8 hours for P2s etc) and 99.5% availability for business critical services. They agreed. We began to measure our performance and improvement began (I'm a big believer in that you always get what you measure). It took nearly 2 years before we met these targets, now however, we meet and exceed these levels and my colleagues are very happy with the level of service.
Cost Effectiveness
It is at the level of cost effectiveness that you begin to demonstrate your commercial acumen. You do this by demonstrating that you spend money with care and you understand that cost control and value for money are critical for the ultimate success of the business. In this stage all IS business cases must have a positive impact on the cost of IS operations, however you choose to measure it (for us it is a combination of net present value and payback). The only exception to this is if you need to explicitly invest in such things are disaster recovery which directly target reducing business risk. Even here you should show that you are cognisant of the need for a balance between cost and risk. One of the outcomes that you should seek to achieve as you progress through cost effectiveness is to reinvest at least some portion of the operational savings into projects to help move your systems forward (through economically positive projects). For us our total IS spending basically remained flat for years (as a percentage of sales) as we progressed through cost effectiveness however during this time we reduced our operational costs by over 35%, built our capacity to deliver more projects and increased our capital/project spend by nearly 300%.
Many IS commentators believe that you shouldn't look at you IS department on the basis of costs but rather you should as quickly as possible move towards a profit center or even an investment center so all discussions are based on "value". While I have no objection to accounting for IS an a profit center I do not believe it is necessary. The main aim here is to demonstrate commercial acumen not to avoid scrutiny. My experience is that most executives are quite capable of understanding value no matter what the basis of accounting is. Also every organisation that I have been in looks at it's costs hard no matter how the accounting is done. The bottom line, however your organisation typically accounts for things is fine. Work within the accounting framework and show your competence.
As you work through the first two layers of the hierarchy and towards achieving the private victory it is likely that you will find that there are many initiatives that serve both reliability and cost effectiveness purposes. For example the less faults you have the more reliable but also the lower the operational costs as you can redirect peoples time and therefore costs away from operations towards improvement initiatives. Another example is that the modernisation of old legacy systems will often provide substantial cost savings and improved reliability.
Business Enablement
Having achieved the private victory most of your colleagues will have at least begun to reevaluate the IS departments contribution to the organisation. If our example is anything to go by you will begin to receive reasonably regular recognitions for the work that you have done. Also the types of conversations you are having with your colleagues will be changing. It is likely that your colleagues have all but lost interest in talking about service levels and if you are charging for your services it is likely that they have stopped talking so much about the charges. Rather most of your conversations will be about the projects they want delivered and increasingly they will engage in conversations about their longer terms goals and the role IS can play in helping to achieve them.
The purpose of business enablement then is to leverage the reliable and cost effective systems that you have created to enable all parts of the business to optimise the current core business model. This enablement will take two main forms. Firstly to use technology to improve operational efficiency through process automation. For many organisations this is likely to lead to a move towards greater process orientation. Secondly, to make better use of your data and information and begin to present this information to key decision makers in a way that will support them to make more effective decisions. Generally, process automation works on business efficiency and therefore cost reduction. Decision effectiveness however tends to work on improvements in sales and margin through better decisions. Both sets of tools operate side by side although they may be more effective in different parts of the business. For example in retail, process automation works best in operational areas such as supply chain and store operations whereas decision effectiveness is the tool of choice for our merchandising teams.
While this level of the hierarchy is not characterised as providing competitive differentiation the reality is that very few organisations truly optimise their existing models. As a result you are likely to begin to gain significant competitive advantage within your market place as you work through the process of optimising your existing business model.
Finally a quick note on the skills you require within your IS team. When the focus is on the first two layers of the hierarchy the primary skills you want in your team is great technologists who know how to really make your IS systems hum. As you move into business enablement however the core skill set changes. Yes you will still need great technologists but now your focus is on proactively teaming with other departments. This means you will need some new skill within your IS team. Specifically, you will need to build a deep understanding of how the business works and adds value to your customers (ie how it makes money). Indeed, the IS team needs to understand the business and how it operates as well as their colleagues in the departments they are engaging with. Only then will they begin to engage with you proactively as peers and in a strategic way.
Competitive Differentiation
Having worked with your colleagues to get the most out of your existing business model the door is now open to begin to look at ways to either change your business model or introduce new business models that will substantially change the basis of competition within your industry. This is where all the industry hype says you should be but it is a place that few achieve, especially few for large traditional industry incumbents. Honestly I do not really know what happens at this level of the hierarchy as we haven't achieved this and are some way off getting to here (our current focus is business enablement). I do believe however that when you seriously focusing on new business models there is a lot more at play than simply technology. For example the role of disruptive technology and the difficulty that incumbents have in nurturing disruptive technology will need to be examined. I am a fan of the work that Clayton Christensen has done in this area.
So, that's my version of the IS hierarchy of needs. It plays a major role in our IS strategy, what we do day to day and how we explain why we do what we do in IS. The hierarchy of needs philosophy is beginning t be picked up by other parts of our business. They are looking at the technology and asking how they can apply it to their parts of the business so we are starting to get a shared development language across the business.
Another key part of how we operate is the concept of persistent
needs. That is focusing on those issues that are ever present no
matter how good or bad you may be. I will explore this topic and how
it relates to the hierarchy of needs in more detail in a future post.
Finally some acknowledgements. None of the ideas presented here are really mine. Pretty much everything is borrowed. While I have acknowledged two key sources being the work of Abraham Maslow and Stephen Covey the reality is that this thinking is the result of many ideas from many sources and many tangential thoughts. While I was developing this framework I thought the final outcome was unique. I have since discovered that a number of other people have taken the ideas of Maslow in particular and applied them to IS. This includes Stephen Sheinheit CIO for Metlife, Cathy Harris from Gartner and Claude Durand from Osiatis.
It is very reassuring to me that others have reached similar conclusions as it provides a source of validation to my thinking. To the extent that I have inadvertently borrowed someone else's ideas, thank you for helping me on my journey and I apologise if it has caused you angst as it was unintentional.
