Unlike the Development and Operations organizations, Governance is a functional role, not a position. People throughout the IT organization perform governance roles. The Governance organization is little more than a collection of committees.
The most obvious and common of the committees is the Change Advisory Board (CAB) responsible for approving the changes to production systems. This group should be led by Release Management and include the proposers of changes along with those impacted by the change. Typically, the group has a set of fixed members from infrastructure and PMO along with temporary invitees reflecting the drivers for the change and the other affected parties.
The Enterprise Architecture Oversight Committee (EAOC) is lead by the chief architect or CTO and includes the leadership of all development and infrastructure groups. This group is charged with maintaining the list of approved/acceptable technologies within the company and vets any proposed new technology – ensuring that they are both supportable and support the strategic direction of the company.
Another governance group is the Process Improvement Committee (PIC). This team is responsible for defining, producing, and responding to all IT performance metrics for Development and Infrastructure, using this information to define Service Level Agreements and Operating Level Agreements (SLA/OLA) and any process improvement initiatives. This is the natural home for Six Sigma methodologies and projects (Yes, Six Sigma can be applied to IT). Once identified, process improvement projects are passed to the Portfolio Management group.
The Project Governance group (PG), led by the head of the Project Management group, arbitrates all project conflicts ensuring that projects are prioritized and resourced at the company level. Another key function of this team is to spot when one silo within the business is taking action that will either conflict with or potentially enhance the operations of another. Significant project timeline and cost risks are directed at this group for resolution or mitigation. Out of this resolution, problems requiring Process Improvement focus will be surfaced and referred to PIC.
The final committee in the Governance arena is the Strategic Planning Committee (SP). This might be chaired by either or both of the CTO and the leader of Portfolio Management. The group uses the roadmaps of all the business units and corporate executives as input to define the IT roadmap for the next 2 years, adjusted at each quarterly meeting.
Good article. The description of each of these groups can be expanded, and this framework should be used and expanded in the organization.
Where I am now, we have a committee responsible (which is a role) for reviewing and approving new Infrastructure Designs. The designer would touch all the above mentioned governance groups in the design process.
Hi Lionel. Thanks for contributing to the discussion. You are absolutely correct that this can be expanded, and will be in future articles. I’m working my way through a series of progressive revelation that started with the first post in the series on April 23rd with the structure of the entire IT department. It was followed by posts on Operation, then Development, now I’m diving in to each of the sub-groups in those areas. I’d welcome your feedback on all those articles as well. Given our common history, we know each other’s backgrounds and the assumptions we each make, so we can point out ways to better the design and communication of the concept.
In my postulated organization for this series, the Infrastructure Designs would be reviewed and approved by the Enterprise Architecture Oversight Committee. Depending on the scope of the change initiative, certainly all the groups might need to weigh in.
Given your background, would you be interested in guest-writing an article about one of the sub-groups? I’d be honored to publish it here for you.
Glen, thank you. I would certainly be interested in guest-writing an article about one of the sub-groups, let me know which one. My background is Infrastructure Architecture and Design, but as you know that touches on all the disciplines you have mentioned.
Hey, Lionel. You have probably interacted more with the CAB than I have, that would be a good one. If PIC interests you, go for it (maybe do both in the same article?). I’d also be interested in your comments on the Infrastructure Operations article (a few days after this one).