Project Baseline Management
When project requirements have been analyzed and documented and the project planning baseline has been established for scope, cost, and schedule, project execution and control activities can begin. This involves application of conventional system control techniques to the project effort.
Considering the project effort to be a process, the plans, specifications, resources, and methods are the inputs. The process outputs should be continually monitored and compared to the plan. Adjustments in the process should be made to conform the project output to that desired. Variance between project results and the plan should be assessed and reported periodically.
For a project to be under control, it needs to be organized as a closed system. This is done by establishing baselines for scope, cost and schedule and then putting them under some form of version control. Once the project has been contained in these three dimensions, it can be measured, monitored and controlled. If a project does not have such baseline management, it cannot be managed and measured as a closed system, and must be therefore considered to be out of control. No meaningful performance measurements can be made where the scope, cost, and schedule are not bounded and under some form of change control disciplines.
If it becomes apparent that the project cannot be managed to its baseline, radical changes may be required. Changes to project scope or the realization that the project plan is seriously flawed can make the baseline of questionable value for project control. In such a case, the project may have to be replanned and re-baselined. When a new baseline is established, the same process of monitoring output and controlling the process must be continued.
Establishing the baseline is the formal end of the planning phase and the beginning of project execution and control. Controlling the project baseline is absolutely essential to project success. Other than misunderstood requirements, bad cost and schedule estimates, and technical difficulties, the things that will most likely imperil a project are the changes.
It is hard to evaluate what has changed if you don’t know where you were to start with. Knowing where you started, and documenting it, establishes your baseline. This baseline is your budget, schedule, and project scope. After the initial iterative planning process, the planning baselines must be frozen and put under configuration control.
The importance of putting the scope and plan under version control cannot be overstated. When you have version control, you can measure progress and status. Without version control, status and progress measurements become meaningless. A project without a stable planning baseline is flying blind.
Requirements creep can drive costs and schedules beyond their thresholds, and changes implemented in a haphazard fashion, or even many changes implemented in a disciplined fashion, can create confusion throughout a project organization. It is therefore important to manage the pace of change as well as the change process itself.
On-going requests for changes to the project requirements may be symptomatic of an incomplete initial requirements analysis or the failure of the project team to adequately involve and communicate with users and customers early in the project effort.