As you know, we at Velocity Procurement try to share our experience and expertise using a more familiar and relatable style. The same goes for how we view the subject of “successfully deploying S2P SaaS solutions.” There are a lot of takes on how to get it right, but our take on transformation makes it much easier to put into action in real-time. Let’s start with some of the basics.
We’ve seen in many cases where the business team doesn’t really know what to expect when the implementation project begins (kick-off). Often there are team members that are learning about the project for the first time. Because of this, some unwarranted perceptions and opinions are formed. There are always some folks that start pushing back with comments such as, “why am I involved”, “why wasn’t I told about this earlier,” “I have a day job you know,” or “I am not the person you need.” From a change management perspective, these are classic symptoms of resistance.
Then there is the work. It’s pretty much the norm that a business team will have a very good idea of what the project will entail, the effort and time it will take. However, there is often a gap in this knowledge as it extends to the other key project team members. Recently, during a kick-off project, we learned that the IT Director, who knew about the effort required to support the implementation but hadn’t talked to his ERP Technical Team members to inform them. And, due to their competing projects and bandwidth, this quickly became an issue – which put the Solution Integrator (SI) on the offensive due to the untimeliness [impact to schedule].
Even when the business team has been a good communicator of the roles and effort the organization can expect during the project, we still find there isn’t a good sense for how long the project will take. SI’s tend to promote either an elongated timeline to protect against resourcing constraints and other outlying dependencies OR they establish an aggressive timeline to maintain a budget and go-live date. It’s here where the client should take a deeper look at the project plan, preferably by a 3rd party expert or PMO. We’ve seen clients drastically improve their project success rate by imparting this additional inspection of the project strategy and planning.
Way too often we see business leaders and managers have big dreams of what their new toy (aka Procurement Software) will be able to do, for the right reasons of course. If for nothing else, their name is now tied to this new solution and the ultimate success of the implementation project. It’s both exciting and nerve-racking at the same time. However, if the stakeholder expectations do not align with the project goals and intention, this can sabotage the project. The good news is this CAN be avoided.
The foundation, of course, to getting all you can out of the new solution are the use-cases. We often see a lot of emphasis on the as-is vs to-be business process study – which is a great first step to the configuration journey. But we can’t just leave it there, unfortunately it often is. We hear client’s say “hey, just put the best-in-class process in the tool and we’ll be set right?” Not likely. Having just a solution that leverages best-in-class functionality will rarely work. This is because there are too many nuances in business process from department-to-department and company-to-company.
That said, it’s really about use-cases. Ideally, you’ve developed and scrutinized the use-cases prior to selecting a solution to ensure your selection has what it takes. Otherwise, the design and evolution of the use-case library will not only avoid the “square-peg in a round-hole” conundrum, but it will go a long way to getting adoption from the usership when it’s time for UAT’s, training and go-live.
Certainly, we’ve covered a few of the more traditional pitfalls to successfully deploying S2P SaaS solutions, such as team readiness, project plan, business alignment and managing expectations. That said, let’s not forget to address some of the more critical items that sometimes, believe it or not, are overlooked.
Time and again we work with clients that tend to get a little tunnel-vision as these projects progress. Specifically, some folks need to be reminded that this new solution is going to impact hundreds, if not, thousands of employees across the company – so we need to be very mindful of what that means. We’ve heard firsthand from business managers “they’re going to just love self-service procurement, no need to worry,” “supplier catalogs are going to make everyone’s job easier,” or “the solution is so intuitive, we don’t need any in-depth training.” Of course, we now know that these are not so true, right? So, I hope you can see, without a long explanation here, that a programmatic change management effort is critical to ensuring adoption. Change is inevitable, yes, but there is an easy way or a much harder way.
As mentioned earlier, we mentioned the IT Director and his/her limited involvement and top-down communication. We know that IT plays a big part in how successful the project is and it is within, yes, you got it – technical integration. There have been so many situations where the SI is heavily dependent on the business team to perform heavy lifting in this area. In a perfect scenario, a deep-dive of the integration requirements are done prior to solution selection or at the very least part of the project planning sessions. It’s critical to ensure that the key scope attributes (mapping, integration method, identification of the integration objects, etc) and the identification of resources are carefully assessed.
To the same extent, we all know that these implementation projects typically have limits, such as number of suppliers enabled, number of catalogs built and how many contracts will be migrated. It does make sense, right? Well, we are often asked a series of questions as we get closer to go-live, for example “so how do we enable the rest of our suppliers and catalogs,” “who is going to train our suppliers after go-live,” and “it seems like a lot of work to migrate the rest of our thousands of contract documents, how do we get it done fast?” which leaves a lot to be desired. These project limitations should be considered at the beginning of the project to ensure a successful go live transition and usership adoption.
Phew. That was a mouthful.
So, as you continue on your procurement transformation with S2P Solutions, we hope that this information will help you regardless of what stage you’re in. Please reach out to us if you would like to further discuss this article. We’d love to hear about your experience.