Integration Project Considerations for Saas Vendors

At Dispatch, we work with dozens of enterprise SaaS application vendors, either directly or through our enterprise engagements. Many of these companies are young and emerging challengers, and some are established titans in the new enterprise SaaS world. All the SaaS organizations we work with are fantastic, and they all are passionate about their solutions unlocking enterprise value and transforming how business is done.

Every SaaS vendor we work with invests heavily in core functionality and user experience. And every one of the clients we work with is excited by the opportunity to transform their businesses using cloud-based solutions. Our role in integration projects is to unlock the value of these applications by plugging them into an enterprise’s app ecosystem. This is essential because enterprises need each application to be an orchestrated element of workflows that span applications and functions. They expect each app to consume, transform and transmit data between systems in a reliable and timely way that unlocks overall business value for their organizations.  

Unfortunately, integration projects can be a source of frustration for SaaS vendors. Most modern applications have a robust API, and most emerging and established SaaS vendors have well trained and competent professional services teams and partner networks of systems integrators that understand their solutions and the broader SaaS ecosystem. So given that, why do so many integration projects seem to get bogged down, slow the path to go-live (and revenue), undermine the excitement of getting started with new solutions, and sometimes outright fail?

Well, the answer is complicated. But if you’re a SaaS vendor at any stage of development, there are some things to be mindful of as you go through the pre-sales and sales process with your customers that may be helpful to consider.  

Culture

Your customer’s culture and biases can have a significant impact on the success of any project, including a complex integration between two or more SaaS systems. It’s valuable to understand the customer’s culture and reflect on how it differs from your own. It’s also valuable to understand how your customer’s culture may be inconsistent between stakeholder groups – especially between business and IT stakeholders.

When it comes to SaaS integration projects, we tend to measure cultures along the continuum between innovation and optimization.  

You can get a sense that you are working with an innovation-biased culture if you hear them speak in terms like the following: 

• “We exist in a dynamic market”, or “we are the disruptor in a mature market”
• “Speed is more important than cost”
• “We believe our company changes too fast to worry about fine-tuning every process…they’re going to change anyway”
• “We’re focused on top-line growth more than maximizing profitability”
• “The cost of NOT changing is too high”
• “We accept that errors and mistakes are a side effect of speed. We won’t tolerate slowness due to caution”
• “Let’s get up and running quickly, then we can add or change functionality as needed”
• “We can change our processes to adapt to your solution”

In contrast, an optimization-biased culture may use words and phrases like the following:

• “We only want to do this once”
• “We want every use-case automated because we need to extract the maximum value from the integration”
• “We’re okay to hard-tool this because we don’t expect to change”
• “Your solution and integration must adapt to our existing processes because that is how we do things and they have already been optimized”
• “We need a firm plan on exactly how the integration will work before we start, and we expect we will not deviate from this plan”

Understanding these biases is extremely important to help you define a successful project.  A rigorous, detailed project plan that fully mitigates risk will not fly in an innovation-biased culture, because it will be too cautious and will contain too many assumptions that likely won’t hold true in a dynamic environment.  Similarly, an agile, iterative project approach will be met with resistance in an optimization-biased culture because they will be looking for project cost confidence and will be uncomfortable with ambiguity.

It’s useful to assess where your culture lands across this continuity as well…especially because your own biases will be reflected in assumptions you may make regarding how the customer would approach your integration project. If your bias is different from your customer’s, you need to be mindful that what drives their decisions and how they approach integration projects might be different from how your own company would.

It’s also useful to understand whether your customer’s culture is consistent across stakeholder groups.  Quite often, business stakeholders have a more innovation bias, but IT is more conservative. In other cases, project leadership may have an innovation mindset, but end-users are reluctant to change known workflows. Consider who is driving the overall project and how strong their leadership appears to be across different stakeholder groups. Be aware – you may get caught up in battles between internal groups with different biases about solution design and implementation. These battles can stall a project and cause substantial churn and frustration.

For Innovation Biased Customers

• Recommend a Systems Integration (SI) partner with a similar cultural bias and success with clients that have comparable cultures.
• Recommend high speed, lower scoped sprints with limited core functionality part of an initial go-live, and introduce advanced functionality / corner-cases in subsequent sprints
• Keep discovery time low and be prescriptive – customer stakeholders likely won’t have time or patience to sit in meetings to think through what they do today. Instead, they will be interested in what you recommend for new workflows and why. They expect your solution to introduce change and largely embrace it.
• Have an expectations-management session upfront about how they would like the project to be run and talk through common project risks. Gauge their willingness to accept those risks and their understanding that high-velocity projects likely won’t be perfect right out of the gate.
• Innovation biased organizations tend to set very aggressive timelines. Be honest about your experience at other customers of similar size and scope about what can be accomplished within that timeline and gauge their reaction.

