Which Project Implementation Methodology is ‘right’ for me?

Authored by Jamie Smith

It’s December, the nights are drawing in, the car needs de-frosting and you’ve found yourself in a position where you have to decide which project implementation methodology to utilise for a software development project. Agile or Waterfall? You may have a personal preference already, not really be sure or you may even not be involved in projects at all. Either way, I invite you to read on.

In software development, one of the first decisions between customer and supplier is, typically, which project implementation methodology to utilise (you may even search the web and read a well put-together blog to help you in this decision). In essence, in the United Kingdom at least, this routinely is a decision between a Waterfall approach versus an Agile approach. Neither is perfect, although each may have its own strengths and weaknesses depending on project requirements, resources and so on. The choice, however, is ultimately the decision of the customer as project sponsors i.e. the ones who are paying for it!

Waterfall Methodology

When applied to software development, the Waterfall approach is a linear, ‘downward-flowing’ stage model that requires extensive upfront design.

The general stages involved in the software development life cycle only begin once the previous one has concluded (waterfall) and are customarily:

  • Requirements gathering;
  • Design;
  • Coding;
  • Unit testing;
  • System testing;
  • User acceptance testing (UAT);
  • Bug/Issue resolution; and
  • Delivery.

It is commonplace in this approach to have stage gates before each subsequent stage i.e. a checkpoint involving a review of certain criteria that must be met before progression onto the next stage.

With such a rich rigid structure, the initial design may be more straightforward when compared to other approaches as the deliverables are agreed upon at project inception between the customer and supplier before any work proceeds. This, by proxy, means progress is easily measured as the full scope and deliverables are known in advance and can be evaluated at each ensuing stage gate.

The rigid structure also allows for, depending on the active phase of the project, various members of the team involved to continue with other work throughout software development. For example, the testing team can have testing scripts prepared whilst the coding phase is underway which is an efficient use of time.

In addition, the customer in a Waterfall approach may not necessarily need to know within great depth the technicalities of the delivery approach as they only need to be present at reviews/stage gate status/approval meetings etc. This allows the project to not be reliant on a strong customer presence, which is sometimes a good thing.

A focused design stage that is completed early in the software development lifecycle also allows for a more complete understanding of all of the expected deliverables.

What may have become apparent from the precluding paragraphs is that the Waterfall approach is heavily reliant on the initial requirements gathering. An ineffective requirement gathering stage that is not in line with the customers’ expectations will result in a heavy financial and temporal investment into a piece of software that, ultimately will not be fit for its purpose.

Poor requirements definition typically results from one of two main failings; insufficient investment upfront by the customer in defining in writing exactly what is desired from the new piece of software; or insufficient knowledge of the current business processes and data flows.

There is little room for manoeuvre in a Waterfall project, and while change control procedures enable functional and non-functional aspects of the project to be modified to some extent, these usually attract the penalty of on-cost and delay and there is always the possibility that the customer will be dissatisfied with the software that is ultimately delivered. More often than not, the majority of end users only really get to experience the new software late on in the project.  One of the most common catalysts for project failure is a lack of enthusiasm and engagement by end-users during acceptance testing as they start to realise that the new product/ service does not meet their expectations despite seemingly having past muster during requirements mapping and the early stages of testing.

It is this late visibility and subsequent lack of manoeuvrability which are key foundations behind the genesis of the Agile methodology.

Agile Methodology

To combat the shortcomings in the Waterfall methodology, the Agile approach is an iterative design, develop and delivery process. Rather than trying to identify all the tasks necessary to deliver the complete system to an agreed schedule, tasks are prioritised and then designed, developed, delivered and tested. Time is strictly managed in “sprints” typically just 2-4 weeks in length focusing entirely on the prioritised deliverables.

This approach to software delivery emphasizes the delivery of wholly complete functional components promptly with stakeholder engagement throughout the process and reviews from the customer at the end of each sprint or evaluation of each periodic build.

This approach obviously requires much more customer involvement throughout the project rather than just at the beginning (when creating the business requirements) and at the end (when engaging in user acceptance testing). This increased involvement delivers key functionality much earlier and allows for changes to requirements or a refocusing of priorities as the project progresses typically at a much lower cost both temporally and financially.

The heavy focus on the customer during development also helps to create a strong sense of ‘ownership’ increasing morale and confidence in the project at both ‘boots on the ground’ and board level.

An ability to reprioritise during development is useful when there are strict deadlines in place for a piece of software to be operational, with an Agile approach a ‘basic’ version or ‘minimum viable product’ (“MVP”) that operates core functionality can be realised in time for the deadline whilst the ‘bells and whistles’ can be built onto the software in later iterations if budget and time permit and if the project’s sponsors allow.

Whilst the Agile methodology does address some of the drawbacks associated with a Waterfall methodology, Agile does have limitations of its own. The most obvious are:

  1. The heavy reliance on customer involvement throughout the project;
  2. The lack of an upfront defined scope, timescale and cost which large corporations and central government contracts cannot sometimes handle; and

iii. Difficulties in measuring progress against identifiable milestones.

The need to continue the day to day operation of a business may mean the customer cannot commit enough time to an Agile project methodology and it is not difficult to envisage a scenario where a customer simply does not have the interest in software development at a low-level and is just focussed on the end product.

Frequent re-prioritisation may also lead to certain, less essential areas of the software not being completed within the project timeline. Particularly, for example, if the items find themselves low on the MoSCoW rating (Must have, Should have, Could have, Would like) or a number of issues are faced during development of core components thus consuming excess time and budget.

As a collaborative approach, Agile is typically more suited and is more likely to be successful if both customer and supplier are physically located within the same area. Of course, discussion can and will take place on the telephone or via email but physical participation in scrums, workshops, and project meetings always produce better results.

The ‘right’ methodology

Trouble deciding? The correct project methodology to use is entirely circumstantial, dependent on various factors associated with all parties involved and the structure of the business(es).

The pros and cons associated with both Agile and Waterfall listed above go a long way towards deciding which project methodology to adopt. For example, a project with a broad scope would be better suited to Agile likewise with a project with a high degree of unpredictability in the final scope – Agile would afford the flexibility to deliver a suitable product and also improve the time to market of an operational piece of software.

Conversely, a project for a customer for whom the diversion of resource away from the ‘day job’ for extended periods presented problems would be more suited to a Waterfall approach.

There are other commercial factors that may also sway the decision on the best-suited project methodology. Note: there is no correct methodology for any project as each has its own associated benefits and downfalls, however, an individual project may be better suited to being managed in a particular way (Agile/Waterfall).

As Agile is a relatively abstract approach in comparison to how many large corporates and government departments are typically run, a board of directors or government officials may not initially be receptive to a project being managed via an Agile methodology. This may become a constraint on the decision process forcing a Waterfall approach, although successful projects are typically run with mutual respect between customer and supplier and the supplier, typically the technical expert of the two should be able to advise on the best-suited approach.

Similarly, a supplier may be more familiar with one methodology and have limited experience of the other again forcing a constraint on a project being managed in a particular fashion.

Both Waterfall and Agile are well-established, long-standing methodologies. Both are capable of delivering a successful project and both are recognised as offering industry best practice processes for software delivery. When making the final decision on which approach to follow relax, be pragmatic, and be safe in the knowledge that the approach that can deliver the product in a timely manner and as close to being within budget as possible is the correct approach.