Managing your next Software-as-a-Service project

10 March 2016

Abi Ainscough

Abi Ainscough


As a Project Manager implementing a Software-as-a-Service application, you need to be aware that there’s a whole new way of working.

2015 was the year of Software-as-a-Service (SaaS), and the future continues to look bright for SaaS offerings. A recent article published by Forbes predicts that the global spend on the marketing of SaaS products is set to grow by nearly 40% in the next three years . It’s not just a huge trend in the private sector: the government’s G-Cloud 7 framework, which went live in November 2015, is set to encourage public sector organisations to take advantage of cloud and SaaS offerings on a national scale.

This SaaS trend is also clearly reflected in SAP’s product roadmap with offerings like Cloud for Customer, S/4HANA Finance, Cloud for Analytics and Simple Logistics, with more HANA-Cloud based tools on the horizon.

These cloud-based tools are necessitating a change in the way we think, not just about the SAP tools themselves, but also about how we deliver them. On the one hand, clients can expect to interact, maintain and support their SaaS tool in a different way to traditional on-premise tools. And on the other hand, sales and delivery teams have new considerations to plan for, new benefits to realise, and new challenges to be overcome. Let’s take a look at some of the things you can do to ensure that your next SaaS project is a success.

Two’s company

With a traditional on-premise project, actual contact with SAP is minimal, outside of licensing discussions, and assuming that the project runs smoothly. For the most part, it’s just your delivery team and your client. 

However, the nature of SaaS solutions means that you need to work with SAP just as closely as you’re working with the client. Close and regular contact with SAP is vital to the success of your project, especially if you’re working with a brand new SaaS tool. If done correctly, this communication can help with a wide range of things, from understanding the software roadmap and release schedule, to raising bugs and even helping to shape future development. 

Set your expectations right

Managing expectations is a challenge for any project, and with a SaaS project there is a whole new set of expectations in the mix, especially if this is your client’s first time working with SaaS. The differences between an on-premise implementation and a SaaS implementation are many, and after the tool has been delivered, the implications of using, for example, Cloud for Customer instead of traditional CRM, will continue to impact the usage and support of the tool throughout its whole lifecycle. It’s not just CRM in the cloud – the differences run deeper than that, and this needs to be understood.

It sounds obvious, but spelling out the practical implications of choosing SaaS as opposed to on-premise, and making sure that your client fully understands what these implications mean for them, can mean the difference between success and confusion.  Doing this earlier (as in, during the sales cycle) rather than later will mean that everyone is walking into the project confident of what the outputs will be.

Knowing (and not knowing) your tool

Let’s use an example here of Business Planning and Consolidation (BPC) vs Cloud for Analytics. BPC is a well-established Goliath of a tool, while C4A is a bleeding-edge SaaS tool. Thousands of companies across the globe rely on BPC every day for their planning, consolidation and reporting activities, whilst at the time of writing you can count the number of productive C4A instances on one hand. This means that every C4A project currently in progress is a project of discovery. We’re still ascertaining the finer details of what the tool can do; where the differences lie, what its strengths are, and what’s missing. You can read more on this in Matt Ainsworth’s insight.

In addition to this, SaaS tools develop and mature much faster than traditional on-premise tools (for example, we’re seeing a new release of C4A once a fortnight). Major changes in functionality should be expected regularly, especially just after a tool’s launch, and you’ll find that the tool you end up with at the end of the project is more developed than the one you started with.

There are a few key takeaways from all of this. Firstly; be open and honest with the client about what you do and don’t know. It will come back to bite you if you make assumptions about functionality, only to find out a few days/weeks/months down the line that the functionality you discussed isn’t available.

This also ties back to the first point I made. Working closely and regularly with SAP will help you to understand as much as possible about ever-evolving SaaS tools, and will also make you aware of SAP’s plans for the solution in the future. 

One size fits all

SaaS tools are limited in some ways because SAP are responsible for supporting one tool worldwide. This means that cloud tools are great for lightweight, high-level work and can be delivered in record time thanks to their standard, out-of-the-box content. On the other hand, if you’re looking for a tool that you can manipulate and customise in order to follow a highly complex business process, then a SaaS tool may not be for you.

Let me give you an example from a recent C4A project. We were working with a public sector client who had a particularly complex HR planning requirement. The functional lead on the project knew from experience that it was possible to meet this requirement using BPC, but because it required deep configuration and customisation, it wasn’t an option for our C4A client. 

With cloud-based tools like C4A, SAP are pushing clients to consider what is really necessary to their business process, and whether or not their business processes are really as efficient as they can be. The cloud tools are developed to reflect “best practice” for every business process, and clients are encouraged to simplify their processes to get the best out of the software, rather than complicate the software to match an overly complex and outdated business process.

What’s mine is yours

From a PM perspective, one of the major considerations when implementing a SaaS tool is the dependencies on SAP. This manifests itself in a number of ways. For example, if the system goes down mid-way through your project, SAP is responsible for getting it back online - not your project team, and not your client. This can result in some frustration, as your project team will be itching to get back on with the implementation. On the other hand, it does mean that your system will probably be back online quicker, as the problem has SAP’s global team of experts working on it, rather than your team on the ground.

Another way this dependency makes itself visible is through the release cycle. In order to properly plan for a new release during your project timelines, a few actions need to happen. First, SAP need to communicate to the client (usually the IT support team) that a release is on the way, what functionality this release impacts or improves, and what the timeline is. Then, the client’s IT support team need to successfully communicate this information to the project team. Finally, you as a PM need to invest time in planning for this release. Does the update mean system downtime? Will any reconfiguration need to be done? In order to fully prepare for the new release and ensure minimum disruption to your project, this process relies on that clear and thorough communication that I’ve mentioned before. 

The takeaway

We’re moving into an era where heavy, on-premise, monolithic solutions are no longer the only option. Cloud-based SaaS solutions are on the rise, and implementations of SaaS technology are becoming more and more common. To reflect this, SAP have made changes to their project implementation methodology and best practices (you can read more about this here in Jon Gregory’s insight on SAP Activate). However, making changes to the theory behind project implementation is only half of the story. As a Project Manager on a SaaS project, there are many practical differences between traditional on-premise projects and SaaS ones. If you can master these practicalities you’ll be well on your way to ensuring a successful SaaS implementation.

View comments


Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race

We use cookies to provide you with the best browsing experience. By continuing to use this site you agree to our use of cookies.