„If I were not doing this already, knowing what I now know, would I start doing it again today?“ – Dave Barry, American Business Author

Over the past few years, while advising on scaled agile development processes in IT departments, I have seen several business applications being rewritten, refactored, or re-platformed.

Developing a new solution or process can be challenging as there are often disagreements on what needs improvement. This results in a laundry list of requirements that can quickly become overwhelming and exceed the current solution’s functionality without measurable improvement goals.
Similarly, moving an existing application to a new platform to reduce complexity or cost often leads to additional demands („While we are at it…“), causing feature creep and project delays.

In my observation, opportunities to simplify, tighten, and improve historically grown demand and feature thickets are generally often missed.


A Blueprint for Success

However, things do not have to be this way. Here’s how:

Owners – Not Committees

When implementing a new solution, it is vital to start by appointing an empowered project lead or a product owner (PO). The ideal scenario would be to have a pair consisting of an IT PO and a responsible individual from the business department. Their roles should be defined as active leadership rather than managerial roles (decision-drivers – not committee moderators!), and they should be endowed with a certain level of authority.

This duo must be held responsible for implementing and maintaining a solution, just like the duos of product managers and engineering leads for commercial products. They should be held accountable for ensuring the process and the solution are meeting agreed business objectives when rolling it out and continue to be responsible for necessary improvements for a certain period after rollout.

Go for Measurable Business Impact

In order to measure success, it is essential to agree upon a set of Key Performance Indicators (KPIs) and use them to track progress towards desired business impacts. However, sometimes, these goals need to be clarified or defined in more detail. In such cases, the Project Duo must work with the relevant stakeholders to agree upon key performance indicators (KPIs).

They also need to validate the feasibility of these goals with suppliers and vendors before starting the project’s implementation phase.

If the objectives appear unachievable due to technology or organizational constraints, they must be adjusted in agreement with IT and business. If the goals are set as aspirational „moonshots,“ it is crucial to be transparent with everyone involved to manage expectations.

Once the desired business impact is clear and measurable, high-level design principles must be agreed upon. Depending on the project, these principles may range from broader architectural decisions (e.g., cloud vs. on-premise or hybrid) to UX principles (for example, using SAP Fiori).

Only Build What You Truly Need

We recommend using a zero-based approach once the strategic fundamentals are clear.

This approach requires the project team to work through the existing solution(s) and user journeys (or best practice process flows) and analyze process data to identify the value-adding core activities as well as the distracting complexity drivers.

Based on the insights gathered, the project team then develops a minimum viable „green field“ prototype flow, initially focusing on the most common scenarios and leaving out exceptions and edge cases. The guiding principles should be simplicity and user-centricity, aggressively applying heuristics like Pareto and Hitchens’ Razor*.

Finally, the impact of the resulting minimum viable process on the business goals and critical process parameters (throughput time, …) has to be evaluated to ensure it will deliver the desired improvements.

Iterate and Know when to Stop

The team subsequently collaborates closely with stakeholders and users to refine the minimum viable solution by iterating in an Agile working model, incorporating additional constraints and features only where necessary. It’s crucial to encourage the PO or Project Duo to thoroughly question and discuss any additional demands and weigh the added complexity against the impact on overall business objectives, relevant KPIs, and design principles.The project should be considered complete when further efforts fail to yield significant (!) additional benefits to business goals (impact on the agreed KPIs) or user experience, as determined by the Project Duo and agreed upon with the business department and IT.

We believe that

  • Clear Outcomes: Establishing a project-ownership model with measurable KPIs tied to business goals
  • Validated Goals: Ensuring objectives are realistic given constraints before starting
  • Starting from Zero: Designing a minimum viable solution based on core processes, iteratively adding complexity only when absolutely necessary
  • Iterating and Stopping: Continuously evaluating impact of additional demands on business goals and ending the project phase when adding complexity yields diminishing returns

are common sense principles, but they must be consciously applied to increase IT project success.

To add some more background, here are two reads on zero-based process design and zero-based thinking:

Unlocking enterprise efficiencies through zero-based design

McKinsey’s view on a zero-based approach to process redesign, adding automation and reorganization to our abovementioned approach.

Click to view!

Zero Based Thinking

Gennaro Cuofano’s short introduction to „Zero Based Thinking“ explains the approach’s general principles.

Click to view!