When new software isn’t enough - How effective management can drive the success of new software systems | Sandfield

23 August 2017

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.

Novopay

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”.

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.

Mechanic


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.

Related Articles

Case Study

My Concrete app: Making hard easy

The My Concrete app shows customers exactly where their concrete delivery is. A NZ-first, it was developed by Sandfield with Allied Concrete to make jobs easier for the construction...

Read more 

Opinion

Architecting a robust, scalable system

One of the key architectural decisions that needs to be made when designing a transactional system is the trade-off between concurrency and accuracy. The decision is not always straightforward,...

Read more 

Opinion

SQL upgrades: Why you need a roadmap

In 2005, late on a Saturday night, I inserted the first of two CDs into SQL Server 2000 and started an in-place upgrade. The upgrade completed normally and all systems ran without a...

Read more