Sonya Oberstar considers whether the Agile approach might present a better way to manage SAP project budgets, reducing cost blowouts and increasing the focus on delivering business value.
In my recent column for Inside SAP, I looked at whether Agile methodology can work in a SAP environment. Arguments for and against were put forward and it certainly opened the door for further discussion.
The next area I want to look at is how and where do we start investing in Agile transformation and establish the new capabilities that will lead to us productivity and delivery nirvana?
The first step is to look at the value of ‘customer collaboration vs. contract negotiation’, which requires a rethink of the fundamental way the industry negotiates and collaborates on commercial contracts with SAP services vendors.
Current waterfall based contracts are often hundreds of pages long and created and debated by lawyers from both sides with clauses that cover exact plans and milestones, detailed schedules, damages, timeframes, requirements and technical scope, resource characteristics and composition, responsibilities and deliverables, over periods of many months and even years.
More often than not, traditional waterfall budgets and contracts are at the ‘big’ end of the budget scale and based on fixed price, fixed scope and fixed timelines. They generally end up with many expensive change requests and often become troubled and fail to deliver. This can see engagement escalating into massive blowouts and litigation slinging matches.
Typically, waterfall projects start missing the planned deliverables from about 70-80 per cent into the project. This can occur for a multitude of reasons such as unclear requirements, hidden complexities, lack of test data, disjointed teams, lack of executive support, unproven technologies and then penalties start kicking in and fights around contractual scope change start, leading to further blowouts.
So the nine-month $15 million project becomes a 16-month $25 million re-scoped project. Project managers are replaced a couple of times by new people who can ‘push it in’ in the new timeframe and budget. Stress prevails…
The industry unfortunately is riddled by ERP project problem stories like this.
So why am I painting this bleak picture? It’s one that all of my candidates and clients tell me about on a regular basis. I’m not pointing fingers here as to who is to blame, but what I want to highlight, based on my day-to-day discussions with stakeholders across SAP, is why don’t we look at another approach?
I’m finding more and more clients and candidates are asking me why we keep going down this path and how does an Agile contracting change that way of working? Furthermore, how do we find the staff that ask these questions or the companies that employ this kind of thinking?
In contrast to waterfall, the Agile contract looks and works quite differently. Think of it as progressive iteration contracting, which allows for changes based on learning and business value delivery with evolutionary learning cycles that drives potential contractual changes. While I do appreciate legal terms need to remain, my argument is that an agile contract needs to be structured and budgeted for differently. For example, by applying incremental delivery, yes, bit by bit, section by section, deliverable by deliverable or, in ‘agile terms’, in iterations.
It could be based on a business value roadmap, articulated by epics and user stories, that emphasises incremental business outcomes, as opposed to documentation and technology deliverables, but also relates to measurable value from working minimum viable products (not over-specified and over engineered requirements).
The contract could be bound only to the cost of the first iteration, but within an estimated overall budget for all iterations provided. Payment made on a joint assessment of business value delivered at each iteration and delivery incentives could also be built in.
The key to effective agile contracting in this case is to establish full transparency, trust and partnership between the parties as well as monitor relevant metrics that support the iterative and incremental nature of the contract such as team stability and happiness, productivity related velocity improvement, business value increase and product owner and user satisfaction.
Establishing a good agile contracting approach requires substantial effort in collaborative working, which may incorporate assurance strategies such as evaluating a range of paid implementations of small value short timeframe accelerated prototypes and proof of concepts of alternative solutions and architectures from various competing vendors (e.g. competitive sprints). This means that businesses will value delivery capability, technical acumen and cultural appropriateness and it can be conceptualised, articulated and assessed better.
The true value emerges from the interaction and the learning so that appropriate changes in the course of action can be applied, or in the worst case scenario, opt for an early termination of the project.
Creators of LeSS (Large Scale Scrum), Craig Larman and Bas Vodde, provide a range of insights from the contract chapter in their book Practices for Scaling Lean & Agile.
They state that agile and adaptive frameworks “engender an increased alignment of motivations for the parties since they both have ‘skin in the game’”, “and they may improve fundamental fairness and relationship building. This philosophy is at the heart of the concept of a win-win approach, and it will create the trust and relationships that will foster further business.”
Of course we also need to be aware of Agile bias and dogmatism because there is a definite place for fixed price fixed scope and timeframe waterfall contracts or even blended contracts where elements are Agile-delivered and other components, such as infrastructure, follow traditional waterfall approaches.
Waterfall remains applicable particularly where a project component is simple and straight forward and can be clearly articulated in engineering terms with little uncertainty, and where the parties have a proven repeatable process and track record of delivery in similar or the same business and technology contexts.
However, complex Agile contracts can provide sorely needed progressive flexibility for delivering rapid innovation projects in an iterated way where ambiguity and complexity is reduced through collaborative teamwork and joint learning – important where a competitive edge is achieved through working software delivering real business value.
So what does this mean for today and tomorrow’s workforce in the SAP sector? And more importantly how do we, as an industry, become more open to these new ways of thinking?
Going by my chats and discussions, it’s those that are not open to new ideas that will either be left behind when shortlisting for new and exciting roles and projects.
So I ask again, how agile are your contracts and budgets? It’s not just the success of the project that is on the line, it’s the possibility of attracting top talent in the future as well.
