As SAP Activate is announced, is the ‘traditional’ approach to IT projects dead?

19 October 2015

Jon Gregory

Jon Gregory

Former Consultant

SAP Activate, SAP’s latest delivery methodology, was announced recently. Eventually this will replace SAP’s current ASAP methodology as the preferred approach to SAP solution delivery. This got me thinking more about agile delivery as a concept.

I find that ‘traditional’ SAP projects with long blueprint phases, drawn out development cycles and big testing phases, are becoming a thing of the past. Organisations are leaning towards more agile approaches to solution delivery, such as SAP Activate and SCRUM, which can deliver ROI faster.

This post is based on my experiences on a project at Barnsley Metropolitan Borough Council, which was delivered using agile principles. See Barnsley Council digitally transforms service operations with SAPUI5 applications. I believe these principles should be commonplace in SAP implementations in order to:

  • Build a solution that completely meets the customer requirements
  • Gives the customer the best opportunity to succeed in using and adoption the solution
  • Start to deliver benefits to the customer as quickly as possible.

No one methodology should be rigidly followed – an approach needs to be tailored to the project, customer and supplier requirements. However, there are some elements of agile (mainly associated with Scrum) delivery that I believe should be commonplace:

Understanding requirements

Some will have you believe that agile equates to rocking up on-site and coding without any requirements. Of course, this isn’t the case. Instead, what agile delivery does offer, is a process to provide ‘just enough’ requirements to start developing iteratively.

In my experience, a burst of short workshops, followed by screen wireframes or simple prototypes, can provide the basis of the customer requirements. Three days of workshops can replace two weeks of blueprint workshops, two weeks of write up, and two weeks of review and comment.

The requirements will never be fully captured in such a short space of time – but by building in iterations, they don’t need to be.

Customer-developer collaboration

I’ve found that agile evangelists paint a picture of Waterfall approaches that the customer and the development team meet up for phase gates and testing only. I’ve never known this to be true. However, the manner in which agile happens means that the end-user has to be involved from day one throughout. Iterative development requires regular feedback and touchpoints. On the recent project, I saw three key benefits to this:

No surprises

The end-user had to be to be involved throughout development of the solution, as the finer detail of the requirements were worked out. As a result, we know that everything we’ve built meets the requirements of the customer, because they’ve seen it all!

Reduced testing and training time

With the solution continually seen and touched by the users throughout the project lifecycle, the effort to train and test dramatically reduced. Users already had an intimate knowledge of the solutions capabilities and were able to test, and deploy with minimal support from Bluefin, reducing the customers spend on implementation.

Change management

Engaging a group of users from the beginning and working together made our change management easy. We had a group of people shouting from the rooftops about our solution, running demonstrations to the workforce throughout iterations. They were warmed up to the solution by the time we went live and as mentioned above, this dramatically reduced time and cost needed for training. Our benefits case has yet to be realised as we went live recently – I’m sure there will be a blog on that soon!

Rapid deployment

Going live with drops of functionality rather than waiting for a ‘big bang’ results in customers starting to realise a return on their investment much more rapidly than waiting for a full end to end solution to be deployed. If a project lifecycle is six months, but one key component of the solution can be scoped, built tested and deployed in four weeks, why not do it?

Summary

This isn’t a case of agile methods vs waterfall. There’s a place for elements of both on most projects. But some agile processes and principles have to become commonplace across all projects in order to do the best work, cost efficiently for our customers.

The ‘traditional’ IT project is dead – we need to move with the times.

View comments

Comments

Blog post currently doesn't have any comments.

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