To apply cyclical project management, a number of conditions must be met:

1. Users/customers are actively involved.
In cyclical project management, the formulation of requirements, design, implementation and testing take place in each cycle. This means that many decisions must be taken in a cycle. If the software is to provide a good reflection of the wishes of the customer, the customer must participate actively in the project team. Customers must present their wishes as clearly as possible to the programmers and designers. This generally involves weekly (or at least bi-weekly) presence in the project team.

Within a project, customers are involved with determining the desired functionalities and the planning of the cycles. They collaborate on the acceptance tests, approve or reject intermediate results and collaborate on the general direction of the project. The active involvement of the customer also leads to better results in the waterfall method.

2. The team is authorised to take decisions.
Within a cycle, the project team must be authorised to do what they think is best. If the project team does not have this power, the cyclical model of project management will not work. If constant authorisation from superiors is necessary during a cycle, this can lead to stagnation. Moreover, outsiders are often poorly informed about what is going on, because they do not actively participate in the project team; this makes it difficult for them to make sensible decisions.

3. Project result (software) can be broken down into smaller parts.
With cyclical project management, parts of the project are performed in a number of cycles. This is possible only if the software that is to be created is divisible into a number of more or less separate components.

4. The requirements that are imposed by management with regard to the software are primarily global; management does not impose direct, concrete or specific requirements. One of the strengths of cyclical project management is that the customer, designers, programmers and any testers work closely together within the cycles. If there are already specific and concrete requirements at the beginning of a project, this impedes the freedom of the project team to use their better judgment to make design choices. Many requirements on a project are revealed during the process to be in need of adaptation and should therefore not be (too) firmly established in the beginning.

5. The activities are intelligible for the customer.
If considerable technical work that is difficult for the customer to understand must take place within a cycle, a risk emerges that the customer will not be in state to participate well in the team. In such a situation, the customer has very little to contribute to the necessary design choices.

A similar risk arises when the progress is not visible to the customer. For example, much of the work may involve coding, with very little being done on the user interface. It is important that customers have sufficient insight into the substance and progress of a cycle in order to ensure that they are not pushed into the background.

6. It should be possible to take a step backwards.
Even in cyclical project management, teams sometimes pursue paths that later prove to have been wrong. In such a case, it should be possible to take a step backwards. If a new module that is created in a cycle proves inadequate, it must be possible to resume working with the old module. This imposes demands, particularly with regard to the archival and documentation of the project materials. Concurrent Versioning System (CVS) and Subversion are two helpful tools for these tasks (see Appendix 3 for a list of tools).

7. In addition to programming, programmers should be able to communicate with customers, and vice versa. Team members must be in state to think conceptually. Discipline is necessary in order to persevere with the work.

8. The organisation in which the project takes place must also offer sufficient support for this method of working. Systems for time reporting, archiving and scheduling are necessary to support the projects. These registration systems ensure the transparency that is necessary to ensure the adequate distribution of resources across projects and time.

9. Projects should have sufficient priority, team members must be released for projects. Requiring team members to work in too many projects at the same time does not work. If an organisation is insufficiently adjusted to working with projects, the flexibility of cyclical project management is likely to lead to chaos. The waterfall method also benefits from an organisation that is arranged for working with projects (see Wijnen, 2004, p. 111).

The director of a software house, who was more of a visionary than he was a manager, had a brilliant idea nearly every month, and he was continually starting new projects in his company. Older projects were consequently never completely finished, and the employees were sometimes working on as many as five projects at once. The charismatic director had once read a book on rapid application development (RAD) and was quite enthusiastic about it particularly about the aspect of rapid. He posted the basic concepts of RAD over the copier and subsequently assumed that everyone would start working according to these concepts. After all, it was a wonderful method.