Kristin RuminerIT Project Manager| PrivateLittle Rock, Ar, United States
If your plan covers a multi-year project, do you keep those items even though their % complete will never reach 100%? Or do you continually modify (add/change/delete) the plan to match current tasks? I Saving Changes...
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. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
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. Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
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. Saving Changes...
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.
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. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Kristin
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.
Thomas Saving Changes...
Kristin RuminerIT Project Manager| PrivateLittle Rock, Ar, United States
Thank you all for the very detailed and helpful information. I truly appreciate learning from you all! Saving Changes...
Jeffrey HarmaTechnical Project Manager| Plante MoranRochester Hills, Mi, United States
Your use of the words "tasks" and "project plan" lead me to believe you are asking from a schedule tracking tool perspective (i.e. MS Project). In which case I would either mark the task(s) complete or set the duration to zero in order to get them off the radar. Deleting the task(s) could disrupt the logic in the rest of the schedule, and if it's thousands of tasks long you could be debugging for a while.
If I've misunderstood the question, then I agree with those above. :-) Saving Changes...
