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
Ralph Schoon (63.1k●3●36●46)
| answered Jun 18 '13, 8:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited Jun 18 '13, 8:05 a.m.
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. Comments As far as what the 'current data' is, items that have been added to the plan since the last Planned Snapshot was taken have no Planned Start Date or Planned End Date. Refreshing the browser does not fix this.
Thus it does not possible to get a view on 'reality' without generating a new Planned Snapshot. Then you will have the new Planned Start/End Dates for all work items.
I like the ideas for making the Proposed Snapshots more useful. I'm not sure that we can get agreement that 'it can't be helped', that has been difficult so far.
So far we've compared snapshots a couple of times. It seemed to give us the value of seeing what work has been added or removed from the plan between the two snapshots. But we hadn't tried it really since the projects got rolling. It seems to provide a lot more useful data now. I will show this to my team and see if we can leverage it better.
Thank you.
1
Ralph Schoon
commented Jun 18 '13, 11:04 a.m.
| edited Jun 18 '13, 11:05 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Michael,
1
Ralph Schoon
commented Jun 18 '13, 11:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
With respect to your answer. The planning seems to be done when doing the snapshot. However, in the agile scheduler, it happens when the item has an owner and an estimate. Can you try that? Agile seems to not rely that much on snapshots for the schedule. I will have to look into formal planning as stated above. Good input.
Right, all of our items have owners and estimates. But if they were added since the last Planned Snapshot, the Planned Start/End Dates are blank ( ----- ). 1
Ralph Schoon
commented Jun 18 '13, 11:44 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Thanks, I will add that to my list of investigation topics.
From: https://jazz.net/library/article/1152
"As the development plan progresses, it is important that good practices are in-place for declaring updated plans as planned snapshots by teams/projects"
This is the kind of thing that I'm looking for. I'd like to see a whitepaper, article, or presentation from IBM Innovate that lays out these best practices.
There is a brief mention about how to do this:
"therefore, it is important to save the planned snapshot as the plan progresses."
But this needs to be covered in more detail w/ multiple examples.
1
Ralph Schoon
commented Jun 18 '13, 12:25 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I and others in Jazz Jumpstart and development are in violent agreement with your statement and determined to take up the challenge. It will require some time and informed input as much as we can get. Stay tuned. 1
Ralph Schoon
commented Jun 18 '13, 12:32 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
This especially holds true for formal planning. We have widely adopted agile but I think there is lack of experience with formal planning. But also keep in mind that RTC provides you with a life plan and not a file based plan that also hardly reflects reality. You will have to deal with the tool being aware of the time flowing. Yep, that is certainly something that I am aware of and I am working to get my team used to that style of planning. It has a lot of great benefits, but it takes time to adjust to it after years of creating a static plan at the start of a project and then trying to stick with it for 6 months even with changes and work being added (that is never updated in the plan because it is static).
I looked at https://jazz.net/library/article/658 and it has a lot of really helpful information (including the Planned Start/End Date listings in the work item editor (as discussed). But it stops short of giving best practices for when and how to take Planned Snapshots.
One question there asks about teams taking daily snapshots and Sharoon suggests the possibility of weekly snapshots. But I'd like to hear more about this. Have Formal Project Teams teams found weekly snapshots to be a best practice?
showing 5 of 9
show 4 more comments
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.