Requirements Control is a key to effective project risk management.

Assuming the project plan is sound (executable), one of the most important activities to control throughout the duration of the project life cycle is “change management”.  Sometimes a change to project or product requirements cannot be avoided, especially when issues arise and the project has to be re-planned or re-baselined.  There are other times, however, when project stakeholders decide to impose changes mid-stream, as a result of more recent market data or information acquired.  There are also instances when team members themselves decide to make a change – for instance, adding a new feature or performance improvement that was not pre-planned because it seems like the right thing to do.  I’ve also seen product development processes which include opportunities for project sponsors (e.g., marketing managers) to make changes to product requirements at key junctures in the projects’ life cycles (e.g., phase gates).  Without a formalized change review process, the normal process is to “absorb” the risk, and keep all other project and product requirements unchanged – this keeps the change agent safe, but makes the project team’s job more difficult.  Thus, there is a tendency for certain groups to oppose formalized (and visible) change control processes, especially if they have been able to stay “safe” in the past, and able to effectively negotiate with project teams in a way that they are never to be blamed when the team fails.  In my book “Project Risk Management: A Practical Implementation Approach” I focus on the concept of re-balancing the project plan whenever a change is imposed.  Bottom-line, to “do more with less” in an effective way, you must be able to control requirements changes in a formalized way.