ATIS_CCB_Charter.pdf

DEPARTMENT OF THE ARMY

U.S. ARMY TRAINING SUPPORT CENTER

FORT EUSTIS, VIRGINIA 23604-5166

REPLY TO

ATTENTION OF:

TRADOC Capabilities Manager Army Training Information System

(TCM-ATIS)

Configuration Control Board (CCB)

Charter

1. Purpose.

This document is the charter for the TRADOC Capabilities Manager - Army Training Information System (TCM-ATIS) Configuration Control Board (CCB). The CCB provides change management of TCM-ATIS systems. This charter identifies roles and responsibilities of the CCB and its members.

2. Applicability.

This charter applies to the TCM-ATIS and CCB members (voting and non-voting).

3. Scope The CCB is the focus of configuration change activities for software and documentation for ATIS.

This charter establishes the composition, function, responsibilities, and authority of the CCB. The charter grants authority to the CCB to implement and manage baseline changes to ATIS systems, legacy software, and associated documents. The CCB is a voting board. It will approve/disapprove implementation plans and schedules of proposed changes based on problem reports (PRs) and other change requests. The CCB will use change management (CM) procedures to control changes and ensure that all changes to configuration items (CIs) are documented. The primary objective of change control is to establish and maintain a systematic change management process that:

• Provides efficient processing and implementation of problem reports that maintain operational readiness

• Ensures complete, accurate, and timely changes to documentation

The CCB is responsible for the preparation and approval of the CCB Charter. This charter will be revised periodically to reflect appropriate changes in the CCB composition and level of authority.

4. Mission.

The CCB will:

4.1. Approve or disapprove implementation plans and schedules of PRs and change requests for software and associated documentation changes to the ATIS systems and legacy systems baseline.

4.2. Prioritize, sequence, and manage changes to the ATIS based on available resources, urgency, and TCM ATIS objectives and priorities.

4.3. Institutionalize and maintain a process to provide insight and input by TCM-ATIS staff into the plans and schedules for the development and implementation of the ATIS.

4.4. Review and approve software architecture design and supporting system documentation.

5. Organization.

The membership is composed of Government and contract representatives. The designated members shall be delegated full authority at the CCB. The CCB will review tickets, assign action items, establish a time period for the implementation of the change, establish priorities, and ensure activities are properly documented. CCB membership is maintained by the CCB Charter.

5.1. Chair. The Technical Integration Manager of the Development Division TCM- ATIS is chair of the CCB.

5.2. Secretariat. TCM-ATIS shall provide the secretariat to perform the CCB administrative tasks directed by the Chair.

5.3. Voting Members. Voting members consist of:

• Development Division Chief, TCM-ATIS, (Chairperson)

• Capabilities Integration Manager, TCM-ATIS

• Functional Integration Manager/COR Functional Team, TCM-ATIS

• Technical Integration Manager, TCM-ATIS

• TDC Functional Proponent Lead, TMD

• COR Development Team, TCM-ATIS

CCB Observers:

• System Support Manager, TCM-ATIS

• Delivery Division Chief, TCM-ATIS

5.4. Non-voting Members. Nonvoting members are the Secretariat and invitees.

5.5. Invitees. Other organizations or individuals may be invited to attend a CCB meeting if a member sponsors them and their attendance is coordinated with the CCB Chair. The sponsoring member shall coordinate participation of invitees. Standing invitations exist for:

• Software Technical Lead

• Systems Engineer representative

• Functional Analyst(s)

• Test Team Lead

• Database Lead

• Requirements Manager

• Configuration Manager

6. Functions and Responsibilities.

The CCB acts on tickets submitted to the change request management system

(CRMS) affecting ATIS systems baseline. The CCB is the focus of configuration change activities for ATIS and legacy systems and associated documentation. It is the official forum for final review, implementation approval, and documentation of problem reports and change requests to the established baselines.

6.1. The CCB Chair will, as a minimum:

6.1.2. Schedule and conduct meetings.

6.1.3. Develop an agenda prior to meetings.

6.1.3. Present status of CCB activities as required.

In addition, the CCB Chairperson shall:

