Project Baseline is a method of project planning where a project's scope, budget and risks are defined. The method will involve the use of project plans that will serve as a map or framework for the entire project. Each team will then develop sub-processes that work towards achieving a specific set of objectives. The whole project can then be tracked and monitored by the Project Management System (PMS).
Applying a baseline to projects is an important instrument for measuring project schedule performance during the post-project assessment. Setting a baseline for a project is quite easy, and there are several application which are effectively designed to develop a baseline i.e. Primavera P6, Microsoft Project and smartsheet etc. so the project manager can save a snapshot of the entire project at any time. Defining multiple baselines can be very useful to provide a history of planning progress during the post-project evaluation.
When a project is under estimation, this may have an effect on the whole project and cause the project manager to give too much emphasis to things that are not very relevant to the project. Using the default baseline settings for all tasks in the plan is both simple and effective in most cases. However, if a project has an incremental or phased approach, there may be additional considerations. In the specific case brought to my attention, the deviation from the task-level baseline was used as a performance measure for influencing bonuses paid to personnel assigned to tasks within the project. This increased the stakes in establishing a baseline that would accurately reflect the variance at the task level. Applying Project Baseline to Incremental Projects in Project Management can be done with the help of the Project Management System (PMS) and will ensure that the projects are well defined so that the goals and objectives are measured against the project.
A Zero Baseline procedure can be applied for the entire project at the beginning of the development phase after customers approve the requirements, which works well for projects that use a pure waterfall method, where requirements are locked down and project resources have the capability to commit to task-level start and finish dates. This modulation point also helps distinct the source of the overall project variance into design and development areas, as the clock doesn't start until customers approve the design.
Because the metric is based on the duration of the task, rescheduling tasks in the project does not affect the task performance metric for the assigned resources. However, the resources still have an interest in the overall project planning, because the project-level variance is used as a team matric. This process of applying a unique baseline and gathering performance metrics directly from the project planning application has worked very well for several years, as projects showed a sharp dividing line between the design and development stages, or were executed in waves of smaller projects.
Recently, the projects with lower priorities have started to use an incremental approach where independent task groups can run in any order, but can be rescheduled if there is any conflict between higher priority projects and operational tasks. In this type of "whitespace" project, it is expected that there will be regular rescheduling and that the total duration of the project will increase.
In addition, the design of each deliverable product can include research conducted after the task force has been assigned, allowing for more accurate schedules to be estimated later in the plan. When each result has its own asynchronous schedule within the overall project, it becomes impossible to define a single point in time as a fair benchmark.
If the baseline is set at the start of the first assigned task, the snapshot shows the tasks that were not sent to a resource for estimated duration. Also, not assigning tasks does not mitigate the negative impact on staff performance metrics, as the baseline will be associated with each resource assigned to the task at a later date. Conversely, if the baseline is set at the start of the last assigned task, all previously completed tasks will have a zero deviation. In either case, the data will create a disadvantage or an unfair advantage when used as a performance measure.
As usual, the key to setting a baseline is not so much the technical feature, but attention to downstream effects and communicating with stakeholders about how best to find a solution that fits with the objective of the project.
Komentarze