Andy Jordan is President of Roffensian Consulting S.A., a Roatan, Honduras-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at firstname.lastname@example.org. Andy's new book Risk Management for Project Driven Organizations is now available.
During the early stages of any project, the focus is always on completing the requirements. Both the project team and the customer invest huge amounts of time and effort capturing, reviewing, refining and ultimately approving the requirements that need to be delivered by the project. Both parties know how important it is to document the requirements accurately and completely--without that, we have no chance of delivering what is required.
And yet as soon as we have achieved the key milestone of having requirements approved we start changing them through our change-control processes. Why do we go to the effort of documenting what’s needed if we are then going to move the goal posts at a time when we need things to be stable in order to build what’s required?
The reality of change Change is inevitable, but it is also necessary. The customer’s needs may change, the environment in which they operate may have changed, technology breakthroughs may have occurred--all of these are factors that can impact what the project needs to deliver in order to achieve the customer’s goals. If we don’t change the project to respond to those changes then we are not going to give the customer the right solution.
For project teams, we often see change as something that detracts us from the work we need to be doing to deliver requirements. But the truth is that if we