• Ensure that all members have an opportunity to consider and address all tickets.

• Direct, when necessary, appropriate members to provide additional information required for consideration of a ticket.

• Designate a substitute to conduct a CCB Meeting if necessary.

6.2. The Secretariat will, as a minimum:

6.2.1. Perform the administrative tasks associated with the CCB.

6.2.2. Organize and store meeting agendas, meeting minutes, updated rosters, and associated documents within the ATIS configuration management (CM) system IAW the TCM-ATIS CM plan.

The CCB Secretariat shall:

• Generate and publish the CCB Charter.

• Generate the attendee distribution list for the CCB.

• Generate the CCB agenda report.

• Report all tickets submitted for adjudication.

• Review documentation for completeness and compliance with established policies and procedures.

• Ensure all members are provided an agenda and a report, which at a minimum includes PR id, headline, detailed description, priority level for each change, at least one day prior to a CCB meeting.

• Ensure that circumstances leading to a vote are recorded in the minutes.

• Record meeting minutes and check the minutes into CM within 5 working days.

• Inform all members of implementation approval or disapproval of tickets.

• Assist in the maintenance of the CRMS system.

6.3. Each CCB Voting Member will, as a minimum:

6.3.1. Act as a focal point for the organization to resolve issues and activities related to Army training and doctrine products/information, technology and architecture(s).

The CCB members shall:

• Review agenda items and be prepared to provide their official position at the CCB meeting. In all instances of non-concurrences, the dissenting member’s opinion will be reflected in the minutes.

• Provide the CCB Chairperson a broad base of experience for assistance in making decisions.

6.4 CCB – Oversight Responsibilities

The CCB shall:

• Enforce change management policies, processes, and procedures used to process tickets.

• Review and approve any changes to the baseline ATIS and legacy systems and documentation. The CCB will approve changes to the baselines if it can be implemented within budget constraints.

• Approve deployments to the production IT infrastructure.

• Request level of effort (LOE) estimates from the Software Configuration

Control Board (SCCB) for change requests.

• Form advisory groups as necessary to conduct analysis and research for perceived issues that require course of action decisions.

7. Procedures.

The CCB will observe the following general procedures:

7.1. Standing Rules and Operating Procedures. The CCB may establish standing rules as required, per section 7.5, to effectively carry out this charter. Standing Operating Procedures are listed in Appendix A.

7.2. Meetings. The ATIS CCB will meet weekly, or at the Chair’s request by electronic notification. Meeting dates shall be at the same weekday and time to maximize participation of voting members or arranged to minimize schedule conflicts and maximize participation of voting members. CCB meetings will follow an agenda published at least one day in advance of the meeting, and are facilitated by the Chair.

CCB meetings may be held live (synchronous) or virtually (asynchronous by email).

7.3. Quorum. A quorum will exist when a simple majority of the voting members are present.

7.4. Issues. Any member of the TCM-ATIS may raise an issue with the CCB Chair. It is at the CCB Chair’s discretion whether it should be included in the agenda for the next meeting. The CCB may vote to forward a technical issue to the AOG or functional issues to the RCB, and LOE issues to the SCCB.

7.5. Decisions. CCB decisions shall be made based on a consensus of the voting members. Decisions concerning the scope, mandates and standards in the ATIS will require that (1) a simple majority of the quorum present vote in favor of a motion, and (2) no substantive disagreements are raised. The voting member(s) raising a substantive issue must submit a written rationale to the CCB Chair within three (3) working days, who will add a discussion item concerning the rationale to the agenda of the next meeting. If it is still unresolved after that meeting, the CCB chair will bring it to TCM-ATIS.

7.6. Charter Review. The CCB charter will be reviewed as necessary.

APPENDIX A

CCB STANDING OPERATING PROCEDURES

The CCB Secretariat schedules CCB meetings as required, distributes agendas, generates reports, records CCB decisions, composes and distributes minutes, generates reports, and forwards tickets and action items for action. These operating procedures define CCB meeting times for disposition of PRs to ensure timely approval, assignment, and implementation. The CCB directs the SCCB to assess the impact of proposed changes and provide inputs at the CCB meeting.

