Procedure: WebCMS and Intranet CMS Feature Intake

Brief Description

This procedure defines the feature intake processes and requirements for the identification and development of Feature Requests (FRs), the evaluation of the feature’s impact, and the roles and responsibilities for making changes to the Web Content Management System (WebCMS) and Intranet Content Management System (IntranetCMS). The feature intake process applies to those products and services that, if changed, would have a direct impact on the project’s output (i.e., product, system).

The documentation and tracking of all Feature Requests will be managed using this procedure. Web and Intranet Council Members can submit feature requests and bugs using this form.

• Rationale
• Definitions
• Exemptions
• Feature Intake Process
• Related governance documents
• Full metadata about this standard

Rationale

Formal feature intake ensures that proposed changes to the identified systems follow a rigorous process of evaluation and implementation so that traceability and accountability are supported and documented. This will help to ensure that available funds are allocated to a prioritized list of changes.

This procedure applies to the Office of Information Management’s (OIM) Information Discovery Division’s Web Infrastructure Services Branch. This document is intended to define the process and procedures by which changes to EPA’s flagship Intranet site, work.epa.gov, and flagship Internet site, www.epa.gov, are requested and performed. 

Definitions

Feature Request: A proposed change to the functionality of the WebCMS or Intranet CMS application. More formally, it is a request a customer, stakeholder, or employee submits when they want to see a specific feature added to a product or service.

Feature Intake Committee (FIC): A formal group of project stakeholders who are responsible for reviewing, evaluating, approving, delaying, or rejecting changes to the project as well as documenting all decisions and recommendations. The Feature Intake Committee includes the Feature Intake Administrators, Feature Intake Committee Chair, WebCMS and Intranet CMS Technical Leads and Office of Digital Communications (ODC) and Web Infrastructure Services Branch (WISB) Staff as needed.

Bug: Often, a condition in which the system's actual behavior doesn't match the user's expectations. Also, a system failure that happens under certain (maybe rare) circumstances.

Roles and Responsibilities: 

Exemptions

There are no exemptions to this procedure.

Feature Intake Process

1. Step One: Feature Request is Submitted
   • All stakeholders are encouraged to submit FRs to enhance and improve EPA’s internet and intranet environments. Feature requests must be reviewed by the requesters program or regional office’s representative (Web Council or Intranet Council Representative), who will submit the request through the online form. Only requests from the applicable Web Council or Intranet Council member will be considered. To submit a FR for a feature or enhancement to these systems, the Feature Requester identifies a requirement for change to either of these systems and submits a Webform for a Feature Request. The FR will include:
     • Who is making the request.
     • Description of desired feature or enhancement including proposed functionality.
     • Reason for the request.
     • Benefits (who, what and how).
     • Impact of the request including projected costs, how many users/visitors would be affected, and risks concerning site/content integrity (if known by submitter).
     • Any supporting documentation, including mockups or screenshots.
2. Step Two: Feature Request is Evaluated
   • The FIC Chair and Technical Leads reviews the FR within five business days of receipt and determines whether additional information is required. An initial impact assessment of the change to the project’s time, scope, and cost will be conducted. The decision to submit the FR for FIC review will be based on factors, such as:
     • Number of feature options presented.
     • Benefits of the feature: Will this feature make the site better? Can the feature be added to both WebCMS and EPA@Work?
     • Complexity and/or difficulty of the feature options requested: How much development time or effort is required to complete the request? Will the requested feature require custom coding?
     • Scale of the feature solutions proposed: How will this change impact all web areas? If this change is made, how widespread will its effects be? Does the request make sense for the other web areas?
     • Cost.
   • WISB will research options based on requirements and needs of the CMS to determine if there are any available alternatives that more align with the above evaluation criteria.
   • The request can be rejected if the above factors are not sufficient. If the FR is rejected, the FIC Chair returns it to the Feature Requester with a rationale for rejection. The Feature Requestor may submit a revised request.
   • If there is insufficient lead time to follow the formal SOP process, the WISB Branch Chief may approve and expedite the request.
3. Step Three: Pre-Approval of the Feature Request
   • The FIC Chair will forward the Feature Request and any supporting documentation to the Feature Intake Committee for initial review. The FIC will determine the feasibility of this feature by examining factors, such as: 
     • Risks to the project in implementing or not implementing the feature.
     • Impact on the project in implementing the change (time, resources, quality). 
   • After initial review, the Feature Intake Committee may: 
     • Pre-Approve: The FR is pre-approved and continued in Step Four of this SOP.
     • Approve: The FR is approved outright because impact, resources, requirements, and implementation are minimal. If approved outright, proceed to Step Six of this SOP. Generally, these kinds of feature requests are completed by EPA.
     • Defer: If the information provided to support the FR is not adequate or substantial enough to decide or the timing of the request is not appropriate, the FR is assigned a status of deferred.
     • Blocked: The requested feature has a prerequisite that is not implemented.
     • Reject: If the FR is rejected, the FIC Chair returns it to the Feature Requester with a rationale for rejection, and the FR is closed out. The Feature Requester may submit a revised request. 
4. Step Four: Acceptance Criteria and Level of Effort Assessment Meeting 
   • FIC Chair will set up a meeting between Feature Requester, Technical Leads and Development Team to find concurrence on Acceptance Criteria. Once Acceptance Criteria have been determined, the Development Team will provide a level of effort to the FIC Chair. 
5. Step Five: Development Approval 
   • After Level of Effort Assessment Meeting the FIC may: 
     • Approve: The FR is approved for implementation. It will be assigned a high, medium, or low priority to provide guidance on sequencing the implementation of the FR. The process continues to Step Six. 
     • Reject: Based on the level of effort, requirements, and financial considerations the FR will not be approved. The FIC Chair provides the Feature Requester with a written rationale for the rejection and the FR is closed out. 
6. Step Six: Plan, Develop, Test, Deploy 
   • Plan: Development Team will prioritize, schedule, and assign to a production release. 
   • Develop: Development work will be completed.
   • Test: Testing of work will be conducted on staging by Development Team and includes testing from the Requester or other SMEs.
   • Deploy: The Feature Request is implemented into the Production environment and documented in the Release Notes. The Feature Request is closed out.

Related Governance Documents

EPA

Related Policies

• None

Related Procedures

• None

Related Standards

• None

Related Guidance

• None

Non-EPA

• None

Full Metadata about this Standard

Name WebCMS and Intranet CMS Feature Intake
Type Procedure
Required or Recommended Required
Effective date July 09, 2025
Date last approved July 09, 2025
Category Web Governance
Web Council review by July 09, 2028 (or earlier if deemed necessary by the Web Council)
Governing Policy Web Governance and Management