2.120.4 Design Coordination

Manual Transmittal

October 03, 2014

Purpose

(1) This transmits new IRM 2.120.4, Engineering, Design Coordination (DC) Process.

Material Changes

(1) This transmittal establishes the new IRM publication for the DC Process.

Effect on Other Documents

This process description does not impact any other document.

Audience

The DC Process is applicable to all DC Groups and associated Stakeholders.

Effective Date

(10-03-2014)

Sri Rao,
Acting Director, Solution Engineering

Process Description

  1. The objective of DC is to clearly communicate and define processes, interfaces, roles, responsibilities, and collaboration between stakeholders during the design collaboration phase of the Information Technology Infrastructure Library (ITIL) lifecycle.

Introduction

  1. Design Coordination

Administration
  1. All proposed changes to this document should be directed to the Chief, Solution Engineering Process Maturity owner of this process description and be pursued via the Integrated Process Management (IPM) process to clearly define interfaces, roles, responsibilities, and coordinate participation and collaboration between stakeholders.

Purpose of Process Description
  1. This DC Process Description (PD) describes what happens within the DC process and provides an operational definition of the major components of it. This description specifies, in a complete, precise, and verifiable manner, the requirements, design, and behavior characteristics of the DC process. The PD is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document.

  2. For the purpose of this document, roles such as: Service Design Manager, Lead Design Engineer, and Configuration Management (CM) Lead are provided to describe a set of responsibilities for performing a particular set of related activities. The DC process entails and addresses applications, Infrastructure and project activities.

Document Overview
  1. This document describes a set of interrelated activities, which transform inputs into outputs, to achieve a given purpose, and states the guidelines that all projects follow regarding the DC process. The format and definitions used to describe each of the process steps of the DC process are described below:

    • Purpose – The objective of the process step.

    • Roles and Responsibilities – The responsibilities of the individuals or groups for accomplishing a process step.

    • Entry Criteria – The elements and conditions (state) necessary to trigger the beginning of a process step.

    • Input – Data or material needed to perform the process step. Input can be modified to become an output.

    • Process Activity – The list of activities that make up the process step.

    • Output – Data or material that are created (artifacts) as part of, produced by, or resulting from performing the process step.

    • Exit Criteria – The elements or conditions (state) necessary to trigger the completion of a process step.

Process Overview

  1. Process Overview

Work Products
  1. This section describes the work products needed to execute the process (known as inputs) as-well-as those produced by the DC process (known as outputs).

Work Products Used by This Process (Inputs)
  1. The following work products are used to assist in the implementation of the DC process:

    • Enterprise Life Cycle (ELC) Documentation Standards - Relating to the design portion of the lifecycle

    • Internal Revenue Manual (IRM) – Those pertaining to the design processes in the ELC

    • Design Requirements – Requirements by which designs are specified and documented

    • Engineering Plan - Required for all engineering efforts including the design phase of the ELC

    • Decision Analysis and Resolution (DAR) Processes – A required Technical Solution Process procedure that addresses alternative decision making processes for DC

    • Security Plan – To ensure new designs or design changes do not impact IT security requirements

    • Service Level Agreements SLA(s) - To document service requirements, designs and needs when external parties such as contractors and vendors are implicated in DC

    • Request For Change (RFC) – An integral part of DC that is used to document requests for Design Changes

    • DC Plans – To document the design details, strategies and processes

    • Design Schedules – To identify, track and monitor the DC effort(s)

    • Design Procedures – A Capability Maturity Model Integration (CMMI) requirement to ensure the design process is documented and adhered to

    • Design Requirements Traceability Matrix (RTM)– A CMMI requirement to ensure design requirements are mapped to the systems/sub-systems and modules to be implemented

    • Interface Control Document (ICD) – A document addressing both man and machine interfaces and connections

  2. Along with the work products used, the following related IT Process artifacts are used:

    • ELC - Design process.

    • Solution Concept Definition.

    • BSRR – Business System Requirements Report.

    • COH – Computer Operator's Handbook.

    • DSR1 - Design Specification Report: Part 1 Logical Design.

    • DSR2 – Design Specification Report; Part 2 Physical Design.

    • ICD – Interface Coordination Document.

    • Revised DSR – a combined DSR1 & DSR2 in final approval.

    • User Documentation & Training Materials Report.

    • Plan Maintenance Artifacts (Functional Equivalents).

    • Program Requirements Package (PRP) - Programming Requirements Package – (DSR2) (revised DSR).

    • Core Record Layouts & File Specifications – (ICD).

