Part 2. Information Technology

Chapter 120. Engineering

Section 6. Engineering Planning Process

2.120.6 Engineering Planning Process

Manual Transmittal

June 03, 2024

Purpose

(1) This transmits a new IRM 2.120.6 Solution Engineering - Engineering Planning Process Description (PD) and Procedure.

Material Changes

(1) Making changes to IRM to be OneSDLC Compliant.

Effect on Other Documents

IRM 2.120.6 dated December 28, 2022 is superseded.

Audience

The Engineering Planning Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for Engineering Planning.

Effective Date

(06-03-2024)


Rajiv Uppal
Chief Information Officer

2.120.6.1 (06-03-2024)

Program Scope and Objectives

  1. Overview - This IRM describes the formal process for implementing the requirements of the Engineering Planning Process.

  2. Purpose - The IRM outlines what Engineering related work needs to be included in the Engineering Plan.

  3. Audience - The Engineering Planning Process is applicable to all Information Technology (IT) organizations, contractors, and other stakeholders having responsibility for Engineering Planning.

  4. Policy Owner - The Associate Chief Information Officer (ACIO) is responsible for overseeing all aspects of our systems that operate the nation’s tax infrastructure.

  5. Program Owner - Solution Engineering Division (SE), which is under Information Technology (IT), Enterprise Services (ES).

  6. Primary Stakeholders - Information Technology Projects are the primary stakeholders for the Engineering Planning Process.

  7. Program Goals - The Program goals of the Engineering Planning Process is to have all Engineering related work documented in the Engineering Plan during the project initiation phase.
    .

2.120.6.1.1 (06-03-2024)

Background

  1. A process is defined as “A set of related activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

2.120.6.1.1.1 (06-03-2024)
Process Description

  1. The Engineering Planning Process outlines what Engineering related work needs to be included in the Engineering Plan.

2.120.6.1.1.2 (06-03-2024)
Goal

  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.
    The goal of the Engineering Planning Process is to have all Engineering related work documented in the Engineering Plan during the project initiation phase.

2.120.6.1.1.3 (06-03-2024)
Objectives

  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • Relevant Engineering Processes are documented in the Project’s Engineering Plan (EP)

    • Negotiated collateral engineering work is in the Project’s Engineering Plan

    • Resource needs are established (SLA)

2.120.6.1.2 (06-03-2024)

Authority

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to the SE division.

2.120.6.1.3 (06-03-2024)

Roles and Responsibilities

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Name Description
    Engineer Responsible for:

    • Assists with identifying which Engineering Processes are needed in the Preliminary Engineering Plan

    • Consults with Project Lead as needed for all steps in the Engineering Planning Process.
    Project Lead The Project Lead is responsible for following all steps in the Engineering Planning Process.

    • Negotiates with the Engineer assigned to help establish the Service Level Agreement and review time-lines.
    Project Office The Project Office will provide the Project’s Tailoring Plan.

2.120.6.1.4 (06-03-2024)

Program Management and Review

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

    Process Management  
    Statement: The Engineering Planning process will have a single Process Owner and a separate Process Manager responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.
    People:  
    Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. The mission, goals, scope and importance of the process must be clearly and regularly communicated by upper management to the staff and business customers of IT. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Engineering Planning will not be successful.
    Process:  
    Statement: Modifications to the Engineering Planning process must be approved by the Process Owner. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.
    Technology and Tools:  
    Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention.
    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.

2.120.6.1.5 (06-03-2024)

Program Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

2.120.6.1.5.1 (06-03-2024)
Controls

  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Solution Engineering Policy (Directive) The project will include in its Engineering Plan either by inclusion or reference, planning materials specifying how the following will be accomplished:

    • Annual Review

    • Execution of Engineering Process

    • Obtaining needed resources to perform Engineering Process

    • Control of work products required by the Management Process

    • Engagement of stakeholders affected by the Data Management Process

    • Monitoring and Controlling of the Management Process

    • Collection of Management Process measures

    • Review of Management Process status with high level of management

    • Recency of approval signature

    • Establishment of the Management Process within the project's defined processes

    • Submission of lesson learned and process improvement suggestions from the execution of Management Process
    Scope All projects following the OneSDLC will be used to select, design, and implement solutions to requirements and associated activities in accordance with this policy.

