It was tricky finding a title for this post that wouldn’t get a ‘roll your eyes’ type of reaction as it flashes up in your inbox or news feed. Let’s face it – the topic has been around for a while and has generated lots of cyberspace content. So, do I have anything new to say? Why have I decided to write about this topic?
Despite numerous IT implementation failures, we keep repeating history.
Many statistics and research point to high percentages of failed IT projects. I do have a perspective on this, however, before I start sharing it, I’d like us to get aligned on a few things…
What do we mean by success or failure when it comes to IT projects?
A simple business view definition would be a project that is delivered on time, on budget and to specification. However, I’d like to qualify this further by defining success as:
- the realisation of tangible benefits;
- with business requirements being met or exceeded;
- where users choose to use the system because they can get things done more efficiently and effectively;
- and not at the expense of the customer’s experience!
Which root causes do I not want to talk about?
There are some typical causes of failure in projects that are common across all large changes, and not unique to IT implementations and these are not the focus of what I would like to share in this post. Here’s a few repeatable reasons why projects fail: Poor project definition; scope creep; inadequate training;overlooking essential stakeholders and insufficient rigour and undefined requirements.
I’d like to go beyond this obvious stuff that we all know we should focus on in all of our projects.
Some organisations have the foresight to know there will be more to their IT project than a technical solution delivery. Others realise this part-way through the project, when they start seeing that they are only going to get a technical solution delivery! I liken an organisation to a human body, it’s complex with lots of inter-connected parts and ‘systems’, (some better understood than others), which allow it to function. An IT system is often referred to as the backbone of the organisation, giving support, structure, flexibility, protection, connections, response and flow. Words that are associated with both the spine and IT systems! So when I think about ‘change of system’ projects, I can’t help but consider this obvious question:
Would a neurosurgeon operate on the spine without understanding and planning for all possible impacts? Then, why would an organisation replace it’s core IT system without understanding and planning for impact on all surrounding parts and connections?
Attachment points to muscles and organs, stability, flexibility, mobility, support for various activities and protection of other parts of the body are all considerations that a neurosurgeon would account for in planning any correction to the spine. Considerations that, if you extend your thinking to an IT implementation project in a business, could translate very easily!
The project approach and lifecycle often only include activity that directly correlates to the technical scope and solution of the project.
I find that many organisations do consider the basic principles of successful project and change management for their IT projects. Often their implementation partner brings some of this discipline to the table, even if their own internal capability and capacity do not suffice. However, the project approach and lifecycle often only include activity that directly correlates to the technical scope and solution of the project. Therefore, what usually doesn’t get included are those activities that adapt the surrounding systems and structures so that the system change can be successfully embedded. After all, a round peg, needs a round hole! So whilst the project team and solution provider are busy focused on specifying and building the
round peg, is anyone actually thinking about the round hole?
Just as a multi-disciplinary medical team would consider the wider context of the change (before and after surgery) for the patient, as well as meticulously planning and conducting the procedure itself, an organisation also needs to collaborate across some topics that are wider than the absolute scope of the project and that goes beyond solution delivery alone:
- What is the business’ readiness for this system change?
- Does the set-up of the project give enough consideration to the business aspects of the change, and not just the activities for the technical solution?
- What does ‘integration’ actually mean in the context of this organisation and the scope of this system change?
- What is the impact on existing processes, policies and procedures ensuring that all upstream/downstream changes are considered?
- How is the design of the organisation impacted? Can we take advantage of the system change to redefine boundaries around who does what and hence make the acceptance of the system more of a ‘natural fit’ to how work gets done?
These are some of the areas that differentiate successful systems implementations from those that are not! There is not a checklist or ‘off the shelf’ approach to address these areas – each one needs to be explored within the context and culture of the organisation and the nature of the system change. However, co-creating the answers to these questions; designing the appropriate approaches and interventions; and ensuring that all necessary business changes are integrated with the technical activity within the project will allow you to enjoy more success than the ‘install and hope’ alternative.
IT projects are not just the delivery of a technical solution. But that’s how most businesses approach the issue – resulting in legacy issues long after the installation has gone live. That’s not to say that internal IT teams or external providers have not done their job – but that a crucial layer of business oversight has not been allowed for. An external provider cannot understand every nuance of your business. But many companies rely on their insight too heavily – resulting in a ‘one-size-fits-all’ solution that fails to consider the specifics of your culture and business context. Considering the interconnected parts and managing the required changes will require time, effort and resource however, armed with foresight and knowledge you will be more realistic in setting timescales and budget and your approach will be tailored entirely to the quirks of your business.
Is your organisation embarking upon an IT system change? Do you, the patient understand the wider context of what the change will mean? Do you really understand what will stay the same and what will have to change?