Work Products Produced by This Process (Outputs)
  1. The following work products are produced by the DC process, and may be used as inputs to other processes:

    • Design RFC’s - Used for documenting changes to existing designs or introducing new design objects.

    • Design Plan – Used to define high level resources, strategies, needs and requirements.

    • Design Activity Schedule – Used for identifying, managing, tracking, and reporting DC activities. Schedules are coordinated with operations.

    • Final Design Selected from a list of alternatives – Using the TS process in selection of design alternatives.

    • Requirements List – An approved list of design requirements. It is managed by the Configuration Management process.

    • RTM – A matrix mapping functions to be implemented to the requirements that drive them.

    • DC Metrics - A CMMI requirement, to ensure that the DC process is measured and metrics are reported.

    • Feasibility Report - A report indicating the feasibility of the proposed designs. The feasibility report is part of the TS process as-well-as the RFC process, where the feasibility of submitted changes is voted on and decided by the Change Control Board (CCB).

    • Updates to the Service Design Plan (SDP) – Updates resulting from DC decisions and analysis.

    • Issues and Risk Analysis Report – Defined Issues and Risks related to the design.

    • Approved RFC’s for process improvement – Process improvements agreed to by DC team staff.

    • Accepted Issues Lists and status reports – Finalized issues lists and their current status.

    • Schedule Analysis/Anomalies – Any schedule impacts that need to be documented.

    • Design Status Reports – Status reports for staff and management, indicating progress towards DC schedule realization.

    • Implementation Procedures – Post how design(s) are to be implemented.

    • Documented improvements reports/lists – Posts recommended DC process improvements.

    • New/Updated strategies, policies, and methods – To ensure process improvements are implemented.

    • Resources allocations lists – To document and track DC resources

    • Compliance Reports – Indicating DC efforts are in compliance with documented requirements and IRS regulations.

    • Action plans – To document actions needed addressing DC risks, Issues and Change Requests (CR’s).

    • Collaboration Meeting minutes – To document action items needing addressing.

Roles and Responsibilities
  1. Many roles are involved in the DC process. This section defines the roles used throughout this document and their responsibilities.

    Role Description Definition of Responsibility
    Service Design Manager
    • Ensure DC Policies and Methods are assigned and being implemented.

    • Coordinate DC activities across project design efforts.

    • Maintain service strategies related to DC activities.

    • Ensure appropriate milestone exits are done and ensure the SDP is updated.

    • Ensures Configuration Management (CM) is conducted according to documented procedures.

    • Keep Engineering appraised of: Issues, Changes and Risks associated with DC efforts.

    • Approve CR’s that come out of the DC process.

    • Monitor Risks and Issues identified by lead engineer and respond appropriately.

    • Approve CR’s that come out of the DC process.

    • Maintain service strategies related to DC activities.

    • Ensure appropriate milestone exit reviews are done when DC CR’s have been completed.

    • Formulate service improvements and responses that come out of the DC process.

    • Identify roles and responsibilities related to the service.

    • Ensure cost effectiveness of the services provided.

    Lead Design Engineer
    • Coordinate DC Activities.

    • Monitor DC Progress.

    • Identify/Report Risks and Issues.

    • Issue Change Requests (CR’s) where needed.

    • Monitor, track and report all technical solutions coming out of the DC process.

    • Ensure enterprise design standards are integrated into DC efforts.

    • Inform Engineering Manager of current DC efforts and status.

    • Develop/Modify design standards and standard patterns using the CM process.

    Configuration Management Lead
    • Manage DC baselines, risks and issues lists.

    • Manage CR lists and status.

    • Maintain DC documentation libraries.

Design Coordination Process Flow Diagram
  1. DC Process Flow Diagram

    Figure 2.120.4-1

    This is an Image: 61941001.gif

    Please click here for the text description of the image.

Design Coordination Process

  1. Process Steps:

Step 1: Define and Maintain Policies and Methods
  1. Define and Maintain Policies and Methods

Purpose
  1. At this step, design teams coordinate and maintain policies, strategies and methods to ensure that consistent and accurate approaches are implemented during DC efforts. Design coordination, project management, and change management groups collaborate to define policies and practices for all design work.

Roles and Responsibilities
  1. The CM Lead maintains current/up-to-date policies and procedures related to DC. Updates and new versions of these policies and methods are maintained, controlled and published by the CM Lead. Change Management is also performed and maintained by the CM Lead.

  2. The Service Design Manager develops and maintains DC policies and strategies by utilizing CM processes and procedures.

  3. The Lead Design Engineer develops and maintains design standards and standard design patterns following CM process and procedures.

Entry Criteria
  1. This step occurs after the following are in place:

    • Approved Design Requirements – To guide the DC effort(s).

    • Documented Service Strategy - As documented in the Engineering Plan and addressing DC policies and methods of implementation.

    • Defined Service Design Standards (SDS) and Enterprise Standards Profiles (ESP) - To manage the process and to ensure DC policies and methods are understood and communicated.

    • Identification of Design Teams - To ensure resources are in place and that policies and methods are understood and communicated.

    • Updated Organization Chart - To document lines of communication to ensure policies and methods are supported during DC.

    • Completed Engineering Plan – To detail coordination, implementation and use of engineering design resources, policies and methods.

    • TS Process – To provide structure to the design decision making processes and to document alternative design models.

    • Up To Date Security Plan – To ensure new proposed designs, or changes to current designs meet agency security requirements.

    • SLA(s) - To document service, design requirements, service needs, policies and methods that are used during DC by external service providers.

    • RFC(s) – Used to document requests for Design Changes or for issuing new functionality.

Input
  1. The following are inputs to this process step:

    • ELC Documentation Standards

    • IRM’s pertaining to the design phase of the ELC

    • Standards Design Patterns

    • Enterprise Architecture Document

    • Enterprise Standards Profile

    • Feedback from projects, operations and business units

    • Design requirements

    • Agency Security Requirements

    • Architectural Constraints