CCB Meetings The CCB will meet once per week. An agenda will be published by the CCB

Secretariat at least one day in advance of the meeting. All CCB members should be present at each CCB meeting and should be familiar with the changes being considered.

The CCB Secretariat will review the items on the agenda. CCB Members will review impact, priority, category, and establish a release/sprint target for each ticket or keep the ticket on hold. The CCB Secretariat will record the final dispositions in the Change Request Management System (CRMS). The CCB meetings may be conducted where all members are physically present and/or conducted by teleconferencing.

In the event that the CCB Chairperson cannot attend a CCB Meeting, a person designated by the chairperson shall conduct the meeting.

The CCB Chairperson may cancel a weekly CCB meeting. If this occurs, the

CCB Secretariat will prepare an agenda as usual and distribute to CCB members. CCB voting members will vote (either on each ticket or on all tickets) to move tickets forward in the CM process in order to avoid delays in tickets processing. Voting members will have 2 working days to return their votes. Tickets receiving a majority 'Yes' vote will be moved forward or closed, as applicable.

Special CCB Sessions Using Email

Special CCB sessions may be called or voted on by email: to process emergency problem reports and to process go/no-go requests when moving builds to production. The chairperson will verify that the appropriate board members are present or notified prior to commencing a special CCB meeting. The notification or agenda will contain the duration of the session, the purpose of the session, the recommended course of action and all information pertinent to the type of session. Any CCB member may request additional information or request that the duration be modified.

The chairperson will modify the duration and provide additional information when needed. Duration shall be assigned by using the following default guidance unless directed otherwise by the chairperson. Emergency problem reports and go/no-go requests have durations of 24 hours starting when the secretariat sends the email calling for the vote. The duration must be clearly indicated at the beginning of the special session email.

Votes are counted at the end of the duration using the guidance that follows. At the end of the 24 hour voting period the simple majority will determine actions to be taken.

Votes are yes, no, or abstain. A yes vote means acceptance of the recommended course of action. A no vote is a vote against the recommended course of action.

Abstentions are applied when a voting member does not respond within the duration. If the vote indicates acceptance of the recommended course of action, then the recommendation shall be applied at the earliest opportunity. If the vote indicates rejection of the recommendation, then the issue will be added as a special topic to the next regular CCB meeting for disposition. If all voting members abstain, or if it’s a draw, the secretariat will notify all members that the issue will be added to the next CCB agenda as a special topic.

CCB Advisory Groups

Advisory Groups may be formed to address problems that are specific in nature and require an immediate and/or focused effort. Usually this will be focused on a specific set of issues in one or more related PRs. Advisory Groups may also be formed to address recurring problems that repeat themselves over long durations. A few examples are:

general complaints about performance and issues related to usability and training

CCB Advisory Group Formation

1. Any voting member of CCB may request an advisory group be formed to address a specific problem, tasking, or a recurring problem.

2. The request must be made in writing and presented to the CCB Secretariat.

3. The request will contain, recommended wording of the problem definition, recommended wording of the purpose, recommended tasks, recommended deliverables, recommended chairperson, and recommended duration.

4. CCB Secretariat will forward the written request to all CCB voting members and an agenda item will be added to the CCB agenda. Vetting of the recommendations will be conducted via email and during the added section of the CCB agenda.

5. A CCB vote will be called no less than 5 full work days from the time that CCB Secretariat forwards the request. Any CCB voting member may request additional time to review the recommendations prior to a vote. Vote may be conducted via email at the discretion of the CCB Chairperson.

6. An affirmative vote passes the advisory group charter to the advisory group chairperson with a deadline for completion of the charter.

7. The chairperson will recommend the membership and will recommend changes to any section that may be needed.

8. The chairperson will return the charter to the CCB Secretariat who will forward the charter to the CCB voting membership.

9. A vote may be called for the next scheduled CCB meeting or by email at the discretion of the CCB Chairperson.

10. An affirmative vote will be considered CCB ratified and will be sent to Chief, Development Division and Chief, Delivery Division for signature.

