Successful implementation of new digital systems is more important than ever for businesses to innovate and differentiate from their competitors, but new software is only as successful as the human process powering it.
The winning outcome of new software systems for a business depends on far more than just the technology
Putting new IT systems in place is generally a big investment and when everything is done right, pays dividends. But when the process and system aren’t in sync, it runs the risk of being wasted money, or worse, more costly than doing nothing.
At Sandfield, we tend to have a different view to the norm on what makes a successful project. The traditional goals tend to be meeting original budget and deadline, and final functionality meeting the initial specification. We’ve learnt that these types of KPI’s are only part of determining a successful project - deeper digging during a live project often reveals new challenges and solutions that shift the goalposts.
What is success?
Our definition of success is simple - everyone’s happy. This is always our end goal. Enough experience over the years has shown us the key ingredients to achieve this, a previous blog post talked about the importance of communication to a successful project.
The winning outcome of new software systems for a business depends on far more than just the technology.
We wouldn’t recommend putting a new solution in place unless an organisation is prepared to be fully engaged in the entire process - ready to either make changes in the business or ensure the software exactly meets existing business processes.
Once stakeholders have invested in having a new system built, from the outset, it’s important they are also invested in driving any process changes that come out of the new system.
Once Novopay was launched, there was almost daily media attention about the system’s widespread problems
A well-known example of a disconnect between new systems and process is the Novopay debacle. The Ministry of Education would be the first to admit it had the best of intentions, but wasn’t fully engaged in the planning, testing and driving of new processes that came with its new payroll system.
A bit of background - the Ministry’s vision was to replace the existing schools payroll system with a modern, technology-based solution which would provide greater functionality, a better user interface and more useful information about the national schools workforce
Once it was launched, there was almost daily media attention about the system’s widespread problems - with more than 8,000 teachers receiving either the wrong pay or no pay at all among other things.
While Novopay and Talent2 are the names we may remember from the debacle, this is not necessarily a fairly earned bad reputation. Although the software had a few bugs, more crucially, it didn’t match business process - so one had to change
One of the other key learnings following the official Novopay Enquiry was not only that its main weakness was mismanagement of the Novopay vendor relationship, but also the “need to identify and engage with customers and users in a meaningful way throughout change projects”, as identified by a report by the Institute of Directors.
The critical point here to consider is that the same software has examples of working fine elsewhere. To ensure success, it is all about matching the business process and that can only be driven from the top.
It's all about matching the business process and that can only be driven from the top
This brings us to the value of Scenario Testing - essentially testing out a number of different possible situations that may occur with a new system. This ensures the new system and the business process can deal with whatever comes its way before it goes live and there are real business consequences.
The story of the race car
Imagine you have an old race car at home, you and your friends have some basic mechanical knowledge and tend to do a lot of servicing of it yourself.
But what if we transferred you and your team of friends to the Grand Prix, tasked with maintaining a top racecar.
Suddenly, with the time pressure of the race and a much more sophisticated car to service, having one person changing the tyres and refuelling doesn’t quite work like it used to. The vehicle is different, the environment has changed, and therefore a different process is needed to service it efficiently.
Just like the race car analogy, all stakeholders need to be engaged with the process and system and be ready and able to respond to change for it to have any benefit or it’s pointless to bother with new software.
There will always be barriers and resistance to change
There will always be barriers and resistance to change. The most effective way to approach these is by recognising potential barriers, and proactively making decisions about how to deal with any resistance to change that may occur.
A common one might be that your end-user isn’t willing to change, so the decision tends to be either to train/manage those people through the change or change the software so that the people don’t need to change.
Unfortunately, as the Novopay example shows - simply ignoring these barriers and hoping for the best will end up costly and potentially with people thinking the project failed.
To engage stakeholders consistently in the process, it’s useful to hold project governance meetings throughout the project - communication is key - these topics need regular air time and often solve important potential pitfalls.
Even though things are faster than ever, for your project to be successful - it is still crucial for management to invest time to support the new system by owning and driving the right level of change for their team at a pace that’s comfortable to the organisation.
If existing business processes need to change then this needs to be owned, embraced and driven by the management team. As history shows us, just putting the software in and hoping it will all work, doesn’t.
