PART I. IS AN AGILE APPROACH APPLICABLE FOR AN SAP PROJECT? SHOULD I FAVOR IT OVER THE CLASSIC WATERFALL?

Why AGILE?

According to the 9th Global Project Management Survey (2017) from the Project Management Institute (PMI) a significant portion of IT projects globally are still reported as finished late (49%), exceeded their initial budgets (43%), not met their goals (31%), and failed outright (14%) with a lack of clearly defined and achievable objectives (37%) and a poor communication (19%) as the primary causes of failure.

Figure 1: IT project failure and success rates, source: PMI pulse of profession 2017

However, comparing to their earlier surveys, the researchers noticed a positive trend – for the first time in five years, more projects are meeting business intent and there has also been a significant decline in money lost: organizations are wasting an average of $97 million for every $1 billion invested, due to poor project performance—that’s a 20 percent decline from one year ago.

They suggest that this positive trend is due to the change in the way organizations are managing projects and programs. One noticeable change was the growing importance and usage of agile as a technique for managing projects. A full 71 % of organizations report using agile approaches for their projects sometimes, often, or always. Around 72% of all survey participants reported the organizational agility has become greater in their organization over the last five years. Moreover, they noticed that the “champions” (organizations with 80% or more of projects being completed successfully) have a keen focus on using agile approaches to projects—55 percent versus 24 percent of “underperformers”.

Figure 2: Change in organisational agility over time, source: PMI pulse of profession 2017

Figure 3:  Current usage of agile approaches, source: PMI pulse of profession 2017

Given this trend agile approaches deserve close attention also in context of SAP projects.

What is an agile approach?

Currently there are many definitions of what is agile. In our definition we prefer to go back to the “roots”: 

An agile approach is a way of doing work according to the “Agile Manifesto” following the

agile values*:

• Individuals and interactions over processes and tools,
• Working software over comprehensive documentation,
• Customer collaboration over contract negotiation,
• Responding to change over following a plan

and agile principles**:

• Customer satisfaction by early and continuous delivery of valuable software,
• Welcome changing requirements, even in late development,
• Deliver working software frequently (weeks rather than months),
• Close, daily cooperation between business people and developers,
• Projects are built around motivated individuals, who should be trusted,
• Face-to-face conversation is the best form of communication (co-location),
• Working software is the primary measure of progress,
• Sustainable development, able to maintain a constant pace,
• Continuous attention to technical excellence and good design,
• Simplicity is essential,
• Best architectures, requirements, and designs emerge from self-organizing teams,
• Regularly, the team reflects on how to become more effective, and adjusts accordingly.

* Source: Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). “Manifesto for Agile Software Development“. Agile Alliance. Retrieved 14 June 2010.
** Source: Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). “Principles behind the Agile Manifesto“. Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.

Let us break down these values and principles into SAP project practices by comparing an Agile SAP project with a Waterfall SAP project.

Figure 4:  Characteristics of Waterfall and Agile SAP projects, source: Agilon GmbH

In the focus of an agile SAP project is the Customer and his requirements. The Customer’s requirements are “translated” into a business value and a project purpose by Project Stakeholders, broken down in prioritised features by the Product/Process Owner. Teams build themselves around the features so that a feature can be designed and implemented end-to-end by one team. The implementation of the features is an iterative and incremental process. Each iteration includes planning, designing, building and testing activities dedicated to prioritised feature items. At the end of each iteration teams demonstrate results to Stakeholders and other teams and reflect on their progress. Before the next iteration, the Product Owner reviews, adjusts and re-prioritise requirements so that requirement changes are not postponed to the end of the project in contrast to Waterfall SAP projects. As teams are trusted to make their best and continuously improve themselves there is no authority role who is in charge to micromanage the teams and plan their work. The system demo presented on a recurrent basis and the feedback from the Customer and Project Stakeholders is the only formal measure of the project progress.

Is agile applicable to SAP projects?

To answer this question, we rely on the guidance of the prominent “Stacey Matrix” developed by Professor of Management at Hertfordshire Business School in the UK, Ralph Douglas Stacey. The “Stacey Matrix” is a model for approaching complex situations. It plots certainty on What needs be done the vertical axis and certainty on How it needs to be done on the horizontal axis. Depending on where on the matrix a task or an initiative lands it is mapped to one of the decision-making domains — simpel /obvious, complicated, complex, chaotic. For each domain there is a recommended decision-making approach:

