- Project Initiation
- Wild Enthusiasm
- Search for the Guilty
- Punishment of the Innocent
- Promotion of Non-Participants
- Definition of Requirements
I have witnessed this exact series of steps acted out in grueling detail at a number of organizations. My personal favorite is the punch line of finally defining requirements.
What really makes you think is that it is believed that defining requirements is too time consuming. I have even heard “Why should we define requirements? They’re just going to change and we’ll have to update all of the docs!”
For me, software development is largely risk management. Not having requirements against which development and testing occurs is a significant risk. Most immature organizations are able to survive due to the presence of a hero which characterizes them as CMM level 1. This hero has enough knowledge of the desired end result that she effectively embodies the requirements. If this hero leaves or if there is an attempt to scale up development beyond the means of the hero, all begins to disintegrate. Identifying the risk associated with requirements and properly understanding its impact is paramount to a successful project.