For Optimization Biased Customers

• Recommend an SI partner with a similar cultural bias who are successful with clients that have comparable cultures.
• Build in a comprehensive Discovery phase in the project that covers all stakeholder groups. Give time for customers to think through their own processes and why things are done a certain way. This also gives them time to get comfortable with your application and how changes in workflow can be accommodated. 
• Include frequent demo days with the stakeholder groups to ensure solution design is aligned with expectations.
• Include extended test and validation time in the project to include all use-cases, including corner cases.
• Include sufficient training and change management time to help the organization adjust to any changes they must absorb – even if they’re positive, they may be met with resistance.
• Optimization biased organizations tend to expect the discovery and design sessions to product perfect and unchanging specifications. This rarely happens, so prepare them for the potential of new requirements emerging as they become familiar with your application and the workflows associated with it.

Experience

Enterprise SaaS integration projects can be complex. Field mapping and data transformation between apps can be challenging because of the different data models each app employs. While this can be difficult, typically, the more challenging element of these kinds of projects is workflow design and automation.  To do this well, you need to not only understand how your app works, but also how upstream and downstream apps work, the workflows that span across apps, the people and organizations that are involved in the work, and the underlying business context.

Integration projects tend to involve multiple parties which add to the complexity. When workflows span across functions, the needs of various business stakeholders must be considered. IT involvement can also include systems specialists and data and systems security teams that are each driven by different goals. Sometimes multiple systems integration partners and multiple software vendors are involved, especially if the integration of your solution is coincidental with broader implementation projects, or if the integration of your solution requires configuration changes in other applications.

Experience in managing these kinds of projects is therefore extremely important to predict success with your integration. Consider the following questions during an initial assessment:

• Has the customer recently completed an integration project of similar scope/scale?
  • If yes, does the customer believe it was successful?
    • Will the same project manager manage your project? Will the same team be involved?
    • Will the same system integrator be involved?
  • If they don’t feel the project was successful, ask why? 
    • Will the same team manage your project? Have they made changes to their project governance approach to prevent another failure?
    • Will the same system integrator manage your project?
    • Do you have confidence that lessons learned will be applied to your project?
• Does the customer have recent experience with integration projects involving the same business stakeholders? Do the business teams understand their role in design, test and implementation of the project?
• Does the project manager have experience in your domain? Do they understand the technical and non-technical elements of solutions in your domain?
• Does the customer intend to involve multiple SI’s? If so, why?
• Does the customer intend to involve different software vendors? What is their expectation of how they will work and interact with your company (if at all)?
• Is the SI known to the customer? Is there a high level of trust with the SI?
• Is the SI known to you? 
  • Have they successfully completed similar projects with similar types of customers? 
  • Do they have domain expertise in your space?
  • Do they have domain expertise in your customer’s industry?
  • Do they have experience with your application AND the upstream and downstream applications in scope with the project?
  • Do they have experience in any middleware solutions to be used in the project?
• Does the SI have experience with the business side of an integration project (not just the technical and field mapping side)?
• Does the SI have change management skills?

It’s important to note that in the discovery and design phases of integration projects, many business stakeholders will struggle to fully articulate what they do and how they expect the system to work. Frequent demos are necessary throughout the integration project to show future-state workflows and ensure design continues to meet expectations.

In the same vein, when an integration being demoed or tested doesn’t work as expected, business stakeholders can have a hard time differentiating what’s a bug or defect versus an incorrect design specification.  IT stakeholders tend to be more understanding of the difference between these two types of issues – possibly because of their experience delivering their own solutions to the business.

Application Infrastructure Lifecycle

One important consideration is understanding how your application fits into the customer’s app ecosystem. In particular, how new or established the primary applications are (SAP, Workday, SFDC etc.) has a significant bearing on how to run the project.

Brand New

If the customer intends to go live with your integrated solution as part of a broader implementation of a new primary system, consider the following:

• Implementing a core system is an extraordinarily complex job in and of itself. It can involve massive changes in workflows across the organization and fundamental paradigm shifts of how things are done. 
• These kinds of projects are costly and introduce significant risks to the organization.
• Each integration to 3rd party systems introduces additional stacking risks to the overall project.
• Workflows and data models will be in flux, so your project may be impacted by shifting requirements and unexpected issues.
• Delays in the primary project will likely impact your integration.
• You may have limited access to customer resources or SI attention as they address other issues in their project.
• If your solution is new and unfamiliar to the customer AND the primary system is new, consider this a high-risk implementation to do in parallel with the primary go-live.
• If your solution was already used (and integrated) with the prior system, there likely will be a strong desire to integrate your solution on day one with the new system. If so, consider the additional risks of adding your project into phase one versus a temporary manual workaround until the new system is stable.

