Guidelines: Important Decisions in Project Management

The following decisions should be made regarding the Project Management discipline's 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: Workflow Detail: Plan for Next Iteration, Workflow Detail: Manage Iteration, and Workflow Detail: 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: Workflow Detail: Conceive New Project, Workflow Detail: Evaluate Project Scope and Risk, and Workflow Detail: Develop Software Development Plan.

Document the decisions in the Development Case, under the headings Disciplines, Project Management, Discipline.

Decide How to Use Artifacts

Decide which artifacts to use and how to use each of them. The table below describes those artifacts you must have and those used in some cases. For more detailed information on how to tailor each artifact, and a discussion of the advantages and disadvantages of that specific artifact, read the section titled "Tailoring" for each artifact.

For each artifact, decide how the artifact should be used: Must have, Should have, Could have or Won't have. For more details, see Guidelines: Classifying Artifacts.

Artifact	Purpose	Tailoring (Optional, Recommended)
Business Case	Used to determine whether or not the project is worth investing in.	Recommended.
Iteration Assessment	Captures the result of an iteration, the degree to which the evaluation criteria were met, lessons learned, and changes to be done.	Recommended.
Iteration Plan	The detailed plan for the iteration, including the time-sequence of tasks and resources.	Recommended.
Software Development Plan Measurement Plan Problem Resolution Plan Product Acceptance Plan Quality Assurance Plan Risk Management Plan	Includes all information required to manage the project.	All projects need some planning in order to manage a project. Smaller, less complex projects, may have a single document capturing the project plan. Larger, more complex, or more formal projects will require multiple separate subplans.
Project Measurements	This is the repository of all measurements related to the project.	Recommended for most projects. On many projects, only a few measures are used, such as cost and progress measures. A metrics database is required only when there is large amount of metrics data to be managed. Many organizations gather metrics data from multiple projects in order to glean information to apply to future projects.
Review Record	Captures the results of a review of one or more project artifacts. Review records can avoid misunderstandings of decisions made during a review. They also serve as evidence to stakeholders that project artifacts are being reviewed.	Recommended for most projects. Most projects will want to record decisions made in meetings with the customer and other key stakeholders, in order to ensure a common understanding. Reviews records for other reviews may or may not be formally captured, depending on the review formality applied by the particular project.
Risk List	This is a prioritized list of project risks.	Recommended. May be just a section in the Software Development Plan.
Status Assessment	Used to capture a snapshot of project status, including progress, management issues, technical issues, and risks.	Recommended. The Status Assessment may be combined with the Iteration Assessment if the iterations are frequent (one each month). If iterations are lengthy, there will be a need for intermediate Status Assessments.
Work Order	This is a negotiated agreement between the Project Manager and the staff to perform a particular activity, or set of activities, under a defined schedule and with certain deliverables, effort, and resource constraints.	Recommended for most projects. May be implemented using Change Requests.

Tailor each artifact by performing the steps described in the Activity: Develop Development Case, under the heading "Tailor Artifacts per Discipline".

Topics

Decide How to Perform the Workflow

Decide How to Use Artifacts