Please login or join to subscribe to this thread
The plan gets revised, but it is often inefficient to do it continuously. This is where a rolling-wave or blockpoint plan is effective.
I often use the phrase, "The plan is the plan until it changes.":
The complete plan is the baseline plan plus approved changes. Integrating all the changes into the baseline vertically and horizontally may be a time consuming and expensive process so it is done infrequently. On the other hand, you don't want to keep working on things you never plan to finish so you may have some type of change board that approves lower level plan revisions on a regular basis, including "stop work orders".
At periodic points in the project plan, the baseline is updated with the approved changes, including removal of tasks that are no longer required. That reduces the overall "churn" in the plan, while being responsive to a changing environment.
Not updating the Plan may result in confusion and misunderstandings. You may see the tasks as no longer relevant but others may not. Two immediate problems: 1) some stakeholders may still expect task completion as these tasks may be important to them, and 2) someone may be applying effort to these tasks which ultimately may be wasted. A proper change process should make sure all stakeholders are on board. I am not suggesting this be done 'continually' but should be frequent enough to minimise the risk to the project.
My opinion is that you have a baseline for a reason. It serves as a benchmark that you can use to determine where you are in relation to where you should/could/would have been. So removing tasks after the baseline has been approved means that you will not easily identify the impact of doing it. Removing tasks should only be done on the current version of the schedule and not on the baseline schedule.
A lot depends on the approach to your project. If a predictive approach is taken, then if there are specific tasks which were part of the original scope of the project and are no longer relevant you'd likely need to follow your project change control procedures to ensure there is stakeholder awareness of their removal, remove them and then re-baseline. If an adaptive approach has been taken, unless those represent major scope components or their removal will result in other material changes to your project, you can safely remove those.
As Kiron mentioned, it depends.
I agree with Kiron. In a predictive approach, you need to perform change control to remove certain tasks of the project, changing the baseline. For other part, if the approach is agile, removing or changing tasks is a habitual process between iterations.
the removal of any tasks that were communicated has to be explained to stakeholders. Change management does this. I would think in a program with several projects and teams this is needed also if it is run in agile terms.
But you can hide tasks in the schedule representation if they are not relevant to the current status of the program.
Please login or join to reply