Process Activity
  1. Technical architects and engineers review all current strategies, policies and methods including: Enterprise Architecture, ESP, RFC Processing, ELC documentation standards, Standard design patterns and IRM’s related to the design phase.

  2. Establish Coordination Meeting(s) – To plan, monitor and ensure DC policies and methods are communicated and understood by all staff and stakeholders.

  3. Review all active Risk Lists and Policies - To document design risks coming In/Out of the DC process, and the corrective actions needed to mitigate them to ensure DC policies and methods are in place and addressed.

  4. Review all Issues Lists - To analyze potential design issues and concerns and determine if any DC policies and methods have been violated prior to and during the design phase of the ELC.

  5. Create a DC Implementation Schedule – To plan, assign, and track DC and to ensure that all planned policies and methods are addressed.

  6. Develop the Coordination Plan - To document and reflect policies and methods applicable to the DC effort. The plan addressed the following: resources, strategies, alternatives considered/approved, schedule adherence, coordination meetings, coordination processes and plan implementation.

Output
  1. The following are outputs to this process step:

    • RFCs for updates to existing strategies, policies and methods

    • Updates and/or new strategies, policies and methods

    • Design Plan reflecting DC Policies and Methods

    • Design Activity Schedule

    • Risk Tracking Procedures

    • Issues Tracking Procedures

    • Approved DC Coordination Policies and Methodologies

Exit Criteria
  1. This process step is complete when:

    • New Policies and strategies that have been created or updated.

    • A Implementable Design Plan reflecting DC Policies and Methods has been developed.

    • A Final Design Activity Schedule has been created.

    • An approved Risk Tracking Methodology has been formulated.

    • Approved Issues Tracking Methodologies have been developed.

    • A documented DC Coordination Policy and Methodology have been developed.

Step 2: Plan Design Resources and Capabilities
  1. Plan Design Resources and Capabilities

Purpose
  1. At this step the design resources and capabilities are put in place to ensure that requirements are addressed and mapped to the actual designs slated for implementation.

Roles and Responsibilities
  1. Service Design Managers are responsible for: identifying/tracking all active design efforts, the allocation of staff, obtaining DC resources, and posting DC schedules.

  2. Senior managers set priorities for/between design efforts and allocate resources among them.

Entry Criteria
  1. This step occurs after the following events are in place:

    • Design efforts have been planned and/or announced.

    • Approved Design Procedures are in place – To aid in planning and resource allocation.

    • Preliminary Design Requirements have been published so that resources can be planned and allocated.

Inputs
  1. The following are inputs to this process step:

    • Project Plan: Listing Resources available to be used for DC efforts.

    • Resource availability and capabilities from supplying organizations: To help in planning and resource allocation.

    • Service Level Requirements (SLR): Documenting any resources/capabilities allocated via external organizations for supporting DC.

    • Design Requirements: To ensure DC requirements are documented, and that resources needed to implement them are in-place.

    • Information Security: To determine resources and capabilities required for information security compliance of DC efforts.

    • Architectural Constraints: To identify potential impacts where the as-built architecture may be negatively impacted by DC related activities.

    • Interface Requirements: To help plan/allocate needed resources when external interfaces impact DC planning efforts.

    • Migration Requirements: Depicting the rollout of design changes and steps to be taken.

    • Operational Requirements: To document resources on the operations side of DC, to ensure that operations is part of the overall DC effort and that any DC activity will not negatively impact operations.

Process Activity
  1. Identify all current design efforts.

  2. Review schedules and resources needed.

  3. Identify resources and capabilities that are not available or in short supply.

  4. Develop an action plan to resolve the unavailable resources and capabilities.

  5. Execute action plans, monitoring its progress and updating as necessary.

  6. Identify project specific schedule issues and coordinate resolution with affected projects.

  7. Identify schedule and resource conflicts between projects.

  8. Coordinate conflict resolution alternatives with projects.

  9. Resolve schedule and resource conflicts between projects.

  10. Ensure project plans are updated as needed.

  11. Monitor compliance to schedule and re-evaluate resource and schedule conflicts if indicated.

Output
  1. The following are outputs to this process step:

    • DC Schedule reflecting resources allocated.

    • Allocated Resource List - Reflecting assigned resources commensurate with and mapped to the DC Schedule.

    • Action Plan addressing missing or marginal resources needed to support DC.

Exit Criteria
  1. This process step is complete when:

    • A final and documented DC Schedule reflecting resources needed has been developed.

    • Approved Allocated resource Lists, commensurate with [and mapped to] the DC schedule has been documented.

    • An Action Plan addressing resource issues has been done.

Step 3: Coordinate Design Activities
  1. Coordinate Design Activities

Purpose
  1. At this step, activities performed entail the coordination of all design activities across projects. This coordination includes: Managing changes, schedules, resources, conflicts, suppliers and support teams involved in the process.