2.120.6.1.5.2 (06-03-2024)
Metrics

  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.

  2. Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Engineering Planning process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

2.120.6.1.5.3 (06-03-2024)
Tailoring Guidelines

  1. The tailoring guidelines identify the allowable variations of the IT organization’s standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process.
    All tailoring requests, with supporting rationale, must be submitted in writing to the Chief, Solution Engineering Process Maturity, and approved by the Engineering Planning Process owner.

2.120.6.1.5.4 (06-03-2024)
Quality Assurance

  1. The Engineering Planning Process may be part of a Quality Assurance review at the discretion of the Process Owner.

2.120.6.1.6 (06-03-2024)

Terms/Definitions/Acronyms

  1. Terms/Definitions/Acronyms

2.120.6.1.6.1 (06-03-2024)
Terms and Definitions

  1. Terms and Definitions

    Term Definition
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are:

    • R: Responsible for the action (may do the task)

    • A:Accountable for the action (including approval)

    • C:Required to be Consulted on the action

    • I: Required to be Informed of the action If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.
    UWR A Unified Work Request is a documented formal request from any organization requiring IT services for changes to current or planned systems, corporate hardware or system testing, etc. Used for registering demand for IT products and services including hardware and software for an organizational level business need. NOTE: Impact Cost Analysis Summary (ICAS) Requests or Impact Cost Analysis Detail (ICAD) Requests are children of the parent work request.

2.120.6.1.6.2 (06-03-2024)
Acronyms

  1. Acronyms

    Acronyms Description
    EP Engineering Plan
    GEL Government Equipment List
    ICD OneSDLC Interface Control Document
    IPM Integrated Process Management
    OneSDLC One Solution Delivery Lifecycle
    RACI Responsible, Accountable, Consulted and Informed
    SE Solution Engineering
    SDSR Simplified Design Specification Report
    SLA Service Level Agreement
    UWR Unified Work Request

2.120.6.1.7 (06-03-2024)

Related Resources

  1. Engineering Planning Data Information Document

2.120.6.1.8 (06-03-2024)

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. Below is the training resource available for this process:

    • Engineering Planning Process Training

2.120.6.2 (06-03-2024)

Process Workflow

  1. A process workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

2.120.6.2.1 (06-03-2024)

Main Process Diagram

  1. Figure 2.120.6-1

    This is an Image: 74884001.gif

    Please click here for the text description of the image.

2.120.6.2.2 (06-03-2024)

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

         
         

2.120.6.2.3 (06-03-2024)

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder or they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Recipient
    Preliminary Engineering Plan Going through the Engineering Planning Process supplies all areas needed to fill out the Engineering Plan Data Item Description (DID) and this includes the Service Level Agreement (SLA). Engineering Documentation Process

2.120.6.2.4 (06-03-2024)

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Activities are measurable in terms of efficiency and effectiveness. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    EP 1.0 Determine which Engineering Processes need to be in the plan Determine which Engineering Processes need to be in the plan

    • Send a request for an Engineer to help with engineering planning

    • Obtain initial agreement with Engineer for a Service Level Agreement (SLA)

    • Agree based on the SLA which engineering processes belong in the EP
    EP 2.0 Negotiate collateral engineering work Negotiate collateral engineering work (e.g. Training, metrics, QA reviews)

    • Determine Human Resource resource needs for the project

    • Determine Stakeholder Involvement

    • Determine Engineering Training needs

    • Determine metrics to be collected
    EP 3.0 Establish Engineering resource needs (SLA) Establish Engineering resource needs

    • Establish SLA between the Project and SE

    • Specify Needed Project Engineering Environments

    • Collect Engineering Plan details

2.120.6.2.5 (06-03-2024)

Procedures

  1. Procedure

