Project Manager’s Tool Kit – Change Request/Variation

Change is inevitable! To meet ever-changing needs and complexity of business, project teams are increasingly embracing Scrum/Agile methodologies. Project teams are using new tools and methods like Card walls, Daily stand-ups, Internet/Intranet Chats, advanced task management tools (like JIRA). However, one thing that Project teams are not doing so well is managing change within project.

In projects environment, change can be of various types. Traditionally, changes are mainly associated to Project Scope. Such changes are managed via Change Request (signed off by Project Sponsor/Board). In Scrum, however, Product Owner takes ownership of such scope changes.  It is important to note that changes within Projects are not limited to Project Scope, other types of changes also affects project delivery. Project Manager is ultimately responsible to manage all such changes throughout Project execution.

time-for-a-change-897441_1920

Following table illustrates different types of changes, their possible impact to the project and suggested measure to manage the specific change:

 

Change Impact Measure

Change in Project scope

Due to proposed change in project scope, there may be required change in project budget, time and quality.

NOTE: Change in Project scope implies:

  • Increase in scope
  • Decrease in scope
  • Both increase and decrease in scope. (For example, discount deliver of report from the scope and add delivery of new executive dashboard.)

It is important to manage all such changes, irrespective of the fact if these changes have any material impact to project budget, time or quality.

PM should raise Change Request (to be signed off by Project Sponsor)

Illustrate following in the change request:

  • Why there is a need for change in Scope
  • How change request is important to Project Business Case
  • How change request would affect project’s budget, time and quality
  • Does Project Team have resources to deliver the Change request
  • Any alternate approaches
Change in basic assumptions

  • Project team member(s) not performing as expected
  • Lack of ownership/commitment from Project team
  • Lack of requested skill-set within project team
  • Quality of deliverables
  • Additional time

 

PM should raise a Change Request (signed off by Project Sponsor/Senior Supplier/ Executive)

Illustrate following in the change request:

  • Identify Problem
  • Propose solutions
  • Provide Pros/Cons for each solution
  • Provide description of risks associated with Status quo

 

Change in Software version – Sometimes software vendor may request to upgrade software version (in middle of UAT) due to bug/defect fixes in the latest software release Risks associated with new software release, stability of new release, additional testing etc.

 

PM should raise a Change Request (signed off by Project Sponsor/Senior Supplier/Executive)

Illustrate following in the change request:

  • Problem – Proposed new software release may have additional quality issues, which may require additional testing, hence additional budget, resources and time.
  • Propose solutions – Allocation of additional budget, resources and time
Handover of work between resources Unplanned/Planned handover of work between project resources may require rework, inefficiency, communication issues. PM should raise a Change Request (signed off by Project Sponsor)

Illustrate following in the change request:

  • Problem – Due to unexpected change of Project Team member, there is expected disruption to Project tasks. New assigned resource may require additional time to come up to speed with the project. Project task milestones may have to be moved to accommodate the proposed change
  • Propose solutions – Allocation of additional time/budget to deliver specified milestones
Decisions made by Project Board/Senior Supplier/Executive

  • Moving Go-Live date
  • Not adopting the specified infrastructure (Servers/Clients/Network etc)

 

  • Project budget, project resources availability to support the project
  • Knock on effect on other projects in pipeline etc.
  • Software performance
PM should raise a Change Request (signed off by Project Sponsor/Senior Supplier/ Executive)

Illustrate following in the change request:

  • Identify Problem
  • Propose solutions
  • Provide Pros/Cons for each solution
  • Provide description of risks associated with Status quo

 

 

It is important for PM to acknowledge and notify various changes to appropriate stakeholders throughout the project execution. If approver does not approve the given Change Request then it is in best interest of everyone involved, to log it as a risk in Risk Register.

At the end of the day, PM is ultimately responsible for day-to-day management of the project. If PMs are not actively looking at such changes then these changes will affect the project, without any notice. Therefore, as a PM, it is in your best interest to keep your eye open to all such changes to the project.

Let me know what you think about this topic? How have you managed such changes in past?

 

Advertisements

Share your thoughts

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s