Capability Pattern: Project Management
This capability pattern covers the activities and workflow for the Project Management discipline.
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Description

To explain the work involved in the Project Management discipline, the activities and work products are organized into a capability pattern for the discipline.

Each activity represents a high-level goal that needs to be achieved to perform effective project management.  In the initial iteration of the Capability Pattern: Inception Iteration, the Project Management discipline begins in Activity: Conceive New Project , during which the initial Artifact: Vision, Artifact: Business Case and Artifact: Risk List artifacts are created and reviewed. The objective is to obtain enough funding to proceed with a serious scoping and planning exercise.

An embryonic  Artifact: Software Development Plan is created, and the project bootstrapped into life with the initial Artifact: Iteration Plan. With this initial authorization, work can continue on the Artifact: Vision, Artifact: Risk List and Artifact: Business Case in Activity: Evaluate Project Scope and Risk. This is used to give a firm foundation for fleshing out the  Artifact: Software Development Plan. Reference: Activity: Plan the Project.

At the conclusion of Plan Project, enough should be known about the risks and possible business returns of the project, to allow an informed decision to be made to commit funds for the rest of the Inception Phase, or to abandon the project. Next, the initial Iteration Plan is refined to control the remainder of the initial iteration in inception, in an invocation of Activity: Plan for Next Iteration (the activity used here is the same as will be used for planning subsequent iterations - hence the somewhat odd name in this context). In Plan for Next Iteration, the Role: Project Manager and Role: Software Architect decide which requirements are to be explored, refined or realized. In early iterations, the emphasis is on the discovery and refinement of requirements; in later iterations, on the construction of software to realize those requirements.

At this point, the Discipline: Project Management merges into a common sequence for all subsequent iterations.

The iteration plan is executed in Activity: Manage Iteration, which is concluded by an iteration assessment and review, to determine if the objectives for the iteration have been achieved. The  Task: Iteration Acceptance Review may determine that the project should be terminated, if the iteration has significantly missed its objectives, and it is judged that the project cannot recover during subsequent iterations.

Optionally, at about the mid-point of the iteration, an Task: Iteration Evaluation Criteria Review may be held, to review the iteration  Artifact: Test Plan, which by this stage should be well-defined. This optional review is usually held only for lengthy (six months and longer) iterations. It gives project management and other stakeholders the opportunity to make mid-course corrections.

In parallel with Manage Iteration, the routine daily, weekly and monthly tasks of the project management are performed in Activity: Monitor & Control Project, with the idea that expectations may need to be reset based on the experience of the previous iteration.

When the final iteration of a phase completes, a major milestone review is held as part of Activity: Close-Out Phase. Planning is done for the next phase, assuming the project is to continue. At the conclusion of the project, a  Task: Project Acceptance Review is held as part of Activity: Close-Out Project. At this point the project terminates, unless the review determines that the delivered product is not acceptable, in which case a further iteration is scheduled.

Detailed planning, in Activity: Plan for Next Iteration, then leads into the next iteration. In parallel, changes to the Software Development Plan are made at this time, in Plan Project, capturing lessons learned, and updating the overall Project Plan (in the Software Development Plan) for later iterations.

Properties
Event-Driven
Multiple Occurrences
Ongoing
Optional
Planned
Repeatable
Usage
Usage Notes

Decide How to Perform the Workflow

The following decisions should be made regarding the Project Management discipline's workflow:

  • Decide how to perform the workflow by looking at the activities in this workflow. Study the diagram with its guard conditions and the guidelines. Decide which activities to perform and in which order. 
  • Decide what parts of the Project Management activities to perform. The table below shows some parts that can be introduced relatively independently from the rest.
  • Decide when, during the project lifecycle, to introduce each part of the workflow.

Part of workflow

Comments

Iterative development Some customers have an existing project management workflow, but are interested in introducing the parts of the Rational Unified Process Project Management discipline that focus on iterative, risk-driven development: Activity: Plan for Next Iteration, Activity: Manage Iteration, and Activity: Evaluate Project Scope and Risk
Project start-up Some parts of the Project Management discipline focus on the start of the project and should be introduced early in the project: Activity: Conceive New Project, Activity: Evaluate Project Scope and Risk, and Activity: Plan the Project
More Information