This is part 3 of a 4-part series on project change management. This topic is a chapter in our upcoming book, Redefining the Basics of Project Management, scheduled for second quarter 2014.

Project Change Management

Change Management in the Fog

‘Project change management in the fog’, is a term we use to refer to the part of the project life span where control is mostly qualitative due to the ambiguity of the scope definition.

Why using the analogy of fog?

Scenario 1

Well, imagine you are driving in extremely dense fog, you will not see anything. Driving in these conditions would be wrong, and one should stop on the side of the road.
Relating this to project management, this would be a condition on a project where the team does not know the scope and objectives. In other words, this is not really a project, and the organization should stop the work.

Scenario 2

Now, imagine you are driving in dense fog. You might be able to see some things, but not clearly. Driving under these conditions is dangerous, but if we must, extra care is in order. However, even in these conditions, we would be able to see a few meters ahead; not the details but enough to stay on the road.
Relating this to project management, this would be similar to the time span between idea and project authorization document where we do not see the details of the project & product scope. However, even in these conditions we would know if we are sidetracking off the project objectives.

We represent this scenario via the bottom arrow in the figure above. In this case control is against the idea statement.

Scenario 3

Continuing with the analogy! In this scenario imagine you are driving in fog (not dense fog), you will be able to see things, not very clear, but enough to pick up speed, while maintaining cautions.
Relating this to project management, this would be similar to the time span between PAD and PM Plan or PM Plan and PDP, depending on the density of the fog. In this period, there is more clarity but still not enough to see the full details; i.e. quantitative. Refer to the second and third arrows in the image above.

Why did we present the above analogy?

Because the traditional view of project change management, as we raised earlier, is that organizations do not implement a change management process until after full funding (from SG5 onward), and in some cases only in relations to contracts.[1]

Traditional Change Management

Traditional project change management refers to the common practices for managing project changes. In most organizations, that we have worked with, management of project change is limited to projects where the work is being performed under contract and the changes would be specific to changes to the contract. This is mostly control against the fourth control reference point, as we discussed in the prior chapter. Refer to first arrow from the image above.
With this approach, the team is skipping proper control between control reference points 1 and 4. This is the foggy, ambiguous area.