Observable Deliverable

To accomplish WellFormedWorkPackages it is essential that the deliverables which the task produces are observable. Too often a task is defined, such as "Design the rf Amplifier". It sounds good, but what is the deliverable? Often the task will have multiple definitions depending on who you talk to. The designer will have one idea, the project engineer another and the program manager yet another. Often the customer will have still another. All the stakeholders IncludeAllTheStakeHolders will also have different ideas. What a mess! This can all be avoided by clearly defining the deliverable when the task is defined.

In the instance I mention the rf amplifier design might have the following deliverables: 1) a schematic, 2) a prototype, 3) test results from operating the prototype under a predefined set of conditions included temperature surveys. This would all be spelled out in the work package definition and result in a check list of "observables" that is used to observe that the task is complete. -- RaySchneider