CCB Advisory Group Dissolution

Termination of advisory groups may be done at any time by CCB vote. Any CCB voting member may call for a vote to terminate an advisory group. Vote may be conducted at a CCB meeting or by email.

CCB Change Control Process

Figure. Change Control Process Flow

All tickets are functionally reviewed before being submitted to the CCB for consideration. The CCB may request that the SCCB to provide a LOE for any ticket.

Based on LOE and resources available, the CCB will assign implementation priority, plan sprints, and assign tickets to the sprint schedules.. The CCB will review each ticket and its assigned priority level. The COR of the development team may downgrade the priority during the SCCB process. If a P1 is downgraded because of resource or schedule issues, the COR will notify the CCB.

PR Priority Level

The PR Priority Level is used to categorize the magnitude and/or urgency of a change request. The functional manager identifies a priority and category based on the user’s perceived impact. The PR Priority Level may be changed by the CCB as necessary to adjust to changes in the environment throughout the ticket’s lifecycle.

The CCB reviews and adjusts the PR priority level and category according to the following criteria:

Category Description Applicable Priority Levels Problem Report Items that cause the program to fail to operate as required or as previously approved - PRs validated by functional team.

1-2

Directed Change Required new feature or required change based on policy or other directed guidance.

1-2

Enhancement Request New feature or modification of current features (cannot violate policy/technical restrictions).

A new capability, modification or removal of an existing capability from a formerly approved baseline.

Priority Level (Impact) Description 1 (High) Work-stoppage - user cannot complete operational or mission function IAW official requirements.

This includes:

• Displaying of existing data

• Processing new data

• Providing functionality previously available to the system user which renders the system unable to accomplish its primary mission.

• Ensuring system/data security 2 Work-around available - user can complete operational or mission function IAW official requirements through a reasonable alternative work-around

3 New feature or capability that would improve system usage but does not affect a required operational or mission essential function.

Release/Sprint Planning Support

The CCB may assign a PR or change request to be implemented in a target release/sprint. If the CCB does not have resources available to implement the change, then the ticket will be held in CCB Hold until the CCB decides to move it forward to the release/sprint backlog for the ATIS system in question. The release/sprint planning process for the ATIS system will then be able to schedule the ticket for work. A ticket will be re-assigned to another release via the release/sprint planning process if it fails during the initial assignment.

Content Repository, Data, and Database PR Process

Content repository, data, and database PRs are tickets submitted to change data/content/structure within the (production) system that cannot be modified by the user through the user interface.

Data PRs are generated when the data manipulation capability is either bugged or doesn’t exist. This includes data that has been corrupted via any of the system interfaces that cannot be repaired by users.

Content repository PRs are submitted to request a change, addition, or deletion of a node in the content repository.

Database PRs are tickets that identify database schema changes. Database schema changes are typically generated in conjunction with software change tickets.

The CCB will now review content repository, data, and database tickets because these tickets represent potential significant workload and may also indicate underlying systemic problems that need a better solution.

RESULTS OF A CCB REVIEW - Tickets

The CCB will consider all available information concerning a ticket in order to render a decision. The CCB Secretariat will document the decision. The CCB may keep a ticket in CCB Analysis if additional information is being requested from the functional team, in SCCB Analysis if LOE estimates are requested from the SCCB, or in CCB Hold if resources are limited. Based upon the recommendations of the CCB one of the following will be authorized:

• Approved for implementation. An approval will result in implementation of a PR. The approved PR is placed into the product, release or sprint backlog for implementation during an upcoming sprint.

• Disapproved. Disapproved is a rejection and means that the PR cannot be implemented as it stands. A rejected PR will be accompanied with a message explaining its rejection. The ticket will then be returned to “Submit” state to be reviewed – updated or closed – in coordination with functional proponents.

• Closed. The CCB will close a PR once it has been validated and is ready for closure, is a duplicate of another PR, or is an operator error.

Deployment to Production Approval

The CCB will approve or disapprove deployments to a production site.

• The CCB will receive test reports and RCB recommendations on moving new software builds to production servers.

• The CCB will approve any configuration changes to production or production-like environments.