I developed the IS Hierarchy of Needs while I was the CIO of The Warehouse. I developed the hierarchy because I had to. Let me explain.I became the CIO of The Warehouse full of joy and hope of the world because I believe in the power of technology to be a major catalyst of change and a source of competitive advantage and as CIO I was in the prime position to make this happen. You see previously I was a consultant and while I love consulting two things in particular grated on me. After many years as a consultant I was frustrated that I seldom got to see the fruits of my labour because I usually left when the implementation project was over. Most IS enabled projects however take time to bed down and deliver the promised benefits so I was rarely there to see the final results achieved. Worse yet, I could see that in many instances the decisions that my clients were making meant that they were well on the path to ensuring the project failed to deliver on the promises that were made. I found this very frustrating as it meant all my hard work and all the hard work of the team would be wasted, or worse, we would get blamed for a bad result. As CIO I would have the chance to change this.
What I found shocked me. An IS organisation in disarray. There was no time or money to focus on driving competitive advantage because all our money went into keeping our systems working. 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. I had a lot of empathy for my team, they were smart and they did work hard, but I was on “management’s side”. 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 and some of those decisions I previously hated began to make some sense. I had to work out how to get from where we are today, struggling to operate and maintain our systems where I wanted to be which is in a position to deliver value and ultimately be a source of advantage for The Warehouse??
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 an 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 initiatives to drive competitive advantage and (presumably) delivered 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 we were about 20% – 25% less efficient than industry 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.
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 Covey’s 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 get your own back yard sorted before you were in a position to effectively engage with others. Covey’s work is primarily directed at the individual however I could easily see parallels to our department and our business and I used Covey’s insight to begin to understand that before the IS team could effectively 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 doing my own job!! (Later, I came to realise that this was true for all parts of the business and that the way an IS team works with a department who hasn’t achieved the private victory is very different to the way you work with one who has).
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 IS department as a whole!! Maybe I needed to make one up!! My mind fell onto Maslow’s hierarchy of needs. While I was aware of the concept of the hierarchy of needs I wasn’t a scholar of Maslow’s work or psychology generally (this has changed over time and the more I study leadership, myself and my impact on the world around me 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 and that we focus compulsively on satisfying our most basic needs before moving onto our next most basic need, thus, forming a hierarchy. This cycle of compulsion until satisfied then move to the next need, continues until all of our deficiency needs are met and we reach the ultimate state of striving for self actualisation.
(for those who are interested in learning more about Maslow’s Hierarchy wikipedia andBusinessballs.com both have good summaries 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. If you are here now congratulations and good luck. You have all the guidance in the world on how to be successful in business model innovation as this is where all the industry hype says you should be. “Innovate or die” is the cry. Better yet, you now have a solid base to build on including being trusted within your organisation that will support you in being successful.
Please note however, real business model innovation is something that few companies achieve, especially few for large traditional industry incumbents, unless there is a compelling dire consequence of not changing. A good place to start looking to understand why is Clayton Christensen’s work on the difference between sustaining technology and disruptive technology.
So, that’s my version of the IS hierarchy of needs. It plays a major role in how I view strategy and guides my recommendations on what needs to be done day to day in order to be successful. The hierarchy of needs philosophy has been picked up by others who are using the concept to help them understand what they need to do in their parts of the business as the concept is universal.
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.