Three Tips for Successful Cloud Projects

Software-as-a-Service has been a trend for about seven years and it is becoming more and more established in the field of business software. Especially HR registers enormous annual growth rates and more and more companies are switching from conventional software products installed in the company to the cloud.

Moreover, the provider market has consolidated significantly over the past two years and the largest, initially on-premise manufacturers such as Oracle and SAP have become the largest Software-as-a-Service providers. This makes it easier for companies to select a cloud product and take the first steps toward Software-as-a-Service. Companies are entering new territory all the same, as the implementation of cloud software differs fundamentally from original software implementation projects and thereby presents different challenges.

Challenge #1: Time-to-value

For me, time-to-value is the greatest challenge facing cloud projects. Time-to-value is the time from when leasing of the software begins until the software actually goes live in the company. The problem here lies in the fact that the implementation period reduces the lease period and thereby the actual use of the software. As a result, the implementation period in cloud projects must be kept as short as possible. This requires customers to fundamentally rethink their approach and move away from months of configuration workshops and defining business processes and towards rapid deployments based on best practice configurations. It must be possible to manage these activities using external implementation partners after examining the customer requirements and through a large number of projects.

My suggestion: Work with experienced implementation partners who have a wealth of cloud experience and can provide demonstrable best practice configurations. Adapt these configurations; it is definitely faster and more efficient than building a configuration from scratch.

Challenge #2: Configuration in place of customization

Software-as-a-Service is based on a uniform code. In other words, all customers that use a piece of cloud software from the same manufacturer access the same product (always the latest version). In this respect, customization is only possible to a limited extent (at least at this time). This too represents a huge difference to on-premise software, where the customer can adapt or expand the product relatively easily. However, it is possible to configure cloud software to a high degree and thereby adapt it to customer requirements. As a result, companies have to deal with configuration options and limits early on. Moreover, it must be clear when opting for cloud software that the aim of the implementation is not necessarily to only map the existing processes in the system. It must also involve critical analysis and sensibly adapting the existing processes to the system.

My suggestion: Look at implementing cloud software as an opportunity in many respects: analyze ‘old’ processes, take advantage of the opportunity to use best practices or configurations that have been successfully implemented many times, and ensure sustainability, as your cloud software remains fully updatable at all times.

Challenge #3: Follow the roadmap

With Software-as-a-Service, companies receive more than a finished product that they will need to update in a few years’ time; to a certain extent, they are buying the manufacturer’s product roadmap. I for one think companies should take that into account deciding to buy. Some manufacturers, such as SAP, do not create their roadmaps based solely on input from internal product managers, but rather incorporate customer feedback into the product development process as well. The larger the customer base, the more practical feedback available and the more likely it is that the regular updates deliver valuable new functions for customers. In the case of SAP, this is an ongoing process that occurs four times a year (without a release change project).

My suggestion:
Prioritize your requirements and compare them with the product functions and configuration options currently available. Do not delay your go-live date until all of the requirements are covered. Instead, ‘review’ the roadmap or regularly obtain information from your implementation partner on new functions and opt-in for these functions if necessary.

Why this approach is recommended

This approach offers the following advantages over conventional approaches to implementation:

  • Short time-to-value (see Challenge #1)
  • Opportunity to receive system feedback from end users and take their requests into account
  • Distribution of the implementation budget over the entire lease period
  • Guaranteed ‘regular’ support provided by the implementation partner