Recently, I joined a breakfast of CIOs in London. During the discussions, there was – what I would call – grudging agreement around the table that IT implementations usually start out with a business objective.
As one CIO put it however, “a third of the way through the project, the why of it got lost and we focused solely on the requirements list and on how to make it through.” With the desired business outcomes all but forgotten, these projects invariably fail.
Indeed, Prosci’s latest 2016 report showed that 59.3% of all IT projects did not meet their business objectives. A terrifying statistic.
But why are they failing?
Business leaders are accountable to their shareholders, and every decision at that level is ultimately driven by the need to generate improved returns. What I’ve found over the last few years has been puzzling – business leaders speak about how important ‘adoption’ is, yet I rarely, if ever, find a project consistently linking business needs with IT delivery.
A business case is often identified, a decision taken and the implementation project is thrown over the fence for ‘IT to deliver.’ Adoption is then assumed.
Doing a minor survey of a few dozen projects over these past months, I found that not a single project has had a definition of ‘adoption.’ I think this happens because it’s considered ‘fluffy’ and right down the alley from ‘the guys from change.’
Getting back to accountability, every single project leader was under pressure to streamline their projects and efficiently use their resources. Anything ‘fluffy’ invariably got cut. So, in most cases the resources of the corresponding client teams were cut by IT under a variety of titles linked to cost optimisation. Business usually did not even get involved and even if it did, a dedicated change team was set up operating independently of anything that IT did. In effect, working towards its own goals. Adoption and change are people powered. IT delivery focuses on the systems only. These two areas need to be integrated for success, not separated.
Case in point: one company established an independent readiness work stream using a waterfall approach in its planning, while the IT delivery was set up strictly agile. The lack of synchronisation led to 3-6 months delay in the go-live for each iteration!
What’s the solution?
I’ve found a simple solution, which I’ve been deploying over the last few years. It provides a clear and simply defined KPI structure for adoption.
My adoption KPI solution requires businesses to integrate system elements from software application, business process compliance, data quality audits and even behavioural aspects and actual business outcomes outside of your systems into one, neat, measurable KPI for your various business areas.
This KPI can be further broken down into components for system, process, behaviour and business results to allow for effective, data-driven improvements.
The Adoption KPI Explained
For your staff to make decisions based on your new system, they need to learn to trust it. And they can only trust, when they know the data is sound. For the data to be of sound quality, it needs to be continuously worked with it in the system. My approach provides a clear path to achieve this.
For people to continuously improve, leaders need to keep them consistently motivated and provide momentum over long periods of time, to allow new habits to form. The initial uptake is only the start of the journey. It continues into the process and quality of what your staff do with the system and finally on how they use system, processes and data to drive their decision making. Staff rotation, vacation period and system upgrades continuously put pressure on your adoption.
With an appropriate KPI like the one proposed, it becomes easy to identify root-causes and drive mitigation measures pro-actively (click to enlarge graph). On the other hand, without a KPI, you would not even see the deviations starting. System use will continue for a long-time albeit your staff will first grumble about bad data, processes not working and finally re-create their black books and Excel tables to use the system only superficially or abandon key functions of it outright (click to enlarge graph). Your investment up in smoke.
How can I implement the Adoption KPI Methodology?
You’ll need to upskill an ‘Intervention Team’ to implement, monitor, intervene (based on data and root-cause analysis) and drive your business adoption. Do not rely purely on your team’s business analysts, but on your staff who live and breathe your day-to-day operations. View it not as simple training but as transforming your way of working, and delivering results.
Fact-based. No more fluffiness.
Personally, I am on Peter Drucker’s side: “What you cannot measure, you cannot improve.” The earlier the better, of course… but also: better late than never. Who wants to lose millions of pounds worth of investment, after all? If you want to make your projects more successful, start today!
You’ll also need to define your adoption objectives jointly with the business, considering day-to-day operations. Do this not just for the go-live day but also for three, six and 12 months later, moving from simple system operations, like logging on, to data quality measurements, to actual business outcomes.
Why? The implementation of business-critical software should always focus on adding value to the business. Clearly identify and quantify the business outcome expected from your implementation, and use these as your north star.
In other words: start with the end in mind.
Contact me, Alexander von Massenbach – firstname.lastname@example.org to find out how my team at Hitachi Solutions can help you ensure that your business objectives are met when implementing or upgrading critical software applications.