What to Know Before You Sign a SaaS Contract
The following article comes from our very own veteran Program Delivery practice leader, Kim Wineland.
Gartner analysts expect cloud-based application services – a.k.a. SaaS – to grow by nearly 17% in 2023, so there are lots of deployments ahead. If your organization is planning one of them, here is something you must know before you sign a contract:
Chances are, your expectations related to delivery methodologies will differ from how SaaS projects are delivered.
That means you might want to hammer out several aspects of your project before moving forward with a SaaS vendor. Among the things to review are definitions of terms, implementation methodologies, RACI assignments and how you’ll adjust the deployment as you learn and progress.
Typically, software-as-a-service solutions are configurable, not developed. By SaaS solutions, we’re looking at those created only for SaaS delivery. ERP providers and others also have SaaS options, but they’re more likely to follow – or at least incorporate – traditional waterfall delivery methodologies.
We’ve all seen those waterfall steps. Traditional IT project delivery starts with requirements gathering, which means looking at the processes end users follow and the data and functionality they require to do their jobs. Then comes the design phase, in which the logical design activities map user requirements to system capabilities and physical design covers the technology needed. Next, there’s the implementation or build phase of the project, the time at which code is written, followed by verification or testing and, ultimately, maintenance.
If this is how you’re accustomed to delivering an IT project, you’ll likely want to take a close look at the statements of work SaaS providers will give you. Those documents will tell you what the product does and how the vendor provides it to customers.
Generally, SaaS vendors will expect you, the customer, to select from pre-determined configuration options. After you make those configuration choices, the vendor can customize and hand off a product. It sounds very efficient, and it is. However, it isn’t in line with the delivery methods most IT professionals with a few years under their belts are accustomed to following.
The write stuff
Expectations / Requirements
With templatized implementation approaches, there generally is a lack of documentation for things like requirements and process flows, too. Lack of documentation means that it’s hard for buyers and their end users to see how the applications fit their daily activities. There’s nothing that says, “these are the requirements, these are the processes, and here is how those processes will work end-to-end going forward.” Additionally, SaaS companies usually don’t document best practices so that customers can see a viable starting point from which their systems will be configured.
In addition, the vendor isn’t asking the software customer, “What is the outcome you’re trying to achieve?” Because of this, software customers don’t always know why they’re selecting a configuration choice because they don’t understand the ramifications of those choices. It can lead to rework at the eleventh hour.
Documentation is important for training purposes, too. Often, the software provider supplies base training documentation that gives a high-level foundation of how the system works. The company buying the software has to take that base training documentation and make sure it reflects configuration choices and has all the detail necessary for people to do their jobs.
Here’s an example: Supposed you’re a retailer implementing software for workforce time and attendance, and you add a process to the clock-in procedure for anyone more than 10 minutes late. That type of specialty documentation and training wouldn’t be in the documentation supplied by the vendor, and it would be something the customer would need to develop.
Knowing the SaaS solution buyer will be responsible for final documentation is something that should be mapped out in a RACI matrix before the project gets a green light.
RACI is an acronym that stands for the words “responsible, accountable, consulted and informed.” The person who is responsible is the one who does the work. The accountable person is the one who owns the task, the one who has to review and approve that task on its completion. The consulted people are those who gave input, such as stakeholders, and informed participants in the project are simply people who need to be kept up to date with the project’s progress.
Filling out the RACI matrix for each element of the SaaS solution implementation can help you identify where there are gaps between what you expect and what the software vendor provides.
You will need this understanding to ensure proper resource allocation. A lot of companies are going into SaaS projects lean on their project teams because they have been told by their vendor partners that the software is configurable, so implementation is easy. Generally, the implementation is more complex than what these SaaS companies are presenting. You will still have design work, testing, deployment planning and, as noted, you may have documentation to produce. In addition, you may need to coordinate with other departments or hire help for change management communications.
While you’re exploring the details of the deployment, don’t forget to verify that everyone has the same understanding of terms. I once worked with a SaaS firm that had a completely different notion of what was covered in the “design” phase of a project than the company I was supporting as a consultant. We were using traditional project management terms, and they weren’t, so design activities went on well beyond our expectations of when we anticipated them would be done. It made for some uncomfortable progress reports to higher ups.
Talking through expectations, delivery methodologies and deliverables – such as documentation – will eliminate awkward conversations with your vendors, end users and organizational leadership. It might get you some additional service, too. Some SaaS companies will deliver that documentation if it’s negotiated up front.
So, dig deep, question everything, and know what you’re getting before you sign a contract. If you do, you’ll experience a project delivery with much more clarity and alignment on scope and deliverables. You’ll have a more realistic timeline. You’ll understand your resource allocation needs. Best of all, you’ll reap cost and time savings. This is due diligence worth doing.