| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="_fPbdIKe2Edmzde8VFK5bxg" |
| name="plan_the_project,_0lC70MlgEdmt3adZL5Dmdw" guid="_fPbdIKe2Edmzde8VFK5bxg" |
| changeDate="2007-04-12T11:51:12.011-0700" version="1.0.0"> |
| <mainDescription>Developing the project plan provides an opportunity for the team to agree on project scope, objectives, initial timeframe,
 |
| 
 |
| and deliverables. It allows the team to begin demonstrating self-organization by defining success criteria and work
 |
| 
 |
| practices to be used. Collaboration and consensus by all key project participants is the goal, but the project manager has
 |
| 
 |
| ultimate responsibility for ensuring that everybody is committed to the plan.</mainDescription> |
| <keyConsiderations><p>
 |
| 
 |
| Gain agreement with stakeholders and the rest of the project team regarding the order of objectives and the duration of
 |
| 
 |
| the project and make adjustments as&nbsp;necessary.
 |
| 
 |
| </p></keyConsiderations> |
| <sections xmi:id="_JLWeYOeUEdusqr8cJFUf_w" name="Establish a cohesive team" guid="_JLWeYOeUEdusqr8cJFUf_w"> |
| <sectionDescription>Gather a team with the right mix of personalities and skills for the project. Project planning, even at the summary level,
 |
| should not be done in isolation since it outlines what the project will deliver and how. The team starts by discussing who
 |
| plays which roles and agrees on their responsibilities. The project manager needs to make sure that staffing is made in
 |
| accordance with the project's interests and that every necessary role is covered.</sectionDescription> |
| </sections> |
| <sections xmi:id="_lQsYcOeUEdusqr8cJFUf_w" name="Discuss release roadmap" guid="_lQsYcOeUEdusqr8cJFUf_w"> |
| <sectionDescription>Based on the broad goals set on <a class="elementLinkWithType" href="./../../openup/workproducts/vision_2E71B03C.html" guid="_0WVxcMlgEdmt3adZL5Dmdw">Artifact: Vision</a>, stakeholders determine the product release roadmap. They communicate
 |
| to the team when releases are needed and what features are sufficient for each one. Discussion of releases is focused on
 |
| their business value but the team can provide technical input to the roadmap. The Project Plan is updated with the foreseen
 |
| release roadmap, defining dates, theme and objectives for each one. Releases are several months long, being 2 to 4 months
 |
| the most common timeframe.</sectionDescription> |
| </sections> |
| <sections xmi:id="_oQ7PQOeUEdusqr8cJFUf_w" name="Estimate project size" guid="_oQ7PQOeUEdusqr8cJFUf_w"> |
| <sectionDescription>According to the release roadmap the team creates a candidate <a class="elementLinkWithType" href="./../../openup/workproducts/work_items_list_39D03CC8.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>
 |
| that defines the scope for the near term releases and produces rough estimates for each item (see <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>). Estimates will be used for discussing with the
 |
| stakeholders priorities for what seems realistic to develop within the constraints of the project. Out-of-scope work can be
 |
| considered in future releases.</sectionDescription> |
| </sections> |
| <sections xmi:id="_pzgcUOeUEdusqr8cJFUf_w" name="Evaluate risks" guid="_pzgcUOeUEdusqr8cJFUf_w"> |
| <sectionDescription><p>
 |
| The team identifies project risks, performs a qualitative risk analysis to assess their order of magnitude, and updates
 |
| the <a class="elementLinkWithType" href="./../../openup/workproducts/risk_list_C4B6F290.html" guid="_Ckay8Cc_EduIsqH1Q6ZuqA">Artifact: Risk List</a>. The project manager facilitates the team decision about which
 |
| risks they should respond to, and which risks they should watch for.
 |
| </p>
 |
| <p>
 |
| Responses may include avoiding or mitigating risks, exploring opportunities or increasing the probability and positive
 |
| impacts of the risk. Depending on the case, work items may have to be added or removed from the Work Items List to make
 |
