„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.
Zero Based Thinking
Gennaro Cuofano’s short introduction to „Zero Based Thinking“ explains the approach’s general principles.