As mentioned yesterday at the beginning of class, the quality of the W5HH submissions varied widely. Perhaps it would have been helpful to spend some class time talking about the assignment because we haven’t talked much about project management per se, only touching on it tangentially in the lessons on process models and agile development. Consequently, it bears mention that the W5HH principle summarizes key project characteristics and applies regardless of project size or complexity. A well-written version should be sufficiently detailed that another team could execute the plan without additional information (and complete the project successfully!).

Given the opportunities for improvement, each team may resubmit the assignment by 1030 on Monday, 24 September. I will regrade the submission and the final score for the assignment will be the average of the two submissions. This opportunity reflects the fact that software engineering is an iterative process where feedback and revisions improve the final product. In addition, it is likely that you will encounter similar assignments in other contexts, such as your capstone projects next year, and I want you all to have a good example that you can use as a template.

As you consider revisions, feel free to schedule a meeting with me if you have questions regarding my feedback. I’ll also provide the following synopsis for each section that guided my review and grading:

Why
The background should describe the project, including its rationale (i.e., importance) and alternatives. A small amount of original research may be appropriate. The description should go beyond the information provided in the project description.
What
Is the scope for the project clearly defined? Is it unambiguous and understandable at the technical and managerial levels? Are the tasks to complete the objectives defined, at least at a high level?
When
Is a tentative project schedule included? Are there milestones to identify separate phases of the project? Are there clear deliverables for each milestone? Is the schedule realistic? For tasks that require coordination among teams, are the teams’ respective schedules consistent?
Who
With multiple people working together on the project, it is important for each person to have clear responsibilities. What organizational paradigm will be used? Are the responsibilities for each role defined? Are the integration points with other teams (or software libraries) identified?
Where
Are the responsibilities of those outside the project team enumerated? Such responsibilities likely include integration points with other teams.
How
Is there a project and technical management strategy? If not, who will resolve disagreements should they arise? How will tasks that require coordination among teams be managed?
How
Is a tentative project schedule included? Are the estimates appropriate for the scope of the project? Are the computing resources (e.g., physical hardware) described?