Roles and Responsibilities
  1. The Service Design Manager is responsible for the day to day coordination of DC activities. The Service Manager ensures the various design efforts are in compliance with policies and standards, The Service Design Manager also ensures that DC efforts are in alignment with the CMMI in the areas of: Technical Solutions, Configuration Management, Measurement/Analysis, Risk Management, Decision Analysis Resolution, Organization Process Definition, Project Management and Project Monitoring and Control.

  2. The Lead Design Engineer monitors the design efforts for compliance with policies and standards, and reviews designs to ensure compliance to standards for DC efforts.

  3. The CM Lead ensures that DC policies are up to date, available and maintained in the Process Asset Library (PAL), and changes to protocols and procedures are kept current and available to staff involved with DC. The CM Lead also coordinates any work related to the Change Request process.

Entry Criteria
  1. This step occurs after the following events:

    • A preliminary DC implementation schedule has been documented.

    • All CR’s have been reviewed and documented.

    • Documented DC requirements are in place.

    • All required DC resources have been allocated.

    • Formal reviews of design work products (i.e. documents, modules, Request for Quote (RFQ) status) to monitor current status have been done and needed changes were approved.

    • Issues and Risk Lists have been analyzed and issues resolved (or waived).

Input
  1. The following are inputs to this process step:

    • Design Plans

    • TS Decision Analysis

    • Engineering Plan Updates

    • Documented Requirements

    • Initial SDP inputs are posted

    • Design Review minutes

    • Implementation Schedule

    • The RTM

    • Cost Benefit Analysis (if required by project)

    • Updated Issues Lists

    • Updated Risk Log

Process Activity
  1. Assign a Point of Contact (POC) for all coordination issues. This person is responsible for the effort.

  2. Encourage and facilitate collaboration between design efforts to promote consistent, effective and efficient design across the enterprise.

  3. Monitor design efforts for compliance with policy and methods.

  4. Review developing designs for compliance with design patterns and Enterprise Standards Profile.

  5. Attend and participate in all milestone exit reviews involving design work.

  6. Approve / disapprove designs at milestone reviews.

  7. Review compliance of policy, methods, design patterns and Enterprise Standards Profile with projects and develop action plans to gain compliance if needed.

  8. Monitor execution of action plans and take corrective action if indicated.

  9. Review developing designs for consistency across efforts.

  10. Monitor Schedule commitments to ensure that the implementations of designs are on track. Report any slippages or impacts to schedule to Engineering Manager for action.

  11. Perform Design Reviews to ensure that as the design activity progresses, that the schedule, costs and implementation are on track.

  12. Review Issues and Risk Lists to determine if there are any problems requiring corrective actions. Document corrective actions needed and taken.

  13. Inform the Configuration Control Board (CCB) of current status, risks and challenges. Ensure costs-related challenges are communicated to finance group.

  14. Peer review interim work products produced to ensure compliance with customer requirements and documented agency design coordination processes and procedures.

  15. Publish status reports to the DC team and stakeholders to inform them of any design issues/problems.

Process Outputs
  1. The following are outputs of this process step:

    • Issues and Risk Analysis Reports reflecting coordination issues and action items

    • Design Review Findings

    • Design Status Reports

    • Finalized DC Schedule

    • Signed Design Implementation Plan

Exit Criteria
  1. The following are exit criteria for this process step:

    • Defined Issues and Risk Analysis Reports reflecting coordination issues and action items

    • Documented Design Review Findings

    • Final Design Status Reports

    • Documented DC Schedule

    • Published Design Implementation Plan

Step 4: Manage Design Risks and Issues
  1. Manage Design Risks and Issues

Purpose
  1. At this step, DC uses formal risk assessment and management techniques. This is done to manage risks associated with design activities and to reduce the number of issues that can be traced to poor designs.

Roles and Responsibilities
  1. The CM Lead is responsible for maintaining, managing and publishing Risk and Issues lists.

  2. The Lead Design Engineer is responsible for entering and tracking Risks and Issues and ensuring that they are posted on Risk and Issues Lists. The lead is also responsible for corrective action tracking and reporting of these lists.

  3. The Service Design Manager is responsible for reviewing Risk and Issue Lists.

Entry Criteria
  1. This step occurs after the following are in place:

    • Documented Requirements

    • SDP Inputs

    • SE Engineering Plan

    • Issues Management Plan

    • Up to date Issues Lists

    • Risk Management Plan

    • Risk Lists

    • Waiver Forms (if needed)

    • Design Status Report

Input
  1. The following are inputs to this process step:

    • Documented Technical Requirements

    • Known Risks

    • Known Issues

    • Approval and Signoff Sheets

    • Updates to the SDP

    • Engineering Plan

Process Activity
  1. Mitigate Issues and Risks.

  2. Ensure Implementation Plans and Procedures are in place.

  3. Ensure Design Plans and Procedures related to how the service is to be implemented are finalized.

  4. Identify all known risk and issues that are either closed out or where waivers have been filed.

  5. Document all approved, implemented, verifies, and validated RFC’s, and ensure that issues and risks related to the change have been resolved.

  6. Verify all SLA compliance reports are reviewed and all related issues have been resolved.

Outputs
  1. The following are outputs to this process step:

    • Risk and issue free Design Implementation Plan

    • Verified/Validated issues and risk lists

    • SLA Compliance and Issue Reports

    • Risk and Issue Waivers

