What is the True Value of a System Selection Project? (Part 1 of 5)

Hint: It’s not just selecting the system

If you’re looking for a new enterprise system, you may be wondering how much time and effort should be invested in the system selection process. By looking at: 1. The risks of not doing a detailed System Selection Project, 2. How system selection mitigates risks, 3. Indicators that you need to perform a system selection, 4. What it takes to do a detailed System Selection project, 5. The benefits of doing a detailed System Selection project; We will answer “What is the True Value of a System Selection Project?” 

In Part 1 below, we look at the risks of not doing a detailed System Selection project.

Mitigating System Implementation Challenges with a Detailed System Selection Project

In the realm of medium to large enterprises, the road to system implementation is often riddled with unexpected obstacles. If you’ve been down this path, you’re well aware of the challenges that can emerge. One of the most effective strategies for navigating these challenges begins not with the implementation itself but with a meticulous System Selection project.

Unfortunately, System Selection is frequently hurried, lacks depth, or is overlooked entirely. The consequences of these shortcuts typically emerge during or after implementation.

In this article, we delve into the story of “1EasyTool” to shed light on the common pitfalls encountered during implementation and how a comprehensive System Selection process could have effectively prevented them.

A Tale of System Implementation: 1EasyTool

On Friday morning, the executive team returns from their annual offsite. You meet with your boss for an update, who energetically gives you the cliff notes of the updated company roadmap. He is most excited share that the company will soon be launching an Enterprise Application called 1EasyTool to replace the current Financials, Supply Chain, and Customer Self Service tool!

He explains that during the offsite, 1EasyTool held a 30-minute demo, then the CIO presented pricing and the six-month implementation plan. The executive team unanimously agreed that 1EasyTool is the enabler they have been looking for and following the meeting, the CEO signed up for a five-year contract! Your boss goes on to share that implementation will begin in three weeks, you’ll be the decision maker for the Purchasing and Inventory department. He adds, you may want to dedicate a representative to support the project about two hours per week.

Six weeks later, the 1EasyTool implementation team holds a project kickoff. The 1EasyTool team explains their approach to be finished in November (Before Black Friday) and lets you know you’ll be hearing from them soon. You’re not exactly sure how much time they need from who, when, but everyone is excited and the 1EasyTool team seems organized enough.

You and your representative are interviewed by the 1EasyTool Team, and it seems your requirements are captured. At a follow-up meeting a requirements review is held and as a courtesy, you invite your expanded team. Members of your expanded team ask a question and then another as you realize most of the product catalog requirements and all of the custom product order requirements were completely skipped. This throws the project team into a tizzy, and with such a large scope missed, there are questions on whether the project can still meet the November deadline. Ultimately, your C-Suite holds some negotiations with the 1EasyTool implementation leads. Agreement is made to update the scope and with some extra elbow grease plus significant overtime from your team, they can get the project back on track.

With the updated scope approved, and the product catalog requirements captured, the 1EasyTool implementation team begins build. They find that the custom product catalog requirements demand both a customization and unplanned integration to the customer facing webpage. To support the build your 2 hour per week team member is called into 2 hours per day of meetings to provide clarification and help smoke test. As the decision maker, you are approving changes on the fly daily, and honestly, it’s hard to keep track of what is being built. This effort was unexpected and disruptive, but you recognize the importance.

It becomes evident that testing will need to be rescheduled and to prevent missing the November go live, the implementation team suggests using the two weeks testing contingency before testing begins.

Build finally completes and eagerly, your company moves into testing. The implementation team is ready to go with test scripts and developers are on standby ready to mitigate issues. The product catalog and custom product catalog is working as designed for the employee user and your team is pumped! You hand off your test records to the inventory and finance teams and then testing comes to a screeching halt! While the requirements for the product catalog and custom product catalog were built, the downstream requirements to differentiate inventory orders, and direct to customer orders were never reviewed. Further, the sales team tester informs you that when logged in as the customer user, the self-service portal is buggy, half missing, and so slow they fear losing customers before checkout.

Everyone is frustrated. Testing is put on hold. The implementation team takes a week to investigate the issues then asks for another three weeks before testing can be resumed. The project is under the magnifying glass, and you as the lead procurement and inventory stakeholder, are asked to support daily remediation and follow up calls. So much for 2 hours per week.

Over the next few weeks, remediated bits of code are rolled out and retested, end-to-end tests are done over the course of days rather than hours and stakeholders are fatigued. Little by little you get through it, but excitement in the company has dwindled, and the 1EasyTool has been nicknamed 1ImpossibleTool.

With testing finally over, the system launches, happy announcements are sent out, and minus the missed Black Friday launch, things seem to be successful.

A few days later, the organization finds a string of critical issues:

• Automatic re-order quantities were set incorrectly and everything in stock was re-ordered three times!
• Accounting is unable to track where inventory is issued
• Phone orders have spiked due to unforeseen use cases when customers attempt to use the custom catalog through the self-service portal
• Employees were not given friendly tools to accurately identify their new GL (General Ledger) charge codes
• The ability to conduct change orders does not exist (It is planned on the two-year software roadmap)
• There is general confusion on how to operate in the new system

The project team and much of the organization are scrambling to put out the fires, the core operational staff is working overtime, and customers are seeing the impact – the project is bright “Red”!

After several weeks of chaos, workarounds and band-aids are put in place. There is a general consensus that the project will require a phase 2 to be fully operational which will incur additional time and budget at the expense of other initiatives.

In the Lessons Learned meeting, you hear, “We didn’t…

• Fully scope what we needed before selecting a system”
• Know there were problems until we started to test”
• Know there were unsolved use cases until we went live”
• Bring in the right stakeholders early enough”
• Understand what the vendor meant when they said “Of course our system does that”

Comments are made “Who picked this system?”, “Would have been nice if they had asked for our input”. Not only does your organization need to stabilize the technology, but they also now have to change the organization’s “1ImpossibleTool” perception. Your team is exhausted and there is a mountain of work ahead. If only you could start over!

As it relates to the Tale of 1EasyTool, a detailed System Selection project would have mitigated so many pain points:

For many the tale of 1EasyTool is déjà vu and something you will work hard to avoid repeating. When you personally experienced a difficult system implementation, was a detailed System Selection project done?

A detailed System Selection mitigates the root cause of so many system implementation challenges. The chart below shows how a System Selection could have mitigated the System Implementation Challenges seen in the Tale of 1EasyTool. A path to living happily ever in advance of the Black Friday Sale may have existed if System Implementation had been done.