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.
