An overview of project planning
One approach would be to follow each of the steps in the Step Wise framework, identifying the products created. You could end up with something like this.
0. Select project: feasibility report
1. Identify the scope and objectives of the project Terms of reference
2. Identify project infrastructure standards, procedures related to progress reports, change control, etc.
3. Analyze the characteristics of the project Technical plan, risk register
4. Identify products and activities Product breakdown structure, product descriptions, product flow diagrams, ‘ideal’ network of activities
5. Estimate effort for each activity Schedule task durations and costs
6. Identify the risks of the activity. Updated schedule of task durations and costs, updated risk register
7. Resource Allocation Gantt Chart
8. Review advertise plan: Advertised plan
9. Lower Level Planning: Detailed Plans
A second approach might be to take the content of the plan document and treat each subsection as a product in its own right.
Discussion points may include:
Sometimes a product may be an updated version of an existing product. Planning in a way is a particular type of design process, often you will have to go back and modify things you have already created. This leads to the need to have points when the products are basic, that is, when they can no longer be changed without a formal management process being followed.
Which products must exist before the activity testing program can be carried out. What products does this activity have? These seemingly simple questions make students think about what the assessment process really entails.
One question that may arise is what is meant by program testing. It includes the process of diagnosing errors, correcting and retesting the program. When you’re allocating time and resources to this in a project, then the answer is probably yes. If so, a broader range of products could be identified, eg, fixed software, change requests, out of specification.
An employee of a training organization is tasked with creating case study exercises and solutions for a training course that teaches a new method of systems analysis and design. The person’s work plan has a three-week task to learn a new method. A colleague suggests that this is not a satisfactory task, as there are no concrete deliverables or products of the activity.
To carry out usability testing for a new word processing package, the software must be written and debugged. User instructions must be available describing how the package should be used. These have to be examined to plan and design the tests. It will be necessary to select the subjects who will use the package in the tests.
As part of this selection process, they will need to complete a questionnaire detailing their previous experience and training in typing and using word processing packages. Subjects will perform the required tasks using the word processing package. Tasks will be timed and any problems the subjects encounter with the packet will be noted.
After the test, the subjects will complete another questionnaire about how they felt about the package. All test data will be analyzed and a report will be produced with recommendations for changes to the package. Because the Product Flow Diagram is often the product of a subjective process, it is always worthwhile for the person writing the Product Flow Diagram to write a rationale for the particular sequence of activities.
The training plan will describe the structure of the course with approximate times for the main topics. This will has to be agreed with the client. The plan assumes that the training provider uses the design of the slides as a preliminary step in the detailed design of the course.
The slides are then supplemented with training notes and exercises. The manual puts them together in a packet for students. The number of students must be known before printing the material in order to know how many copies to make.