What are the best practices for taking Planned Snapshots in a Formal Project?
What are the best practices for creating Planned Snapshots in a Formal Project?
Some people on my team believe that the following should be done:
1) Create a Planned Snapshot after the schedule for the project is approved.
2) Run the project against those dates and never take another Planned Snapshot for the release.
There are some problems with this:
1) People enter or delete vacation dates. If a new Planned Snapshot is not taken, then they are still responsible for starting and finishing work during their vacations and/or have no work during times where they have canceled vacations.
2) Team allocations are changed. We currently have 4 teams with simultaneous releases. The fourth was just added and the resources are shared across teams. In order to add the 4th project, we had to reduce people's allocations on the other teams. Thus the Planned Start/End dates are no longer valid and a new Planned Snapshot is needed, otherwise they may be required to start/complete work when they are not allocated to the team. Or they may end up having correct allocations, but work start/end dates that require 100%+ allocation (i.e. 80 hour weeks).
3) New work items are added to the release. If no Planned Snapshot is taken, then these items never get assigned a Planned Start/End Date.
The arguments against taking Planned Snapshots every one or two weeks are the following:
1) This changes the data returned by the Schedule Variance view to make everything appear like it is on schedule, when just before the snapshot there were multiple work items behind schedule.
2) There is the desire to hold everyone on the team to the strict dates that were defined at the start of the project. Taking new Planned Snapshots causes these dates to change.
Can someone please give me some official feedback on best practices for this? I have searched Google, these forums, the RTC bug database, etc. but I cannot find any whitepapers or best practices anywhere that cover this.
Like I said above, my company has 4 simultaneous releases going right now and we are having a lot of problems figuring out how to make Formal Project Planning work in RTC. Many features that we assumed were in the product (and saw demoed in Agile projects) just don't work or exist for Formal Projects.
We contacted the consulting agency who sold us the software and they have Formal Project Planning training, but it does not cover anything but the most trivial and elementary examples. There does not appear to be any real world training or best practices anywhere!
Thank you.
One answer
Hi Michael,
I have only touched formal planning so far, and thus only limited experience. However, you have three snapshot types available.
Here some documentation I have looked into when poking around: https://jazz.net/library/article/1152
I can't say anything to the scheduled variance.
With respect to plan snapshots, you have the following
1. Regular - you can have as many as you like. You can keep them as a baseline and also compare against them. Proposed and planned snapshots become regular ones if you create a new proposed or planned snapshot.
2. Proposed - the proposed schedule for a plan. You can only have one. If you create a new one the old is kept and changed to regular. The plan keeps the proposed times for comparison.
3. Planned - the planned schedule. You can have only one of it.
You can compare any plan snapshot to see slippage. You can also select to display the current schedule, the planned and the proposed schedule in the Work Breakdown and Schedule and any other plan view configured to show the Gant section.
The current schedule is based on the current data in the plan (allocation, start time etc.) calculated when the plan was last refreshed in the browser, as far as I can tell.
As far as I am concerned, the current plan shows the reality and the proposed and planned snapshots show what was reality in the plan (like your old project plan in any file based tool) which is aging and does not represent the reality after not being updated for some days.
I would probably
From my perspective, the reality is fact. If your allocations change, people ask for vacation or are otherwise occupied, you need to re-plan and the plan that was true and ideal in the past is reduced to just some data point in the past useable to better understand what went wrong and reduced it to history.
I shared your questions with others and hope they can provide more insight. There might be others with more experience with formal planning that step up and share their knowledge. This is the best I can do.
I have only touched formal planning so far, and thus only limited experience. However, you have three snapshot types available.
Here some documentation I have looked into when poking around: https://jazz.net/library/article/1152
I can't say anything to the scheduled variance.
With respect to plan snapshots, you have the following
1. Regular - you can have as many as you like. You can keep them as a baseline and also compare against them. Proposed and planned snapshots become regular ones if you create a new proposed or planned snapshot.
2. Proposed - the proposed schedule for a plan. You can only have one. If you create a new one the old is kept and changed to regular. The plan keeps the proposed times for comparison.
3. Planned - the planned schedule. You can have only one of it.
You can compare any plan snapshot to see slippage. You can also select to display the current schedule, the planned and the proposed schedule in the Work Breakdown and Schedule and any other plan view configured to show the Gant section.
The current schedule is based on the current data in the plan (allocation, start time etc.) calculated when the plan was last refreshed in the browser, as far as I can tell.
As far as I am concerned, the current plan shows the reality and the proposed and planned snapshots show what was reality in the plan (like your old project plan in any file based tool) which is aging and does not represent the reality after not being updated for some days.
I would probably
-
Create a new proposed snapshot after finding that the reality has changed, looking at the current plan and the originally planned snapshot. Use the new proposed snapshot to communicate the changes.
- Create a new planned snapshot after agreeing with management that reality and plan don't match as usual because the reality has changed and everybody agreed it can't be helped.
- Keep the old planned and proposed snapshots with as regular snapshots with a useful name to be able to compare the currently "planned" or proposed plan against the reality back then.
From my perspective, the reality is fact. If your allocations change, people ask for vacation or are otherwise occupied, you need to re-plan and the plan that was true and ideal in the past is reduced to just some data point in the past useable to better understand what went wrong and reduced it to history.
I shared your questions with others and hope they can provide more insight. There might be others with more experience with formal planning that step up and share their knowledge. This is the best I can do.
Comments
1 vote
1 vote
1 vote
1 vote
1 vote
showing 5 of 9
show 4 more comments