Last week while attending the IFS UK&I User Group Annual Conference outside of London, I had an opportunity to sit down and chat with Alastair Clifford-Jones, CEO of consulting firm Leadent Solutions. Besides bonding over a mutual love of live music and sharing parenting tales, we reflected on our years in the world of field service – what has changed and what hasn’t.
One of the points that Alastair brought up related to what has changed is that earlier on in his time working with field service organizations, there were situations where software implementations went awry because the technology simply didn’t work the way it was intended (or promised) to work. With the advancements that have been made and the current state of service management software, however, the reality is that today’s technology does work. “Technology works; projects fail,” says Alastair. “The solutions that exist in the market today are strong – but that doesn’t mean that implementations always go smoothly.”
I asked Alastair to share some of the most common reasons that the implementation of a solid field service software solution go wrong. With many years of experience consulting in a variety of field service industries and with numerous software platforms, he summarizes the five failure points that take the best of intentions off course.
1: CHANGE MANAGEMENT GETS DEPRIORITIZED (OR CUT)
While companies all “see the value” in change management and consider it an integral part of software implementation, according to Alastair efforts often deteriorate as a project goes on. “Change management may account for $2 million of a $10 million project as a company sets off with great intentions, but it’s the first thing to get cut from the budget,” he says. It isn’t so much a failure to recognize the importance of change management, but rather the willingness to compromise on well-laid plans when dollars need to be saved or reallocated.
Companies that think they can find shortcuts or workarounds with change management to save dollars often find themselves in the midst of a failed project, because as we all know change management is critical to acceptance and adoption of the system.
2: THERE’S A FAULTY DEFINITION OF FAILURE
Another common failure point Alastair described is that companies sometimes perceive failure when, in reality, the project hasn’t failed at all. “What we see is that often expectations haven’t been met and stakeholders deem the project a failure, what has really happened is that the expectations or course of success weren’t set or managed correctly,” he says.
We discussed that during the course of a successful software implementation, there is often a period just after go-live where performance does dip – if a company isn’t expecting this, it can cause a panic that the project has failed or the investment was a mistake, when what’s really needed is a bit of patience. They don’t know that they just haven’t seen the process through to the point where performance begins to rise and value begins to become apparent.
3: NOT SETTING SUCCESS METRICS
It is incredibly difficult to determine your level of success or failure if you don’t have KPIs in place. “We see projects fail because companies didn’t have KPIs before, and don’t set them before beginning implementation,” says Alastair. “To get an accurate view of your project’s success or failure, you have to have KPIs set and measured before, during, and after the project.”
Not having set KPIs also prevents companies from being as focused as they need to on what areas will lead them to project success. For instance, if you know that you have a really poor first-time fix rate, this gives you a critical area on which to focus for initial improvement. That success will breed further success, but without knowing what to focus on you are doing a lot of guess work which is a recipe for disaster.
4: INEFFECTIVE PROJECT LEADERSHIP
Striking the right balance of product leadership for a field service software implementation can be challenging, because the business function needs to weigh in but so does IT. The lack of a unified team, clear communication, and coordinated efforts puts strain on a project’s trajectory. “What we see is that, often, software is being implemented by someone who doesn’t understand the business. They are working to give the business what they’ve asked for, but as the business asks for those things they don’t have the technical expertise to articulate them in relation to the software’s capabilities,” says Alastair. “This lack of alignment causes major issues and does a lot of damage that takes substantial time and money to repair.”
This is an example of an area where a consulting firm can add a lot of value to a software project, because they have the knowledge and expertise to weigh all stakeholders needs and land on the best possible outcome.
5: PROJECTS MOVE TOO SLOW
Many field service organizations have adopted a more agile software deployment methodology, but not all. Alastair explains that the companies still using the waterfall approach struggle in an ecosystem where change is occurring so rapidly. “What happens in the waterfall scenario is that the project delivered meets the objectives outlined, but the business needs have already changed significantly since the objectives for the project were set,” he says. It’s worthwhile for companies to consider how they can make their software purchase and deployment process more agile to be better aligned with the market and to avoid this failure point.
