Okay, I will admit it. I am sort of “Old School” and a traditionalist when it comes to my SAP implementation approach. To be honest with you, it’s how I grew up. I am a product of my environment and the ASAP/Waterfall method of delivering SAP solutions has worked pretty well for me for the past 20 years or so.
But in the words of Bob Dylan, “Times they are A-Chanin” so I need to look at and embrace the up-and-coming methods that folks are using to implement their SAP solutions using an agile approach.
A talked a little bit about this in a recent Blog about SAP’s new methodology called “Activate”. It is definitely founded on an agile principles and given SAP’s new vision of pre-configured solutions with minimal change up front and process improvement evolution over time in a prioritized log it should work pretty well.
But does that mean that everything we practitioners have been doing for the past 20+ years gets thrown out with yesterday’s newspaper? I don’t think so. In fact, I think there are a lot of components of the traditional implementation approach that will be around for quite some time.
In my opinion, as SAP Practitioners moving forward, we cannot live in a pure Waterfall world nor can we live in a pure Agile world. We must strike a balance between the approaches and build a hybrid that will allow us to maximize the best of both worlds for our client’s success.
So the question becomes, “what’s the right balance”?
I recently attended a presentation given by Michelle Shuttleworth of Deloitte Consulting LLP that really resonated with me. In her presentation she had the following chart to use a guide post as to how much waterfall and how much agile to indoctrinate into your SAP program based on aspects of scope, culture, flexibility, technology and team composition.
In looking at this chart, those programs where the Scope is well-defined, there is a culture where planning is preferred, there is a high amount of rigor, the technology is understood and you have a variety of specialist would gravitate towards a waterfall approach. And correspondingly, those programs where scope was not understood, planning was not a cultural norm, the culture is highly adaptive and needs flexibility, the technology is uncertain and team composition is more cross-functional would favor a more agile implementation approach.
So here is where my “Old School” thinking kicks in. I don’t know about you, but if an organization is going to be spending tens if not hundreds of millions of dollars on an implementation and get into a contract with one or more 3rd Parties to deliver a solution, wouldn’t that require (to protect all parties) a fairly defined scoped, a pretty decent plan, and a good understanding of the technology to be used? So, to me, these are components where I think leveraging more of the waterfall approach would make sense.
So let’s talk about the other two components: flexibility and team composition. Flexibility is a tough one and is one of the components where I think and Agile approach can come in pretty handy. So where would client’s and SAP Programs need most of their flexibility?
- Reports
- Interface
- Conversions
- Enhancements
- Forms
- Workflows
- Mobility
And this my friends is where most SAP Programs, regardless of method, derive their success or failure. My contention is that the SAP part (the configuration and business process procedure components) are fairly straight forward. It’s all the non-standard stuff that are relatively unique to each implementation that makes or breaks an implementation.
So can Agile methods improve the delivery of RICEFWM deliverables? I think so, if properly planned and managed using the Agile techniques, where the organization culture will allow for its adoption, and most importantly, WHERE THE RESOURCES ARE MADE AVAILABLE TO EXECUTE AS FOCUSED TEAMS TO COMPLETE A SPRINT.
Correspondingly, I think the waterfall approach can work pretty well if it is properly planned and managed, the organizational culture allows for a waterfall approach and most importantly, WHERE THE RESOURCES ARE MADE AVAILABLE TO EXECUTE AS FOCUSED TEAMS TO COMPLETE A SET OF WORK PRODUCTS TO PRODUCE A DELIVERABLE.
The other component, team composition, falls right in line with the Agile approach. For the most part, each RICEFWM deliverable is going to be a composite of many work products that are going to require many different skills from many different resources to complete. They require a cross-functional approach of Business Subject Matter Experts, Functional Analysts/Designer, Technical Designer/Developers, Product Owners and alike, under the best working conditions, working as a unit to complete a sprint.
To me, this is where the waterfall approach usually breaks down. Because of the traditional individualization of resources on an SAP Program, getting resources to work as a “Unit” has been extremely challenging and where I have seen the most waste on Programs. This is because individuals prioritize work products differently than say an overall team. And Teams prioritize work differently than an overall project. And projects prioritize work differently than an overall program.
So unless you can organize individual’s works to align with team deliverable productivity that aligns with the Project’s Prioritization which also aligns with the overall Program Prioritization, an agile approach may work better for you.
At the end of the day it’s all about Focused Resources and Execution positioned to Deliver
So what was the key takeaway that I got from Michelle’s presentation? No matter the approach (waterfall or agile), it comes down to having the right resources, free from distraction, performing focused work, together. Whichever approach gives your SAP Program the highest probability of executing the preceding statement, that’s the approach you should use.
Over the next few blogs, I will discuss some of the techniques I have used with great success that incorporate some of the leading disciplines of both waterfall and agile approaches while maximizing the utilization of the right resources working together in focused execution to produce a sprint (via agile) or a set of work products deliverables (via waterfall). Stay tuned.
