Consider this story of a typical software implementation for business specialists (in this case, an oil and gas company information management system) – provided by software company KADME of Stavanger.
[This is based on an article by Gianluca Monachese, Director Business Development, KADME AS and Vasily Borisov, Director of Technology, KADME AS, to be published in Digital Energy Journal Aug-Sept issue and also presented at the PNEC conference in Houston earlier this year.]
Consider an organization which has decided to change their information management system because the software they have been using for the last 20 years is not supported anymore.
They produce a Request for Proposal (RFP), trying to describe what they want.
The RFP is often written by the most experienced users of the old system, who have been doing their work in the same way for many years. So the RFP may include specific requests based on how a certain user wants to work, such as “It should also be possible to merge results and compare data, and a table view, row view and chart view of the data must be provided”
In order to cope, vendors often end up increasing the price, to cope with the risk presented by a non-clear technical requirement that might add considerable amount of work to the scope.
The customer will most likely end up with a system that is regarded by the end users as “not as good as the previous one”, while the vendor will have developed a heavily customized, less supportable solution that deviates from the product they had developed on the basis of their technology and market research.
After software deployment, there is a lot more resistance.
If the new system is better than the old one, then it will also be better at showing the underlying data errors. It is usually the same people that are looking at the new system now who made those data management errors.
Users are reacting by default, blaming bugs in the new system, because they do not see exactly what they were seeing earlier.
It is up to the vendor to defend why the information is presented in the way it is, and to demonstrate that any inconsistencies are not due to the new system. So the new vendor can easily end up with no friends among the operational staff.
Often, the organization leaves the vendor at the mercy of the flow of critics from the end users. The project team on the customer side is quickly disbanded and the vendor is left to “support” end users that were probably not properly involved in the early stages of the project and that were not sufficiently informed about the rationale behind the change.
“Training courses” quickly turn into discussions on why the system does things in this way rather than another.
Leave a Reply
You must be logged in to post a comment.