In this article we'll look at different methodologies, how to combine them if required, and additional activities that are required to deliver successful projects.

Selecting the correct methodology and enhancing it as required is critical. Be wary of 'purists' that believe a particular approach is right for all projects. This is not the case.

Let's start by looking at the history of the different methodologies.

Waterfall

The first significant IT methodology was Waterfall.

The name of this methodology comes from the sequential nature of the phases. Winston W. Royce created the methodology in 1970, and he explained that it was like water flowing from one rock to another: each phase is completed in sequence before the next one starts.

Mr Royce was aware of the potential risks with the sequential approach. He included prototyping in his original document, but unfortunately most people didn’t read that far and missed this critical point.

Waterfall has been in continuous use since 1970, and over half of all IT projects in 2022 used this methodology.

Joint Application Design

Joint Application Design (JAD) was created by IBM® in the late 1970s. The results of using JAD were positive, with projects reporting reduced development timescales and a higher level of stakeholder satisfaction.

One of the key principles of JAD is client involvement throughout the complete project lifecycle, from analysing requirements to developing the application and testing.

Rapid Application Development – 1991

James Martin, working at IBM, published the Rapid Application Development (RAD) approach in 1991. RAD uses rapid prototyping to assist in developing innovative solutions to enhance business processes.

RAD is an Agile framework that favours fast feedback over long planning, development and testing cycles.

DSDM – 1994

DSDM was created in 1994 in response to the need for enhanced governance on RAD (Rapid Application Development) projects. It is an Agile framework that pre-dates the Agile Manifesto and is strong on alignment of iterative development with strategic goals.

The DSDM framework has robust project management and governance and includes additional roles to support this. Also, stakeholders are involved in the development process.

Agile Manifesto - 2001

The Agile Manifesto was created in 2001.

The four principles of agile development are:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.

3. Customer collaboration over contract negotiation.

4. Responding to change over following a plan.

Manifesto for Agile Software Development (agilemanifesto.org)

There’s an important point to discuss about Agile. Many people misinterpret the principles, and this can have serious implications for projects. They mistakenly assume that the items on the right are not important (or don’t apply at all) on an Agile project, but this isn’t correct.

The principles in the Agile Manifesto mean that the items on the left have a higher priority, but it does not mean that the items on the right are not included or significant. They are important, and the degree of importance depends on:

• The complexity of the project.
• The type of project. (Does it include new infrastructure, dependencies with other teams and complex data mapping?)
• Scope of delivery.
• Number of people on the project and number of teams.
• The type of project.

All the methodologies included above can be used to deliver successful projects. Many people believe you have to choose a single methodology and use it exclusively. However, in the real world many companies are using both. They select the best methodology for the type of project they are delivering.

Another common scenario is combining the best from each methodology. This is especially true on major programmes with substantial development and infrastructure builds. For example, replacing a legacy ERP system with Software as a Solution (SaaS). Some parts of these programmes are a natural fit for Agile, and some require the discrete test phases of Waterfall.

Some Agile frameworks are suitable for infrastructure programmes, but many organisations prefer to use Waterfall for the infrastructure build and Agile for the development. This is one of the strengths of the methodologies: that they can be used concurrently on a programme.

Another consideration is the transition to methodologies. Agile has been around for over two decades, but some organisations have not used it. Don’t underestimate the learning curve for an organisation that has never used Agile. Many of them are reluctant to change the practices and methodologies that they have used to deliver projects successfully over a long period of time.

It isn’t uncommon to see companies using their own type of Waterfall or Agile. This can work well, but it’s critical that everyone is using the methodology consistently.

What really counts is delivering the highest quality product possible on time and to budget. Whether you are using Agile or Waterfall, it’s essential that you understand the requirements, write quality code that can be maintained, test thoroughly, plan and prove the cutover, train the users, work with the support team to provide the information they require and support the users during the warranty period.