Exit Criteria
  1. This process step is complete when:

    • Risk and issue free Design Implementation Plans are done

    • Verified/Validated issues and risk lists are completed

    • The SLA Compliance and Issue Reports have been done

    • Risk and Issue are addressed

    • Waivers [where needed] are documented

Step 5: Improve Service Design
  1. Improve Service Design

Purpose
  1. The purpose of this step is to ensure that the goals and objectives of the DC service design stage are consistently achieved by continually working to improve the effectiveness and efficiency of service design activities and processes.

Roles and Responsibilities
  1. The following are roles and responsibilities for this process step:

    • The CM Lead maintains RFC’s and Issues Lists that form the basis of discussion for DC improvements.

    • The Service Design Manager issues RFC’s with the goal of improving service design based on the DC activities such as: Issues Management, Lessons Learned, Design Reviews and discussions that took place in DC planning and management meetings.

Entry Criteria
  1. This step occurs after the following events have taken place:

    • Process Improvement Lists have been generated

    • Risks, Issues Lists and status reports have been analyzed and improvements have been identified

Input
  1. The following are inputs to this process step:

    • Risks, Issues Lists and reports indicating a need for process improvement

    • Published Design review findings

    • RFC’s relating to process improvements

    • Meeting minutes with process improvements and actions identified

Process Activity
  1. Determine which risks, issues, RFC’s and meeting action items are to be implemented.

  2. Schedule time frames for implementing approved process improvements.

  3. Document the finalized [and approved] RFC’s and manage/track improvement opportunities.

  4. Log, Manage, Track, Implement and Report the status of process improvement opportunities.

Output
  1. The following are outputs to this process step:

    • Process Improvement implementation schedule

    • Approved RFC’s for process improvement

    • Scheduled Lessons Learned meeting agenda

    • Process Improvement Implementation Status Reports (i.e. Open/Closed, Approved, Submitted etc.)

Exit Criteria
  1. This process step is complete when the following have occurred:

    • Process Improvement RFC’s have been published.

    • Process Improvement Status Reports have been published.

    • Up-To-Date Process Improvement Implementation Schedules are in place.

    • An Updated Service Improvement Plan has been done.

    • A Lessons Learned session has been performed.

Process Measurement
  1. The Service Manager will regularly review quantifiable data related to different aspects of the DC process in order to make informed decisions and take appropriate corrective action, if necessary. To be effective, measures of DC should result in an increase in successful changes that deliver the required business outcomes with minimal disruption or other negative impacts on business operations.

  2. The following monthly metrics shall be gathered and reported on a monthly basis:

    • # Of Design Risks per Month

    • # Of Design Issues per Month

    • # Requests For Changes per month

Training
  1. Training requirements at a minimum need to be in place and completed for the following:

    • Use and application of DC Metrics Design Templates in the generation of or changing of metrics templates

    • Design change management processes and procedures

    • Use of this procedure in implementing DC Processes

    • Training in DC use and application

Procedure

  1. Introduction

Administration
  1. All proposed changes to this document should be directed to the Chief, Solution Engineering Process Maturity, owner of this process description, and be pursued via the Integrated Project Management (IPM) process to clearly define interfaces, roles, responsibilities, and coordinate participation and collaboration between stakeholders.

Purpose of Procedure
  1. This DC Procedure describes what happens within the DC process and provides an operational definition of the major components of it. This procedure specifies, in a complete, precise, and verifiable manner, the requirements, design, and behavior characteristics of the DC Procedure. It is a documented expression of a set of activities performed to achieve a given purpose. Tailoring of this process in order to meet the individual needs of each project is covered in the Tailoring Guidelines section of this document.

  2. For the purpose of this document, roles such as: Project Managers, Service Design Manager, Lead Design Engineer and CM Lead are provided to describe a set of responsibilities for performing a particular set of related activities. The DC procedure entails and addresses applications, Infrastructure and project activities.

Procedure Overview
  1. DC Procedure

Purpose
  1. The purpose of this procedure is to outline the required steps in the design coordination process. It represents in a complete, precise, and verifiable manner process inputs, steps to be executed and expected outputs. It entails the decomposition of Business Service into supporting services and includes Technical and Organizations Service Designs and Request for Changes (RFC’s) to services.

Related Process Artifacts
  1. Related Process Artifacts:

    • Engineering Life Cycle (ELC) Documentation Standards - Relating to the design portion of the lifecycle.

    • IRM – Those pertaining to the design processes in the ELC.

    • Design Requirements – Requirements by which designs are specified and documented.

    • Engineering Plan - Required for all engineering efforts including the design phase of the ELC.

    • TS Process – A required IT process that addresses alternative decision making processes for DC.

    • Security Plan – To ensure new designs or design changes do not impact IT security requirements.

    • SLA(s) - To document service requirements, designs and needs when external parties such as contractors and vendors are implicated in DC.

    • RFC(s) – An integral part of DC that is used to document requests for Design Changes.

    • DC Plans – To document the design details, strategies and processes.

    • Design Schedules – To identify, track and monitor the DC effort(s).

    • Design Procedures – A CMMI requirement, to ensure the design process is documented and adhered to.

    • Design RTM– A CMMI requirement to ensure design requirements are mapped to the systems/sub-systems and modules to be implemented.

    • ICD – A document addressing both man and machine interfaces and connections.

