Task: Plan the Project
A collaborative task that outlines an initial agreement on how the project will deliver the product vision. The resulting project plan provides a summary-level overview of the project.
Disciplines: Project Management
Extends: Plan Project
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.
Relationships
Main Description
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.
Steps
Establish a cohesive team
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.
Determine project size and scope

The team produces rough size estimates for each item  in the Artifact: Work Items List (see Guideline: Agile Estimation).  Considering product Vision, the estimates will be used for discussing with the stakeholders priorities for what seems realistic to develop within the constraints of the project. 

If the project is feature-driven, the team looks at how many people they would need to complete these work items, which gives them a high level understanding of project duration, staffing profile, and scope. If the project instead is date-driven, the team assesses how much work can roughly be done in the time-frame given and using the available team. Out-of-scope work can be considered in future releases.

Evaluate risks

The team identifies project risks, performs a qualitative risk analysis to assess their order of magnitude, and updates the Artifact: Risk List. The project manager facilitates the team decision about which risks they should respond to, and which risks they should watch for.

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.

Outline project lifecycle

Define the iteration length and use it to assess target velocity (see Guideline: Agile Estimation). 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.

OpenUP organizes iterations into a set of phases. Each phase in the project lifecycle will end with a milestone aimed at providing stakeholders with oversight and steering mechanisms to control project funding, scope, risk exposure, value provided, and other aspects of the process (see Concept: Project Lifecycle)

You don't need to spend too much time in doing this planning. The Project plan should document only  a brief summary of  project milestones and 1-3 objectives for each iteration. Do not commit individual work items to the plan, since this will force too much re-planning. The goal is just to create a high-level plan outlining how the team can build the resulting application in the given set of iterations. Extra level of detail will be achieved in other planning sessions throughout the project (see Task: Plan Iteration). You may need to revisit this plan later to adap it based on what you will learn by running the iterations (see Artifact: Iteration Plan from previous iterations).

Establish costs and articulate value

Develop a rough order of magnitude estimate for the costs of resources needed to complete project work items.  A simplified project costing model can be applied by multiplying the approximate cost per person for the entire team by the length of an iteration to derive ongoing financial impact (i.e., 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 help stakeholders to decide whether it's worth moving forward with the project or not. If necessary propose options to decrease costs, such as removing from the scope low value and high cost work items.

Plan deployment
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.
Key Considerations

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 necessary.

More Information