Keys to Project Success - Part 8

Changes Ahead

This post is a continuation of  Keys to Project Success - Part 7

Manage Project Change

What is ‘project change’?  It’s anything that deviates from the plan.  We often consider change to be only a change in requirements, and indeed that is a change.  But there are far more sources of change than that.  For example, one of your team members is suddenly taken ill for what appears will be an extended period of time.  Your plan was to have them working throughout the project.  So that’s a change.  There are subtler forms of change too, such as tasks taking longer than anticipated.  We often don’t consider “being late” on a project as a change, but it is.  And, just in case you were wondering, change is inevitable on all projects.  The world is constantly changing around us, so to think we might somehow cocoon ourselves in a static bubble while we execute our project is wishful thinking at best.  It is far better to just accept that where we think we’re going now and what it will look like is not where we will end up, and that’s to be expected.

Function-Time-Cost Change Triangle
So then why manage change in the first place?  Without effective and transparent change management, the success of the project is compromised.  Project success, don’t forget, is measured by how well the project meets the needed functionality and quality, delivered by when it was supposed to be delivered, and at or below the cost it was supposed to cost.  Changes impact one or more of these three facets.  And if we don’t manage the change such that we can adjust these facets along the way, then when we’re measured at the end of the project, we’ll inevitably fall short.  Through change management, as changes happen, we adjust the appropriate facets, and then measure against the new and approved reality.

Changes are not always bad.  Your end-users bringing a modification to the design forward that will allow the company to better generate revenue is arguably a good change.  But all changes have consequences to the project, and those consequences need to be understood and managed.

I use a relatively straight-forward approach to managing change that is I believe both light-weight and effective.  There are a couple of prerequisites to using this approach.

  1. You must have a written-down, well-constructed, baselined plan.  This includes all date-constrained critical milestones that the project must meet.
  2. You must have a change board.  The change board is a collection of decision-making stakeholders in your project that can decide whether or not to approve changes, and have the authority within your organisation to commit additional resources, adjust externally impacted schedules (such as product launch marketing, or external customer implementations), and agree to design and quality changes.  This is a critical component of ensuring your change management is transparent.  This change board may be the entire project steering committee, or a subset of that group.  If a subset, the project champion / sponsor should nonetheless be part of the change board.

The change-management steps are outlined below:

  1. Identify the change, and clearly articulate it.
  2. Articulate the rationale for making the change.  Why should we do it?
  3. Determine the root-cause of the change; this is different from the rationale.  Why did the change happen?  From where did it originate?  Was an error made, or did we just have not enough information at the time?  This information is critical for continuous process improvement.
  4. Determine what has to be done to effect the change.  There will be a new set of tasks, and don’t forget the work that may need to be done to ‘undo’ some previously completed work.  And, include the work to update the various documents (such as designs, plans, schedules, etc.).
  5. Quantify the change in terms of impact to
    1. Functionality and quality – what will the change do not only to what you’re delivering, but the level of quality you’ll deliver.
    2. Schedule – use your project scheduling tool here to determine the impact on the overall schedule as you schedule the new work from 2. above.
    3. Budget – What changes in the cost structure for the project?
    4. Project Risk – Changes alter the risk profile of a project.  Don’t forget to look at the catalogued risks, and assess which are affected by the change.  And, don’t forget to catalogue new risks that become apparent in the new work, or as a result of the new direction.
  6. Determine the cost of what you’re throwing away.  While sunk costs are not a consideration in a current financial decision, determining what to do about the change (including not changing) often depends on not just the cost considerations, particularly changes that could be classified as ‘cosmetic’.
  7. Create a change proposal.  This is a written document that details the results of your analysis above.  A relatively simple form could be used with the following headings:
    1. Project
    2. Change Proposal Number
    3. Date
    4. Title / Short Description
    5. Prepared by
    6. Cause
    7. Nature of the change
    8. Rationale
    9. Schedule impact
    10. Cost impact
    11. Throw-away impact
    12. Project risk impact
    13. Decision
  8. Assess materiality of impacts.  Sometimes, changes are minor, and can be easily absorbed into the contingency of the project (every project should have contingency).  If after your analysis you determine that none of the major milestones will be compromised and the cost change is easily accommodated within the budget, provided this is part of your Project Change Management Plan, you can make the change without going to the change board.  A trivial example of such a change would be increasing the width of a database column to accommodate data that is larger than originally anticipated while under development.  A design document would have to be altered too perhaps, but that’s likely it.  However, that same change when you’re in User Acceptance Testing has a very different cost profile.  So, do the analysis and document it.
  9. If significantly material, seek approval from your change board.
  10. Once approved, adjust the appropriate project artifacts to the new baseline.

Using the above recipe (and following all the other keys to success), you should arrive at the end of your project with everyone believing it was a success, despite the inevitable twists and turns you encountered along the way. 

 

Read part 9!

Add new comment