Buying "big" software, a massive ERP package, salesforce automation or CRM package, or a business warehouse can be a harrowing process. Your offices are besieged by software and implementation providers, business stakeholders offer conflicting requirements, and you are rarely sure if the budgeted time, money, or both are adequate. Further complicating matters is the fact that you will likely have to live with the software for years, potentially struggling through a multiyear implementation process and then enhancing and maintaining a technology that may be with you for decades. With the long road ahead in mind, these four tips can help ease the process:
1. Buy based on the business case
Big software vendors are experts at flashy pitch sessions, where neat features are spotlighted and amazing efficiencies are promised. While these are all well and good, most big software implementations fail due to scope enlargement generally due to adopting the software to meet a business requirement, rather than a feature not working as expected. Evaluate your software decision in light of the business case that triggers its purchase, and demand the vendor demonstrate how their software will support your key business processes. Even the most compelling feature will be worthless if tens of thousands must be spent to adopt the software to your business.
Along the same vein, avoid shelving the business case once a selection has been made. Map requirements to processes in the software and note where you expect customization or where a business process will be changed to better fit the software. The business case should be a living representation of the objectives of the project, not fodder for a dusty shelf in the CIO's office.
2. Factor in all the costs
Perhaps the most pressing pain of big software is its costs, felt all the more acutely when the budget is overrun multiple times and the CIO is sent hat in hand to beg for more funding. The best way to get a handle on costs is investigating past large implementations at your company. Look at the amount of customization that was required versus what was expected, and use that to extrapolate implementation costs. Failing that, multiply your expected implementation costs by two, especially if they seem incredibly low or rely on some newfangled methodology the vendor is pitching that they claim will make implementation nearly painless. Usually these "best-practices" methodologies are not all they are cracked up to be, and the promised benefits evaporate almost as quickly as the vendor sales staff once the contract is signed.
3. Get "real" references
It is certainly expected that you will ask vendors for references, and most will provide you with glossy "case studies" riddled with compelling quotes, with a "CIO just like you" detailing how the package went in "on time and under budget, and brought about world peace in our time." These should be regarded as marketing copy rather than references, and you should insist on talking with current and past customers of the provider. Past customers that the vendor provides were likely successful implementations, but currently implementing customers represent more valuable feedback, since the jury is still out.
Don't shy away from trolling the Web for "horror stories" about that particular package and then calling the CIO of the company. Assuming you are in noncompeting companies, most would be more than happy to talk with you and detail their experiences with the software and provide some caveats. Even across industries, sales, logistics, and back-office functions are remarkably similar, and with a sample of three to five CIOs you can quickly discern if there is one area of the software that presents a frequent problem.
Do the same for implementation partners, support, and ancillary companies, since good software can frequently run into a rocky road with a bad implementation partner.
4. Stack the team in your favor
Implementation "partners" invariably present an interesting paradox. The longer your implementation drags on, the higher their revenue. Allowing them free reign over critical scoping and project decisions is like asking an employee to write their own paychecks. Ensure your team retains control of scoping decisions, and don't shy away from bringing in an impartial advocate to evaluate the project team's structure, checks, and balances before the implementation even starts. With the big burn rates tied to big software, optimizing the project and avoiding months or even a few weeks of delays can add up to serious cash.
While this is just a sample of the many facets of implementing a massive enterprise software package, I hope it will serve as a high-level guideline as you embark on the long journey of "big software." These types of implementations have made or broken many a CIO (or in some cases, an entire company), so proceed with careful consideration, keep the business case in mind at all times, don't fear bringing in impartial advocates, and stack the deck in your favor.
Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent over a decade providing strategy consulting services to Fortune 500 and 1000 companies. Patrick can be reached at firstname.lastname@example.org, and you can follow his blog at www.itbswatch.com. All opinions are his and may not represent those of his employer.