Think about a “Maslow’s hierarchy of business needs” when planning how your project fits into the broader implementation. In phase one, integrations should be focused on the critical few only (e.g. payroll and benefits in a Workday implementation). These are essential because without them the business would cease to operate. If integrating your solution is not fundamental to your customer’s operation, wait until the system is live and stable before beginning your project. Yes, that may mean manual data entry and the inefficiencies of a non-integrated solution for a period of time, but this typically leads to better and more efficient outcomes than integrating with a brand new, unstable and unfamiliar system prematurely.

If the customer decides to hold your project until the core system is stable, you may still want to have a few sessions with the project team to provide guidance on how your system works and what you consider best practices for an integrated solution.  This can help ensure the primary system is configured to accommodate your integrated solution and avoid rework during your project.

Early Days

If your customer has recently implemented its core system that you will integrate with, this can be an excellent time to run your project. If the system has gone live within the past year, consider the following:

• Does the customer consider the new system stable? Was the project a success?
• Are the same team and SI available to run your implementation project? They will have a deep familiarity with the architecture and design choices they’ve made, which will be helpful. If they have also integrated with your system at other clients, that is an extra bonus.
• Are process flows well understood using the new system?
• Was the customer using your solution before their main system change? Do they already have a good understanding of how integrated workflows would be designed with the new system? Do they already use your system in a non-integrated fashion?  The more familiarity they have with your system, the less likely there will be a need to change any configurations of the primary system to accommodate your solution.

Be careful if the new core system remains unstable, if workflows are still in flux, or if there is project exhaustion among core stakeholders. Also, be careful if the project team has moved on or there will be a new SI that is unfamiliar with the design decisions and implementation challenges of the core system. Have an open dialogue with people that lived through the project about what went well, and what they feel should change for subsequent projects.  

Mature

The good news if the customer’s systems are mature and your solution is a new addition to a stable app ecosystem is that project scope and risks are limited and more in your control. In these environments, consider the following:

• Is the app ecosystem stable and dynamic?
  • The customer frequently adds or changes applications in a measured way and has a track record of successful integrations that maintains the overall stability of the system. 
  • Do they use modern middleware for data orchestration and integration between applications? If so, do you have case studies of how your app is integrated with that middleware and whether there are any particular issues or concerns to manage?
  • Do they have trusted SI partners that they work with for new system integrations? If so, they may be the ideal SI for your integration, even if they don’t have direct experience with your app, and especially if they are experts in the customer’s middleware solution.
• Is the app ecosystem stable and stagnant?
  • The customer has a stable system but changes or additions to the app ecosystem are infrequent. They don’t have recent experience with integration projects and are concerned about how your project may introduce risks and inefficiencies they aren’t equipped to manage.
  • These organizations probably don’t have a trusted SI partner because projects are too infrequent. In that case, you may consider recommending SI’s who have familiarity both with the core system, your application, and the soft elements of change management for an organization not used to change.

Other Considerations

Here are a few other considerations when planning integration projects:

• Executive sponsorship: A senior project sponsor who has a sense of urgency and ownership is very valuable to address roadblocks and enforce timely decision-making. But be aware – if the sponsor is too senior there is a risk that lack of availability insufficient operational context can make the role effective. If the sponsor is too junior, they may not be effective in driving decisions that impact stakeholders across the organization.
• Data quality: If your customer indicates that data quality has been an issue, they may want to initiate a data cleansing/data management initiative first before beginning your project. Automated workflows can quickly break down if data quality isn’t solid, which may cause the project to fail, even if technically the solution is robust.
• Development environment preparation: Ensure the customer understands their role in preparing the development and test environments.  This includes provisioning of sandboxes, development accounts with the right permissions and providing adequate and representative test data.
• Available resources during solution design: If your customer is not willing to devote sufficient resources during solution design, you may face unexpected surprises with last minute scope change requests, as stakeholders realize late in the project that the design doesn’t meet their needs.
• Available resources during testing: Customers need to actively participate and lead acceptance testing and end-to-end testing of all use-cases.  If they fail to devote these resources, issues may not be caught until the solution is in production.

Summary

Most enterprise SaaS software vendors invest substantially in their API’s, integration technologies and professional services competencies to reduce the complexity of integration projects. Unfortunately, integration projects are still a source of pain for many vendors and their customers which can delay revenue, slow adoption, and impact customer satisfaction. In an ideal world, new software would plug into app ecosystems like lego blocks and self-configure to seamlessly communicate with upstream and downstream applications. We’re making progress towards that goal, but we’re not quite there yet. Until then, the best chance of success for these kinds of projects is to consider both your customer’s technical and non-technical context, work with a variety of high-quality integrators and fine-tune your approach to match each customer’s unique needs.