by Hessel Friedlander Before you sign a software development contract, make sure that everyone in your organization who needs to be on board is on board. If that sounds so obvious it doesn’t need to be mentioned, consider what happened on a recent project in South Africa.

A manufacturing company hired a service provider to do a major upgrade of order-entry software that the client had been using successfully for more than five years. The provider followed standard project management methodology, and everyone played ball. The client signed off on specifications and attended weekly progress meetings as well as workshops held to show system prototypes. There were disagreements about certain aspects of the specifications, but the provider resolved them to the client’s satisfaction.

In short, both sides seemed to be cooperating to everyone’s satisfaction. Until about two months before implementation was scheduled. That’s when the client refused to test the new system, claiming that the upgrade did not suit its business needs. This despite the fact that the client had been kept informed at every stage of the project and the project team delivered exactly what both sides had agreed on.

The client acknowledged that the service provider had done everything right. So what went wrong? In short, the client rushed into the upgrade without looking at the alternatives and without getting agreement from key stakeholders.

When a computer system goes out of date, a company has to decide whether to upgrade or buy a new package. A different system means a new supplier, new functionality, and training for all users. In addition, all the information has to be taken off the old system and put onto the new one, raising the risk that some of that information will be lost. 

It’s generally easier to upgrade, which has none of the challenges of the new and unknown. The easiest choice isn’t always the best one, of course. That’s why the people who will be most affected by the buy-or-upgrade decision need to be consulted on what would be best.

The key stakeholders in this case — the client project manager and the user technology consultant — were not singled out to make sure they agreed on the benefits of the upgrade. This meant that they accepted the project’s goals in principle but decided to wait to see what it delivered before they would give their approval.

It was the user technology consultant who approved every specification, and he never told the service provider that he was dissatisfied. He did have reservations, however. He began sharing his criticisms with the client project manager, which spread doubts about the business value of the upgrade on the client side. Although relations with the service provider remained cordial to the end, the client finally rejected the upgrade and decided to buy a new system.

The key lesson here is to explore all the alternatives before committing to a project. And the best way to do that is to bring the key stakeholders into the decision-making. The client’s failure to do that in this case meant that they bought the new system they wanted but also paid for an upgrade they didn’t want.

Hessel Friedlander is a project manager at CSC in Johannesburg, South Africa.