Commentary
The project seemed the same as many others. It was a software development project and the purpose was to do a major upgrade of software for a Client that had been using it successfully for over five years.
The standard project management methodology was followed and everyone played along. Things went well until about two months before implementation when the Client refused to test the system. The claim was that the software was not what they had been expecting and that there was no point in moving to the upgraded software. This was a big surprise to everyone as the Client had been extremely cooperative from the start. Specifications had been signed off, weekly progress meetings attended, and workshops had been held to show system prototypes. There had been disagreements about certain aspects in the specifications and these had been resolved apparently to the Client's satisfaction.
The only indication that there was a problem came about when the Client was asked to test the system, as per the project plan. The Client refused and started to make excuses. Word came about in a very indirect way that the Client was not happy with what was being done. The Client's User Technical Consultant apparently went about telling people that there was not much difference between the old system and the upgraded one. The issue was escalated to senior management on both sides and eventually this led to the cancellation of the project.
The "lessons learned" showed that the Client was satisfied with the project but not with the product. Two of the key decision makers felt that the upgrade was unnecessary. An effort should have been made to ensure that they accepted fully what the project was setting out to produce. The Service Provider's Client account manager/post-sales person should have made regular contact with them once senior Client management had authorized the project and signed off the scope documentation. They could have then shared their doubts, which could then have been referred to the project team to be managed.
Regular quality audits should be conducted to make sure that everything is on track. These audits should be carefully worded so that the Client expresses exactly what the issues are. In this project an audit was conducted but the Client gave no indication that there was anything wrong with the product.
Most important, of course, is to acknowledge that there is a risk that the Client may not see a benefit in the resulting product. Unfortunately, this was not considered and it was therefore difficult to deal with the problem when it suddenly arose.
There is also a joint responsibility between the buyer and the seller to make sure that the sale is successful. The Client should do some research in the market rather than accepting, at face value, what a sales person has on offer. If the Client does not do its homework, then "buyer's remorse" can become an issue at some stage. Clearly, this should be included in the list of project risks so that the project team has a mitigation plan to deal with it.
|
Part
3: Suggestions to Avoid Similar Situations
