By now, most enterprises are exploring some sort of move to an on-demand delivery model that will supplement or replace their on-premise applications. But given security and reliability concerns, many are not ready to make a wholesale commitment of their most sensitive systems to the cloud.
Instead they are replacing components of on-premise applications with SaaS, often as a hybrid deployment or in a pilot project. SaaS acts as a supplement - not an immediate substitute - for existing applications.
Pilot projects seem like they should be easier to implement than a full SaaS. However, the same missteps that can doom a full SaaS implementation, are often amplified in a SaaS pilot project. It is not uncommon for Catalyst Resources to be called in after a company has already invested significant resources into a SaaS pilot and are now struggling to “make it work.”
The fundamental problem is that the pilot project is addressed as a traditional software engineering challenge focused on developing core application features (vs the set of user experiences that define the service) and use of top-down engineering practices (vs agile, iterative development) The result is internal conflicts, missed deadlines, frustrated senior management, and a web app that is no one is going to use.
With SaaS, whether creating a full implementation, hybrid components, or pilot project, there must be a very tight coupling between product design, development, business strategy, marketing, training & support, adoption campaigns, and online operations. The pilot project needs to address the organizational changes at the same time as the software changes. The approach can be particularly challenging for companies that are engineering-driven. But with SaaS, where the product is a service and user experience is the key to adoption/retention, it is essential to look beyond piloting just the product features, and instead, pilot the full software-as-a-service life cycle.