The IT Value Chain

The IT Value Chain

All around the country – when IT leaders (whether this person is titled CIO or Director or Manager – which is a topic for a later post) speak with their CEO, the topics of infrastructure performance, SLA performance or incident management are not the primary topic of conversation. Most of these conversations do not address IT strategy, security or governance structure. What will be discussed is the status of a key project, a failure in managing one of the above topics or that the CEO’s new smartphone is not working. So my first set of postings will address how IT can be recognized as being successful by non-IT people, especially by the executive team. Another way to put it is ‘What is the IT value chain?’. IT is just another part of the business, and therefore IT professionals must think in business terms. For those of you not familiar with Michael Porter’s work on strategy and the business value chain, I encourage you to do a little reading. Just to set the stage for this article, my intended audience is the leader of IT in the company. The companies are specifically PE and VC firms or their mid-market portfolio companies. This is the world I have come to understand. In each posting, I will mention the intended audience. Many blogs will be directed to business executives.

So what is the value chain of IT? What does IT do that executives perceive as adding value? It can be stated very simply as plan-build-run. From there, it gets a lot more complicated. First, I am going to describe what is not included in the IT value chain. Many of these I mentioned in the first paragraph. The value chain does not include strategy, architecture, budgeting, organization development, data center management, regulatory compliance, security, vendor management or any other activity that does not directly impact an end user (customer). No IT organization can successfully run without these. They are very important. But no business executive wants to talk about these items. It would be like going out to your business customer and engaging in a lengthy discussion about your accounting function. Accounting is a necessary part of the company, but not what the business customer sees as adding any value.

The first step in the IT value chain, to plan, is all about managing demand. At this point you might think demand is a long list of project requests you have compiled on a spreadsheet or, if you are a little further along in your organizational maturity, a project roadmap. If this is your starting point then you are missing several key processes for success. Your business has a sales function that includes Customer Relationship Management (CRM). The purpose of CRM is to understand the needs of the customer and to fill and prioritize the pipeline. This needs to be your first step also. Filling the pipeline is easy, since demand will always exceed supply in a support organization. So the key for success is demand management–establishing a framework that lets the business set priorities and decide on what to purchase. I recommend two points: first, get your executive sponsor involved, and second, have a quantitative process to set a score for a project. The executive sponsor should be the person IT reports to that is on the executive committee – the CEO, CFO or COO. This person needs to be involved in the IT organization, understand the many demands on IT, and how the non-value chain portions are managed. If you do not have this level of commitment, find someone else to report to.

The quantitative process assists in setting priorities. Key elements in this include;

  1. Project title (everyone should be able to identify the project and purpose from this),
  2. Corporate goals that the project fulfills (from the documented company strategy if you are fortunate enough to have one, or the implied company strategy if you are not),
  3. Business and project risks,
  4. Business owner (IT does not own these projects, if you do not have a business owner you do not have a project),
  5. If it is a regulatory requirement,
  6. Financial estimate,
  7. Time and effort estimate and
  8. Project dependencies.

This list will be different for each organization so consider this is a minimum criteria list. Other than project title, these elements will all be factors in setting a scoring the project’s priority. Each element should be given a numeric score such as 3 if it meets 3 of the 5 corporate goals or a score of 1, 2 or 3 for project risk, with 1 being High Risk. After scores are set, they should be weighted based on a total of 100%. Once the total values are set, rate each factor and calculate the total. This calculated score does not necessarily have to set the priority, but it gives you and the executive team a process for evaluation.

The other essential element to demand management is your CRM plan. How do you discover what needs exist? You need to have a communication plan for your customers. I learned from a prior CEO to keep a ‘Top 25’ list of people in the company with whom I need to maintain communication. The actual count is up to you but the process is the same. Identify these ‘customers’ and how they like to be informed. Use MBWA (Management By Walking Around), phone calls on specific topics or projects, email updates, scheduled meetings, or a monthly/quarterly status. I have found that some of these people only want to hear from IT when an incident occurs and is resolved that impacts them or their department. Others like informal, free thinking discussions. Use what works best for the customer. Develop a matrix with key people down the left and the topics and communication method across the top and, then, execute the plan! Invite some to lunch. A CRM, as simple as this, can resolve many issues I have found in IT organizations that are struggling with too many project requests.

So far, I have talked about the IT value chain, what it is and isn’t, and about two key steps in the ‘plan’ segment of the value chain. Do not confuse this with strategy, which is a topic for a future posting. I also have not talked about projects vs. support, which is always a grey area since support development can become a significant effort. Next week I will get into the build (really build or buy and implement) segment of the IT value chain. I hope this provokes discussion. Over the course of 30+ years of experience, I have developed a framework that works in most organizations. What I have learned is that it is a just a framework, and should be applied to meet each organization’s need.

I encourage all IT management to look at industry standard frameworks including COBIT, ITIL, PMBOK, ISO, NIST or whatever else you want to study to help you build a framework that supports your business growth and transformation.

There are hundreds of potential topics for future blogs. If you think I can provide any insight to help you, please let me know. I will also be glad to share examples of any tools I have created along the way.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *