So if a baseline or snapshot of the plan is what we’re going to measure against, then it’s pretty tempting to wait just a bit longer so we have a little more information and feel a little more certain about the definition of those project objectives. That way we will be more likely to meet them and less likely to need to change them.
But consider this: The purpose of a baseline is as much about recognizing change as it is about preventing it. In the absence of a baseline, how do we even know if what people are asking for is different than what we’ve already done or planned?
Why, for example, do scopes creep? Often it’s because they were never baselined in the first place. How is it that we get into these battles with stakeholders about whether or not what they’re asking for is different than what they’ve already asked for? Maybe it’s because we don’t have anything to compare it to!
Baselines enable us to recognize change and respond appropriately. In order to control the project, we need to know the relative size of a change request or deviation from the plan baseline. Is it small? If so, then maybe we can make some adjustments to how we’re executing to bring ourselves into alignment with the plan. Is it substantial? If so, then we know to go through a process to get approval as to whether or not we will update the baseline and manage to the new plan.
But without something against which to compare changes, we are really guessing as to whether or not it’s even a change. That is likely to result in a creepy scope and a project manager with very little in the way of negotiating leverage.
It’s not enough to just monitor the project if we don’t have a means of controlling it. Without baselines we can’t do either.
Don't forget to leave your comments below.
Comments
However, in my view there is an even more important baseline that is even more often overlooked and that is the "Where-are-we-n ow baseline. Since projects are about change, especially where administrative and systems projects are concerned, if you don't know what the situation is now, how will know what improvements you have made, and by how much, at the end of the project?
Baseline really plays a big role depending on the size of the project, Type of project, who the customer is and where are these customers from (Japan, USA, Europe or Asian countries). I constantly face this problem. My experience with Japanese customers - you collect the requirement, estimate and create an execution plan and got it approve. Base line them. Well you thought all set. Now my customer's competitor changed the spec. of his product. This forced my customer to change the requirement. Now if I ask for change request and change management and change in estimates first of all I am looked at strangely. Secondly I am not going to get my next project if I keep insisting on this point. This is the practical scenario.
We need to change the way we do project management. Yes it is important for any project to have base lined plans. But plan should include such variations as a rule and not as an exception for the present day conditions.
What I normally do is keep buffers in my baseline plan (is it really baseline - not exactly but it helps where negotiations are very difficult or result in a win).
But I certainly believe with proper baseline, tighter control and reasonably good relationship with your customer we could certainly succeed in most of the projects