While the term “iterative design” and “agile methodology” are often used interchangeably, they fundamentally mean different things. In this article, I will define what iterative design is and debunk some common myths surrounding it. Finally, I will demonstrate how the principle of iterative design can be applied to a waterfall approach, using an ERP implementation as an example.
By understanding the principles of iterative design and applying it to digital transformations, companies can increase their levels of user adoption, solution effectiveness, and continuous improvement in their organization.
Table of Contents
What Is Iterative Design – And What It’s Not
Iterative design is a methodology used to design solutions in multiple cycles that include design, build, test, and refine activities. This methodology can be used in various types of solution design including software design, business process design, and system configuration (design).
Iterative design is frequently and mistakenly referred to as an Agile methodology. While agile uses iterative design, the agile methodology is a holistic approach to managing projects which includes iterative design along with other practices. Iterative design is a design approach which values feedback, flexibility, and continuous improvement (like agile) but can be used in many different methodologies (including waterfall).
Another common misconception is that iterative design is building a solution, getting feedback, and refining the solution without spending any time gathering requirements. In reality, iterative design focuses on gathering requirements and designing in iterative cycles. These iterative cycles often include solution development and testing as a means of effectively gaining feedback.
Why Use Iterative Design
People often assume that it’s best to complete a design in as few iterative cycles as possible. The truth is, there are many benefits to using multiple iterative design cycles when designing complex solutions beyond simply arriving at a good solution. Here are a few examples of why this is the case:
Most users don’t immediately know what they need in a solution.
Whether we are working on optimizing business processes or designing a brand-new software solution, most users that are asked to provide requirements and ideas struggle to provide all the requirements up front. Often, a lot of the requirements that are provided are based on what the user knows (generally a legacy process or system) and not on what is truly needed.
Using multiple cycles of iterative design enables users to begin seeing future possibilities as well as gaps in what they’ve communicated. While an experienced business analyst and/or solution architect may be able to get closer to the right solution the first time by reading between the lines, it usually takes at least three iterations for users to fully understand the new solution and see the potential gaps in communication.
Iteratively designing and building a solution allows users to get used to incremental changes.
Change is difficult for everybody and changing how you do your job (especially if it’s one you’ve done for 10+ years) is particularly hard. Even if a process or system has been very inefficient, it’s hard to imagine being successful with anything significantly different.
By using iterative cycles of incremental changes, users are better able to adapt to the changes and buy in to the solution. Even if the end solution is significantly different, contributing to the design process through incremental changes helps users feel a sense of ownership of the new solution.
It’s commonly said that it takes communicating something 7 times for it to really sink in. While you don’t necessarily want to plan on 7 iterations of design, it does take at least 3 iterations for the design to start sinking in for users and frequently 4 or 5 before they truly feel comfortable with it. This is why it’s common to get new requirements at the end of a project – the users are finally understanding what’s being proposed and are seeing the gaps of things they didn’t think to communicate earlier.
Designing smaller pieces and iterating over them allows for quicker, visible progress.
One of the reasons many people have tried to move away from the waterfall methodology is because of the challenge of waiting until the analysis and design activities were fully completed before any “visible” progress was made. It is a very rare skill to be able to hear requirements and a design approach and be able to visualize how a solution will function.
By using an iterative design approach, small pieces of the solution can be designed and built quickly so there is a visible solution for users to “get their hands on”. Taking that iterative approach and slowly combining the smaller pieces into larger sections of the solutions may require some rework, but it allows for the feedback cycles to begin much earlier than at the completion of a full solution, which leads to more efficient solution design in the long run.
Applying Iterative Design to an ERP Implementation
Generally, ERP implementations are conducted using a waterfall approach by first analyzing the needs, designing the processes and system, building the solution, and testing the final solution before releasing it to the company. Given the nature of ERP systems and the inability to implement just small portions of it (or change key settings after using it), it’s often not feasible to follow a purely agile methodology. However, you can utilize iterative design within a waterfall methodology to gain a lot of the agile benefits.
We recommend taking a business process centric approach to ERP solution design. By separating requirements and functionality into categories of processes, you can focus on smaller sections in your initial iterations.
For example, your business may have processes that fit within the Procure to Pay, Quote to Cash, Plan to Inventory, and Financial Plan to Report process categories. Within Procure to Pay, you will have process groups like Manage Vendors, Manage Purchase Orders, Manage Vendor Invoice, and Pay Vendors.
Transformation is not easy, but it doesn’t have to be impossible. Take control of your project’s success today and schedule a free 30-minute consultation to find out how Victoria Fide can equip you for transformational success.
We recommend starting with the smaller group of processes like Manage Vendors, going through a few iterative design cycles and then combining it with the larger category of Procure to Pay and doing another couple of iterative design cycles before combining all your categories together and finalizing your design.
The iterative design cycles may look something like this:
- Discuss the Manage Vendors processes, document requirements, and build recommended to-be processes.
- Configure the ERP system to support the documented requirements and to-be processes and then walk through those Manage Vendor processes within the ERP system along with some users. Document the feedback and update requirements, processes, and ERP system configurations.
- Walk through the Manage Vendor processes a second time with a focus on exception processes in an effort to gather more requirements that may not be top of mind to the users. Document the feedback and update requirements, processes, and ERP system configurations.
- After going through cycles 1-3 with the other process groups within Procure to Pay, walk through the full end-to-end Procure to Pay processes with the users. Determine where there are gaps when combining the processes and document the feedback – including updating requirements, processes, and the ERP system configurations.
- Do a second walkthrough of the combined Procure to Pay processes. At this point you’re hopefully only finding small things to change that are not significantly altering the solution design.
- Finally, do a walkthrough of all the combined process categories. Generally, this looks like a business simulation where you take a business scenario (like selling a standard product) and walk it from beginning to end throughout the entire business until the final financial steps have been completed.
We generally recommend covering multiple key business scenarios as part of cycle 6 so you can be sure the processes work across all your critical scenarios.
Once you’ve completed cycle 6, you are usually ready to move out of the iterative design cycles and into final testing, training, and go-live.
After go-live, there may be other phases of implementing additional functionality. These can be considered larger, overarching cycles of your iterative design approach. As you iterate over your roadmap, you will find that you begin to move into a continuous improvement approach which is the ultimate application of iterative design.
Achieving Success with Iterative Design
When applied well, iterative design is a key component of achieving success in digital transformations, even when using a traditional waterfall methodology.
By adopting this iterative approach, your final solution is sure to accomplish your business goals, empower your users to own the solution, and provide a foundation for continuous improvement as your business grows.
As you seek to equip your company for a successful digital transformation, consider leveraging our expertise to guide your implementation process. Explore our range of services tailored to enhance your projects or browse our premium digital transformation templates and workshops. For further assistance, feel free to contact us to discuss how we can help you achieve your business objectives efficiently.
About the Author
Adele Graser is the Chief Operating Officer of Victoria Fide Consulting. For more than 13 years she has worked to help companies implement complex solutions and make significant, disruptive business process changes. One of Adele’s greatest passions is to enable people and organizations to realize their full potential. Her approach with consulting is to not only help design solutions that follow generally accepted best practices, but to also help team members understand and take ownership of those solutions. She has a great mix of visionary, detail oriented, and communication strengths that allow her to see the big picture, translate that into a tactical plan, and communicate the vision to many different levels of an organization.