2.120.6.2.5.1 (06-03-2024)
EP 1.0: Determine which Engineering Processes need to be in the plan

  1. This step is to determine which Engineering Process need to be in the EP.

    ID Task Name and Description Role RACI Duties
    EP 1.1 Send a request for an Engineer to help with engineering planning Project Lead,

    Engineer    		 R

    C    		 Send a request for an engineer to help with Engineering Planning

    • Create a Unified Work Request for engaging Solution Engineering Services.

    • Send a request to the Solution Engineering Front Door e-mail box with the UWR number requesting an Engineering Contact for Engineering Planning for the project to the following e-mail address: it.engineering.customer.support@irs.gov. The requestor will be assigned an engineer to help with engineering planning.
    EP 1.2 Obtain initial agreement with Engineer for Service Level Agreement (SLA) Project Lead,

    Engineer    		 R

    C    		 Obtain initial agreement with Engineer for a Service Level Agreement (SLA)

    • Decide if the project needs full service from SE or if the project requires review only service.

    • If review only go to task 1.3.

    • For full service go to task 3.1

    Note:

    Full Service means SE will become fully engaged in the work and will be responsible for all engineering deliverable and artifacts.
    EP 1.3 Agree based on the SLA which engineering processes belong in the Engineering Plan Project Lead,

    Engineer    		 R

    C    		 Agree based on the SLA which engineering processes belong in the EP.

    • Project Lead negotiates labor costs and funding with Engineer assigned.

    • Document which engineering processes are needed for the project with the assigned engineer

    • Use the Process tailoring guidelines contained in the Solution Engineering process descriptions contained in the Integrated Process Management (IPM) Process Asset Library and in the IRM’s Engineering, and Data Engineering chapters.

    Note:

    *RACI is a responsibility matrix that describes the participation by various roles in completing the tasks or deliverable for a project or business process. RACI is derived from the four key responsibilities typically used:

    • Responsible – The person that is assigned to do the work.

    • Accountable – The person that makes the final decision and has ultimate ownership.

    • Consulted – The person that must be consulted before a decision or action is taken.

    • Informed – The person that must be informed that a decision or action has been taken.

     

2.120.6.2.5.1.1 (06-03-2024)
Cross-Functional Flow Diagram

  1. Figure 2.120.6-2

    This is an Image: 74884002.gif

    Please click here for the text description of the image.

2.120.6.2.5.2 (06-03-2024)
EP 2.0: Negotiate collateral engineering work

  1. This step is to negotiate collateral engineering work with the Project Lead.

    ID Task Name and Description Role RACI Duties
    EP 2.1 Determine human resource needs Project Lead,


    Engineer    		 R


    C    		 Determine Human Resource resource needs for the project

    • List the required human resource needs
    EP 2.2 Determine Stakeholder Involvement Project Lead,

    Engineer    		 R

    C    		 Determine Stakeholder Involvement

    • List stakeholders that will be involved in each Engineering Process/Artifact.

    • List the stakeholders involvement activities for each Engineering Process/Artifact

    • The Engineering Process/Artifacts include:

      • Solution Design Process: Simplified Design Specification Report (SDSR)

      • Interface Design: Interface Control Document (ICD)

      • Hardware Analysis and Design/System Configuration Validation Process: Government Equipment List (GEL)

      • Data Management

      • Naming Data Elements
    EP 2.3 Determine Engineering Training needs Project Lead,

    Engineer    		 R

    C    		 Determine Engineering Training needs

    • List the Engineering Processes that will be used for the project and document if any training courses are needed.

    Note:

    Refer to section 2.120.6.1.8 for more information
    EP 2.4 Determine metrics to be collected Project Lead,

    Engineer    		 R

    C    		 Determine metrics to be collected

    • Identify the metrics the project needs to collect

    • Capture those metrics during the execution of project

    • Deliver the metrics to Process Maturity (PM) for storage in the appropriate Measurement Repository.

    Note:

    *RACI is a responsibility matrix that describes the participation by various roles in completing the tasks or deliverable for a project or business process. RACI is derived from the four key responsibilities typically used:

    • Responsible – The person that is assigned to do the work.

    • Accountable – The person that makes the final decision and has ultimate ownership.

    • Consulted – The person that must be consulted before a decision or action is taken.

    • Informed – The person that must be informed that a decision or action has been taken.

2.120.6.2.5.2.1 (06-03-2024)
Cross-Functional Flow Diagram

  1. Figure 2.120.6-3

    This is an Image: 74884003.gif

    Please click here for the text description of the image.

