Now that we have identified a scope change we need to react to it.
Change Requests. A change request is a formal method of asking for something different. It puts in writing what the request is and the impact it will have on the project schedule, budget and deliverables. Using it as the basis for discussion allows a decision to be made on whether to accept or reject it. Once it is approved it becomes an integrated part of the project’s defining documents, overriding what was originally agreement.
For our discussion we will look at who can initiate a Change Request and what type of information to include.
In most environments I have worked anyone can initiate a Change Request. In practice it is usually the Project Manager who ends up researching and documenting it. The general rule I follow is to allow a maximum of 4 hours to document a change. If it will take longer than 4 hours to research and write it up then consider issuing a separate Change Request that authorize the additional effort. For example, an additional feature to a screen may be a simple item to document. The effort to document a new data feed may take days to research all of the ramifications. The cost of that research in time and budget needs to be agreed to before it is spent.
In addition to the project identification information (i.e. project number, name, PM, etc.), the key areas a Change Request should cover include a description of the change, justification of it and the effect on the project scope, schedule and cost.
Description. The first thing to include is a description of the change. This should be done in the language and terms of the impacted group. Don’t use technical jargon. Keep it simple and clear.
Justification. Explain why this change is necessary. If I have to tell you a thousand times I will, don’t use hyperbole. This is your chance to tell the person holding the money why we need to include this in the project. Cover things like savings, functionality, regulations, etc.
Effect on Scope. Just like we did in the Statement of Work, lay out the scope of the change. Using one of our examples from before, if you are adding more JAD sessions, specify how many and any changes to the number of people, duration, etc. This is where you need to be as precise as in the defining documents. Remember, once this Change Request is approved it becomes part of the defining documents.
Effect on Schedule. Changes impact time lines. When features or other items are added to a project it will take longer. Make it clear that you can’t add 10 things and still meet the deadline.
Effect on Cost. When asking for more money, do your math. I don’t subscribe to the “pad it” theory. Be realistic, not optimistic, but don’t add 20% “just in case.” If the Sponsor sees this behavior he will always cut your budget by 20%. It is better to just be up front, show your figures and be honest.
Without this more formal process you may end up the type of situation that happened to my dad. He occasionally does carpentry work on a time and materials basis for people. Once he was installing a door between two rooms. He had it all roughly framed in and the owner asked to have it moved to the other end of the wall. So he pulled the frame, put studs back in the wall and started framing it in at the other end. Again the person changed their mind and wanted it moved back closer to the center. Being the customer centric man he is, my dad moved it again.
When he presented the bill to the owner, she couldn’t understand why it was so high to install a single door. My dad replied that he had actually installed three doors and filled in two of them. Since it was time and materials the homeowner hadn’t considered the extra cost.Note: Although our discussion has focused on adding scope to a project, a Change Request can also be used to remove scope or clarify an existing point. A classic example of reducing scope is moving something from Phase 1 to Phase 2. If this happens the impact to the schedule and budget should be to shorten the duration and decrease budget. Commonly reducing scope is used to bring the project back on schedule and in budget so you won’t see the timing or financial adjustments.
Thomas Cutting, PMP is the owner of Cutting’s Edge (http://www.cuttingsedge.com/) and is a speaker, writer, trainer and mentor. He offers nearly random Project Management insights from a very diverse background that covers entertainment, retail, insurance, banking, healthcare and automotive verticals. He delivers real world, practical lessons learned with a twist of humor. Thomas has spoken at PMI and PSQT Conferences and is a regular contributor to several Project Management sites. He has a blog at (http://cuttingsedgepm.blogspot.com).