| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="_fPbdIKe2Edmzde8VFK5bxg" |
| name="plan_the_project,_0lC70MlgEdmt3adZL5Dmdw" guid="_fPbdIKe2Edmzde8VFK5bxg" |
| changeDate="2008-07-14T13:50:23.405-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 role responsible for
 |
| this task must ensure 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. Make adjustments as&nbsp;necessary.
 |
| </p></keyConsiderations> |
| <sections xmi:id="_gu-PgIyBEdyhZb-MhCJrlA" name="Identify a cohesive team" guid="_gu-PgIyBEdyhZb-MhCJrlA"> |
| <sectionDescription>Revisit the resourcing for the project.&nbsp;Identify gaps and initiate hiring or re-allocation of resources as needed.
 |
| Discuss with the team who plays which roles, and have them agree on their responsibilities.</sectionDescription> |
| </sections> |
| <sections xmi:id="_jknm8IyBEdyhZb-MhCJrlA" name="Estimate project size " guid="_jknm8IyBEdyhZb-MhCJrlA"> |
| <sectionDescription><p>
 |
| The&nbsp;team produces rough size estimates for each work item&nbsp;found in the <a class="elementLink"
 |
| href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project
 |
| Work]</a>.
 |
| </p>
 |
| <p>
 |
| Discuss with stakeholders to&nbsp;determine what is realistic to develop within the constraints of the
 |
| project.&nbsp;Use stakeholder priorities and estimates from the team to guide these discussions.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_4Xg3QOFpEdyhmsbt0Xyl8A" name="Forecast project velocity and duration" |
| guid="_4Xg3QOFpEdyhmsbt0Xyl8A"> |
| <sectionDescription><p>
 |
| Define the iteration length and use it to assess target velocity. 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.
 |
| </p>
 |
| <p>
 |
| If the project is feature-driven, the team uses the <a class="elementLink"
 |
| href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project
 |
| Work]</a>&nbsp;and target velocity to forecast the number of iterations required to complete the project. If the
 |
| project instead is date-driven, the team assesses (using the known velocity of the&nbsp;team) roughly how much work can
 |
| be done in the given time-frame. Out-of-scope work can be considered&nbsp;for future releases.
 |
| </p>
 |
| <p>
 |
| The team should not spend too much time&nbsp;doing this planning. The project plan should document only&nbsp;a brief
 |
| summary of&nbsp;project milestones&nbsp;and between one and three objectives for each iteration. Do not commit
 |
| individual work items to the plan, because this will force too much re-planning. The goal is just to create a
 |
| high-level plan outlining how&nbsp;the team&nbsp;can build the resulting application in the given set of iterations.
 |
| Extra levels of detail will be achieved in other planning sessions throughout the project (for example, when planning
 |
| iterations). You may need to revisit&nbsp;this plan&nbsp;later to adapt it based on what you will
 |
| learn&nbsp;by&nbsp;running&nbsp;the iterations.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_lrYj0MBAEdqSgKaj2SZBmg" name="Evaluate risks" guid="_lrYj0MBAEdqSgKaj2SZBmg"> |
| <sectionDescription><p>
 |
| The team identifies project risks, performs a qualitative risk analysis to assess their order of magnitude, and updates
 |
| the&nbsp;<a class="elementLink" href="./../../core.mgmt.slot.base/workproducts/project_risk_slot_FC0351C4.html"
 |
| guid="_0TkXgNpUEdyzZqGyZ7hwdw">[Project Risk]</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 <a class="elementLink"
 |
| href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project
 |
| Work]</a> to make sure that responses will be prioritized and handled by the team along with other project work.
 |
| Because it is not feasible to plan responses for all identified risks, the team&nbsp;may decide to accept some of them.
 |
| Keep the risks to watch in the risks list, and communicate them to stakeholders.&nbsp;Determine actions only if they
 |
| occur.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_xWBhUIyBEdyhZb-MhCJrlA" name="Establish costs and articulate value" |
| guid="_xWBhUIyBEdyhZb-MhCJrlA"> |
| <sectionDescription><p>
 |
| Develop a rough order of magnitude estimate for the costs of resources needed to complete project work items.&nbsp;A
 |
| simplified project costing model&nbsp;can be&nbsp;applied by&nbsp;multiplying the approximate cost per person for the
 |
| entire team by the length of an iteration to derive ongoing financial impact (that is, cost per iteration). This first
 |
| round of planning should keep things very rough and flexible. The goal is just to articulate value against the budget
 |
| constraints of the project, and to help stakeholders decide whether it is worth moving forward with the project or not.
 |
| If necessary, propose options to decrease costs, such as removing low-value and high-cost work items from the scope .
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_zeN84IyBEdyhZb-MhCJrlA" name="Plan deployment" guid="_zeN84IyBEdyhZb-MhCJrlA"> |
| <sectionDescription><p>
 |
| Plan the strategy for deploying the software (and its updates) into the production environment as early as possible,
 |
| because it may impact the <a class="elementLink"
 |
| href="./../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project
 |
| Work]</a>. The team may need to discuss the release timeframe with the operations and support departments to ensure
 |
| that the project fits into the overall corporate deployment system.
 |
| </p>
 |
| <p>
 |
| Whenever possible, the team should consider deploying small releases (release cycles of three to four months at most).
 |
| Releasing software into production frequently is a good way to&nbsp;get early feedback from the users, in order
 |
| to&nbsp;enhance the overall product quality.
 |
| </p>
 |
| <p>
 |
| Capture the objectives for deployment and release dates in the <a class="elementLink"
 |
| href="./../../practice.mgmt.two_level_project_planning.base/workproducts/project_plan_1CDBB7E4.html"
 |
| guid="_0a6vcMlgEdmt3adZL5Dmdw">Project Plan</a>.
 |
| </p></sectionDescription> |
| </sections> |
| <purpose>Get stakeholder buy-in for starting the project and team commitment to move forward with it. This plan can be updated as
 |
| the project progresses based on feedback and changes in the environment.</purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
