Author: Gloria Qiao, Founder & CEO of Trusli
There is a lot of literature about the keys to a successful technology implementation project. During my career at big tech, I have personally selected, participated in, and implemented multiple systems. Some of them are company-wide and massive, such as an ERP system. Others were much smaller, specific, laser-focused systems. Also, some of them are traditional, old schools or even a bit stale software systems such as SAP or Oracle (no offense). Others are quite innovative, lightweight, cutting-edge software. However, big or small, old or new, I noticed that in most cases, regardless of the software and the functionality, HOW the system is implemented will eventually dictate whether the system is successfully adopted and loved by the team or a disaster and eventually be left aside despite the initial impetus. So how to ensure a successful selection and implementation process? Here are some points for discussion and debate.
1. Know the why first
Many companies have a mission of “adopting new technology” without considering specifically the reasons. A project without an intentional purpose will eventually turn into a joke. Before selecting a solution, the team must understand a few things: which teams are we serving with this solution? What is the as-is process? What pain points are we trying to resolve? Which stakeholders should we involve? Knowing the answers to these questions will give the project team a clear road map of WHOM to include in the project and HOW to push the project forward. Chief Innovation Officers should not “innovate” just for the sake of it. We must identify the objective and the users of the new technology first.
2. Find the right executive sponsor and have this person set the vision and goals for the team
Once we identify the problems we are solving and for who we are building the solution, we must then find the right executive sponsor. It depends on the project. For a simpler solution such as a procurement system or a CLM, the head of that specific department, such as the CPO or General Counsel, might be sufficient. For more complex, cross-functional projects such as an ERP or a PLM, we may need someone that’s much more “cross-functional,” such as a CFO or even a CEO.
Once we identify the executive sponsor, have the sponsor address the team. Innovation projects sound fancy, but in reality, it takes a lot of time and effort. And the team has a day job to do to keep the lights on. The executive sponsor must then explain the why and express the vision to the team, and ask for their devotion and support. For complex projects that take a long time, the executive sponsor may even ask functional teams to dedicate resources specifically to this project so that people don’t skip meetings and leave the project idle once they get busy with their day jobs.
3. Include and listen to the team
Once we identify the why and the WHOM, we then must listen to the team to outline and solidify their needs.
Different teams may have extremely different pain points or care about. For the same Contract Life Cycle Management system, the procurement team may care mainly about the deal negotiation process, while the legal team may only want a neat dashboard of all the existing contracts and classify them properly. They may also inform each other and discover things that they didn’t know they wanted. In the same example, the legal team may discover that they want automated redlining functionality for deal negotiation as well after discussing and listening to their procurement counterparties.
Including the key stakeholders will also prevent deploying technologies that that team won’t use. Because they have a chance to express their needs and participate in the selection process, this team will become a natural ambassador and advocate for the adoption of the new technology.
4. Document the needs properly and conduct a proper RFP
Getting input from the teams does not stop with taking notes. Once we hear their pain points and needs, the project manager must thoroughly “translate” their needs into a requirement document and prepare a Request for Price (“RFP”) or a Request for Quote (“RFQ”) document, and conduct a proper process.
The team managing the process must know the industry landscape and knows whom to ask for the quotes. This alone may be a separate project. Based on our needs, what is it that we are looking for? Is it just a CLM? Or are we looking for something more comprehensive to help us manage deal flows and/or approval processes? Who are the front runners? Should we solicit quotes from the established players only, or should we include the front runners in the industry who may be smaller startups? Are we risk-averse, or can we tolerate some risks in exchange for innovation? These are questions that the team must answer before embarking on this journey.
5. Include the right stakeholders in the selection process and make a fair yet practical choice
Great, now the RFP is out, demos are scheduled, then what?
Make sure the right stakeholders are included in the selection process.
First, we must choose a solution that solves their problems. If they are not there to see the solutions, then who is making the choices?
Second, including them in the selection ensures that once a selection is made, the project team has their support and buy-in to implement the solution. If they feel they are not heard in the selection process, it’s natural that they won’t participate passionately in the implementation process.
Experienced teams typically develop a “score card” listing the various factors and key cares of different teams and have them rank the various solutions. One key thing to note is that the project team will never satisfy everyone. Every team has a different perspective and thus, naturally, they have their preferences. However, what matters is a fair and somewhat scientific selection process. Once the scorecards are filled out, the team should get together to discuss the perceived pros and cons of each solution, debate their preferences, and ultimately come to a compromise to select a solution that satisfies most teams’ needs in a comprehensive way. We must make tradeoffs in that process. However, the process itself should be transparent and feel fair for the team.
6. Once a solution is selected and the implementation process starts, change management is key
Choosing the right system is only half of the battle. Maybe less than half. Once selected, the same team that was involved in the selection process must then dedicate time and energy to the implementation.
The executive sponsor should address the team again to explain how the selection was made and emphasize the importance of time and dedication to the implementation process. If the selection process did not involve fully dedicated members of the various teams, maybe now it’s time to ask them to do so for the implementation. No meetings should be missed, and no excuse will be accepted.
The executive sponsor and the project management team should also address the broader team and the entire company about the why and the how of this project. Why are we implementing a new ERP system? What does that mean to each of the functions? How does this impact how we work going forward? Getting ahead of the questions of the various teams at this stage becomes extremely important.
Although we all want to think that we love innovation, in reality, change is tough. We are used to doing things in certain ways. We are “stuck in our old ways”. We want to go the easy way and just get it done. We don’t want to spend time learning a new system. All of this should be addressed by a properly managed change management program with the right explanations and manuals to explain the why and the how.
7. Solidifying the requirements and deploying the right functionalities in the right way will maximize the utility of the new solution
Some teams may think at this point, they already know what we what, why another round now?
Well, because now the specific solution has been chosen, it may or may not contain all the functionalities you initially wanted or needed, or it may even bring new things that you never dreamed of.
Having a highly functional dedicated implementation team (it can be either internal or external) is key at this point. They must understand the technology chosen in-depth, so they can explain all the possible functionalities and solicit feedback about what the team and how it can be done properly. Without this, it’s as if we are buying a Ferrari but only allow the team to drive at 45 miles an hour.
8. Document the functionalities and train the team post-go-live
Another key aspect of change management is documenting all the functionalities during the build process and providing proper training to the target teams and broader user groups post-go-live.
Going back to the car example, even if we have bought and properly enabled a Ferrari, if no one knows how to drive it, then it will still sit there idle or go at 45 miles an hour.
Modern cutting-edge software should be so sleek that it’s intuitive to learn how to use it. If not, maybe you have selected the wrong system.
However, even for the most intuitive programs, the team may still need training to complete complex tasks. Having a proper way to document and deploy such training becomes key. Programs like “Walkme” goes a long way in this stage.
Many innovation projects fail outright. I once worked for a company where they spent millions on selecting and trying to deploy an ERP system, only to abandon the entire project halfway.