Figure 5:  Stacey Matrix, adapted from R.D. Stacey, source: The Tools and Techniques of Leadership and Management: Meeting the challenge of complexity. Routledge, London 2012.

By mapping these decision-making guidelines to agile vs. non-agile principles and practices we conclude that agile approaches suite “Complicated”, “Complex” and “Chaotic” domains while non-agile the “Simple” domain.

Figure 6:  Decision-making in Waterfall and Agile frameworks, source: Agilon GmbH

In the next step we will explore which domains SAP projects can be assigned to. 

First let us clarify what is an SAP project.

An SAP project, in a broader sense, is an IT project aiming an implementation or upgrade of one or several SAP products in an organization for a purpose of process automation or optimization. SAP products are enterprise software, platforms and frameworks of the company SAP SE. 

In the narrow sense SAP projects can be classified by their goals and size. Based on the goal we usually distinguish the following SAP project types:

• SAP implementation (IML): the goal is to either automate/digitalize manual processes of an organization with the help of SAP products or to replace or partially replace legacy enterprise software with SAP products.
• SAP landscape transformation (LST): the goal is to adjust the current SAP system landscape to the changing business environment due to reorganization, merges and acquisitions, carve out, process and cost inefficiencies etc.
• SAP conversion/upgrade (UPG): the goal is to upgrade an older SAP product version to a newer one often accompanied with procedural and organizational adjustments to the new technical capabilities and requirements
• SAP improvement (IMR): the goal is to improve the existent processes and/or applications
• SAP support (SUP): the goal is to provide support to SAP users in analyzing and fixing technical or functional issues

Each project type can be associated with a certain level of certainty of the “What” (requirements) and the “How” (solution to meet the requirements).

Figure 7:  SAP projects types by scope certainty and complexity, source: Agilon GmbH

Furthermore SAP projects vary in their size and each project type can be small, medium or big dependent e.g. on the number of modules, developments and interfaces to be implemented, number of legal entities to be covered, number of users to be trained etc. Here is a exemplary size estimation:

Figure 8:  SAP projects types by project size, source: Agilon GmbH

Obviously the bigger the project size the higher the number of technical, processual and organizational dependencies and therefore the lower the certainty of business requirements and solution to be implemented. 

Taking all the above into account most SAP projects can be assigned to either “Complicated” or “Complex” domain on the “Stacey matrix”.  The exceptions are the support/bug fixing projects, small improvements and small system upgrades.

Our brainstorming in a round of experienced SAP experts confirmed that nearly all SAP projects can be characterized by high uncertainty, high complexity, many dependencies, long duration, high knowledge and human resource intensity.

Since the most advantageous approach for the “Complicated” or “Complex” domains is an agile approach, this is the approach we would recommend for complex and complicated SAP projects – new SAP implementations, SAP system landscape transformations, big SAP upgrades, big and medium-size improvement projects.

Pro’s and Con’s of an agile approach in the context of SAP projects

Now let us dive deeper to investigate typical issues of SAP projects and see whether an agile approach can help to overcome them.

Figure 9:  Pro’s and con’s of an agile approach with regard to the typical SAP project issues, source: Agilon GmbH

An agile approach lays a foundation to overcome many typical SAP project issues. It improves communication between business and IT experts, users, consultants and developers, within a team and between teams and project stakeholders. Guided by the business value it helps to get rid of unnecessary documentation and to increase the value of the implemented software instead. Frequent team meetings with the Product Owner assure the scope is fully understood and all requirements are up to date and planned for implementation according to their priority.

An agile approach sets up a work environment that stimulates continuous fast learning, knowledge sharing and enthusiasm of the involved people. As a result, lack of expertise and commitment are mitigated in the medium term.

In the contrary to the Waterfall approach with a fix scope and variable time and budget, an agile approach sets fix time constrains and allow the scope to vary dependent on business value and business priorities. This prevents projects from becoming cost traps, delays, and ensures that the right results are achieved.

However, an agile approach has also its limitations. If business values ​​are not clearly defined and communicated, there is no consistent goal prioritization or the agile values ​​and principles are not lived in the organization, agile projects can lead to budget overruns and overall failure, similar to non-agile projects.