Related Artifacts
  1. Related Artifacts:

    • ELC - Design process

    • Solution Concept Definition

    • BSR – Business System Report

    • BSRR - Business System Requirements Report

    • COH – Computer Operator's Handbook

    • DSR1 - Design Specification Report: Part 1 Logical Design

    • DSR2 - Design Specification Report; Part 2 Physical Design

    • ICD - Interface Control Document

    • Revised DSR - a combined DSR1 & DSR2 in final approval

    • User Documentation & Training Materials Report

    • Plan Maintenance Artifacts (Functional Equivalents)

    • PRP - Programming Requirements Package – (DSR2) (revised DSR)

    • Core Record Layouts & File Specifications – (ICD)

Entry Criteria
  1. The DC procedure occurs after the following events have occurred:

    • Client Requirements are available – To ensure client driven policies, methods and strategies are specified.

    • The PD has been approved.

    • A Documented Service Strategy has been developed - As documented in the engineering plan and addressing DC policies and methods of implementation.

    • Defined SDS and ESP have been formulated - To manage the process and to ensure DC policies and methods are understood and communicated.

    • The Identification of Design Teams has been developed - To ensure resources are in place and that policies and methods are understood and communicated.

    • An Updated Organization Chart is in place to manage the procedure - To document lines of communication to ensure policies and methods are supported during DC.

    • An Engineering Plan is in place– To detail coordination, implementation and use of engineering design resources, policies and methods.

    • TS Process is in place – Provide structure to the design decision making processes and document alternative design models. Also to ensure that repeatable policies and methods are utilized during DC implementation.

    • A Security Plan is in place– To ensure potential designs (and changes to them) are not of a security concern and to ensure that security policies and methods are understood.

    • SLA(s) (if specified) are in place - To document service, design requirements, service needs, policies and methods that are used during DC by service providers.

    • An RFC is being formulated and ready for DC – Used to document requests for Design Changes which are an output of the Change Management Process. RFC’s are an integral component of DC and current CM plans address policies and methods for implementing them.

Input
  1. The following are inputs to this DC procedure:

    • Documented Functional Requirements

    • Service Portfolio

    • Approved Service Charter

    • DC Processes and Procedures

    • Documented DC Processes Description

    • Management authorization and direction to proceed

    • Documented Change Requests

    • Issues Lists

    • Information Security Requirements

    • Compliance requirements

    • Architectural Constraints: Specific technology or vendors and their constraints

    • Interface Requirements

    • Migration Requirements

    • Operational Requirements

    • Required Access Rights

    • Project Schedules


    Input Examples:

    • Documented (and approved) Functional Requirements

    • Approved Change Requests (CR’s) ready for Analysis and implementation

    • Issues lists that have been assigned to be fixed

    • Up-To-Date Security Requirements to ensure designs are security compliant

Activities
  1. This Procedure covers activities as follows:

    Figure 2.120.4-2

    Activities

    A1 Define and Maintain Policies and Methods
    A2 Plan Design Resources and Capabilities
    A3 Coordinate Design Activities
    A4 Manage Design Risks and Issues
    A5 Improve Service Design

Output
  1. The primary outputs of this DC procedure are:

    • Approved RFCs

    • Risk List indicating possible implementation considerations


    Output Examples:

    • A list of approved RFC’s to be processed and implemented

    • A list of issues that needs to be processed and implemented

Exit Criteria
  1. The DC procedure is exited when:

    • RFC’s are dispositioned

    • Issues Lists and Status Reports are published

    • Improvement opportunities are tracked, managed and documented

    • Implementation procedures are formulated

    • Any SLA’s needed are reviewed and approved

    • Feasibility reports are published indicating decisions made

    • All scheduled activities are closed out

    • Security has approved the design


    Exit Criteria Examples:

    • Published RFC’s

    • Approved Implementation Procedures

    • Approved Design

Procedure Flow Diagrams
  1. A1 Procedure Flow Diagram:

    Figure 2.120.4-3

    This is an Image: 61941002.gif

    Please click here for the text description of the image.

  2. A2 Procedure Flow Diagram:

    Figure 2.120.4-4

    This is an Image: 61941003.gif

    Please click here for the text description of the image.

  3. A3 Procedure Flow Diagram:

    Figure 2.120.4-5

    This is an Image: 61941004.gif

    Please click here for the text description of the image.

  4. A4 Procedure Flow Diagram:

    Figure 2.120.4-6

    This is an Image: 61941005.gif

    Please click here for the text description of the image.

  5. A5 Procedure Flow Diagram:

    Figure 2.120.4-7

    This is an Image: 61941006.gif

    Please click here for the text description of the image.

