Software-as-a-Service application deployments place different demands on the project team than on-premise ERP system implementations

On-premise ERP systems are typically implemented using a waterfall approach. Significant effort is placed on agreeing business requirements up-front before completing system design, build, test and deployment. Like a waterfall, the flow is one way; late changes to business requirements can be prohibitively expensive to accommodate. It also means the business has to sign-up to some system functionality before experiencing it. Although a good project team can mitigate the inherent risk, some stakeholders only see the system at user acceptance testing.

SaaS applications lend themselves to a more iterative approach. There are no database or application servers to stand-up as the vendor provides the infrastructure. With little or no lead-time SaaS vendors can make a pre-configured version of the system available to demonstrate its capabilities. Many also provide “best practice” default configuration. This allows the project team to put the business in front of a prototype early on the project. There is no customisation – as an ERP practitioner would understand it – in SaaS deployments. Instead, changes are quickly deployed via configuration enabling iterative improvement of the prototype with the business.

All this demands a different approach from the project team and wider business. The project team needs to deal with evolving requirements as the business understands the art of the possible. Sometimes the project team have to help the business adapt their way of working to the technology (instead of adapting the technology). To some ERP purists this is sacrilege, but the “throw money at it and customise” option is simply not available with SaaS! Given the iterative approach, the business needs to be available throughout the project.

SaaS deployments, like ERP implementations, often take place in the context of a wider programme that involves organisational change, business process improvement, etc. Programme managers should remember the SaaS vendor, or their deployment partner, will have the expertise to deploy the application, but may not have the inclination or competence to help with the wider change. The “client-side” team composition should account for this.

Aligning the speed of the technology stream to other streams can be more difficult with higher-tempo SaaS application deployments. Understanding the maturity of client processes, including how well these are consolidated across a complex organization, can help the programme manager agree realistic plans with the business sponsors and deployment partner.