Agile/Waterfall/Devop/Wagile

I have a long-standing habit of starting my articles on LinkedIn with a lesson learnt from my early SAP experience, and there is no getting away from it. I am very old… and I did make a lot of mistakes at the beginning, usually well-intentioned, and the learnings have always been a part and parcel of it…

Back in the days, I worked at a small SAP consultancy which, as a rule, had been a subcontractor to the large ones and shouldn’t intend to win projects by itself. However, we were ambitious and wanted to challenge the big boys. So we started to go directly to market in order to win our own work. We went out to the clients directly and soon we started to get traction. Within a few months it was clear that we could be more than just a body shop and could be a prime partner to some large clients.

?

By coincidence, two of the employees, me and another gentleman, almost had won two large clients in the same week! And it suddenly dawned on us that we needed a delivery method of our own if we were going to make it a success (this is before the days of ASAP, the SAP method of the time). We got a team of experts together in a small room on a Monday afternoon and using the knowledge we had gained from our various experiences as sub-contractors and some common sense, we wrote an approach on some flip charts. We spent that afternoon productively and we worked out a branded method that we could all align on, entailing:

?

1. Collect the requirements (these had been in the tender process)
2. Build the scope with modules and level 1, 2, and 3 processes
3. Have a kick-off meeting. And a party too!
4. Write process documents
5. Then break down to the next level , identify the RICEFS
6. Sign off the blue print
7. Then build reusing the documents we already had to identify and cope with test scripts, training, change impact and so on
8. Collect some things centrally that needed to be in place i.e. security, basis, etc. led by a solution lead
9. Go live!
10. Have another party!

?

The whole thing seemed sensible and sustainable with lots of reuse of work done at previous phases, lots of clear milestones to be paid upon and no obvious gaps.

?

This approach looked incredibly similar to the approaches of all the SAP partners at the time. The only main difference I can detect is that some took the collection of requirement really serious and went to extraordinary lengths to prove that they had all been delivered through many phases and numerous spreadsheets, while we may have taken the view that some of the requirements were a bit silly and the client really did not need them!

?

Now looking back, I see a few fundamental issues with this approach. Perhaps, it might not work out in the long run.

?

1. It assumed SAP was the answer to everything and if it did not do what was asked, you would make it do it!
2. It assumed the requirements were what you needed. In reality, they were often answering todays issues caused by the existing systems not the ones you were going to have in future. Why build complex workflows when you are all on the same ERP solution or a cross modules report when it is in one system
3. It also assumed that what you wanted now was what you would need in the future. The solution, when built, was probably very inflexible and added a lot of technical debt for the future if you wanted to change it

?

But then, there was mitigation:

?

1. You would have to innovate and customise SAP in the core product. There was not a lot of choice and that was the perceived wisdom
2. The initial SAP implementation were by and large addressing issues that occurred within the scope of ERP unlike todays that go beyond the back office

?

We knew no better and I can’t remember being warned against it.

?

I am a little sceptical that some of the approaches we invented were to make sure that there were clear billing milestones and that the whole process was very measurable to aid procurement and to make sure the SIs could get some change control, not to actually deliver what was needed.?

?

In the end, the approach outlined above almost guaranteed that we ended up with highly bespoke and complex solutions with lumps of functionality that was never used.

?

So, my point is, well, think about doing things in a different way. Many SAP customers are.

?

1. Embrace Agile and DevOps, not the approach we invented. But accept some tasks can never be agile
2. Don’t gather 1000s of requirements, get the big CXO issues identified and work towards them
3. Go live with MVPs
4. Experiment and try things early, don’t build at the end and find it does not work or does not scale etc.
5. Use a template and stick to standard
6. Look at other technologies if SAP does not have a great answer. Don’t try to make SAP do unnatural things
7. Think why do I need to do this, and why do I need to do it in SAP
8. Try to build commercial relationships that provide good value and trust, but it doesn’t mean measuring by spreadsheet (it will always make the spreadsheet more important than the business outcome)

?

So, what are your thoughts on it? Were the SAP implementation methods doomed or did they do their best at that time? Share in the comments below.

?

?

?