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.

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.

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: Planejar Iteração). 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).

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.