How to Budget Agile SAP Projects
Blog: Capgemini CTO Blog
SAP project requirements cannot be known 100% in advance. That’s why SAP Activate embraces agile. So what do we tell clients who ask (in advance) what a project will cost?
The reality is that virtually all SAP project budgets in the waterfall era were wildly inaccurate. They had to be because they were based on a fixed set of requirements. Stakeholders also would not see any working code for months after the contract was signed — and were inevitably surprised by what they finally did see: gaps in the functionality they were expecting; functionality they did not expect but was implemented anyway; and functionality that worked in a way they didn’t like. Clients also brought to the table new requirements they either forgot to specify in the first place or could not have foreseen earlier. The more fixed the requirements, and the longer that stakeholders waited to see working software, the less accurate the project budget.
That’s why there is agile, which SAP Activate — the implementation framework for SAP S/4HANA — embraces. Agile expects requirements to change incrementally as software is built, which is why agile makes frequent requirement updates a routine part of the project. That has proven to be a much more manageable and less disruptive way to implement software. But defining requirements incrementally raises one very important question: How do you budget the implementation? Business leaders need to make a go/no-go decision on the whole project. That’s hard to do if they don’t know up front how much it’s going to cost. But waiting months for a requirements document to be written defeats the effectiveness of agile and puts you back in waterfall mode. The solution is to write a high-level, outcomes-based budget at the start of the project with built-in contingencies for incremental requirements updates that inevitably come later.
Make Budgets Outcomes-Based
Agile’s advantage is that it is outcomes based. Business stakeholders see sooner whether the project is delivering the outcomes they expect. Obviously, this should also be an advantage when selling a budget. The more buyers are confident that the code (they can’t see) produces the right outcomes (they can see), the more willing they are to pay for the code that produces those outcomes. So consultants should work off a budget that is also outcomes based. In other words, they should build a budget in a way that models how they build the software itself.
In SAP Activate, software is built from pre-configured sets of modules that implement end-to-end value streams (like Procure-to-Pay) called SAP Best Practices. By using another SAP Activate component, Guided Configurations, consultants can quickly produce a minimum viable product (MVP) that approximates what the finished solution will look like. Working closely with business stakeholders, they can then refine the MVP until the proposed outcomes align with stakeholder requirements. Throughout this collaboration, the focus is on business outcomes, not the technical details required to achieve those outcomes. In the waterfall era it was instead those technical details that mostly comprised both requirements documents and contracts. With agile, stakeholders and consultants alike can now reference working software, not merely documents, so there is much less chance of miscommunication.
Likewise, when it comes to budgeting, consultants should employ a model equivalent to an MVP — let’s call it an MVB, for minimum viable budget. Working with SAP Best Practices, stakeholders and consultants get a pretty good idea of what the finished solution will look like, how long it will take to build, what resources will be required, and ultimately what it will cost. MVBs thus offer three key advantages over waterfall budgets:
- They are viable. With an MVB in hand, stakeholders can make go/no-go decisions on whole projects and avoid the delays and cost overruns that typically impact waterfall style budgets (which are not viable).
- They account for change. Like an MVP, an MVB is built to accommodate change, which is inevitable, which will happen incrementally over time, and which may be unknowable now. Just having an MVB reduces the risk that future changes will be based on incorrect assumptions — so stakeholders can build allowances for change into the budget now with less risk of surprises later. And because they embrace an agile methodology, stakeholders will also have much better knowledge in the future of whether a future update is worth funding.
- They are easy to budget. An MVB requires funding an MVP Fortunately, estimating the cost of both items shouldn’t be hard or take long because they are, after all, based on well-known SAP Best Practices. Selling an MVB should also be easy for two reasons: First, an MVP is something consultants will have to build anyway, should the whole project be authorized; and, second, stakeholders should require that they receive an MVB before moving forward with the whole project — simply for purposes of due diligence.
Whether they formally acknowledge it or not, it is inevitable that SAP customers will move toward the MVB model just described. First, they will adopt agile because the costs of not adopting agile are so high. And, second, when they do adopt agile they still need to make decisions up front about whether to fund projects that only get fully defined a sprint at a time. So stakeholders will need something like a minimal viable budget for the same reason they need a minimal viable product. Both offer a framework of confidence around what must inherently be an uncertain future.
Leave a Comment
You must be logged in to post a comment.
