Skip to content

Don’t forget! Five deliverables that must be re-baselined

August 11, 2011 - Project Management

measuring tapeIn this, the last post of the Project Change Control blog series, we’ll be discussing project deliverable re-baselining.  Now that you’ve gone through all the trouble to document and analyze a requested project change, and get the change approved, it’s time to ensure that your overall plan reflects the change so you stay on track.

After a project change is approved, it’s important to make sure the following deliverables aren’t lonely:

1. Work plan

Before committing to new milestone dates, make sure you re-baseline your work plan, and use your newly updated work plan to help you adjust milestones.  You’ll find that activity will enable you to set much more accurate dates than an educated guess will.  Common sense?  Perhaps, but people do love to quickly set a new date based on a gut feeling, rather than a couple hours of work plan rework.

2. Cost estimate and forecast

This one may be obvious, but be sure your new cost estimate also includes costs such as additional resource effort or modified third-party statements of work.  In order to accurately update your monthly cost forecast, be sure you understand what stages of the project the new costs will be incurred (most likely the additional costs will impact multiple stages).

piggy bank3. Business case

Almost any project change will also impact the business case, though in some cases, it may not be immediately obvious.  Obvious business case impact: Increased costs.  Not-so-obvious business case impact: A one-month go-live date shift.  What impact will that have on planned Year 1 benefits?

4. Requirements

Ensure that the scope change is documented as clear, concise requirements in your requirements list, and create a new baseline against which the project’s success will be measured.

5. Resource plan

Are any new resources required to be onboarded to your project, due to the change?  Or will any current resources need to spend more or less time on the project?  Ensure the resource plan is updated, and that all impacted resources fully understand the change.

Project Change Control blog series

  1. Introduction
  2. Document the change
  3. Analyze the impact
  4. Approve the change
  5. Re-baseline the project

Spread The Love, Share Our Article

  • Delicious
  • Digg
  • Newsvine
  • RSS
  • StumbleUpon
  • Technorati
  • Twitter

Related Posts

Comments

  1. Abe Perez February 7, 2014

    Are the efforts of a rebaseline considered rework if the resbaseline is due to slow project setup, poor performance, and not able to fully staff

Trackbacks

There are no trackbacks on this entry.

Add a Comment

Required

Required

Optional