Please login or join to subscribe to this thread
A forecast represents your best guess as of a point in time as to what will happen. That is distinct from a baseline which is a snapshot of what you expected would happen at some previous date. Over the life of the project, there might be multiple baselines as changes to the schedule are formally made and accepted by the appropriate governance bodies. But once an activity has been completed, its forecast start and end dates should be set to its actual start and end dates.
To add a bit to what Kiron said, baselines are strategically updated periodically throughout a project. In a large complex project, that can involve significant time and work, including supplier contracts. To prevent a never ending cycle of plan recommitment, actuals are often shown as a delta (variation) from the planned date so that we are working to the real plan, not the plan from the previous best guess months ago.
In addition to the significant cost, if you just set the forecast to the actuals, that can mess up lots of other schedule logic. There may be right-to-left dependencies, left-to-right, and fixed dates that drive other dependencies. Part of the time and expense of re-baselining the project is analyzing the dependencies to see the impact of a moved date.
When re-planning and committing a new baseline after many deltas have occurred, sometimes the actual date becomes the forecast. It makes the schedule much easier to read. Sometimes we need to show a date moved however to show that something changed, rather than hiding it by showing everything is perfectly on plan. That date may have dependent items in the future, and we may still have work to pull those dependent items back to the left.
The colors I typically see on schedules are black for the baseline plan. If the milestone is colored in black, it was on time. Blue is a new item added to the plan. Red is something late. Red and not filled in is still open and late. Red and filled in is closed later than plan.
First of all, forecast is never bad or good. That´s by definition of estimation. All estimations has an inherent "error" into them because estimations depends on information you have at the time to estimate. You can see this if you search for Barry Bohem´s Cone of Uncertainty which was created for software but it is used in lot of other fiels (in fact the PMI hast included it into its standards). With that said. actuals usually are not equal to forecast. Why? Because my previous statement. Actual shows what happends and Forecast show the original estimation with have the inherent deviation into it. Here comes the strategy each company take for managing budged associated to projects. Some companies adjust the forecast according to actual but maintaining a percentage which is related to the threshold of risk they are willing to accept. Form example, the forecast is adjusted keeping it 20% highest than actual. All this making a projection from one point in the time to the end of the project. My final comment is about is usual to see that some companies do not understand that estimations, all estimations, must be reviewed according you get more information. For example, after requirement definitions, then after design definition, etc. Think about the construction of a house. The estimations after taking the idea, then taken the mockup, then taken the blueprints, etc will vary indeed because you are taking more information into each step.
Michael, I think your co-worker has in mind a baseline rather than just a forecast. Forecasts are a good thing, and why not update them as often as you like? A baseline (a forecast you hang on to) is not so great. Baselines only seem to have negative consequences. Personally I avoid baselining because I have never found a good justification for doing it.
Please login or join to reply