According to The Project Management Institute (PMI, 2004:8), Traditional project management (TPM) is ‘the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.’ In this case project management is therefore, given as a complete cycle involving the completion of the following phases: initiating, planning, executing, controlling, and closing under the guidance of the project team. PMI (2004) further stresses that TPM work is concerned with fulfilling the demands for scope, time, cost, risk, and quality within the framework of predetermined stakeholder requirements. Traditional Project Management is thus characterised by well-organised and premeditated planning and control methods that sometimes result in distinct stages of the project life cycle (Hass, 2007; Thomsett, 2002). The increased need to bring formality into project management (Cadle and Yeates, 2008) and control large development projects (Fitsilis, 2008) resulted in the emergence of TPM’s distinguishing characteristic of making sure that tasks for the whole project are carried out in this predetermined orderly sequence (Weinstein, 2009; Hass, 2007; Chin, 2004). Although this was seen as a solution on one hand (Cadle and Yeates, 2008), its ‘on the shelf approach’ (Alleman, 2005) was seen as major failure in the face of a dynamic project management environment (Leybourne, 2009; Cicmil et al, 2006).

TPM is also centred on the premise that circumstances surrounding project events are foreseeable and the tools used to handle them are also predictable, however, past experiences and literature (Hällgren and Wilson, 2008; Hass, 2007; Aguanno, 2004; Yusuf et al, 1999) show that this is not always the case due to unanticipated occurrences that can interfere with  those plans. Under such dynamic conditions iterations are always important to cater for the changing environment (Fernandez and Fernandez, 2009). However, scholarly evidence (Chin, 2004) show that iterations are not part of TPM (i.e. once a phase is completed it is assumed that there is no need to reconsider it again). This seems to be in agreement and slight contradiction to Cadle and Yeates (2008) as well as Collyer and Warren (2009) who argue that there is degree of iteration of work and products within a stage but very little between the stages due to the high levels of planning and process control involved. The point here is that although TPM has some iterations they are mainly confined to the stages and hence there is very little benefit to the system as a whole. This approach to project management is widely regarded as stemming from the Waterfall Model (McConnell, 1996; Hass, 2007). This Waterfall Model is illustrated in Figure 2.1 below.

The waterfall model is such that work is broken down into stages or sections that should be completed before moving to the next one. It can be seen from Figure 2.1 that the waterfall model is synonymous with the TPM approach because it emphasises on viewing each project stage as a stand-alone activity whose completion has a bearing on how and when subsequent stages are commenced (Cadle and Yeates, 2008; Thomsett, 2002). This suits very well the TPM approach if one considers the use of network diagrams, Gantt chart and its emphasis on milestones. The merits that are put forward for the waterfall model include its simplicity and ease of scheduling in laying out steps for development (Hass, 2007). In addition the waterfall model is adored for its ability to improve quality management through its verification and validation processes (Cadle and Yeates, 2008). It is some these merits that have enabled the waterfall model to become the mainstay of project management. In contrast, Thomsett (2002:137) argues that the waterfall model is “poorly suited to the chaotic and client-driven business environment of the 21st century” because of its tendency to be rigid. This is further supported by Hass (2007)’s assertion that there is need to adhere to specific requirements when using the waterfall model, however, this falls short because reality shows that projects are not sequential in nature (Collyer and Warren, 2009) and most importantly, in most cases, customers are not able to state all the project requirements during the initial phases of the project life cycle (Cicmil et al, 2006).

Another disadvantage of TPM noted by Aguanno (2004) is that any design changes adopted during the testing and development phases of a project have the potential to cause chaos because of the waterfall model’s requirement to complete the preceding tasks first. This may lead to project failure on the basis of time delay and quality, which are the essence of a consulting firm’s continuous ability to attract clients; hence there is a need for methods that can handle this chaos. Furthermore according to PMI (2004), Eden et al (2005) as well as Cui and Olsson (2009) late project changes in TPM are more expensive and have minimal beneficial effect on the resulting project delivery. This demerit of relying on TPM and the changes associated with it is clearly illustrated by the graphical representation suggested by Boehm (1981) and cited by Aguanno (2004), reproduced in Figure 2.2 below. The skyrocketing of cost of changes with time is not desirable with consulting firms because they normally operate on tight budgets and potentially demanding clients (Nelson and Economy, 2008:324-335). This evidence, therefore, compels project managers in consulting firms to look elsewhere for solutions.

Conversely, one cannot easily dismiss the waterfall model because it has its own unique advantages that make some scholars to strongly argue for its use. For example, Bechtold (1999) postulate that the waterfall methodology is highly effective for projects that are wellunderstood and characterised by short time spans as well as fixed requirements.

In recognition of the above-mentioned setbacks, scholars proposed various improvements on the traditional waterfall model (Cantor, 1998). These improvements aimed at reducing the weaknesses of the traditional waterfall model, among other things include the introduction of; overlapping phases (sashimi), subprojects and risk reduction within the model (McConnell, 1996). In particular Birrel and Ould’s ‘b’ model was introduced to address the maintenance issue, the ‘v’ model was developed to show correspondence between the different stages in the project (i.e. addressing the issue of quality assurance) and the incremental (phase delivery) model was created for managing testing and delivery (Cadle and Yeates, 2008). Closely related to the waterfall is the spiral model which was developed to incorporate an evolutionary or iterative approach to project management (Collyer and Warren, 2009).

All these variants of the waterfall model and the spiral model seem to address a number of issues in project management but they are found wanting in one way or another when faced with uncertainties (Cicmil et al, 2006). The spiral model shown in figure 2.3 offers more promise in unpredictable environments and is the one more closely related to APM because it caters for objective setting, risk management and planning (Cadle and Yeates, 2008). Its evolutionary or iterative approach to project management suits well projects with uncertain requirements it follows experimental cycles from objective setting, alternative and constraint determination to the final stage where the next iteration is planned. According to Cadle and Yeates (2008) the spiral model modifies the waterfall model by catering for objective setting, planning and risk management within the cycle.