MSF for CMMI Process Improvement Visual Studio Team System logo
workstreams icon

Plan Project

Project Manager

Participating Roles

Responsible:

Project Manager

Accountable:

Project Manager

Consult:

Any

Informed:

All

Overview

Entry Criteria

  • Vision Statement
  • Business Case
  • Personas
  • Scenarios
  • Lifestyle Snapshots
  • Storyboards
  • Master Schedule

Activities

1

Determine Risk Sources and Categories

  • Brainstorm a list of categories for risk and enumerate a list of possible sources of risk.

2

Define Risk Parameters

  • Define the parameters to be captured for identified risks.

3

Determine Risk Management Strategy

  • Define a strategy in terms of organization and operational procedures for managing risks throughout the life cycle of the project.

4

Plan Project Resources

  • Outline the required personnel, facilities, and equipment that will be needed throughout the life of the project.

5

Plan Project Knowledge and Skills

  • Based on the brief details available from the vision statement and the persona definitions, identify any specialist knowledge or skills needed for this project.

6

Form Project Team

  • Put together a core team to guide the project from start to finish.

7

Establish Project Team Charter

  • The core project team should develop a charter for their work and define the goals of the project and the constraining parameters within the wider organization.
  • A charter should define what the team does and what it does not do.
  • A charter should clearly communicate to the rest of the organization what to expect from the project team.

8

Define Project Roles and Responsibilities

  • For core project team members, define their roles and responsibilities.

9

Define Project Communication Plan

  • Plan how the team will communicate with the wider organization and across other projects within a program.
  • Plan how core team members will communicate with each other.

10

Identify Project Stakeholders

  • Using the vision statement and persona definitions, brainstorm a list of all the project stakeholders.

11

Define Budget and Schedule

  • Based on the business case, vision statement, personas, outlined end-to-end scenarios and storyboards gleamed from lifestyle snapshots or brainstorming, define a delivery date and a budget for the project.
  • Delivery dates are usually determined by external events. In some circumstances a project is entirely scope-driven; in which case the delivery date has to be calculated from more detailed plans. If this is true, then defer the delivery date calculation until detailed estimating is possible.
  • Determine the dependencies between and within the end-to-end scenarios.
  • Divide the schedule into a series of iterations. Determine the appropriate length of the iterations for this project. Typically the length is between two and six weeks; never longer than three months.
  • Apportion the scenarios and personas across the iterations as a rough guide to what functionality will be delivered at which point in the project schedule.
  • Determine a budget using the business case as input and based on the proposed delivery date and the proposed resource plan. If an end date is not yet known, propose the budget based on the business case. The resources and schedule must fit within the budget based on detailed estimates or the project may be cancelled in the Planning Track Governance checkpoint.

12

Plan Project Stakeholder Involvement

  • Estimate when in the life cycle of the project individual stakeholders will need to be involved.
  • Estimate the level of individual involvement at different periods in the life cycle.

13

Estimate Project

  • If the project has a scheduled end date, then project level estimating is simple. Provide the rough resource estimate, the schedule of iterations, and approximate scope of deliverables in each iteration.
  • Detailed iteration estimates will be deferred to the iteration.
  • If an end date is not known because the project is scope-driven, then solicit additional requirements facilitation and analysis in order to derive more detailed plans.
  • Wait until more detailed requirements and analysis is available then estimate each requirement individually.
  • Repeat the Define Budget and Schedule activity using the additional detailed estimates as input.

14

Define Operating Procedures

  • Define the operational management procedures for the day-to-day running of the project.

15

Plan Project Review

  • Publish the proposed project plan. Note this is the outline plan described above. It is not intended to be a detailed plan describing every aspect of the project. The detailed planning is deferred until each iteration begins.
  • Schedule a review with the core project team and any other stakeholders who are available.
  • Review the plan and make any changes necessary to form a consensus.
  • Publish the plan on the project portal.

16

IPMO Project Review

  • Take the project plan to the next scheduled integrated project management office (IPMO) meeting.
  • Present the plan and solicit input on shared resource availability, impact on existing schedules, and stakeholder involvement.
  • Agree to modifying the plan based on feedback from the meeting.

17

Obtain Project Commitments

  • Based on the final plan revised against the whole organization project portfolio, obtain commitments to the iteration plan from all iteration team members and the project sponsor.

Exit Criteria

(C) 2005 Microsoft Corporation. All rights reserved.

MSF for CMMI Process Improvement: Build 050707