When Buying New Software, Make Sure You're Getting What You Really Need
A prospective client recently requested a project review. They had procured a significant software package, and three vendors were engaged to help with implementation. Six months in, the client was noticing a difference between what was expected and what they were getting.
My first step in a project review is to start with the project definition. None existed.
I reviewed the contracts they had established with their vendors, and the problem quickly became apparent: There was a significant disconnect between what the client wanted and what the vendors had proposed.
The client organization is full of smart and well-intentioned people, but they aren’t experts in procurement, software systems, or systems integration. The software vendor engaged in flagrant marketing, selling a basket of software components that seemed necessary and offering the services of their “certified” integrators to help with differing aspects of the implementation.
If this were an agile project, it might run amok in terms of cost and schedule but eventually provide a serviceable product, once they figured out what they wanted. Instead, this was a fixed-price, fixed-schedule project that had a weak definition of scope.
Vendor proposals and contracts offered up statements of work that vaguely described services for working with end-users and helping configure the purchased software:
- Organizational change management? Ignored.
- Data conversion? The vendor is responsible for a one-time import from a client-created pristine flat file (although client data is currently scattered across a dozen or more systems).
- End-user training? Vendors will provide materials and a “train the trainer” session.
- Changes to existing business processes? Vendors are installing software and don’t think it is part of their job.
- Coordinating the tasks needed of the client and the vendors? Silence.
From what I understand, everyone was excited by the demonstrations the vendors gave – making this look like it was software procurement rather than solution procurement.
Let’s get back to basics. The first step in any significant software procurement is to assure there is a clear definition of the business problem being solved.
If there is not a clear definition of the business problem, you aren’t ready to procure a solution, and you will putty in the hands of salespeople who have focus-group tested PowerPoint presentations built by marketing professionals and dazzling demonstrations of how their systems work—after they are configured and integrated into a user’s business.
The business impacts of implementing a system to solve a business problem are easy for people trying to sell you software and installation services to downplay or ignore. Your only defense is to have a clear definition of the problem you are trying to solve going into your solution search. Ideally, your organization has a project manager who can coordinate the effort and assure that your needs are identified and met. If not, frame your contract to have your systems integrators provide that service, or retain an independent project manager to represent your interests.
If you don’t know what you want, you aren’t prepared to negotiate for it. And you will likely be disappointed when delivery begins.
