Most project managers understand the need to prioritise the list of requirements that end users provide at the beginning of a development project. After all, with today's compressed schedules and personnel shortages, it's unrealistic to promise users that all their requirements will be implemented by the deadline.
But many project managers fail to recognise the need to continuously review the initial prioritisation and perform continuous triage to ensure that the most critical requirements actually get implemented.
The old-fashioned strategy often resulted in an agreement between the development team and users that certain critical functions would be available in the initial version of the system. Additional features would be implemented in subsequent versions to be released at intervals of, say, three months.
But while that agreement may have been negotiated in good faith, it doesn't take into account today's volatile environment. Even if a system is developed in the "Internet-time" schedule of three to six months, there's a good chance that the marketplace may change, the competition may change, government regulations may change, some developers might leave the project or the end user with decision-making authority might be replaced.
And since many of today's projects involve new technologies with which the project team is relatively unfamiliar, we have to acknowledge the possibility that initial estimates of time and effort may be highly inaccurate - thus, the Windows 2000 project that looked like it could be done in two months may turn out to take four because of the learning curve and subtle incompatibilities between Windows 2000 and existing legacy applications.
The solution: perform a triage on the user requirements at the beginning of the project, then repeat the process on a regular basis - at least monthly and perhaps as often as weekly, depending on the pace of the project.
Like doctors working on the battlefield, triage involves dividing the requirements into three categories - beginning with a list of critical features without which the system will "die" - that is, become unusable and be rejected by end users.
The second category consists of those features without which the system will be "wounded" but will survive - that is, the users will be substantially affected by the lack of certain features but will still be willing to use the system. The third category includes bells and whistles - the features that everyone would love to have but wouldn't miss if they weren't available.
Failing to perform an ongoing triage tends to create a project that denies reality: everyone pretends that the initial list of requirements will be implemented on time, even though developers, end users and the project manager privately believe that the chance of success is diminishing daily.
This often results in an ugly crisis a few days before the official deadline, when the project manager has to confess that the system - as originally defined - won't actually be finished after all.
Assuming that the deadline can't be slipped, and assuming that it's too late to effectively add more people to the development team, the only solution is to reduce the number of features that will be delivered to the user - in other words, to perform triage.
But doing so at the end of the project is stressful and politically unpleasant. It's also wasteful, because many of the features that are scrapped turn out to be features that were already partially completed.