Change Mangement Items to Add to Project Plan

1      Project Change Management Plan

1.1   Change Management Approach

Every project experiences change. If change is not formally managed, there is little likelihood that a project will be completed on time and within budget. Change can affect a project’s scope, cost, quality, risk, schedule, and work products, as well as the functioning of the project team.

The IT Monitoring & Enterprise Alert – Recommend Architecture & Tools Project will adopt a collaborative change management approach emphasizing an understanding and agreement among all parties about what the project changes are and how they will be managed.

When the project team needs to determine whether there is a change, the baseline documents are always the reference point. The baseline document for this phase of the project will be this document, the “Project Definition” document. Anything that is not covered in the baseline or that alters the baseline is a change. The process allows for change during the project life cycle, but puts the change in the context of the latest documented agreement.

1.2   Types of Change

Change will be classified as either design change or non-discretionary change. Non-discretionary change results from a failure of someone to do what he/she previously committed to, or the failure of some previously planned event to occur, and is sometimes tracked as lost time. A design change is an enhancement/correction to the system after initial specifications have been approved.

1.3   Change Budget

The purpose of the change budget is to provide an appropriation (of dollars and/or hours) that a project can draw from when change is encountered. The Project Team manages the change budget, providing approval for change expenditures when a change is approved or denying change expenditures when a change is deferred or rejected.

1.4   Change Management Process

The project team will manage changes by using the process described in this subsection.

1.4.1 Submit Change Request

Any team member may submit a written change request to the Project Manager.  

1.4.2 Perform a Preliminary Evaluation

The Project Manager reviews each change request and determines whether to defer, reject, or accept the change. If the change is accepted, the Project Manager estimates the effort to perform the impact analysis. Because an impact analysis of significant effort can cause a change to the current project schedule and/or budget, the client must decide whether to move to impact analysis.

1.4.3 Analyze Impact

If the change is to undergo an impact analysis, the Project Manager will assign the change request to a project team member. For our project, simple technical implementation, the technical team assumes responsibility for the impact analysis and involves additional technical staff as necessary.

The assigned resource(s) and the Project Manager first review the estimate for the effort of the impact analysis, and then work together to determine the effort, cost, schedule, and resources needed to implement the proposed change.

1.4.4 Review and Implement the Change

The Project Manager submits the impact analysis report to Project Sponsors for review.

¨       If the change is approved, the appropriate processes are followed to update the work plan, project documents, and the change is implemented. 

¨       If the change is rejected, the Project Manager logs the decision and reason and closes the change request.

¨       If the change is deferred, the date for the next review is set.

1.5   Roles for Change Management

Role (Contact Name)	Role
Project Manager	Receives change requests
Project Core Team	Performs preliminary evaluation
Project Sponsors	Final authority to approve a change for implementation

Starting the Project out Right

First – make sure all stakeholders are at the first meeting. Also ask the Project Sponsor to tell everyone you are the Project Manager (transferring authority). Talk about the processes you will use and the communication everyone can excpect from you.

Once you have a definitive scope, write a requriements document to meet that scope and distriubute it and sign it off. After this point, any change in scope should go through  your defined scope mamangement process.

Do your schedule as a team and construct a Work Breakdown Structure. Break each task down until it is no more than 40 hours or less. Add them back up to get the schedule. If management doesn’t want the date you’ve come up with ask them which scope they want to drop. Remind them that each feature takes time from you (as PM), the coder, the tester, the documenter and suppport.

As you move from requirements to specifications and coding, adding scope is even more costly. It disrupts everyone. Try to put it in a subsequent release.

Above all, make sure you communicate schedule, risks and status very frequently; and hopefully have a team site on SharePoint that everyone can see.

Scope Creep

People have asked me how to stop scopr creep. The way I do it is to have a change review board that every scope change must go through to be reviewd. That usually stops the managers from adding scope since I ask theym to sign off on the change management board in the beginning.

The decond problem id when and engineer wants to add scope on his own. To stop that, I have team members put in their time daily and their remaining time to get a task done. That helps me to find potential scope creep.

It is also vital to explain the whole process to the team and stakeholders. No one really wants the projct to fail and when they realize the impact of adding a little code enhancement to the testing and documentation groups, they tend to stay away from it.

That being said, it is a #1 problem in Project Management. Just keep on top of the project at all times.