How to properly drop tasks in MS Project that have value

Question

Once upon a time a project that I was managing running was fine, when all of a sudden due to dependencies of another project, senior management decided to freeze the project to focus on something else. Weeks later, management decided to change the concept of the previously frozen project and revamp the product.

I was wondering how I would depict this on MS Project. When we froze the project, % Complete was at about 65% with many tasks left open. I was thinking to set all Actual Finish dates to the date of freeze, which would make % Complete 100%. This could be misleading to stakeholders. They might think that we actually finished the project. If I left those tasks hanging, then the project would never seem to have been completed.

To sum up my question, how should I depict dropped tasks on MS Project, with the least risk of misleading information to senior management and stakeholders.

Additional information: The company I work for let's project managers freely choose their own tools as long as it showed information such as % Complete, a timeline, and breakdown tasks.

Answer 1

Seems like you have a new project. I think the simplest solution is to keep the original PMB as is to maintain as a project artifact and create a new PMB for the revamped product. It doesn't seem like a ton of value to alter the existing schedule.

However, if there is a reason to do so I am not seeing, it is totally appropriate to make old work packages 100% complete if stopped midstream.

Example, your budgeted cost of work scheduled (BCWS) = $1,000. You perform (BCWP or EV) $650 when you stopped, roughly 65% complete. You need the performance budget from this package to fund a new work package so you reduce your BCWS from $1,000 to $650 and capture the $350 remaining performance dollars to fund somewhere else. This sets BCWS = to BCWP making it 100% complete. All of this goes through change control and explained in detail to the impacted stakeholders, so there is no misleading anyone.

Notice that you do not alter ACWP (actual cost of work performed) so dollars actually spent, whether you were over- or under-running, remain the same so you do not remove any cost variances. Removing schedule variances by doing the above simply does not matter since you stopped the package. In other words, who cares.

But I really think you should just start a new project. Close the first one down, document the variances in your closing documentation, and call it done. The proceed with the new one.

Answer 2

The way I see it, you have two options... (a) continue using your existing project schedule or (b) abandon it and create a new one. In either case, you have a major scope change, so you cannot continue using the existing project schedule "as-is".

If you choose option (a) because you want to be able to easily see the project history in one place (which can be quite valuable), then I recommend doing the following:

• Make a backup copy of the existing project baseline (assuming there was a baseline "snapshot" originally) into an unused set of baseline fields.
• Set the 'Remaining Duration' to zero for all tasks that were in progress when the project was stopped; this will mark them as 100% complete, but it will only reflect the work that was done up to the point when the project was stopped... but not the uncompleted / remaining work on those tasks.
• Modify any remaining tasks as necessary, attaching a note to each explaining what you did, when you made the change, and why you made the change.
• Add any new tasks as necessary, attaching a note to each explaining what you did, when you made the addition, and why you made the addition.
• Save a new project baseline "snapshot" when you feel that the schedule is ready to execute, and when your stakeholders agree to the new schedule.

If you choose option (b) because you want a fresh start, then I recommend the following:

• Create a copy of your existing project schedule in case you want to use it as a starting point for the new schedule.
• In the existing project schedule, set the 'Remaining Duration' to zero for all tasks that were in progress when the project was stopped; this will mark them as 100% complete, but it will only reflect the work that was done up to the point when the project was stopped... but not the uncompleted / remaining work on those tasks.
• In the existing project schedule, cancel all unstarted tasks in the project schedule. If you are using MS Project 2010 or 2013, then you can simply set the tasks as inactive with a couple of mouse clicks. If you are using an older version of MS Project, then set the remaining duration to zero for all of the unstarted tasks.
• Create a new project schedule from scratch or by using the copy that you created; if you use the copy that you created, then delete all tasks that were completed, as well as any tasks that were in progress that you no longer need.
• In the new project schedule, add and modify tasks as necessary.
• In the new project schedule, save a baseline "snapshot" when you feel that the schedule is ready to execute, and when your stakeholders agree to the new schedule.