Recently there has been a lot of discussion about the low success rate of government software projects. While the statistics say that over 75% of the projects either fail outright or don’t meet promised objectives, We think the real rate of success is actually much lower.
Despite all of the money spent on consultants and “methodologies”, the systems are simply not meeting customer expectations. While one could certainly point to the practices of big software companies who are more concerned about profit than customer success, we think the real problem is with the procurement process that emphasizes conformance to outdated specifications over the ability to perform on a given project. We once delivered a presentation about the future of software to a large group of county IT officials. After the presentation the group went on a “rant” about their current vendor. After the fourth complaint about this vendor we asked “If you continue to use the same RFP that requires 20 installations in your state, do you expect a different result?”
The fact is that delegating responsibility for RFP’s to consultants has only resulted in the same consultants using the same RFP processes to select the same vendors. The most successful vendors are not those with the best products or those with the best results, the most successful vendors are those who have built their business model around compliance with RFP requirements. This is why the same small group of companies continue to be selected and why they deliver the same poor results.
Many vendors with great solutions have tried to break through the “glass ceiling” of the RFP process with new software with little success. Even with a proven track record, any new product is at a tremendous disadvantage. It absolutely amazes us that customers will spend millions (up front) for a system with absolutely no guarantee of results…simply because a lot of other organizations have selected that system. So what can be done? We have developed some suggestions for an RFP that would encourage competition and place the emphasis on the issues that are more likely to determine success.
Here are are our suggestions for a better RFP:
1. Eliminate the functional specifications.
The attempt to reduce a complex software application to a 150 page list of functions is highly ineffective. While some vendors diligently analyze each feature, others simply find some way to interpret each question in the affirmative. A feature that seems critical in one system design, may be totally unnecessary in a more modern system. The scoring and weighting of these specifications is totally subjective and the scoring has absolutely nothing to do with the ability of a given system to produce results. Allow each vendor to provide the detailed specifications that show the advantages of their system.
2. Don’t ask for a fixed price for services.
The fact is that the services required to implement a given software solution are more a function of the culture of the client than the complexity of the software. I’ve seen clients who can implement a payroll system…on their own in 6 weeks and others who are still not ready after 6 years. Some vendors will make a legitimate effort to identify all costs while others will simply “lowball” and skillfully up-sell services once the contract is signed. Requiring a fixed price on services is not realistic.
The best way to understand implementation costs for a given system is to obtain the actual costs from the references provided by that vendor. Find out what successful customers have actually spent and if that amount was within the project budget and ask for rates only.
3. Ask for diverse references.
No two organizations are alike. Ask for references that demonstrate the ability of the system to adapt to different requirements. Don’t be too narrow in what you are willing to accept. Be open to new ideas.
We have prepared a sample RFP that we think would increase competition and improve results. We would strongly recommend that you conduct meetings with prospective vendors before your RFP process.
The decline in software project success seems to parallel the formality and objectivity of the procurement process. More openness can only improve the results.