Protecting Your Atlassian Tools Ecosystem Investment (Part 3): Governance Committee Activities

In Part 1 of this Governance series we discussed the governance model and the need for a Governance Committee, and in Part 2 of the series we discussed the committee roles and responsibilities. Now let’s take a closer look at the activities of the governance committee.

 

Committee Meetings

The Committee will initially meet quite regularly when defining the framework, governance policies, and evaluating change requests. However, once the company settles into steady state The Committee will likely only meet once a month or once a quarter depending on the number of change requests requiring discussion. These meetings should be formalized, and preparation work should take place prior to the meeting, so that decisions can be made during the meeting.

 

It is recommended that the committee select an administrator. This administrator will be responsible for the following:

• Send out the Agenda, including all Change Requests on the docket for discussion, 5 business days in advance of the meeting
• Take notes during the meeting and disseminate meeting minutes
• Formally document meeting decisions and post meeting action items

 

The agenda should include all of the Change Requests that are on the docket for discussion. This allows time for each voting member to ask any questions about any of the change requests and for the administrator to gather any additional information needed from the submitter for the committee to make decisions during the committee meeting.

The agenda itself should include:

• Documentation of attendees present and confirmation of quorum
• Approval of previous meeting minutes
• Introduction of new committee members (if applicable)
• New business
• Review and evaluation of change requests

 

Communication will be discussed a little later in this blog, but it is important to note that any decisions resulting in any change should be communicated to the company once the decision has been made, in advance of the change being implemented, and then again after the change has been completed.

 

Change Requests

The Change Request Process should be centralized, and Senior Leads should input Change Requests on behalf of their teams into Jira via the Governance Project. It is important that Senior Leads do a preliminary vetting of the change which is being requested. Not every change requested should come before the committee.

 

Prior to the meeting, all Senior Leads should ensure that all Change Requests are submitted into the intake system. This is where The Committee Administrator is able to get a list of all submitted changes to be included in the Agenda. All committee members should review the Change Requests in advance of the meeting so that any questions or requests for additional information can be provided to The Committee for consideration when discussing and evaluating the request during the meeting. Failure to do this could result in the inability to make a timely decision on a Change Request.

 

For each Change Request, the Senior Lead which submitted the request on behalf of their area should present an overview of the change being requested. The Committee should then discuss the request and each member should provide an “Objection” or a “Non-Objection” to the change request.

 

Some of the key criteria to consider when voting are:

• Is this change within the policy limits of acceptable changes (not requiring a formal vote)
• Will this change impact anything architectural (requiring a formal approval by the AE)
• Will this change impact any other integrations or automation
• Who will this change impact and is someone from that area represented in this meeting
• Will this change impact the area that i am responsible for representing and if so, how
• How will this change impact enterprise or company reporting

 

If a “Non-Objection” is provided by 70% or more of The Committee, the request is considered accepted. If a “Non-Objection” is provided by 51-69%, then the change should be discussed further with the AE. If a change significantly impacts the ecosystem in any way, the change should be submitted to the Accountable Executive for an approval. All major changes, those which impact more than one Line of Business or Portfolio, should be reviewed by the Accountable Executive.

 

Communications

After any Change Request has been approved and prioritized, the planned changes should be communicated out to the company to notify staff of the upcoming change, in advance of the change implementation. Once the change has been completed, it should again be communicated to the company to remind them of the change and any impact. The Committee should also communicate to the company all software changes for any of the applications, apps, or plugins which impact the user. These communications are often reviewed by The Committee and corporate communications prior to being sent out to the company.

 

Review of Processes and Procedures

Processes and Procedures are often used interchangeably, but in fact, they are two different things. A process is what we do, while a procedure is the actual step by step guide on how to execute. While you may have a process document for users on “How to Request New User Access” the corresponding procedure document on “How to Configure New Users” would be quite different. Both of these documents are equally important and must adhere to and be founded upon the governance documents which the committee has created. While the committee will document what the strategy is, what is allowed within the policy guidelines and what is not, the policy will not include how to execute. The team responsible for execution would be best positioned to own procedure documents. However, the governance committee will often want to review these documents to ensure that they adhere to the governance policies.

 

Some of the processes which are normally included within the purview of The Committee are the:

• Access Management Process
• Change Management Process
• Creating a New Team Process
• Creating a New Enterprise Project
• Creating a New Jira Project Space

 

Many companies create a comprehensive continuity book of procedures which they maintain in Confluence and includes the following procedures:

• Creation of a new user group
• Creation of a new team
• Creation of a new project (depending in requirements and architecture: issue vs project space)
• Creating a new Jira project
• Creating a New Portfolio (Jira, Jira Align, Portfolio Plug-in)
• Creating or Adding a New User
• Moving a User from One Team to Another Team
• Moving a Team from Program or Department to Another
• Changing a Configuration

 

In this blog post we summarized the many activities of the Governance Committee. Stay tuned for the fourth blog within this series where you will learn about best practices and governance tools to help support your governance committee!