At LeapGreat’s September 30, 2026, LinkedIn Live (watch the replay), a panel argued that SAP programs run into change orders because the business signs off on a design before it has seen the future system. The panelists proposed starting with a running SAP S/4HANA development system loaded with the company’s own data, so users can review how the system works before requirements are approved. LeapGreat calls this approach Frontloaded Agile, as opposed to Backloaded Waterfall.
The speakers were Martin Palacios, a chief information officer (CIO) with nine SAP implementations behind him, and LeapGreat’s two founders, who together spent 56 years at SAP. The session was titled “Meet LeapGreat: Moving From Backloaded Waterfall To Frontloaded Agile.” Rhett Bingham, who leads sales in the Americas, moderated. Because LeapGreat hosted the session and sells the product discussed, the claims below are the panelists’ views unless stated otherwise.
Why Signed-Off SAP Requirements Still Produce Change Orders
Palacios has signed off on SAP designs as a CIO. “Every time I got a sign-off, we had to do change orders,” he said.
He said he has not seen a requirements document or blueprinting exercise that reflects what the business user actually had in mind: “I haven’t seen a single requirement document or blueprinting exercise that actually reflects what the person had in their head.” He called that gap the root cause of these issues.
Where Change Requests Come From
Bob Cummings, LeapGreat’s chief executive officer (CEO) and co-founder, started on SAP R/2 in 1990 and spent 28 years at SAP. He described the usual sequence:
- Design documents are signed off.
- The real system first appears during build or test.
- The details that matter turn out to sit at a much lower level than the design documents covered.
- Those details return as change requests, rework, and slipping budgets.
Cummings calls this backloaded waterfall, because discovery happens late in the project, when it costs the most and there is little time left to change anything. He said every project he has worked on uses Agile vocabulary, such as sprints, scrum, and backlogs, while running in practice as sequential waterfall. “True agile means you start with a running system and then refine it again and again and again,” he said.
The SpaceX and NASA Comparison
Cummings used SpaceX and NASA as an analogy. In his account, SpaceX started building rockets and accepted failure. When a rocket blew up, the company called it a rapid unscheduled disassembly and treated it as input for the next build. NASA spent years planning and blueprinting on paper to avoid an explosion on the launch pad. Cummings noted that NASA now buys its rockets from SpaceX, and he presented this as the difference between Backloaded Waterfall and Frontloaded Agile.
How As-Is Studies Add Unneeded Requirements
Cummings described a second problem with starting from a study of the as-is system. If you have only known a horse carriage and never test-drove a car, the horse ends up on the requirements list, because that is where the energy used to come from. The requirement then reads: tie the horse to the front of the car. “You wouldn’t believe what kind of horses we’ve seen in these systems,” he said.
| Backloaded Waterfall | Frontloaded Agile | |
|---|---|---|
| When the business first sees the system | During build or test | At the start of the project |
| When detailed requirements surface | Late, as change requests | Early, while reviewing the running system |
| Basis for requirements | Design documents and a study of the as-is system | A system loaded with the company’s own data |
Precedent: SAP R/1 at ICI in Johannesburg
Dean Milne, LeapGreat’s co-founder and head of engineering, traces the idea to SAP’s first customer. He started on R/1 at customer ICI in Johannesburg, where there were no blueprints or design documents. The consultants were Hasso Plattner and Dietmar Hopp. They sat at the back of the room and told the team what to click and what to enter, and business people were in the room from day one. The team configured the system, looked at the result, and changed it in real time. The notes became the documentation.
Milne called it “the smoothest, the fastest, the easiest project I’ve ever done.” In his telling, Frontloaded Agile was simply the normal way of working at that time. “If people can vet it early, it really makes a difference,” he said.
How LeapGreat’s FrontLoad Works
According to Cummings, LeapGreat’s FrontLoad™ delivers a first S/4HANA development system loaded with the customer’s data, and the work usually takes 7 to 14 days depending on company size. He stressed that it is the customer’s own development system and “this is not demo data.”
The delivery includes:
- Documentation and test cases
- A connected tool chain that includes Cloud ALM, Signavio, Tricentis, and Jira, among others
- A navigation cockpit that lets a business user get started quickly, even without prior SAP experience
Milne said the data load starts from LeapGreat templates with a minimum set of fields: “You don’t need a lot of data to start the process.” LeapGreat can also take in a company’s existing documents as a starting point. It collates them into design documents and versions them, so nothing is lost if a system integrator (SI) leaves mid-program. The product is sold as a software-as-a-service (SaaS) subscription.
What Customers Do With the Running System
Cummings said that with the FrontLoad system in hand, a customer can write its roadmap, statement of work, and request for proposal (RFP) for its integrator. LeapGreat builds the first frontload for system integrators until they can build their own, and it implements directly for some smaller companies. It also builds frontloads for companies that have not yet decided on S/4HANA, whether they run SAP ERP Central Component (ECC) or non-SAP platforms.
Palacios’s Experience at Paper Excellence and Fibre Excellence
Palacios found LeapGreat and used its approach at Paper Excellence and Fibre Excellence. In the usual Backloaded Waterfall pattern, the business first sees paper and is later surprised by the development system. With a running system at the start, he said, everyone including business users had full transparency from the beginning.
Walking the business through the future system made the requirements clean, he said: “When you see it, you know it.” He now uses the approach on every system he deploys, whether or not it is SAP. “I don’t code until I’m satisfied that you felt heard as a user.”
When the Approach Does Not Fit: Pure Brownfield Upgrades
Cummings said the product does not suit a very pure brownfield technical upgrade. “If you are a very pure brownfield technical upgrade and you just want to move from A to B, without leveraging any value from S/4, you don’t really need LeapGreat.”
He added that skipping the chance to bring in improvement, value, and standardization is “a very unfortunate thing,” and that “S4 is really a different animal than ECC.” He prefers the term bluefield, and suggested picturing a system that is 70 percent green and 30 percent brown carried over from the past.
For brownfield moves, Palacios said that on the Paper Excellence migration he could use LeapGreat as a documentation layer with process comparison for continuous improvement. “A go-live is not the end, it’s the beginning,” he said.
Why Boards and System Integrators Care About Risk
Palacios framed the approach in terms of approval. “Boards only speak risk,” he said. In his view, a program that cannot show how its risk is mitigated might not be approved, even when the company needs it.
He said system integrators “bear all the risk and all the accountability,” and that many of his CIO peers find a program has become a runaway train a third of the way in. He said nobody intends that outcome and attributed it to the nature of very large projects. He described LeapGreat as his insurance policy as a CIO and as something that also helps the integrator. In his account, he knew where everything stood, and the people in the room could sign off on how the system would actually work.
User Acceptance Testing Fatigue
Palacios closed on user acceptance testing (UAT). He has seen UAT fatigue set in. “When you don’t get it right and you do a lot of change orders, the business checks out,” he said. After that, users stop volunteering for further testing or improvement suggestions they expect to go nowhere, because the system does not work the way they thought it would.
A Check for Your Current Program
Count how many change requests on your current program trace back to a requirement that someone signed off without first seeing it working on a screen.
About the Author
Robert (Bob) Cummings is CEO and co-founder of LeapGreat, a SaaS platform that automates SAP ERP implementations for mid-size and large manufacturers and distributors. He works on reducing risk in SAP S/4HANA projects and aims to bring implementations as close to the push of a button as technology allows.
