Rebaselining is a Standard Operating Procedure for Project Management that refers to the process of revising a project’s budget. A baseline means a set of figures meant to be used as a base for measuring variances and it can refer to many other things besides money (e.g. timeframe, response time, etc). However for the purpose of this document we refer to the baseline only in the context of a project’s revenue and costs ($ and effort expressed in mandays).

Usually, companies refer to baseline as the P&L established during the bid phase (we will call that “the bid baseline”). However, the baseline is not a static figure; once we understand there is no way we can reach a certain baseline, there is no point into trying to measure against it. This is why baseline can and has to be changed once there is information that the original (bid) baseline cannot be achieved.

It may be found that bid assumptions may need to change as a result of the scope validation and project workplan development processes that would have impact on the project’s costs. Or during the project’s execution and control, project financial changes may occur that would lead to the need to rebaseline the project’s budget. These could relate to changes due to rate changes, amendments and/or unforeseen project conditions.

It is the project manager’s responsibility to bring these changes to the attention of management and present a case to re-baseline the financial cost expectations for the project. The project manager would need to obtain approval for the new budget before it can be used for calculating variances and must obtain approvals from the same approvers that approved the original budget to rebaseline the project’s budget, specifying the business requirements for the re-approval.

This policy is not to be interpreted that costs overrun will be easily accepted. Usually, the management will challenge any such request and Project Managers will need to make a good case in explaining their position.

Purposes of rebaselining:
In case of change requests, it is obvious we want to track the project against the whole funding provided by the client.

In case if internal changes or unexpected events that impact the costs, we need to acknowledge them and attempt to control the changes just as we would do in the case the client has initiated the change.

In case of “scope creep” or customer not fulfilling their obligations, the PM will immediately signal this to the client, understand the impact, obtain new estimations from the team and commit to the new estimations. If the PM fails to obtain additional funding for the change and for commercial reasons the team gives away free days, the PM should still inform the retain the amount for giving their company an edge in further discussions.

In case of plain misestimating, the PM must immediately assess the impact, obtain new estimations from the team and make sure they commit to the new estimations. This will allow the management to ensure there will be no further slippage. The PM must also analyze what caused the error in estimating and propose the necessary update in the estimating techniques used in the company.

Triggers for rebaselining

Any Change Request that modifies the Revenue and will be not handled as a different project.
A Change in services costs (own or subcontracted) that is outside the range of +-10% of total costs.
A change in external costs that implies acquisition of new equipment, new licenses or new subcontractor, regardless of amount.
The new baseline must replace the old baseline in the project progress report, while keeping the old baseline for reference.

A good policy is for PMs to inform on a necessity to rebaseline because of costs overrun as soon as they can predict a cost overrun that might impact the budget (that is, before the costs actually occur).

No comments: