Looking For New Enterprise-Level Software like a new ERP or LMS?
Be Sure To Apply Risk-Based Thinking!
Purchasing new tools, equipment, technology, ERP or LMS for your company is always challenging. The process is fraught with risks, including:
- Will it meet my production demands today and into the future?
- How much do I have to change the work environment to accommodate its installation?
- How can I train my people to use it effectively and safely?
At least when you are buying something tangible, you can develop risk mitigation strategies that reduce your financial exposure while you verify and validate your purchase. Such strategies include progress payments, whereby you can hold back payment unless the vendor can demonstrate achievement of specific performance milestones, or visiting the vendor’s site to see it in operation before they ship it to you.
But what if you’re buying software,
like a new ERP or a Learning Management System?
“Verify” and “Validate” are two words that do not mean the same thing! Just ask anyone in our federal civil service involved in the Phoenix project.
To verify is to confirm performance relative to specification, while validation involves confirmation of fitness in use, i.e. confirming if it works as intended. The Phoenix payroll system had a budget of about $309 million, and the prime contractor, IBM, maintains they delivered the project under budget according to the specification. But it didn’t work! The federal government has now paid IBM over $400 million more to make it work, and they think it will still take years before they will be satisfied.
Software purchases typically have at least two components. Licensing and hardware are purchased up front, while configuration and customization are paid for monthly as the implementation is carried out. The problem is that software is not tangible until it’s ready for user-acceptance testing, which happens after most of the budget has been spent. Software purchases are risky, and the bigger the system, the greater the risk. We need to be on our toes when developing risk mitigation strategies for software purposes.
Risk Management For Software Projects
Richard Fairley proposes that “very few guidelines are available that offer a practical, step-by-step approach to managing risk.” Fairley offers the following seven-step risk management process that can be incorporated into software projects:
- Identify risk factors
- Assess risk probabilities and effects on the project
- Develop strategies to mitigate identified risks
- Monitor risk factors
- Invoke a contingency plan
- Manage the crisis
- Recover from a crisis
Source: “RISK MANAGEMENT FOR SOFTWARE PROJECTS“
18 Enterprise Software Selection Risks And How To Avoid Them
In his 2015 article, Chris Doig, examines common risks associated with software selection:
- Unknown requirements
- Inadequate requirements
- Lack of user buy-in
- Software scope
- Analysis paralysis
- Accelerated time scale
- Political interference
- Selecting the wrong software
- Selecting end of life software
- Selecting bleeding edge technology
- Selecting the wrong vendor
- Non-compliance risks
- Underestimating implementation times & costs
- Underestimating system importance
- Business disruption
- Risks to your job
See the full article for his suggestions to alleviate those risks: “18 enterprise software selection risks and how to avoid them”
How do we limit our financial exposure when making major purchases for software?
First and foremost, don’t commit financially until you are absolutely sure you want to enter into a contract with the vendor for their solution. We need to learn everything we can about both the software and the vendor before we make any financial commitments. Here are a couple of terms to build into your next IT tender:
A. Ask for engagement summaries
Request that the vendor to provide summaries of at least two implementations with customers whose industries and applications are closely aligned with yours. Ask that the summaries include:
~ why the vendor thinks this particular implementation resembles yours,
~ what steps were involved in completing the implementation
~ the project management methodology they used
~ at least two major challenges and how they overcame them
These engagement summaries, which should be at least 250 words in length, will help you confirm whether the vendor understands your business, how the vendor is likely to carry out your project, what kinds of challenges they have had to overcome and learn from, and, perhaps most important, how transparent they are willing to be about telling you how things really went on that other job.
B. Ask for references
For each of those engagement summaries, ask for the customer name, address, and contact information, and follow up by actually visiting the customer! Let’s face it. You might be spending upwards of $1 million on the implementation. Be prepared to spend $10 thousand, or 1% of your budget sending your project team to visit and interview some actual users who worked with the vendor and who are using the product.
For example, if you are buying an ERP, ask to see evidence of how:
~ the sales process works, from placing the sales order to invoicing the customer
~ the purchasing process works, from preparing a requisition and purchase order to paying the vendor
~ the manufacturing process converts raw materials into finished goods
~ to do receiving, shipping, returns, and inventory reconciliation
~ to do month-end reporting
~ the vendor handled issue resolution and scope creep
~ closely the customer’s recounting of their experience with the vendor matches the vendor’s engagement summary
Remember the difference between verification and validation. Check both. And be prepared to discard the vendor’s proposal if you are not absolutely convinced that you and the vendor are aligned regarding your specific requirements.
Complete Our Checklist To See How Solid Your Risk Mitigation Strategy Is
rate your current strategies from 1 – 5 (1 being the least prepared and 5 being the most prepared)
Reviewed Relevant Engagement Summaries
Completed Vendor Reference Checks
Identified Risk Factors
Assessed Risk Probabilities and Effects on the Project
Have Strategies in Place to Mitigate Identified Risks
Have Strategies in Place to Monitor Risk Factors
Have Contingency Plans in Place
Ability to Manage Crisis
Ability to Recover From a Crisis
Score between: 36 and 45
You are ready to take the risk.
Score between: 25 and 35
You still have a bit of work to do to ensure your are Risk Ready.
Score between: 0 and 24
Back to the drawing board – you have a lot of work to do to before you are Risk Ready.