There is an old Dakota tribal wisdom, which was passed over from generation to generation. It basically goes like this:
“When you discover you’re riding a dead horse, the best strategy is to dismount.”
This strategy seems to be simple and logical given the above situation. However, if we adapt this to the IT world, there are often other strategies deployed in reaction to the ‘dead horse’:
- Change the rider (e.g. the IT project manager or service manager)
- Engage an IT outsourcing partner to ride the dead horse
- Add more CPU (horse) power
- Appoint a taskforce to revive the dead horse
- Appoint a committee to study the dead horse
- Create a training session to improve our riding skills
- Arranging to visit other sites to see how they ride dead horses.
- Ignore the dead horse…what dead horse?
- Harness several dead horses together for increased speed
You might find plenty other examples for yourself to what is called the ‘dead horse problem’. Adapted to IT Governance it basically refers to the base concept of Value Delivery. Whatever you do as an IT Service Provider towards your internal or external clients, it should deliver value. If you develop or deliver services that do not constitute (anymore) value to the customer, you end up with the ‘dead horse’. You can try to beat it, you can flog it, this will not change the fact – the horse is dead.
In IT, we need to pay special attention to the dead horse problem: Due to the fast-changing environment (business needs and technology) and complexity we are often confronted with such dead horses. I am sure you already saw them, just to give you two typical examples: The ongoing IT project that is delivering a solution, which is not needed anymore or dependencies on products/tools, which turn out not to support the requirements (wrong tool choice).
The answer to the Dead Horse Problem
So what’s the solution for this? Sure, IT Governance! There are basically two aspects in this:
- Having control mechanisms in place to proactively ensure that no services are introduced, that do not deliver value
- Continuos review of all services to identify their value contribution and taking corrective actions where necessary (the reactive part)
Having a proper Service Portfolio Management in place is key for this. Make sure that each new or changed Service has a Business Case in place, showing a realistic expected Return on Investment (ROI). This is a prerequisite before taking the decision to approve a new (or changed) service and setting up the project. Besides this so-called ‘pre-program ROI’, also make sure that during the Service Design and Transition phase and finally once the service is life (Service Operation), the business case is continuously verified. Especially during longer projects it can happen that the outside requirements change and the original value case needs to be revised. Once the service is life, conducting a Post-Program ROI calculation recommended. This is where it gets very interesting: Does the service really deliver the value that was originally promised in the pre-program ROi? This is the moment of truth. Let’s face it: In reality many of these calculations would end-up negatively. The main reason for this is that the pre-program ROI often can be done based only on hypothetical assumptions and this leaves open room (not to use the word ‘cheating’) to the project requesters to present a positive business case. So, what is the best thing to do, if your new e-Learning platform that was promised to have 50’000 users turns out only to have 5’000? According to the Dakota wisdom: Dismount and search for a new horse!
The role of IT Governance Frameworks
As we learned above, a proper Service Portfolio Management in place is key to ensure the value case of your services and the right decisions are taken – proactively and reactively. Or in the language of the wise Dakota tribe: Being able to know that you have (or will have) a dead horse.
Modern IT Governance Frameworks such Cobit, ISO 20k or ITIL are suitable frameworks to set up a Service Portfolio Management System. This is how they deal with the dead horse problem. On the other side (and here comes the point), they are also perfect to create dead horses. Please allow me to explain on this: Although all these frameworks contain detailed best practices (in ISO 20k they are called ‘Shalls’ and ‘Shoulds’) – does this help you, if the assumptions behind a business case are not sufficiently questioned? Too often these frameworks are misused and people can comfortably hide behind them (e.g. ‘I have a formal business case for my project, therefore everything is ok’). It is therefore paramount that you focus on these key areas when setting up an IT Governance system to ensure that no fake value cases can happen and value is continuously monitored, evaluated and appropriate actions are taken.