http://www.testablerequirements.com/Articles/solomon.htm is one source
Some more thoughts.When the rework is defined in the WBS and the costs associated with that that work activity, performance for the rework needs to be captured in the same way the previous work efforts were budgeted and measured.
Sorry but this is going to be lengthy!There are two interpretations I can see from your statement Craig:1) Rework, retesting and refurbishing should not be called out as separate branches on the WBS from their respective deliverables, but should instead be added as new children elements/work packages as required.2) Existing WBS elements/work packages should be increased in scope to include any necessary rework, retesting and refurbishing. In this case a WBS element 2.2.3 for example would just be augmented to include the additional scope.I agree with interpretation 1) fully. I disagree with interpretation 2) fully!In my WBS training course I point out that testing should be included as a child element of the deliverable being tested, but not as a separate branch of the WBS altogether. It's important to be called out separately so it receives the attention it deserves and yet it still needs to be attributed to the specific deliverable. Failure to do this, in my experience, leads to last-minute shortcuts in critical testing and integration activities (thus, rework).Testing & integration of multiple systems or subsystems is another matter. In this case you may have a separate branch for this kind of SE scope (integration, test, security) as it applies to the entire product. A chief engineer or architect works at this level most of the time, leaving system or sub-system specific SE activities to the engineers for those deliverables.Check out the "Planning for Defects and Rework" section of the link Glen provided. Here Paul points out the following:"...rework should be planned in separate work packages. Failure to establish a baseline plan for rework and to accurately measure rework progress caused many projects to get out of control. "Paul's observation here agrees with my experience. Ignoring the distinct nature of testing, integration, rework, and even security by representing them distinctly leads to sweeping them under the rug, off the radar, and makes them prone to quality risks. It also makes performance management much more difficult than it needs to be.Josh Nankivel, BSc PM, PMPpmStudent.com
Thanks for the comments guys.My sentiments lie with Josh's Definition 1. I'll come bck to this in the future, but am battling sleeplessness from an overnight flight today.
Craig and Josh,If the WBS package is expanded then the Performance Measurement Baseline will be non-compliant with DCMA (Defense Contract Mamnagement Agency). This may be irrelavent to to commerical projects, but it is generally bad practice no matter what domain.And if you're going to do WBS you might as well do it right.Having rework embedded in the workpackage that produices a product hides the work effort. Poor practice.
Rework from the outside is treated differently from rework generated inside, right?Externally initiated rework is a new work package. Internal is an example of the existing one not being completed.The best way to handle this second scenario is to have good, clear, unambiguous statements of what done looks like and to test appropriately before release/closure of the WP.
Craig,Rework initiated from the ouside should be considered scope change and managed through a change control process. Adding budget and time to the baseline is the result of the change control process.Rework internally results from "defects" in the produced product or non-compliant materials in the ISO world.There can be planned budget for that. See Paul Salomon's discussion on EV and SW in CrossTalk. But in order to "plan" for this rework, some understanding of the rate of rework is needed to forecast the needed budget and time.Management Reserve cannot e used to "repair" broken product. This is a common mistake in SW projects, where they use he baseline budget to "get back on schedule," or "repair faulty software." This eats the seed corn as we would say, and causes disappointment all around.When you look at many of the Standish style project failures, the budget control process was not properly handled. They're over budget and behind schedule because they did not separate the three budgets processes:1. Baseline and it's planned rework allocation2. MR3. Unplanned rework
So, if you have screwed up and need to rework something your next question is "Is this something that will happen again?"If so then your estimated rate of progress needs to be adjusted, along with expected end dates, budgets, etc.As for visibility; failing to deliver a work package should be visible in any number of ways, but I am not sure a new work package is the answer. That strikes me as camouflaging the issue in the guise of "new work."
(In my experience and with due respect)As to the first point of course I agree that a red flag should be raised, the root cause should be evaluated and applied as new knowledge for future planning.On the second point, by clearly labeling the new work package as rework, retesting, etc. you eliminate the possibility of camouflaging the issue.When dates slip and rework is incorporated into existing work packages it's much easier to have forgotten about it 3 months down the road and not learned the lessons the experience could have taught.
Josh and Craig,I re-assume we're talking abiout measuring physical percent comment using some method (EV is a good one) in the context of "rework."If you have unplanned rework, your physical percent is reduced by that amount.If your rework is planned - i.e. there is a "planned effort and duration" for the rework in the performance baseline - it is part of the progress of the project. That's how it's do in the federal government under the FAR.If the second "rework" package is planned, there is no reason to assume it hides the root cause. The assessment of the root cause is part of the opening activities of the WP - simple as that. This happens all the time, when we receive something from a subcintarctor that needs repair or alteration, or a part or product internally that needs "update" or altertaion because the system it's going to has been changed. OR and this is more common it has a defect for some good reason. This is called "planned improvements." Now if the defects were unplanned, then that is unrecoverable sunk cost from the cost performance side and the root cause analysis needs to stop that dead. 100% "fit for use" is the guidance in any project that has control of the work processes. Doesn't mean things don't break or show up busted, but it should only happen once.
Josh,Could you explain a bit about "incorporating" reworking in the the work package. Is this a task in the WP, or is it a separate WP.Our System Description has us doing rework in a separate WPs, which then make explicitly visible the "reason" for the rework
Sure Glen. I'm advising against incorporating rework into an existing WP. For instance if a review failure occurs and a delta review is now required, I would create new WP's as necessary to explicitly capture the scope related to "Delta PDR" or whatever it was.So if I had 4 systems and 2 of them failed the review I'd end up adding WPs that specifically capture the scope required for the delta review on those 2.
Josh,Sorry I misunderstood. Yes, rework MUST be accounted for external to the planned work.