One approach would be to go through each of the steps in the Step Wise framework, identifying the products created. You might end with something like this.
0. Select project: feasibility report
1. Identify project scope and objectives Terms of reference
2. Identify project infrastructure Standards, procedures relating to progress reporting, change control etc
3. Analyze project characteristics Technical plan, risk register
4. Identify the products and activities Product breakdown structure, product descriptions, product flow diagrams, 'ideal' activity network
5. Estimate effort for each activity Schedule of task durations and costs
6. Identify activity risks. Updated schedule of task durations and costs, updated risk register
7. Allocate resources Gantt chart
8. Review publicize plan: Publicized plan
9. Lower level planning: Detailed plans
A second approach might be to take the contents of the plan document and treat each sub-section as a product in its own right.
Discussion points might include:
Sometimes a product could be an updated version of some existing product. Planning in some way is a particular type of design process, you will often have to go back and modify things you have already created. This leads to the need for having points when products are baseline ie, when they can no longer be changed without a formal management process being adhered to.
What products must exist before the activity test program can take place. What products does this activity. These seemingly straightforward questions get students to think about what is really involved in the testing process.
One question that may arise is what is meant by program testing. Does it include the process of error diagnosis, correction and retesting the program. When you are allocating time and resources to this in a project, then the answer is probably yes. If so then a wider range of products could be identified example corrected software, change requests, off-specification.
An employee of a training organization has the task of creating case study exercises and solutions for training course which teaches a new systems analysis and design method. The person's work plan has a three-week task learn new method. A colleague suggests that this is unsatisfactory as a task as there is no concrete deliverable or products from the activity.
In order to carry out usability tests for a new word processing package, the software has to be written and debugged. User instructions have to be available describing how the package is to be used. These have to be scrutinized in order to plan and design the tests. Subjects who will use the package in the tests will need to be selected.
As part of this selection process, they will have to complete a questionnaire giving details of their past experience of, and training in, typing and using word processing packages. The subjects will carry out the required tasks using the word processing package. The tasks will be timed and any problems the subjects encounter with the package will be noted.
After the test, the subjects will complete another questionnaire about what they felt about the package. All the data from the tests will be analyzed and a report containing recommendations for changes to the package will be drawn up. Because the Product Flow Diagram is often the product of a subjective process, it is always worth getting the person drafting the Product Flow Diagram to write down a rationale for the particular sequence of activities.
The training plan will outline the structure of the course with rough timings for the major topics. This will has to be agreed with the client. The plan presumes that the training provider uses the design of the overheads as a preliminary step in the detailed design of the course.
The overheads are then complemented by training notes and exercises. The manual brings these together into a package for the trainees. The number of trainees must be known before the material is printed so that we know how many copies to make.