It amazes me that after 30 years in the technology industry the weakest link on my chain when it comes to project management is still managing the vendor. It makes sense that this is an area of major concern and risk for many projects and worthy of a discussion and some feedback from my readers.
Vendor Risk is tough to mitigate. You can check vendors references, you can delay payment (progress payments) to the vendor based upon performance, you can add guarantees until the cows come home but what I have found is Vendors are like contracts; they only apply to those who play by the rules.
A key example is of a project that I am currently working on with a major manufacturer of industrial equipment. We had begun a campaign to upgrade each of their many locations to the latest revision of the software for each site. We had success in implementing two other sites, one with the same software as the third site and one different. It was cookie cutter from the point of the implementation and the only issue was the data conversion and the tricky process needed to upgrade so many versions.
Like many of our clients who waited a long time to refresh they were old to say the least. Thrown in with this was the fact that the satellite site was in Canada. The Company that owns the software had sold it to a foreign company confusing the licensing agreement with the VAR’s. Suffice it to say the company and their VAR’s were a mess.
On top of this the company has begun to enforce rules of who we can and can’t do business with and many of the partners in place when the original implementations were done have long left the fold leaving the client with few (but expensive) choices. The humor of the entire farce was that the primary vendor and the software company had both priced the conversion way out of range with a normal upgrade. Basically it became the lesser of two evils. Add to this the primary vendor was resource challenged and couldn’t commit resources anyway to our project and meet our deadline and you could see the dilemma the client was facing
The short of this is it forced us to look into the marketplace for another vendor who had the skills and could help us. A vendor who had once been “official” but now due to the change in the structure and requirements to be a VAR had been grandfathered in with a “sub partner” agreement (or so we thought).
So we began a critical project with a vendor based in a state not close to ours and had the added requirement of trying to bring forth during the conversion a multi-currency setup that to this point didn’t exist. In hind sight it would have been better to do the upgrade and then add the multicurrency and perhaps this should have pointed out that the VAR had no best practices.
As we got further into the project it became clear the vendor didn’t document anything and became more and more frustrated when we asked for things. Behavior tells a lot. He was slow to respond, his phone was always “having a problem” his emails were short and usually were “I will call you tomorrow to discuss” and it never happened. His structure and accountability didn’t match ours. This was a train wreck and before we could put a contingency in place the all-time worst business move occurred – he disappeared. No calls, one email sending back at the request of the companies CIO the file he converted “so far” and that was it – gone with the wind.
Wow! how could we be so stupid? How did we not see this? Easy – we took a short cut. We were so in love finding a solution provider who was affordable we forgot the basics – references, work product examples, validation of credentials and what they represent, basic instinct?
Sometimes our emotions take hold and we make business decisions based on immediate gratification of a need (Maslow ). So while we discuss the rational ideas and processes we should follow, sometimes we don’t. We let our emotions take over and the idea of solving the problem becomes bigger. Don’t let this happen to you. Treat every member of your project team with the same scrutiny. Validate things for yourself and never be afraid to ask the tough questions. If not, when you make the mistake people will be asking the tough questions to you instead.
I have read articles that peg the failure rate of new ERP implementation projects anywhere from 40% to 60%, but I have not seen failure statistics on “upgrades” even though, as you point out, they have risks too. Not only does such failure waste resources, it creates a stigma and fear of technology and the people who come with it which subsequently inhibits efforts of competent service providers.
The reasons why they fail or disappoint usually include a key issue that you cite, under-estimating the cost and effort of an “upgrade” many versions later. To start with, the company’s own personnel, if they still work at the company, have a hard time remembering the effort originally required to implement their solution. If anyone documented that project and the business processes, it has probably fallen out of use as business needs changed and no one updated it. In addition, these changes over the years may have involved custom changes to the software, which have been totally assimilated and are now considered “standard features” rather than custom enhancements and will be sorely missed if the “upgrade” does not include them.
Companies frequently upgrade to newer versions of their ERP solution to acquire new features that have been added. These new features may require business process changes and training in order to obtain their value. Rarely, do companies realize the importance of planning and managing these project or the need to carefully review what they think they are getting out of it.
The competent VAR or consultant who orchestrates successful implementation projects is one of the most valuable and, I am afraid, under-appreciated skills in the business world.
Comments are closed.