Activity and Steps
  1. This section delineates the activity steps, including roles and tools or templates, needed to perform each step of this Procedure.

    A1: Define and Maintain Policies and Methods

    Design teams coordinate and maintain policies and methods to ensure consistent and accurate approaches are implemented during DC efforts. Project management and change management groups collaborate and define policies and practices for all design work.
    Steps Role
    1. Ensure that a DC Plan and PD are in place for the project considered and are in alignment with the service strategy per the SDPs and the ESP. Service Design Manager
    2.Ensure that Risk Management is applied to the project by having a Risk Management Plan and up to date risk management processes and procedures (including reporting). Lead Design Engineer
    3.Ensure that the TS Process is applied to decisions made during DC proceedings. Service Design Manager
    4.Ensure that a CM Plan is in place and that CM tracks and reports issues found in the DC process. CM Lead
    5.Ensure that DC requirements for systems being addressed are documented, managed and tracked. CM Lead
    6.Ensure that security requirements are in place for all systems to be initiated, changed or modified. Service Design Manager
    7.Ensure that all required IRS compliance regulations and Federal Acquisition Regulations (FAR)s are in place. Service Design Manager
    8.Ensure that all required interface requirements are in place so that DC analysis and implementation in the areas of interfacing systems are clearly defined and understood. Lead Design Engineer
    9.Ensure migration requirements (if required) are in place, understood and implemented in all DC decisions. Lead Design Engineer
    10.Ensure that all required access rights are in place prior to commencement of DC activities. Lead Design Engineer
    A2: Plan Design Resources and Capabilities

    Ensure that the required resources and capabilities are in place to ensure that requirements are addressed and mapped to the actual designs slated for implementation.
    Steps Role
    1.Routinely review and determine if staffing is adequate to support the DC activities as posted in this procedure. Make changes to adjust to resource requirements if required. Service Design Manager
    2.Ensure that schedules are developed that detail activities and milestones to be met for DC activities and that they are assigned to specified staff and approved. Service Design Manager
    3.Ensure that Staff meetings are scheduled, held, agenda’s published, minutes taken and (if required) actions are assigned to DC staff. Service Design Manager
    4.Ensure that risk lists are continually published, so that staff can plan the resources needed to address the risks. Lead Design Engineer
    5.Ensure that current issues lists (with up to date status) are distributed so that resources can be allocated to address issues. Lead Design Engineer
    6.Ensure that a coordination plan is in place that details the assignments, needs, due dates and activities to be accomplished. Service Design Manager
    7.Track and Report Issues and Risks. CM Lead
    A3: Coordinate Design Activities

    Coordinate designs across all projects.
    Steps Role
    1.Formulate requirements for DC analysis with Requirements Engineering and document decisions made. Ensure that a RTM exists for all requirements and maps to the schedule. Service Design Manager
    2.Schedule Coordination Meetings, create agenda’s, take minutes and assign/track action items as required and documenting technical solutions that were developed. Service Design Manager
    3.Ensure that the design selected is specified in the SDP and that all coordination activities to be done are specified (e.g. meetings, design reviews, testing, Verification and Validation and design implementation sequences etc.). Lead Design Engineer
    4.Ensure that DC implementation schedules are in place and activities, milestones and assignments are tracked. Service Design Manager
    5.Use RFC’s for documenting changes, scheduling and coordinating designs that are to be implemented. Use the CCB as the approval forum for all RFC’s. Service Design Manager
    6.Ensure that all interfaces involved are specified and defined. Lead Design Engineer
    7.Utilize the TS Process to coordinate alternatives and design decisions related to DC efforts. Lead Design Engineer
    8.Coordinate and analyze all new requirements. Lead Design Engineer
    9.Perform and document the milestone exit review activities for this phase and ensure the SDP is updated. Service Design Manager
    10.Track DC requirements and manage/control DC documentation. CM Lead
    A4: Manage Design Risks and Issues

    Implement formal risk assessment and management techniques to manage risks associated with design activities and reduce the number of issues that can subsequently be traced to poor designs.
    Steps Role
    1.Ensure that Risk management and Issues tracking plans/procedures are in place to support the DC process. Service Design Manager
    2.Ensure that tools (i.e. spreadsheets/DBMS etc.) are in place to log, track, manage and report issues and risks. CM Lead
    3.Ensure that staff are assigned to manage and report risks and issues. Service Design Manager
    4.Ensure that all risks and issues are assigned, reviewed, and approved for corrective actions. Verify that they are checked to determine if they are closed out (or not). Service Design Manager
    5.Ensure that processes are in place to mitigate and assign corrective actions for risks and issues that have been identified. Service Design Manager
    6.Monitor schedule commitments to ensure that risks in schedules are minimized. Service Design Manager
    7.Perform design reviews so that Risks and Issues can be detected and acted on proactively. Lead Design Engineer
    8.Inform the CCB of all risks and issues. CM Lead
    9.Manage Tracking Tools and publish status reports and ensure that risks and issues are reported. CM Lead
    A5: Improve Service Design

    Ensure that the goals and objectives of DC are consistently achieved by continually working to improve the effectiveness and efficiency of service design activities and processes.
    Steps Role
    1.After DC sessions are complete, assign staff to perform Lessons Learned. Service Design Manager
    2.Ensure a process is in place, to submit and follow up on comments and recommendations. Service Design Manager
    3.Routinely audit the process, and based on findings recommend ways to improve it. CM Lead
    4.Ensure that improvements identified are assigned, managed, and that there is a means in place to verify and validate that they have been implemented. Service Design Manager
    5.Periodically review Design Implementation Plans and procedures, looking for process improvements. Lead Design Engineer
    6.Use RFC’s for submitting process improvements. Lead Design Engineer
    7.If SLA’s are used, periodically review them for process improvement opportunities. Service Design Manager
    8.Perform team peer reviews of all work products and look for document feedback from team for process improvements. Lead Design Engineer
    9.Ensure that issues lists and status reports are reviewed and solicit feedback from both management and staff for improvement opportunities. Lead Design Engineer
    10. Establish a metrics process to aid in identification of improvement opportunities. Service Design Manager
    11. Track all corrective measures taken as a response to documented process improvements. Lead Design Engineer