2.120.6.2.5.3 (06-03-2024)
EP 3.0: Establish Engineering Resource Needs (SLA)

  1. This step is to establish Engineering Resource Needs for the Project.

    ID Task Name and Description Role RACI Duties
    EP 3.1 Establish SLA between the Project and Engineering Project Lead,


    Engineer    		 R


    C    		 Establish SLA between the Project and Engineering

    • Document Service Level with help of Engineer in the Preliminary EP

    • The Engineer assigned to work the project on their EP will make the final determination of the project’s level of complexity

    Note:

    Refer to the tables below the step 3 table for more information about levels of project complexity.
    EP 3.2 Specify needed Project Engineering Environments

    The physical design of the Project’s environments will be included in the Government Equipment List (GEL) developed for each environment the project needs. The GEL for an environment will contain the hardware, software, and tools needed to be acquired for the environment. The GEL for an environment will be produced during the appropriate phase of the OneSDLC life cycle for the environment.

    Note:


    The GEL process is taken care of through the Hardware Analysis and Design/System Configuration Validation Process. Each GEL will need to be reviewed and approved by SE.

    		 Project Lead,


    Engineer,


    Project Office    		 R

    C

    I    		 Specify needed Project Engineering Environments

    • List which environments the project will need to accomplish the project work (e.g. development environment, integration environment, test environment, production environment, disaster recovery environment, and other environments (as required)).
    EP 3.3 Collect Engineering Plan details Project Lead,

    Engineer    		 R
    C    		 Collect Engineering Plan details for the Engineering Plan

    • Collect all details related to each Engineering Planning Process step. These details make up the Preliminary Engineering Plan.

    • Prepare to use the Preliminary Engineering Plan as an input into the Engineering documentation Process.

    Note:

    *RACI is a responsibility matrix that describes the participation by various roles in completing the tasks or deliverable for a project or business process. RACI is derived from the four key responsibilities typically used:

    • Responsible – The person that is assigned to do the work.

    • Accountable – The person that makes the final decision and has ultimate ownership.

    • Consulted – The person that must be consulted before a decision or action is taken.

    • Informed – The person that must be informed that a decision or action has been taken.

    SE Support Time Estimates for
    High Complexity Projects
    Artifact OneSDLC State Full Engagement
    (Development & Review)
    (SE Days )**    		 Review Only
    (SE Days)**
    EP Readiness State N/A 7
    VSA Readiness/Execution State N/A 22
    SDSR OneSDLC Execution State 47 (x 2) 17
    GEL Readiness/Execution State 50 15
    ICD Execution State 47 (x 2) 16
    The numbers for full engagement (development) are estimates for planning purposes only and are subject to change once the scope of the project is fully determined.
    Total SE Days
    (** 1 Day = 8 person hours)    		   238 77
    SE Support Time Estimates for
    Medium Complexity Projects
    Artifact OneSDLC State Full Engagement
    (Development & Review)
    (SE Days )**    		 Review Only
    (SE Days)**
    EP Readiness State 12 7
    VSA Readiness/Execution State N/A 22
    SDSR OneSDLC Execution State 32 (x 2) 17
    GEL Readiness/Execution State 40 15
    ICD Execution State 32 (x 2) 12
    The numbers for full engagement (development) are estimates for planning purposes only and are subject to change once the scope of the project is fully determined.
    Total SE Days
    (** 1 Day = 8 person hours)    		   168 73
    SE Support Time Estimates for
    Low Complexity Projects
    Artifact OneSDLC State Full Engagement
    (Development & Review)
    (SE Days )**    		 Review Only
    (SE Days)**
    EP Readiness State 8 7
    VSA Readiness/Execution State N/A 22
    SDSR Execution State 23 (x 2) 17
    GEL Readiness/Execution State 39 15
    ICD Execution State 23 (x 2) 9
    The numbers for full engagement (development) are estimates for planning purposes only and are subject to change once the scope of the project is fully determined.
    Total SE Days
    (** 1 Day = 8 person hours)    		   122 70
2.120.6.2.5.3.1 (06-03-2024)
Cross-Functional Flow Diagram

  1. Figure 2.120.6-4

    This is an Image: 74884004.gif

    Please click here for the text description of the image.