Objective
Our client, a multi-discipline infrastructure services partner, had recently been through a Field Service Mobility Selection process. They wanted to develop a bespoke Field Service Mobility solution. This was their third attempt at implementing this type of software. The last two attempts had failed, based on their lack of functional and technical design requirements.
The first attempt resulted in use of the pre-built FSM from their ERP, which didn’t meet their business process needs. Their second attempt was to attempt to use an external service package and mobile solution – this also did not meet business needs. With this third try, they selected an IT vendor who was known to them. This vendor agreed to outsource development for fixed price and build them the Field Service Mobility Solution of their dreams.
We were engaged solely to build the integration between the new FSM and their ERP. However, not surprisingly, the project hit considerable road blocks from Day 1.
Original Solution Delivery
- By the time we were engaged, the client and the vendor had signed off on the pricing for the build and implementation of the bespoke software.
- The project started as usual, with the client requesting us to give them a ball-park estimate for the integration. We responded as usual, by requesting a copy of the APIs available for the new software. We also asked for the design document detailing the interactions between the ERP and the mobile device. None of these existed. All that was available was a document of screen mock-ups and a functional wish list. But somehow, they had been given a price for the build!
- The screen mockups had been put together by one of the business BAs, using their current Field Service Mobility product as a basis. No one had looked at where the data was coming from in the ERP and when it was needed. They assumed that the integration would “work exactly the same way as the current mobility solution”. They thought it could be “copied”. Their current mobility solution was an add-on product from their ERP provider. We advised them that using the existing built-in integration would not be possible and that it couldn’t be copied.
Road Blocks Start
- We could see the big red flag for this project from the beginning – the client design essentially was to replace the current product, with a newer version written by a different vendor. At the same time, they were getting a new “front end” developed, without a technical specification. They didn’t understand “the moving parts” of the current solution and assumed that screen mock-ups would be enough to work it out! We couldn’t see how this project was going to move forward. There were too many assumptions, too many dreams, and no detail.
- So, we advised the business that they didn’t have enough detailed information for the integration design and therefore, price. We suggested that they produce a more detailed design document, for both the front-end product and the data integration.
- This is when things got interesting! The business BA was very resistant to doing this. He spent several months fighting against the requirements and then ultimately was moved out of the team. This was also when the first business Project Manager (of three) realised that this was a project which would never be delivered, and resigned.
Vendor Push-Back
- We got a new business PM and asked for the Vendor technical specification for the being-built Mobility software and their required API endpoints. We knew this would at least let us determine how many connection points there were, which directions were needed, as well as the data that would be required. The PM no 2 was more technical than PM no 1, so understood the importance of this. Unfortunately, these documents did not exist. The vendor “wanted us to tell them what was needed.”
- The build vendor provided us with an Excel workbook. They had taken a guess at the ERP data required for… something… This Excel workbook had no relationship to the client screen mock-ups or their functional wish list. It was, however, the only document the vendor would provide.
- We highlighted assumptions they’d made and the data that was missing and the client submitted it back to the vendor. We heard nothing in reply. This was a year after the project had commenced.
- Despite all of this, we were still regularly pushed to provide an integration price. This was impossible to do until we knew what they needed us to build (which we had told our client many times). We’ve had enough experience with Field Service Mobility to know that there are many pitfalls when the design isn’t clear. And we’d seen how complex and detailed their Functional Wishlist was.
The Project Stalled
- We were still included in the ongoing internal project meetings. We continually raised the lack of build and integration design documents as a critical issue. We were repeatedly told that our customer was waiting on the vendor to provide the design.
- After several months of no progress, we suggested to our client that we could help one of their BAs put the design together. Their response was that “they were all too busy” to do this work internally. Around this time, PM number 2 also resigned.
- PM no 3 started. We offered again to help our client to get the right information together. PM no 3 agreed. But the Senior Management response this time was “we don’t want to spend the extra money”. This occurred about eighteen months into a project that been nothing other than meetings, revolving door BAs and PMs, and raising design questions. They told us they would resolve the design issues with the build vendor and then we’d hear back from them.
The Project Died
- It took another few months, but then their build vendor decided they would let us see their new technical documents. However, to do this, we would first need to sign an iron-clad NDA. We signed the NDA and finally got access to the documents. Only to find that they had sent no design or technical documents, just code documentation. They’d been building the product off spec.
- We raised this with our client. We couldn’t do anything with the information provided. We could piece together the endpoints and data needed, but it would take a lot of time.
- The next time we heard from the business, it was several months later. After over two years of burning money and making no progress, they’d decided to halt the project, review/re-develop their requirements, then go to market again.
Outcomes… no achievements here!
- Our client failed with three different Field Service Mobility implementations. They had high-level design ideas but weren’t clear on detail. They didn’t learn from the first two failures and repeated the same issues with the third.
- This project confirmed a lot of things for us, rather than providing new lessons-learned. It was a great example of how sometimes you can say and do all the right things, but you still can’t stop the car crash of the catastrophically bad decisions being made.
- It was a really great example of how sometimes what we want technology to do for us, is either not as simple as we assume or will be a lot more expensive than we thought.
- If a vendor gives you a really cheap price for something quite complex, it’s not a bargain but rather a lesson in overruns waiting to happen.
- When you’re upgrading existing technology in the business, you still need to understand the design and the details of what you need. It isn’t enough to assume that someone can build something the same way someone else previously did. Does it still work? Has your business process changed? Do users have issues with the current process? Does your data support what you’re trying to achieve?
- As at our last update around five years post project start, the client still hadn’t proceeded further with this project and had not decided if they were going to look for an alternative product.
If you’d like to learn more about this project or talk to us, click here for our contact details.