Good Baseline Management is THE most critical factor in the execution and control of a Project. In my experience, more projects get in trouble because of inadequate, erroneous, poorly communicated, and ineffectively managed baselines, than any other single reason.

A baseline is the best available set of knowledge defining “What” the customer wants and the knowledge of the project team defining the “How” it will be done, “When” it will be done and “Who” will do it. You could call the Project Plan a reference point against which future project status positions can be measured. I guess it would be more accurate though to call it a reference vector, since the plan describes the execution as a function of time.

To make the complexities of baseline management easier to deal with, it’s useful to break down the overall Project Baseline in to several subset baselines. Typically those baselines include:
•the Technical Baseline- the specified and derived technical physical and functional requirements for deliverable products and/or services.
•the Cost Baseline – the allocated budget to the WBS elements and Cost Account Managers (and management reserve if the Project Manager allocates it)
•the Schedule Baseline – the Project Master Schedule and all of the logic-linked and resource loaded WBS element supporting schedule.
•the Risk/Opportunity Baseline – a definition of the known uncertainties regarding requirements, assumptions, resources etc. changes to which could impact the performance of the Project.

It’s common for larger, more complex projects for the Project Manager to establish additional baselines that they feel will help them in execution. Examples of these include:
•An organization baseline defining the structure and perhaps even individuals by name, if their expertise and on-going availability is critical to the Project
•A Facilities baseline defining physical resources critical to Project execution
•A Supplier Baseline defining specific sources for procured items critical to the success of the Project

Well-defined baselines are just the start. The Project must have comprehensive, well-documented, disciplined process; a set of meaningful, forward-looking baseline performance metrics; and a Project Manager who clearly articulates and demonstrates through their behavior, the importance of effective baseline management.

Here are a few tips from my personal experience that will help project baseline management and improve subsequent project execution:
•Ensure that all of the appropriate stakeholders are engaged in defining the baselines, their metrics and the trigger threshold for variance analysis and corrective action.
•Since the technical, cost and schedule baselines are intimately interdependent, ensure that the key managers of these baselines don’t work in isolation. Everything is connected to everything else, and an” infection” in one baseline can quickly spread.
•To the greatest extent possible, provide a common collaboration tools that the entire team has access to and can link to all of the appropriate, available data
•For projects durations of less that a year you must be able to look at and analyze performance data on a weekly basis. Even for longer duration projects, weekly performance data is better than monthly
•Proposed changes to any of the baselines must be reviewed by all of the Project disciplines (technical, financial, manufacturing, procurement and quality) for impacts and any impacts thoroughly discussed and analyzed before any acceptance or rejection decisions are made.
•I’ve found it very useful to keep my customers informed of the change traffic in the review process. This requires a lot relationship management effort, but the payoff is that surprises are avoided and valid customer comments can be addressed early.
•Don’t set variance thresholds so low that the trigger team action (and spending) that isn’t of value
•Demand variance analysis that is thorough. Too often I’ve seen superficial variance analysis that allows the real problem to remain hidden and become a bigger issue later
•If performance to the existing baseline no longer makes sense because of customer induced requirements changes or resource constraints, don’t be afraid to exercise the option of re-baselining. I cover this topic in my blog, “Knowing When to Re-Baseline Your Project,” published in April 2012