Each cycle of cyclical project management involves the development of requirements, design, execution, and testing. This implies that many choices must be made over the course of a cycle. If the programme is to accurately represent the client’s desires, the customer must be an active member of the project team.
Customers must communicate their requirements to programmers and designers as plainly as feasible. This often entails weekly (or at the very least biweekly) participation in the project team.
Within a project, consumers contribute to the definition of required features and cycle planning. They cooperate on acceptance tests, approve or reject interim findings, and contribute to the project’s overall direction. Additionally, active customer involvement results in improved results when using the waterfall method.
Within a cycle, the project team must be empowered to make their own decisions. If the project team lacks this authority, the cyclical model of project management will fail to function. If constant approval from superiors is required throughout a cycle, this can result in stagnation. Additionally, outsiders are frequently unaware of what is happening because they are not actively involved in the project team; this makes it difficult for them to make rational decisions.
Cyclic project management is a method of managing projects in which portions of the project are completed in a series of cycles. This is only possible if the software being developed is decomposable into a number of more or less distinct components.
Management’s requirements for project management software are primarily global; management does not impose direct, concrete, or specific requirements. One of the advantages of cyclical project management is the close collaboration between the customer, designers, programmers, and any testers during the cycles. If specific and concrete requirements are established at the start of a project, this limits the project team’s ability to use their best judgement when making design choices. Numerous requirements on a project are revealed to be in need of adaptation during the process and should thus not be (too) firmly established at the start.
If significant technical work that is difficult for the customer to comprehend must occur within a cycle, there is a risk that the customer will be unable to contribute effectively to the team. In such a situation, the customer has very little say in the design decisions that must be made.
A similar risk exists when the customer is unaware of the progress. For instance, much of the work may be devoted to coding, with little attention paid to the user interface. It is critical for customers to have sufficient insight into the substance and progression of a cycle in order to avoid being pushed to the sidelines.
Even in cyclical project management, teams occasionally pursue paths that turn out to be incorrect. It should be possible to take a step backwards in such a case. If a new module created during a cycle is found to be insufficient, it must be possible to resume working with the previous module. This imposes requirements, most notably for the archiving and documentation of project materials. CVS and Subversion are two useful tools for these tasks (see Appendix 3 for a complete list of tools).
Along with programming skills, programmers should be able to interact effectively with customers and vice versa. Team members must be intellectual thinkers. Discipline is required to continue with the job.
The organisation in which the project is conducted must also provide enough support for this mode of operation. Time tracking, archiving, and scheduling systems are required to support the projects. These registration systems provide the essential openness to guarantee an equitable allocation of resources across projects and time periods.
Projects should be given adequate importance, and team members should be made available for them. Requiring team members to work on too many tasks concurrently is ineffective. If an organisation is not adequately adapted to project-based work, the cyclical project management flexibility is likely to result in chaos. Additionally, the waterfall technique benefits from an organised approach to project management (see Wijnen, 2004, p. 111).
The director of a software development firm, who was more visionary than manager, had a great idea almost every month and was constantly initiating new initiatives in his company. As a result, older projects were never completed and workers worked on as many as five projects concurrently. The charismatic director had just finished reading a book on rapid application development (RAD) and was very excited about it – especially the ‘rapid’ element. He taped the fundamental ideas of RAD to the copier and then expected that everyone would begin working with these notions. After all, it was an excellent technique.
Cyclical project management techniques sometimes leave inadequate time to execute required features. Because the duration of the project is fixed, fewer functions will almost certainly be added than initially anticipated.
While this is a legitimate concern, it is also inherent in the waterfall approach. The defining step of the waterfall approach entails an in-depth examination of requirements. This analysis is likely to result in improved time management. This is often not the case in reality, for the reasons stated above.
Additionally, functionalities are omitted in this approach due to a lack of funds to develop them.
Requirements are dealt with pragmatically in cycle approaches. For instance, needs in cycles may be classified using the MoSCoW criteria (Stapleton, 2003) as follows:
Regardless of whether certain capabilities are no longer available, the DANS project managers believe that cyclical work results in higher customer satisfaction than the waterfall approach. In any case, expectations are regularly controlled more effectively, and projects routinely produce outcomes that work, even if they are less complex than initially envisioned.
One commonly cited drawback of XP is that significant power is transferred to programmers. If they abuse this authority, they may exploit the customer’s lack of technical expertise to their advantage. Avoiding this scenario needs a project leader who can look out for both the programmers’ and the customer’s interests. These project leaders help their clients in selecting and planning cycles, in making the technical underpinnings of their selections understandable, and in providing administration and reporting.
Finally, another drawback of XP is that the method’s implementation requires a high learning curve for programmers, managers, and consumers.
We collaborate with ambitious brands and people; we’d love to build something great together.[email protected]