We’ve all heard the stories of organizations spending thousands – sometimes hundreds of thousands – on a Software as a Service (SaaS) automation project that never reaches its “go live” date. We always cringe when we hear those stories, because we know that nearly every time, this “failure to launch” was completely preventable.
Other resources you might find helpful:
Through our experience, we’ve identified five reasons why SaaS projects fail, and I want to share with you the measures we take before, during, and after installation and initialization to make sure your project reaches “go live” as quickly, efficiently, and successfully as possible.
1. Lack of Understanding and Endorsement at the Executive Level
At some point, it’s almost inevitable that you’ll need to rely on your executive team to sign off on something besides the initial purchase. You may require their approval to make changes to your processes to streamline and automate, or you may need their input on how to tailor your dashboards, reporting, or permissions to assign to people outside of the AP department.
If your executives weren’t involved in the planning stages, they may not understand the implications of these decisions, or they may not have the information they need to support the recommendations you and your automation partner are making. And if you didn’t have their full endorsement and buy-in, this may be where the project falls apart.
Of course, this can be prevented by involving the leadership team from the beginning to the extent that they are able. But it can also be prevented with clear, concise communication about the options and recommendations being presented, making it as easy as possible for them to make decisions with confidence. Your vendor should help you prepare that communication, or even communicate directly with the decision makers whose support you require.
2. Accounts Payable Team Wasn’t Brought into the Project Early Enough
It’s natural that your AP team may not like having an automation solution forced on them without their input. We have heard of AP teams actively sabotaging a project, but my experience has been that projects stall because the AP team brings up a valid concern that had not been addressed, or that there was no change management plan to support roll-out, training, or adoption.
Even if the AP team is thrilled to have a new solution, if they don’t have any input during the planning phase, they will likely have questions and concerns about some aspect of the solution and how it is changing their processes. Keep in mind, the AP team still has a full load of daily work to accomplish regardless of the stage of the project.
At a minimum, these situations can cause delays, reduce productivity, and increase costs. This can make change management difficult and can cause delays during roll-out or worse yet, a lack of adoption.
3. IT Resources Were Not Defined or Secured
The good news is that the required IT resources for SaaS projects are fairly limited. The bad news is that if there is any integration with one or more ERP systems, then coordination with IT is crucial, and the lack of IT resources can completely derail your project. Of course, if your automation project is folding up into a larger initiative like a new ERP system, then the project will be more of IT-driven than business-driven.
To prevent project delays, confirm that you are in agreement with IT about what you need, who you need it from, and when you need it. Ask about potential constraints, resource limitations, planned upgrades to any ERP systems involved in the integration, or requirements for projects that will run parallel to the automation project. Although upgrades to your ERP may not impact your integration, that will depend on what you plan to do with business processes around it. If an upgrade is planned, work with your IT department to get a clear analysis of how it may impact the project.
Whether securing IT resources is a budgetary issue or a matter of rearranging the internal priorities that compete for IT time, it’s important that you identify with your IT team that there is an approved project and share the requirements and timeline so that IT resources be aligned.
4. Organizational Changes
Although changes in company roles or structure can certainly present some challenges, it isn’t necessary for them to halt a SaaS automation project. Our motto is that being able to deal with curve balls and still follow through on original plans is just good business management, so if you have changes in key leadership, facility locations, departmental reorganization, or even company ownership, we’ll help you roll with it.
The good news in times of major reorganization is that automation of any financial system puts a dependable structure in place that makes future organizational changes both smoother and less vulnerable to errors or fraud.
Usually changes in your organization are not something anyone can foresee when the project is designed, so there may not be a lot you can do proactively. But you can stay committed to the original vision and rework the design as needed to move the project to “go live” status despite unforeseen challenges.
5. Lack of Clear, Committed Vision
That brings me to the final, and perhaps the most universal, reason that any project fails to launch. Whether the project is simple or complex, involving one department or the entire organization, you increase your chance of success incrementally when you start with the end in mind. When everyone whose cooperation and contribution will be required is clear on the vision and is committed to the reason behind the project, that project becomes hard to derail.
At DataServ, a lot of our discussions have to do with first understanding why we make decisions. Everything from upgrades to our program, dashboard, and reporting, to our visual design is first addressed from the standpoint of “why” – before the “how” is ever considered. When we onboard a client, we take them through that same process to be sure that we’re tailoring our product to optimal functionality, rather than simply mirroring their old manual processes. We provide clients with our Rapid Adoption Kit that goes step-by-step through the variables, options, and implications of the decisions that need to be made. Even our e-book, The Buyer’s Guide to Choosing P2P Automation Technology, is designed to help you think through a lot of these variables before you decide on an automation partner.
It’s important to do the work in advance and work with a partner that’s committed to helping you. If your project is loosely defined, then a lack of support, shortage of resources, or a change in structure will probably cause the project to go haywire and result in failure to launch. But when you have a strong vision defined for the organization and the AP department, we can help create a solid scope built around the project and work with you to make necessary adjustments without losing sight of that vision.
In short, the ultimate prevention against “failure to launch” is to build an automation project plan to match your vision for how you want your company to run.