Very often, the focus of the system purchaser (the organization that buys the system) and the implementer diverge in the acquisition and implementation phases of the system, which is thought to be one of the main reasons why the implementation of a system does not go as well as we would like. The lack of initiative and focus on the part of the customer means that it is not the customer who decides what (the scope of the system), when (the time) and for how much (the budget and the payment terms) should be implemented, but the implementer.
So, the customer acts right from the start when they realize a need. They seek approval from managers and stakeholders to initiate the project, ensuring the need is acknowledged and the decision to make the change is carried out. Later, however, during scoping, their focus decreases as the implementer actively takes the helm. The implementer sees a sales opportunity, takes an interest in the customer and offers to help shape the scope as well as define what the system will need to do and how the project will be implemented. Often, they will offer the solutions they have and know how to implement, but this does not necessarily correspond to what the customer really needs. It's like building a house, if a contractor came in and said: "I know what you need, I'll do everything, you don't have to worry about anything, you'll just come at the end to pick up the keys and pay". The result is not always a satisfying one...
Thus, after the scope has been set, implementers who were actively involved in sales activities and knew about the planned change are chosen. However, they might not be the only options or the best ones available. Often, customers do not consider other service providers or similar solutions.
I know what you need, I'll do everything, you don't have to worry about anything, you'll just come at the end to pick up the keys and pay
The customer becomes more focused when dealing with the contract because it involves money and commitments. However, the implementer still puts more effort during this stage. The project schedule, detailed scope, penalties, and damages usually remain outside the terms of the contract.
During the development and implementation of the system, the focus of both drops. The customer sees someone from the implementation team walking into the organization, asking questions, sending documents for approval. The documents aren't always easy to understand, and sometimes the customer is hesitant to ask for clarification when things are unclear, like diagram labels being confusing or the text being too technical After a while, the implementer brings the finished system and says that it is ready to use, the system is ready.
Then the customer starts paying attention because they need to learn how to use a new system. This is when conflicts arise: the system might not be convenient or align with their preferences, leading to discussions about changing processes. Sometimes the system is not being used the way it is meant to, and there's resistance to altering processes for the system. Changes begin to emerge. During this time, the implementer’s attention increases as well, naturally, due to unexpected new requests that were not part of the original plan. This can lead to going over the budget and delays in system implementation. There's often a wait for changes to be made to align the system with the initial project goals.
If the customer increased the focus on the areas where the implementer is very active, so that it is not the implementer who decides on the scope, the best solution/product and the terms of the contract, we could strengthen our position and implement a solution that is exactly what is needed.
We will delve deeper into this subject in our upcoming insight, where we will discuss key considerations before purchasing a system and outline the essential questions to pose to the customer.
