Assumptions: Key culprit behind failed software implementation

Roehan Manders, Head of Delivery, The CRM Team.

---

Incorrect assumptions are often an underlying cause of failed and disappointing software implementations.

This is according to Roehan Manders, Head of Delivery at The CRM Team, who says assumptions made about existing processes, what new software solutions will do and the value that will be obtained from implementations can undermine the success of these projects.

“In South Africa, we find that many organisations don’t prepare well ahead of implementations. They don’t have internal workshops to properly define what their own processes are. When assumptions are made and processes aren’t documented, it is very difficult to quantify how the process changed the business,” he says. Manders says other key pitfalls and challenges are poor user adoption and internal resistance.

He outlines five essential steps and best practices for a successful software project implementation:

Internal workshops and stakeholder alignment should take place before the organisation selects solutions to be implemented, Manders says.

“The customer or business needs to understand their vision with the possible implementation. They may, for example, have identified a problem with sales. They then need internal sessions to outline their vision to overcome the problem. Do they need to double their revenue, reduce admin or have the best reporting?” he explains.

This process typically begins at executive level and filters down to teams for internal workshopping. Manders says: “In organisations with a high level of maturity, all processes have been documented – for example, how a customer is onboarded and all touch points and steps in the engagement. In other organisations, the sales process is not bedded down, various stakeholders have differing views of what the process is. Before trying to improve a process or systemise it, you need to identify current processes and achieve a common understanding and alignment of what those are.”

This can result in robust debate and certain unexpected findings, he says.

“Once you have bedded down the existing framework and processes, you interrogate what is wrong with the process and how it can be improved. Only after those initial discussions should organisations start looking into the market to research what applications and platforms address them,” Manders says.

Manders notes that it is very important for customers to then start documenting their requirements. “They should not assume their implementation partner knows exactly what they expect,” he says. “They may say, ‘I want a customer portal’, but this is quite a vague requirement. They need to break down and specify their requirements with a lot of finer detail. The implementation partner needs to know if you want the customer to be able to log in and have access to data on current proposals, whether they need to be able to log in via Facebook and Google, and whether a ‘forgot password’ option is required.”

Communicating clearly with the implementation partner is crucial to ensure they fully understand the requirements and how systems should work, Manders says. “A lot of assumptions are made. The customer might assume the new system will do everything the old system does, without telling the implementation partner that. Another assumption is that the partner knows the business, with its every process and requirement. This can cause aspects to be missed and/or disappointment,” he says.

Manders says only one assumption should be made in planning a software implementation: “A rule of thumb is: if you don’t see details of your requirement as part of the implementation, assume it’s not going to get done,” he says.

He notes the responsibility for clearly defining requirements doesn’t rest with the customer alone: “The implementation partner needs to ask the correct questions to help get this information from the customer. Ideally, senior people need to help them navigate this journey, asking the questions and getting as much information from them as possible. Some of the best analysts, consultants and project managers aren’t ‘yes men’ – if the customer requirement doesn’t make sense, they should challenge the customer, asking why they want to do it that way or pointing out when it isn’t best practice.”

Within agile methodology, the role of the product owner is crucial for project success, Manders says. “This person is a key part of the envisioning and analysis phase, manages business expectations and works as the gatekeeper to prioritise requirements and ensure that the project delivers the value expected,” he says. He explains that a good product owner needs to have time and availability for the project, as well as a mandate to manage stakeholders. “They are ultimately the key contact within the organisation during and after the implementation. It is crucial to have the right person – or people – alongside the vendor.”

Internationally, poor user adoption is a major reason for software implementation failure, Manders says. “When customers in South Africa look at a proposal and there’s a line item for training, they often reduce or eliminate the training,” he says. “However, training is a big part of user adoption.”

He notes that ensuring user adoption starts before the implementation: “It’s when the executive positions the value to teams and gives them the ‘why’. Throughout the implementation they need to start sensitising the business through communication from the CEO, creating hype and generating excitement. As the implementation is completed, end-users and mid-management must be trained to use the system and leaders need to be seen using the new system themselves,” he says. “If you don’t enable and encourage people, there will be resistance, people will find the new systems too daunting to use and they will stick with their old systems,” he says.