A common concern, and one that I share, is that a sensible product development process will become bogged down in useless detail or busy work. To prevent this, I've found it helpful to augment the development process described with a few key concepts and processes.
In the early stages of development I give the responsible team maximum flexibility in managing their work products. However, when the time comes for others to make committed decisions on these products, they must be frozen. As a result, the concept of successively freezing various deliverables becomes important. In this approach, various deliverables become frozen over the product lifecycle.
While product managers may examine a wide variety of markets for a proposed idea in the concept phase, they must usually narrow this down to a specific target market in the business plan. For this release, then, the target market is frozen. It may then be further stratified into niche markets, with the focus one niche as the target for the launch activities.
On the development side, you may choose to freeze the requirements, then the user interface, then the database schema, then the APIs that exist among subsystems, and finally the code itself. Note that freezing is not designed to prevent change. Instead, the term "frozen" describes a decision that can only change through a relatively formal change-control process, described next .
Change Management Protocols
Change protocols refer to the degree of formality associated with changing a given outcome. The most lenient change protocol is none. An example of this is when a developer is free to check out source code, make changes to it, and check it back in to the source management system. A formal change management protocol exists when a proposed change must be approved by a committee.
I've found that many developers become uncomfortable with change management protocols. This is because they often misunderstand their fundamental purpose. The goal is not to stifle creativity (as expressed in desired changes to the product) but to ensure that the right people are informed of the change before it is made so that they can properly prepare for it.
Suppose you want to change the layout of the user interface. Before it is frozen, you're free to change it as you see fit. Once frozen, changes need to be managed, if for no other reason than that you have to coordinate changes to the help system, the end user documentation, and the training materials. There might also be changes required in the automated unit tests created by QA and perhaps in updated reference materials for technical support. That's several different groups that must be notified of a potentially simple change.
More generally , the change management process must include those stakeholders affected by the change to make certain that they understand, approve, and can correctly process it. Candidates include technical publications , QA, product management, technical support, and release engineering. In product-centric organizations, change management meetings should be organized and chaired by product management. In other organizations, they should be organized and chaired by the project or program manager running the overall project.
At several points during the project the team may find that they've bitten off more than they can chew. Rather than throw out potentially useful ideas, I recommend creating a recycle bin where they can be stored for future use. A given idea may resurface in a later release or in a future iteration. In a sense, the recycle bin also functions as a pressure valve, reducing (at times) the pressure felt by the development team to get every requested feature into the release.