Version 3 (modified by yliu, 3 years ago)


2.1 Management Plan

An initial management plan should by submitted on 4/5/10. This plan should include

  • Description of the major areas of responsibility for each team member.
  • Definition of your beta and version 1 releases using use cases, storyboards, and/or other models you deem appropriate. You should define the "must have" and "want to have" features and capabilities.
  • Feature freeze and code freeze dates for your beta and version 1 release.
  • Risk analysis.
  • Initial goal breakdown for phase 3 including (at least) the required deliverables and their dependencies.
  • Goal stack including well-modeled goals for (at least) the next week of the project.
  • Plan for the next week including goals to be achieved and team members' responsibilities (via tickets).
  • A summary of work in the first week of phase 3.

Your goal breakdown should divide the major deliverables of phase 3 into smaller and smaller subcomponents until they represent well-defined tasks that can be completed by one person in a couple of hours. Your goal stack will contain the prioritized and sequenced nodes of your goal breakdown. By sequenced we mean that a goal cannot appear above any of its (AND) subgoals in the stack. You need not completely break down all goals at the beginning; just be sure that goals at the top of the stack are well-defined tasks. It is important, however, that you resolve major risks early; e.g. by exploratory work (goals) such as proofs of concepts.

Error: Failed to load processor b
No macro or processor named 'b' found

By Tuesday class time each week, you should update your project plan to reflect the proposed work for the coming iteration (1 week). This includes a new risk analysis, further elaboration of your goal breakdown, updating your goal stack and identifying the goals to be achieved in the coming week, estimating the time you expect each goal will take to complete, and issuing tickets for those goals.

You must also provide a status report that discusses the progress made in the past week. This should identify the goals that were completed, how long it actually took compared to your estimates, and if your estimates are off, abrief discussion on how you plan to improve your estimates in the future. (Note, your work logs should clearly identify who worked on what goals for how long!) You should also discuss goals that were not completed, why, and how to avoid similar problems in the future. [[\b]]

Your management planning will be graded on a weekly basis with 20 points assigned to the initial plan, 5 points for each of the next two updates, and 10 points for the final plan (which covers two weeks). The grading rubric for the inital plan is:

  • (1 pts.) Clarity of general responsibilities for team members
  • (5 pts.) Quality of beta and v1 release definitions
  • (3 pts.) Completeness of risk analysis
  • (3 pts.) Quality of goal breakdown (includes all major work, elaborates high-risk, high-priority goals)
  • (3 pts.) Quality of goal stack (good prioritiziation and clearly elaborated goals for next week)
  • (3 pts.) Clarity of plans for the next week (goals, responsibilities, tickets)
  • (2 pts.) How well you advanced the project in the first week

The grading rubric for each iterim update is:

  • (1 pts.) Completeness of risk analysis and prioritization of goals
  • (1 pts.) Clarify of goals and appropriateness of your plan for the week
  • (1 pts.) Use of wiki and tickets to document progress (including individual work logs)
  • (1 pts.) Completeness and quality of status report
  • (1 pts.) How well you completed the goals from the prior week

Final update values are double the interim update.