Data Baselining / Freezing
One feature of the dashboard occasionally catches people off guard. As an instructor, you should understand the “data freezing” feature so you can help students if they need it.
When engineers complete the assignments in the PSP course, there is a very clear delineation between projects. That is, the engineer will finish program 1A before starting program 2A, finish program 2A before starting 3A, and so on.
On real project work, this rarely holds true; engineers typically have several projects in progress concurrently. In addition, engineers will not generally complete projects in the exact order that the projects appear in their work breakdown structure. In this environment, the notion of “To Date” data becomes a little trickier to manage.
The dashboard is primarily designed to support real project work. So it includes a “data baselining” feature that helps manage “To Date” data, as well as the plans based upon “To Date” data.
Here's how it works: the dashboard maintains one set of “To Date” data. (Engineers can create additional sets of “To Date” data, but only one set exists by default.) This set of “To Date” data rolls up data from all projects that have been marked complete. Incomplete projects do not contribute to “To Date” data, since that would skew phase percentages and other “To Date” calculations.
When an engineer plans a project, per-phase estimates for time/defects are calculated using the current values of the “To Date” data. When the engineer marks the planning phase of a project complete, the dashboard baselines their plan. All “plan” values for the project become read-only and stop recalculating. At this point, the “To Date” data could change (perhaps because some different project was marked complete), and the per-phase estimates would not be recalculated because they have been baselined.
Similarly, when the engineer marks a project complete, all the values in the “To Date” column of the plan summary will be brought up to date, and then frozen. Since they are frozen, the numbers will now remain static; although the global “To Date” data will continue to evolve over time, the “To Date” numbers on this plan summary will remain fixed. This makes it possible to revisit the plan summary a year from now and still see historically accurate data.
During a PSP class, this feature has the potential to catch people off guard in at least three ways.
First, students may not realize that they should be marking tasks complete. If a student never marks their work complete, their “To Date” data column will always show zeros. For this reason, you should encourage students to mark each phase complete with the completion checkbox. Then, when they are finished with Postmortem they should look at their Project Plan Summary form and ensure that the project itself has been marked complete. They should do this before they submit their data to you.
Second, some students may mark the “Planning” phase complete, even if they aren't really done planning. Then, they can't figure out why the dashboard won't let them change their (baselined) estimates. They simply need to understand that they must mark planning incomplete, and the estimates will “thaw” and become editable again.
The final point of confusion applies more directly to the PSP course. Imagine the following scenario: a student has completed programs 1A, 2A, and 3A when they receive program 2A back from their instructor. Some of the numbers on their 2A plan summary were wrong, and need to be corrected. Of course, since 2A has been marked complete, all the data there is now read-only. The student decides to mark 2A incomplete so the data will thaw, and they can make the corrections. Unfortunately, this means that when they once again mark it complete, the 2A “To Date” column will now include data from program 3A.
To avoid this problem, discourage students from marking past assignments incomplete. If they need to correct mistakes on a previous plan summary, have them use the “Unlock read-only data” link at the bottom of the plan summary form instead.