What is steering the choice of methodology behind the design and development of digital systems? Waterfall vs agile; your call

‘Flexible’ and ‘agile’ have been buzzwords in recent years when the conversation has turned to methodology for the design and development of digital systems. In somewhat simplistic terms, flexible methods revolve around the ability to adjust one’s course and priorities based on what offers the most immediate value. This methodology is often juxtaposed against conventional ‘waterfall’ methodology; a phased approach with an emphasis on thorough planning ahead of development. Your fear as a client is of course that you feel you are paying the same amount, but getting less.

However, we would claim that major projects actually depend on flexible development in order to succeed. In terms of both finance and quality. As a general rule, what you thought at the time you hired a procurement consultant to assess what you needed will undoubtedly have changed by the time the project is delivered. Knowit’s perspective on major projects is often that a more continuous process where the design is developed in exchanges between the designer’s proposed solution and the customer’s requirements and criteria offers better and more relevant solutions. The aim of flexible projects is to reduce losses.

The benefits are that one can launch in the market more quickly and learn and adjust along the way based on the recognition that what was thought last year will not necessarily be as smart this year. This is becoming more and more relevant when we see how quickly digitalisation is changing society. Businesses are changing, but most importantly of all, customer preferences are changing continually, and the scale is generally global.

How can one choose the right bidder without using the waterfall methodology?
People spend a lot of time producing estimates in order to present an accurate picture of costs, and projects are often chosen based on the price offered by a bidder. Simply because they want to keep their future costs under control of course. The norm today is far too often for enormous resources to be spent on designing, estimating and developing requirements which are ultimately revised or rejected following testing. We do not believe that committing oneself or the other party to a fixed estimate for a major project can always be expected to be a success factor. We would claim that this does not always lead to control, but an illusion of control.

The waterfall method originates from classic engineering projects. Digitalisation projects differ in terms of their nature from conventional IT projects and require different approaches compared with conventional IT thinking. You will be able to get more out of your development budget if you reallocate your resources in order to capitalise on the inevitable changes that will occur during the project.

Why should you get out of the waterfall?
As a client, you have to be involved, because if you are not, you will not get out of the waterfall. In conventional IT projects, change is difficult. Clear drawings are prepared of everything that is to be produced and everything is planned down to the tiniest detail before the first sod is cut. The end is defined before the start. To ensure the success of digitalisation projects, a flexible approach is required from both sides of the table once a project reaches a certain size.

Requirements change with both time and experience
The requirements that an organisation adopted at the beginning are not necessarily those that are wanted at the end. These are generally established based on the experience that had been gained at the time. New systems, portals, user interfaces and other digital interfaces give new experience, which in turn lead to the creation of new ideas. A project is complete when no one uses it anymore. Not before, but ‘finished’ is still generally defined as being when the product has been delivered. We think that a development project must be worked on until it is no longer used. In other words, there is always more to do.

Little strokes fell great oaks
Flexible working methodology starts with a vision of a bigger goal before small “packages” of development are put together which have a better chance of succeeding. There are fewer things to go wrong and one can maintain control when it does. Fewer tasks are completed and then tested before moving on to the next task. Do you need an online store or are you actually looking to increase your turnover? Even if the vision is the management tool, we know from experience that it can change while the project is under way. If a project is to be a success, it must meet the actual need; the many small tasks must be allowed to follow their natural course, not where we decided they should go when we started planning.

Six takeaways
1. The waterfall requires us to actually predict the future; something we cannot always do.
2. A project is never finished until the website is switched off.
3. Estimation gives an illusion of control, because it is difficult to predict the future accurately.
4. The entire organisation must be flexible. From the client to those who do the work and performs the tests.
5. Without continual deliveries, it is not possible to be flexible.
6. Flexible deliveries depend on transparency and mutual trust.