In recent posts, we’ve learned that business software implementation failures are rampant and that the blame is all on the vendor. And though unhappy customers are suing the software vendors, little speculation is offered on the cause for the implementation failure.
So, these posts, and any others that follow, provide little insight on the learnings on the part of both the customer and vendor from this difficult experience.
In one of my previous posts, I discussed how all parties involved with any software implementation play a role in both its success and the failure. Therefore, they all have something to learn from an implementation failure, which can be as important as customers recuperating their financial investment or vendors clearing their name and image.
What Customers and Vendors Should Do to Learn From An Implementation Failure?
Mistakes and failures are a great opportunity for people to learn, but try to tell that to a chief financial officer (CFO) or a chief executive officer (CEO) who spent hundreds of thousands of dollars, maybe more, on a software solution that falls short of meeting the needs of the company. An immediate reaction may be to reach for the phone and seek legal counsel to recoup some of costs incurred.
A close afterthought may be to recognize that the customer may have something to do with the implementation failure—and the problem, unless addressed, will persist during the next software selection and implementation with another vendor. So while lawyers are busy collecting facts for their lawsuit, decision makers should conduct their own investigation to ensure mistakes are not repeated.
Though a perfectly natural first reaction may be for vendors to try to prove their innocence or come to a settlement, this should be followed by an analysis of the situation to show what went wrong with the implementation.
Most vendors have some type of feedback-gathering process or post-implementation audit in place, and customers need something similar as well. Unfortunately, most often than not, this process proves either incomplete or too formal to bring to light the real issues that led to the software implementation failure.
What to Look For
The biggest challenge in determining what went wrong lies in posing the right questions to the right people. Questions that are too general elicit vague responses, and questions that are too detailed run the risk of getting lost in technicalities—which can make it even more difficult for you to accomplish your goal.
Both customers and vendors should look at how the software requirements were determined and how they were covered during all major milestones of the selection and implementation—even post-implementation—process. Customers must bear some responsibility when the vendors’ understanding is not in line with the customers’, as should vendors when customers start using a system without being completely ready for it.
Importance should be placed on reviewing the escalation rules that were defined to ensure the selection and implementation proceeds only when critical conditions have been met—it is much cheaper both financially and resource wise to delay deployment than risk a failure. If you have these rules, make sure you understand what went wrong and why; if you don’t, make sure you have them for the next selection and implementation project.
What Not to Do
The focus should be on learning something from the implementation failure, on the part of both the vendors and customers—not looking for scapegoats, which can make things even worse, as people are already discouraged by the failure. You also need to make sure that this does not turn into an internal witch hunt, and that your investigation does not target those individuals who had different views or objections toward the strategy and methodology adopted for the selection and implementation. These are actually the people who are more likely to provide you with the answers you’re looking for in order to understand what went wrong with the implementation and how to prevent it from happening in the future.
I agree with your view.
But actual fact is IT Manager (Read CIOs) are generally driven by a budget, which forces them to go for big bang projects just to ensure that they continue to get that budget year on year.
Hence some time or most of the time they find a scape goat as the vendor, the the team member or business for failed projects.
It is always difficult to pin the exact cause of failure as both parties start listing down reasons blaming one another. It is better not to oversell and be honest about what can be implemented for the budget and time frame stipulated by the customer. Here is an interesting read by colleague on a related topic, http://bit.ly/lw5vkq