| sure that responses will be prioritized and handled by the team along with project work. As it is not feasible to plan
 |
| responses for all risks identified, the team can decide to accept some of them. Risks to watch will be communicated to
 |
| stakeholders and remain on the Risk List and actions will be determined only if they occur.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_rGkmsOeUEdusqr8cJFUf_w" name="Articulate costs and value" guid="_rGkmsOeUEdusqr8cJFUf_w"> |
| <sectionDescription>Develop a rough order of magnitude estimate for the costs of resources needed to complete project work items. Aggregate
 |
| them into a budget that allows the stakeholders to decide whether it's worth moving forward with the project or not.
 |
| Estimates must be in a range and be refined as the project progresses. This first round of planning should keep things very
 |
| rough and flexible. The goal is to articulate value against the budget constraints of the project and propose options to
 |
| decrease costs. Low value and high cost work items may have to be removed from scope.</sectionDescription> |
| </sections> |
| <sections xmi:id="_sWzfgOeUEdusqr8cJFUf_w" name="Schedule iterations" guid="_sWzfgOeUEdusqr8cJFUf_w"> |
| <sectionDescription><p>
 |
| Decide which phases are needed in the release lifecycle and break them into iterations (see <a class="elementLinkWithType" href="./../../openup/guidances/concepts/iteration_C20B1904.html" guid="_lam4ADkBEduxovfWMDsntw">Concept: Iteration</a>). The first release will probably need iterations more focused on
 |
| the elaboration of the architecture than subsequent releases, which in turn will be mainly about construction over the
 |
| baselined architecture and transition to the end-users.
 |
| </p>
 |
| <p>
 |
| Define the iteration length and use it to assess target velocity (see <a class="elementLinkWithType" href="./../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html" guid="_CGHskBEdEdqY7JB6N6CW2w">Guideline: Agile Estimation</a>). The number of items to be delivered in each iteration will be set by the velocity of the team and the
 |
| estimates for each item. The team uses the Work Items List to outline what features to implement in what iteration,
 |
| putting top priority work items first, including planned responses to the higher risks or opportunities.
 |
| </p>
 |
| <p>
 |
| You don't need to spend too much time in doing this planning. Produce a brief summary of the iteration schedule
 |
| in&nbsp;the Project Plan by documenting 1-3 objectives for each iteration. Do not commit individual work items to the
 |
| plan, since this will force too much re-planning. That will be done in other planning sessions throughout the project
 |
| (see <a class="elementLinkWithType" href="./../../openup/tasks/plan_iteration_957C90DC.html" guid="_0keUEMlgEdmt3adZL5Dmdw">Task: Plan Iteration</a>). The goal is to create a high-level plan outlining
 |
| how&nbsp;the team&nbsp;can build the resulting application in the given set of iterations. You may need to
 |
| revisit&nbsp;this plan&nbsp;later to adap it based on what you will learn&nbsp;by&nbsp;running&nbsp;the iterations (see
 |
| <a class="elementLinkWithType" href="./../../openup/workproducts/iteration_plan_B46FED39.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a>&nbsp;from previous iterations).
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_tuymIOeUEdusqr8cJFUf_w" name="Plan deployment" guid="_tuymIOeUEdusqr8cJFUf_w"> |
| <sectionDescription>Plan the strategy for deploying the software (and its updates) into the production environment. Discuss release timeframe
 |
| 
 |
| with the operations and support departments to ensure that your project fits into your overall corporate deployment system.
 |
| 
 |
| If you are replacing an existing system, decide whether you will run the new system in parallel with it or you will perform
 |
| 
 |
| a cutover. You may also have to negotiate with the owners of the systems that the new system has dependencies on. Update
 |
| 
 |
| the Work Items List with additional work that may be needed for deployment. Add significant deployment risks to the Risk
 |
| 
 |
| List and, if necessary, make adjustments to the Project Plan.</sectionDescription> |
| </sections> |
| <purpose>Get stakeholder buy-in for starting the project and team commitment to move forward with it. This plan can be updated along
 |
| 
 |
| the project based on feedback and changes in the environment.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
