[1] For this report, it is assumed that a software project plan is the software development plan.

[2] It was assumed that any organization that is responsible for developing and/or maintaining software could be included in the audience.

[3] The guidelines (or rules) for preparing a project's defined software process tailored from the organization's standard software process are (by definition) part of the organization's standard software process. Thus, these rules become an integral part of fulfilling the requirements for the Software Process Definition (SPD) Key Process Area (KPA) for CMM Level 3.

[4] Organizations may want to develop project characteristics tables specifically for their needs.

[5] Most development organizations rely on their management and/or their SEPG to approve waiver requests. An internal compliance agreement, in writing, is archived for subsequent project reviews.

[6] When building blocks are added to create a project's defined software process, lessons learned from the project should be used to determine if a similar building block should be added to the organization's standard software process.

[7] Waiver formats generally are unique to each organization.

[8] An example software development plan template is discussed in more detail in Paragraph 3.4.2.4.

[9] Compliance agreements are typically not deliverable documents; however, an organization may be required to allow auditors to review them.

[10] Referencing replacement building blocks applies to building blocks that are published as standards (e.g., an American National Standards Institute (ANSI) standard) and used verbatim.

[11] The WBS presented in this section is an example. It would need more decomposition to show the level of detail that would need to be employed to develop costs and schedules for this project.

[12] Includes Project Workbench, Method Architect, and Project Bridge.