Project Environments Description Document

Definition

The project environments description document (PEDD) is the environments work product that formally documents each of the environments that will be produced and possibly delivered during a project.

Objectives

The typical objectives of the project environments description document are to formally document:

• How the project environments will be implemented and managed.
• All of the project’s environments in terms of their:
  • Objectives
  • Physical locations
  • Stakeholders
  • Components
  • Estimated costs

Benefits

The typical benefits of the project environments description document that clearly defines and documents the environments include:

• It enables the estimation of the costs and required resources to produce and maintain the project’s environments.
• It facilitates the development, test, and deployment of the environments.
• It enables the users of the environments to understand what they will be using.

Contents

The typical contents of the project environments description document are:

• Environment Overview
  • Project Environments Needs Assessment
    (organized by users and other stakeholders)
  • Environments Implementation Plan
    (including procurement, installation, configuration, and testing)
  • Environments Management Plan
    (including configuration management, operations, and maintenance)
• Development Environments
  For each of the following environments, the associated objectives, stakeholders, location, hardware and software components, and estimated price broken down by component:
  • Reuse Environment(s)
  • Engineering Environment(s)
  • Multimedia Environment(s)
  • Integration Environment(s)
  • Test Environment(s)
• Production Environments
  For each of the following environments, the associated objectives, stakeholders, location, hardware and software components, and estimated price broken down by component:
  • Client Environment(s)
  • Contact Center Environment(s)
  • Content Management Environment(s)
  • Data Center Environment(s)
• Appendices
  • Major Issues
    (e.g., potential tool limitations, availability of budget and staffing for due diligence during tool evaluation, and dependencies on other tasks and work products)
  • TBDs
    (incomplete parts of the document with estimated dates to be completed)
  • Assumptions
    (e.g., available budget for evaluation and purchase of components, planned future availability of required component capabilities)

Stakeholders

The typical stakeholders of the project environments description document are:

• Producer:
  • Environments Team
• Evaluator:
  • Environments Inspection Team
• Approvers:
  • Technical Leader
  • Project Manager
  • Customer Representative
• Maintainers:
  • Environments Team, which maintains it during the initiation and construction phases
  • Maintenance Organization, which maintains it during the usage phase
• Users:
  • Project Management Team, which uses it to determine the cost of the environments and to procure their components
  • Customer Organization, which uses it to understand the project environments that they are procuring.
  • Environments Team, which uses it to understand, build, and maintain the project environments
  • Software Development Team, which uses it to understand the engineering environment
  • Integration Team, which uses it to understand the integration environment
  • Independent Test Team, which uses it to understand the test environments
  • Security Team, which uses it to understand the test and production environments
  • User Experience Team, which uses it to understand the multimedia and production environments
  • Content Management Team, which uses it to understand the content management environment that they will use
  • Operations Organization, which uses it to understand the production environment that they will operate
  • Maintenance Organization, which uses it to understand the production environments that they will maintain

Phases

• Business Strategy: Not applicable
• Business Optimization: Not applicable
• Initiation: Completed
• Construction: Maintained
• Delivery: Maintained
• Usage: Maintained
• Retirement: Archived

Preconditions

The project environments description document can typically be started if the following preconditions hold:

• The initiation phase is started.
• The environments team is adequately staffed and trained.

Inputs

The typical inputs to the project environments description document include:

• Work products:
  • Application Vision Statement, which provides an understanding of the overall project.
  • System Requirments Specification, which document the requirements that the production environments must implement.
  • System Architecture Document, which documents the components of the production environments and the mechanisms they must support.
  • Master Schedule, which constrains the schedule in the environments implementation plan.
  • Product Selection Report, which contains evaluations of software tools that were evaluated and selected for incorporation into various environments.
• Stakeholders:
  • Architecture Team, which clarifies the system architecture of the production environments (if needed)
  • Process Team, which specifies requirements for the support the project process
  • Configuration Management Team, which specifies their needs for the support of the configuration management activity
  • Integration Team, which specifies their needs for the support of the integration activity
  • Independent Test Team, which specifies their needs for the support of the system testing activity
  • Security Team, which clarifies security mechanisms to be implemented by the environments
  • User Experience Team, which specifies their needs for the support of user experience tasks (e.g., graphics and multimedia software tools and any associated hardware components such as recording and digitizing equipment)
  • Content Management Team, which specifies their needs for the support of the content management activity
  • Software tool vendor representatives and domain experts (consultants, methodologists, and industry analysts), who provide input on software tools to be potentially incorporated into the various environments
  • Hardware vendor representatives, who provide input on hardware components to be potentially incorporated into the various environments

Guidelines

• Major parts of the sections documenting the development environments may be reused from project to project if the development organization has standardized on certain development tools and platforms.
• Tailor out sections of this document that describe environments that are unnecessary and therefore not going to be produced.
• Avoid unnecessary redundancy between the descriptions of the production environments in this document and in the system architecture document. One document can potentially include this documentation by reference to the other.
• This is a living document that is developed incrementally and iteratively in parallel with other work products (e.g., the tool selection report).
• Different parts of this document are due at different times. For example, the development environments are typically documented before the production environments.
• The project content and format standard and the associated template should clarify which parts of this document are mandatory and which parts are optional.

Conventions

The project environments description document is typically constrained by the following conventions:

• Content and Format Standard
• MS Word Template
• XML Template
• Inspection Checklist

Examples

• Example Project Environments Description Document