Cyclical methods of project management

Because of the issues that have been sketched above, a number of other methods of project management have emerged in recent years. These methods are particularly suited for IT-development projects. Examples of these relatively new streams within project management include DSDM, RUP, eXtreme Programming (XP), RAD and agile project management (McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton, 2002, [ii], [iii])

Although the above-mentioned methods of project management differ according to a number of aspects, they are essentially the same. Because the path toward the final goal of IT projects has proved so uncertain, these methods assume that the goal will be achieved in a number of short cycles. This is the background for the term cyclical project management for these methods.

1. Planning cycle; 2. Investigation of requirements; 3. Design; 4. Implementation; 5. Testing; 6. Evaluation and possible usage

Figure 5: the activities in a cycle

In cyclical project management, the project goal is pursued in several short, successive consecutive cycles. Each cycle is relatively short, preferably lasting less than one month. Within each cycle, a portion of the project is carried out. Analysis, design, implementation and testing occur within each cycle. This is fundamentally different from the waterfall method, in which these activities all take place within their own separate phases. In addition, the waterfall method prescribes only single moments for definition, design, implementation and testing. In the cyclical method, this occurs many times in sequence.

Various components of the software are implemented during the cycles, which are therefore independent of each other. Evaluation takes place after each cycle is completed. Should advancing insight lead to new of different requirements for the project, the activities of the subsequent cycles are adapted to take them into account.

A cycle begins with the making or adjusting of the schedule. Next, the requirements of the result of the cycle are examined. A design is made, programmed and tested. Evaluation subsequently occurs and, in some methods, the new software is brought into use. Thereafter, the following cycle can begin, in order to carry out the following component of the project. (For a more extensive description of cyclical methods and the differences between the methods, see e.g. Kroll, 2004; Chromatic, 2003; Stapleton 2002.)

The most important advantages of working with the cyclical method are as follows:

  • Higher product quality and improved implementation of functionalities,
  • More realistic estimates of time and money,
  • Project team is under less pressure,
  • Higher quality.

The previous chapters have shown that it is difficult or impossible to determine of the desired functionalities accurately in the early stages of a project. In cyclical methods, the desired functionalities are implemented in several short cycles. In each cycle, a small portion of the desired functionality is not only investigated; it is designed, implemented and tested as well. The short succession of design, implementation and testing makes a particularly important contribution to quality improvement. Teams are thereby in state to make adjustments. If a design does not turn out to be good in practice, it becomes obvious during the cycle, thereby allowing adjustment. This way of working also allows customers to request adjustments

Another reason that cyclical project management leads to better quality is that a cycle involves intensive collaboration between customer, designers and programmers. A multi-disciplinary team jointly conceives of and implements solutions. In the waterfall method, the customer is involved primarily in the beginning, in the formulation of the requirements; thereafter, the designers make a design and then the programmers programme the software. The project leader serves as the link between all of the various parties and must ensure that information that is exchanged is delivered to the right place. In practice, many programmers and designers never see the customer, who re-emerges in the process only after the software has been completed.

Cyclical methods of project management are particularly suited to projects in which the goal that is to be achieved cannot be clearly established beforehand, as in creative projects or research projects. Working in a number of cycles with a multi-disciplinary team in which the end-users are also represented allows the team to discover the real goal of the project and how it can best be achieved. Each cycle contains a point for reflection and an opportunity for adjustment.

In waterfall projects, a goal is formulated beforehand. Reflection on the original goal is less of a possibility. The originally formulated goal is never (fully) achieved, and it is likely that neither the originally formulated goal nor the goal that is achieved is exactly what was originally desired.

Figure 10: Better results are achieved by working in cycles. (Illustration: Rachèl Harmsen)

The last reason why cyclical project techniques generate better results is that the customer performs acceptance tests. Quality is further strengthened by using tests as criteria for well-performing functionality from the very beginning. Programmers must therefore define failing tests (or unit tests) before they write their code. The code is considered acceptable only if it passes the failing test.

Test-oriented work requires programmers to prove that there are no bugs in the new code before they write new code. They do this by developing a test (failing test) that would detect any possible bugs before they begin coding. For example, imagine that a programme must be written for calculating the correct amount of change that you must receive from a candy machine. First, the availability of a function to give change must be tested. This function could be called give_change. A simple test could be made and, when it is performed, it is determined that a give_change function does not yet exist. If the programmer then makes the function but does not yet give it any substance, the test will succeed.

The next step would be to test whether the machine gives the right amount of money back when an item is purchased. Insert sixty cents into the machine and buy an item that costs fifty cents. The test will not succeed, because the function is still empty. The programmer then writes the code. In the give_change function, he writes that the amount of change to be returned is the amount of money that was inserted in the machine, less the price of the chosen candy. The test should now succeed. The process continues in this way; for each component of the software, a test must be devised beforehand (example translated and adapted from Chromatic, 2003, p. 27 ff).
The code is not the only component that must be technically tested; the functionalities must also be tested (i.e. acceptance tests). For these tests, the customer determines the conditions under which the functionalities that are to be built can be accepted, before coding begins (e.g. how quickly a computer must respond to a certain action of a user). The prior specification of the conditions under which the new functionality can be accepted has proven particularly difficult and time-consuming. Nonetheless, the active role of customers in testing is an important determinant in the success of a project.

More realistic estimation of time and money
With cyclical project techniques, the functionalities that are to be implemented are not written in stone at the beginning of the project. The available time is specified. Agreements are made concerning the direction in which the project will proceed, and it is determined in the process what is actually needed, useful and realistic with regard to the software that is to be made. In cyclical projects, the functionalities that are to be implemented are not established as fixed goals, and they thus avoid the risk that the necessary hours, and therefore money, can get entirely out of hand. To prevent such a situation, the available time is used as a starting point, and it is determined during the process what is realistic to expect in that amount of time. Also for this reason, cyclical methods of project management are much friendlier for the project team. The team does what it can do within the specified time, but is not pressured to meet unrealistic schedules or to work within an inadequate budget.

Cyclical methods also facilitate the management of external suppliers. With the waterfall method, a project can become bound to a single supplier until the end of the project, regardless of the performance of that supplier. In the cyclical working method, is theoretically possible to make new agreements for each cycle or even for each component to be delivered and, if necessary, to change suppliers.