Spread the love

This is a part of a chapter from our upcoming book in Integrated City Project, a sample – large and complex project. The book is about how to use The Customizable and Adaptable Methodology for Managing Projects™ (CAM2P™) on such a project.
This is a continuation from the previous article

What Do We Control Against?

We control against the plan.
OK, but what plan?
Control against the plan with the approved budget
Only against that plan?
Why the confusion?
Some project management practitioners can only view control (and change management) in light of detailed plans with specific deliverables, quantities; and against an approved budget – the baseline. These practitioners do not recognize that control (and change management) could be against a concept, a rough plan or a semi-detailed plan.
This is a lengthy discussion and we refer the reader to our ‘Redefining the Basics of Project Management’ book for more information. To summarize here, there are Control Reference Points, which are superseded as the project move from one stage to another. Attachment 6 offers the Control Reference Points along the Project Life Span.

The-Project-Baselines-Control-Reference-Points

The Project Baselines and Control Reference Points along the Project Life Cycle (Span)

Driving in the Fog

As stated earlier, although most control actions will be once execution starts, one can still control in the earlier steps between Stage Initiation Document and Stage Detailed Plan; or in the earlier stages, between Idea Statement and Project Detailed Plan. The author uses the analogy of driving in the fog to refer to control in the earlier steps of a stage or a project. This analogy is due to the fact that in these earlier steps the scope and other things are mostly conceptual not defined in detail (no work packages) and lack quantities. Therefore, control is mostly qualitative early on and quantitative after detail planning or funds approval.

Project Control versus Change Management

In some organizations, the author has observed that control for them is inclusive of change management. In others, they are split, which is what is done here as well.
What is the difference between them?
To keep it simple, control is usually related to any deviations from the plan due to work performance or market conditions. For example (a) buying item X for $100 whereas in the plan that item was budgeted at $105, (b) installing 25 gadgets when the plan called for 23, and (c) Item A arriving 3 days later than planned. These deviations happens due to doing work and is exactly why we need the PDCA and control processes. In summary, control is to ensure the team deliver what is required no more – no less.
On the hand, a change is a conscious decision to change the plan. Remember, the plan is per the earlier discussion on Control Reference Points (what do we control against). In other words the plan could be the Idea Statement, the Project Authorization Document, or other deliverables on the Project Life Span. Within a stage, the plan could be the Stage Initiation Document, the Stage Management Plan or the Stage Detailed Plan.

Contingency Management

Part of control, is the management of all control accounts and their work packages. However, the challenge is what to do about contingency? How to monitor and control contingency? Should the team use the ‘bank account method’, meaning drawing (consuming) the contingency until it runs out? The bank account method is not an effective techniques since if the team is consuming contingency too fast, and not controlling and forecasting it, this will lead to delays in communicating the bad news, if the project is not going well.
Will demonstrate this point with a real example during the sample project discussions.

Forecasting

As the team plans the project, scheduling and estimating is ongoing, and cost estimate is a common term. Once the plan is approved, the team shift from using the term estimate to budget, approved budget, or control budget. Next, once the team is executing the work, the budget remains as a reference but the team also start using the term forecast, to refer to the expected cost of the project at completion. In other words, forecasting is an ongoing re-estimate of the project cost (and time) which should be done with every reporting period; weekly or monthly.
How to forecast? There are many techniques and many references on this subject. In the sample project will include some examples.

Sample Project

Now that the concept and knowledge foundation is in place, during the later parts of this book, will demonstrate many of these concepts on the sample project.
[1] Refer back to Chapter 4 discussion on planning and ‘how to’ versus ‘do’.


Spread the love