Project Change Control is one of those areas in Project Management where, if asked whether they track changes, most Project Managers will say "yes, of course, but I just don't have an official procedure for this". The situation in this case is critical. If the Project Manager does not know all the changes that have happened in his or her project, they have lost control of their project, and they will not know whether, once the project is completed, they have achieved their goals. It is vital to the success of any project that all changes are reported, tracked (with individual tracking numbers), and that a decision is made to either accept the change or reject it.
This decision can sometimes be made by the Project Manager. If there are too many factors involved, or if expertise is needed, then the Project Managers can consider setting up an ad-hoc team of experts who can make the decision. This team of people is often known as a Change Control Board. They meet when needed, and their role is to discuss each proposed change (normally changes to Scope), the advantages and disadvantages, and the consequences to the rest of the project of making the change. The most successful process that I have seen works like this:
· A change is requested using a Change Request Form
· The change is logged in the Change Control Log, and given an individual tracking number
· The Project Manager (or their designated Change Control Manager) review the change and decides if they can make the decision to accept or reject
· If they can, they do, noting the consequences of the change and their decision
· If they cannot make the decision, they bring the change to the Change Control Board (CCB) which will make the decision, or appoint a team to investigate the consequences of the change
· If the change is rejected, then the person asking for the change is informed, and the decision logged
· If the change is accepted, then the Project Manager sets into motion the process in which the change is incorporated into the Project Plan.
· It is the final responsibility of the Project Manager to know all changes that have been accepted and to track these throughout the project lifecycle.
It is extremely important for Project Managers not only to put in place a tight Change Control system, but also to manage their projects strictly according to this system. Users, team members, and others in the organization will try to avoid having to use the Change Control Form, will not accept the decision to reject a change (if this happens), and will try to use the "I thought you knew what I meant" tactic when asked why they did not ask for a certain feature or function of the product result when they were defining it up-front. They will cite "The customer is always right" at you, and try to add requirements half-way through the project. In this case, the customer has a choice, and you need to make them aware of their choice. If the change was not in the original Scope and Requirements Document, then they should be told the cost of this extra change. If they don't accept the cost, then the change should not be accepted either. If you do not apply this rule rigorously, you are setting yourself up for trouble, with cost and time overruns. You will also find yourself at the end of the project, not knowing exactly what the result includes (if changes have been made without you being informed), and so you don't know if you succeeded your project or not! This is known as "Scope Creep", and is one of the main reasons for failure of projects.
In order to minimize the changes made to a project during the execution of the project is to make sure that the customer is aware of the importance of defining a detailed and complete Requirements Document. They must list not only what their actual needs are, but also what their implied needs are - their expectations. You as a Project Manager are very much an "Expectations Manager", and you must manage not just your customers' expectations but also those of your Sponsor, your Team Members, and other colleagues. You (or your team members) should work very closely with your customer up-front, and spend the necessary time, to define a complete document. This will save you time later on during execution. If necessary, make a check-list of questions to ask the customer, or use any of the many techniques that exist to ensure that the document is complete.
The steps to use can be:
Clarify the Goals (or high level objectives)
Develop the Business Case
Do an As-Is Analysis (what is the current situation?)
Develop a to-Be Assessment (What does the new situation look like?)
Define the high-level risks
Define the impact of the change on the business and company
Develop the Project Charter
Develop the Scope Statement
We will go into each of these in more detail in a separate article.
The first time you set and strictly apply change control, you will most likely get a lot of groaning and moaning, and people trying to make exceptions, If you manager to stick to your guns, you will find that the second or third time you manage a project, people have become used to the strictness, and they accept your way of managing projects. You will also be a lot more successful in completing the projects on time, in budget, and within scope.