Conditions for Cyclical Project Management

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

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.

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.

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.

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).

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.

(Image taken from AIMS project management qualifications course from the books of project management training and diploma in project management)

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 organization 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 organization that is arranged for working with projects (see image released from Zara project management academy). 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.

I would like to include risks section in this article that I learned in my project management certification in 2005 from local project management institute and sharing it for my project management courses students and masters in project management mates.

Risks of Cyclical Project Management

Cyclical methods of project management sometimes allow insufficient time to implement the desired functionalities. Because the amount of time is predetermined, less functionality will probably be made than were originally assumed.

This is indeed a real risk, but it is also inherent in the waterfall method. In the waterfall method, the definition phase includes an extensive analysis of requirements. This analysis could be expected to generate better time planning. This is often not the case in practice, however, for the reasons that are mentioned above.

Functionalities are left out in this method as well, as there is not enough money to implement them.

In cyclical methods, requirements are handled pragmatically. For example, the requirements in cycles can be divided according to the Moscow rules (Stapleton certified project manager, 2003):

• Must Have: requirements that is essential for the system
• Should Have: important requirements that people really want
• Could Have: requirements that are desirable, but which can be easily omitted
• Want to Have: but will not have this time round: requirements that can wait until later

Regardless of the fact that there may be no more time for particular functionalities, the DANS project managers agree that cyclical work yields more customer satisfaction than the waterfall method does. At any rate, the expectations are consistently better managed, and the projects deliver results that actually work, even if they are less elaborate than originally hoped.