Tailoring Guidelines

  1. All tailoring requests, with supporting rationale, should be submitted in writing to the Chief, Solution Engineering Process Maturity, and owner of this procedure.

CMMI, ITIL and PMI Compliance

  1. The CMMI is used to judge the maturity of an organization’s processes and related procedures and process assets and can be used to plan further improvements. CMMI sets the standard for the essential elements of effective and mature processes, improved with quality and efficiency.

  2. The ITIL contains a collection of best practices, enabling organizations to build an efficient framework for delivering IT Service Management (ITSM) and ensuring that they are meeting business goals and delivering benefits that facilitate business change, transformation, and growth.

  3. The Project Management Institute (PMI) organization advances the project management profession through globally recognized standards and certifications.

  4. This process asset is used to indicate that all artifacts are developed or acquired, incorporating CMMI, ITIL, PMI requirements, to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value to the IRS.

Definitions, References

  1. Definitions, References

Definitions

  1. A Glossary is available on the IT PAL.

References

  1. The following resources either are referenced in this document or were used to create it:

    • ITIL DC Process

    • DC PD

Exhibits

  1. Exhibits A & B

Exhibit A: Glossary

  1. Glossary

    Term Definition
    Artifact A work product created by a process or procedure step, e.g. plans, design specifications, etc.
    Configuration Management A group responsible for documentation, baseline management, auditing, configuration control and maintaining all DC documentation.
    CMMI An IT standard used to judge the maturity of an organization’s processes and related procedures and process assets and can be used to plan further improvements
    Issue A problem found related to functionality that is required to work
    DC Process The methodology and steps taken that ensure design related activities are coordinated in a repeatable and manageable way
    Feasibility Report A report used to document if a DC imitative can be done within reasonable means based on: Cost, Schedule and w/o impacting critical functions in a process
    ITIL A collection of best practices, enabling organizations to build efficient DC processes for delivering IT Service Management (ITSM) and ensuring that they are meeting business goals and delivering benefits that facilitate business change, transformation, and growth
    Metric. A quantitative way of measuring a process. Often provided in the form of charts.
    Process Asset Library A place where all standards, forms, processes and procedures are maintained
    Request For Change Request for Change used to request new functionality in a system
    Requirements Engineering The act of coordinating, identifying, approving, managing and allocating requirements. Typically managed by the CM group
    Requirements Traceability Matrix A cross reference table that ties requirements to functionality that meets and addresses those requirements
    Risk An uncertain event or condition that, if it occurs, has a negative effect on the project
    Service Improvement Plan A plan detailing the improvements to be made in the DC process
    Service Level Agreement Formal agreement between service provider and client detailing in writing what work is to be done and how it is to be verified and validated
    Tailoring The act of customizing, adding to, or leaving out elements specified in a template. Tailoring of templates must be approved before they are used. This DC PD is NOT Tailor-able.
    Template A document construction road map form, that details the elements a document must contain and provides a straw man format for documenting the elements needed
    Work Product For any phase within a process, the verifiable/validate-able output of that phase needed to ensure that that phase of activity produced what it was designed to produce

Exhibit B: Abbreviations and Acronyms

  1. Abbreviations and Acronyms

    Acronyms Definition
    BSRR Business Systems Requirements Report
    CCB Configuration Control Board
    CMMI Capability Maturity Model Integration
    CM Configuration Management
    CMS Configuration Management system
    CCB Change Control Board
    COH Computer Operations Handbook
    CR Change Request
    DAR Decision Analysis Resolution
    DSR Design Specification Report
    ELC Enterprise Life Cycle
    ES Enterprise Services
    ESP Enterprise Standards Profile
    FAR Federal Acquisition Regulation
    FSP Functional Specifications Package
    IPM Integrated Process Management
    ICD Interface Control Document
    IRM Internal Revenue Manual
    IRS Internal Revenue Service
    IT Information Technology
    ITIL Information Technology Infrastructure Library
    ITSM Information Technology Service Management
    PAL Process Asset Library
    PD Process Description
    POC Point of Contact
    PMI Project Management Institute
    PRP Programming Requirements Package
    QA Quality Assurance
    RFC Request For Change
    RFQ Request For Quote
    RTM Requirements Traceability Matrix
    SE Systems Engineering
    SDP Service Design Package
    SDS Service Design Standard
    SLA Service Level Agreement
    SLM Service Level Management
    SLR Service Level Requirements
    TS Technical Solution