Skip to content

Fundemental Shift 10 things you need to shift your IT Department to Demand Focused

October 13, 2008

A Checklist to Action:

Once you’ve decided where to start — or events have made the decision for you — you have to decide on two or three components of the new model to implement, with the objective of institutionalizing them inside of a year. The overall guiding principle should be to institutionalize every year at least one or two of the model components in part of the organization (realistically, you won’t be able to do it company-wide). Examples could be demand management, iterative development or time entry. At the end of each year, you should be able to answer the question ‘What have I institutionalized this year?’.

Here is a high-level checklist of the end-to-end essentials you would need to implement for the new model. If you were to ‘slam-dunk’ it into your organization, this is more or less the order in which you would do it.

  1. CLIENT MANAGEMENT: assign IT client managers to be the single points of contact for your internal clients at the level of department, application or major functional area.

  2. APPLICATION MANAGERS: get the business to assign application managers to be the single points of contact for your IT client managers (above).

  3. ITERATIVE METHODS: start training or recruiting project managers to be able to run interactive workshops for process modeling, and business analysts and developers to design and develop new systems based on a prototyping approach.

  4. TIME ENTRY: get all IT staff to enter time against both new projects and production applications in order to capture your people costs.

  5. APPLICATION-LEVEL COST TRACKING: Once you’ve got time entry under control (above), you will know your people costs in terms of product development and operations. You can then associate this with the corresponding infrastructure costs to determine total costs at the application level. The same would apply to projects, which represent the first phase of an application’s life cycle.

  6. APPLICATION-LEVEL BENEFITS TRACKING: get the application managers from the business to start monitoring the ongoing benefits of their applications. The same would apply to projects, for which you would monitor ‘benefits to completion’ to ensure that whatever is delivered for the first version is capable of meeting the business case originally put forward.

  7. DEMAND CAPTURE (NB not the same as demand management, covered in the next point): ensure all demand for IT products and services from the business is captured into a demand pipeline in a structured format in terms of description, reasons, timing, benefits, costs and feasibility. Note that this component is inextricably linked to the first one in the list — without credible client managers in place managing the business relationship, it won’t be possible to have a demand pipeline.

  8. DEMAND MANAGEMENT: set up an investment committee or project review board to manage the demand pipeline (above) in terms of business priorities and IT resource and scheduling constraints. The resulting prioritization and approvals process (ideally portfolio-based) will cover both new projects and enhancements to production applications.

  9. APPLICATION-LEVEL ASSET MANAGEMENT: however useful your application-level cost and benefit tracking (points 5 and 6 respectively), it is only a snapshot of the present; it doesn’t say anything about the future. For this, you need to combine it with the demand pipeline (point 8 above) to obtain visibility into application change requests and feature requests. With this combined view of both the present and the future, you will then be able to start proper asset management and make informed decisions about funding or retiring applications.

  10. PRICING AND CHARGE BACKS: once the above fundamentals are in place, you can finally start to introduce pricing mechanisms for IT products and services. Note that pricing has deliberately been left for last, because once you’re going to start asking people to pay for something, you’d better be very sure that you have your shop in order in terms of demand, supply and quality of service. People will only accept to pay for something which was previously free if they are generally satisfied with it. Rushing into pricing and charge backs too early can thwart your whole change program and set you back many years — only do so when it has a chance of being accepted (people have long memories when it comes to bad experiences in IT).

A checklist like the above is one thing; translating it into something actionable is quite another. Realistically, such a change program cannot be launched company-wide without the CIO dropping the ball in terms of ongoing projects and keeping the lights on. So whether you are starting from a particular pain point, a mature application which is working well, or an event outside your control, here is a recommended approach — most of which is based on real-world experience in a multinational pharmaceutical company and a global telco.

There are two main phases:

  • The first one is to set up a partnership with a key stakeholder in the business and to deliver a new project with workable results in a short time based on iterative methods. Results, rather than good intentions, will provide you with the credibility to take things further.

  • The second phase capitalizes on these results by formalizing the IT/business partnership around the new project and introducing application-level asset management.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: