<Project Name> - Development Case

1. Introduction

[The introduction of the Development Case provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Development Case.]

1.1 Purpose

[Specify the purpose of this Development Case.]

1.2 Scope

[A brief description of the scope of this Development Case; what Project(s) it is associated with and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Development Case. This information may be provided by reference to the project's Glossary.]

1.4 References

[This section is optional. Alternatively to having an explicit references section using the table below, write down the full name of the document you are referring to in-line with the text where if first appears, then add a hyperlink to the location where the referenced element is stored, and add a acronym (between parenthesis) right after the first appearance of that reference. On subsequent appearances of that reference, use the acronym only.

If you use this section, provide a complete list of all documents referenced elsewhere in the Development Case. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.

NOTE: Be sure to include a reference to the version of the organizational process this development case is based on.]

1.5 Overview

[This subsection describes what the rest of the Development Case contains and explains how the document is organized.]

2. Overview of the Development Case

2.1 Lifecycle Model

[Briefly describe the lifecycle model employed by the project including descriptions of the milestones and their purpose. The purpose is to serve as an introduction to the rest of the development case, not to be a project plan.]

2.2 Sample Iteration Plans

[This section is optional. Include sample iteration plans if they will be helpful for your project.

Your organizational process captured in Method Composer may provide capability patterns that can serve as templates for phase iteration plans. Your organization may have included a delivery process in your published version of the organizational process that can serve as a basis for your iteration plans.

If you are using a separate project management tool to create project plans, this section is not needed.]

2.2.1 Inception Phase

[List the sample iteration plans used during Inception.]

2.2.2 Elaboration Phase

[List the sample iteration plans used during Elaboration.]

2.2.3 Construction Phase

[List the sample iteration plans used during Construction.]

2.2.4 Transition Phase

[List the sample iteration plans used during Transition.]

3. Workflow

[This section describes the workflow of each of the development phases in your project lifecycle. For each phase, identify or describe the standard workflow that is used on this project. Following are some suggested ways to identify or describe the standard workflow:

• The delivery process in your published organizational process includes activity diagrams for each development phase. You can copy and paste those diagrams here or describe how to locate them. Use the 'Notes on Workflow' section to document differences for your project.
• More difficult: rework the activity diagrams to accurately reflect the workflow that your project follows. In this case, there is no need for the 'Notes on Workflow' section, so it can be removed.]

3.1 Inception Phase

3.1.1 Notes on Inception Phase Workflow

[Describe any changes made to the standard workflow for this phase. Typical changes include adding or removing activities or tasks to describe project-specific ways of working.]

3.2 Elaboration Phase

3.2.1 Notes on Elaboration Phase Workflow

[Describe any changes made to the standard workflow for this phase. Typical changes include adding or removing activities or tasks to describe project-specific ways of working.]

3.3 Construction Phase

3.3.1 Notes on Construction Phase Workflow

[Describe any changes made to the standard workflow for this phase. Typical changes include adding or removing activities or tasks to describe project-specific ways of working.]

3.4 Transition Phase

3.4.1 Notes on Transition Phase Workflow

[Describe any changes made to the standard workflow for this phase. Typical changes include adding or removing activities or tasks to describe project-specific ways of working.]

4. Work Products

[A work product is an artifact, outcome, or deliverable. Provide a list of work products to be produced for the project, when the work product is created and completed, along with details of how the work product is reviewed (when appropriate), who reviews and approves the work product (RACI responsibility matrix) what template is used to create the work product, where the work product is kept or what tool is used to manage it. This can be accomplished by embedding a work product addendum to the development case, such as in spreadsheet format. Alternatively, you may use another method to provide the list of work products, either in this document or as an addendum to this document.

Note that if you keep the work products to be produced separately from this document (for example, using an addendum spreadsheet), you must be sure to maintain proper document control of the information.]

NOTE: The work product addendum is considered to be a part of this development case. The two documents are reviewed and approved as if they were one document.

5. Reports

[List any reports that are useful for this project. Describe who uses the report and how it can be created.]

6. Roles

[This section is used for the following purposes:

• To describe any changes in the set of roles; for example, it is common to refine the role stakeholder into more than one role.
• To map job positions in the organization to the roles in the organizational process. The reason for this is that in some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the roles in the process and the job positions in the organization. Mapping job positions to roles makes it easier for people in the organization to understand how to employ the process. The mapping can also help people understand that roles are not job positions, a common misconception.

Explanation of columns:

• Role: Identify the roles used on your project. For example, it is common to refine the role stakeholder into more than one role. You might need to add new roles or clarify how each role is used in the organization by providing role names commonly used in your organization
• Process Role: Y if this is a role identified in the organizational process; N if it is not defined in the process.
• Applicability: Use this column to map job positions in the organization to the roles in the organizational process.
• Responsibilities: Describe any differences in responsibilities in the organization from those described in the process.]

NOTE: The assignment of specific individuals to particular roles or job positions is documented in the Project Plan.

7. Project-Specific Guidelines and Procedures

[Identify any guidelines and procedures used by the project that are not included in the organizational process. These should include any special review procedures, style or coding guidelines, etc. Modify the suggested table to fit your needs.]