Central Governance in a Decentralized Environment

The University of Minnesota offers a large array of non-credit and continuing education offerings across its colleges and divisions both on and off campus. But the colleges and divisions establish their own business processes and often operate independently of one another, creating a decentralized environment. In 2014 the university formed a team to implement an enterprise registration system solution for colleges and departments with non-credit offerings. The team was focused on fiscal resourcefulness, institutional efficiency, data security and quality student services in order to remain competitive in the changing market.

After the team selected a software platform and started the implementation process, it became clear that there were different business needs and competing priorities among the colleges and divisions using the system. Because of our decentralized environment, we ran the risk of people pulling in different directions, focusing on the wrong objectives, and failing to make decisions for the good of the university as a whole.

When it came time to make configuration decisions concerns were expressed that the colleges with the greatest number of offerings or large budgets would dominate the decision-making process. It was important that all colleges and departments felt a sense of responsibility and ownership of the system and were actively engaged in determining strategies and making decisions. Governance became a priority in order to provide accountability, fairness, equity and inclusion.

Defining the Key Needs

During the RFP and early implementation process, we formed a steering committee to provide effective leadership for the software platform. They were the sounding board when there was a disagreement between end users. There was representation from the early adopter colleges, Controller’s Office, Office of Information Technology and University Information Security. This committee was the first step towards formalized governance.

As we moved further into the implementation phase, we realized we needed a value proposition to get people engaged and willing to devote their time and resources. The benefits were in these key areas:

Centralization: This allows the university to understand non-credit activity across the institution. It creates a consistent and seamless experience for our learners. Centralized administration of the system allows colleges and departments to focus on their curriculum and content delivery instead of system tasks. By having data all in one place we can better represent how the university is performing in its outreach goals and the value that non-credit education brings.

Integration: The system provides integration with various systems across the university replacing manual processes.

Cost Saving: The system is funded through the system-wide technology cost pool and that cost is proportioned out between units based on their collegiate FTE totals. This levels the financial playing field for everyone involved.

Transparency: Provide clear information to stakeholders.

Building a Framework for Collaboration

With our value proposition in place, we held a retreat for anyone with an interest in the new enterprise non-credit registration system. The purpose was to create a governance team charter, an acceptable use agreement, and policy statements detailing everyone’s role in ensuring the system would be sustainable across all of the university. Approximately 45 people attended. They were responsible for drafting the initial governance documents.

As the system went live we transitioned from a steering committee to a governance committee. As each college or business unit comes on board they are asked to designate one person as their voting member. As the college or business unit may have multiple, disparate departments using the non-credit registration system it is critical that the voting member is someone who has good visibility and communication channels to the entire organization and can represent all parties with their vote.

Now that we have reviewed the journey the university took to formalized governance, let’s talk about the tools and processes we use to uphold the value proposition and sustain the system.

The team charter was created to define the purpose of the governance team and how they would work to provide effective leadership and coherent shared responsibility for the Destiny One Registration System across the University of Minnesota system.

Included in the team charter:

• Purpose
• Vision
• Goals
• Responsibilities
• Scope
• Meeting Expectations
• Communication
• Voting Rules

Along with our purpose statement, we created the team’s vision for Destiny One, established goals, defined team member responsibilities and scope of the product governance. We also set meeting logistics and expectations such as who should attend and how often.

Executing on (and Adapting) the Governance Model

Communication and change management are important aspects of our governance model. We have a website which hosts information for our user community. Governance is included in the top level navigation. Choosing the Governance tab gives them access to the purpose of our product governance, the team charter, upcoming meeting agendas, minutes from past meetings and our policies and use agreements.

Meetings are held the first Tuesday of each month. This is an open meeting and all current and prospective users are encouraged to attend. Voting members are expected to attend meetings regularly.

Outside of scheduled meetings, the primary means of communication between governance team members is a Google group. This is also our means of communicating with our entire staff user community. When a staff user is provisioned in/out of the Test and/or Production instance of the non-credit registration system we add them to or remove them from the Google group.

Coming to consensus on changes for a centralized system in a decentralized environment can be a challenge. For smaller changes, such as changing a Configuration Point that may impact the business of all users of the system, we previously sent out a survey to the entire user community of more than 400 through the Google group. Responses were minimal and did not provide good representation for whether we should actually make the proposed change.

We now post proposed changes to configuration points on the monthly governance meeting agenda. Each voting member is responsible for discussing the proposed change with their users, soliciting their feedback and voting on the change at the meeting. Voting for these types of changes tends to be a simple yes or no of whether they are in favor of the change.

Not all configuration point changes are brought to governance meetings. We have a staff of six Business Analysts that also make decisions on changes that will be clearly beneficial and not negatively impact any of our colleges or business units.

We also maintain a Google sheet, shared with our staff user community that includes:

• Signed Change Requests (CRs) in progress
• CRs for Prioritization (essentially a wish list)
• Bugs
• Delivered CRs
• Resolved/Closed CRs

How We Manage Competing Priorities

Fairness, equity and inclusion are important especially when prioritizing changes to the system. Everyone who requests a change does so because it is important to their business and it is a priority for them. However, it may not be a priority for someone else. To take some of the emotion out of the prioritization process we came up with a process that relies on math. We solicit input from everyone but also use math to weight the items we are prioritizing. Everyone has a voice in the decision but the math adds fairness to the decision.

Governance team members may submit an item for prioritization consideration. It is reviewed by our IT Director, myself and/or other support team members to determine:

• Is there a viable workaround?
• Is it on the vendor’s product roadmap?
• Will there be a benefit to the greater user community?

If there is value to the request, the item is added to the list of CRs for prioritization. We use a scoring rubric to assign a Rubric Weighted Score. We engage with the vendor periodically to determine the development effort that would be required for each item, ranked from Very High to Very Low. The vendor also provides information about what is on their near term roadmap, priority backlog and regular backlog. This helps us to determine if we should wait for an item to be delivered as part of core functionality. On an annual basis, we send a survey to the entire staff user community asking them to rank the candidate CRs. All factors are taken into consideration and a determination is made by the governance team which items should be proposed for funding. If there is no clear consensus, a subcommittee is formed to make a determination before the final proposal for funding is made. Once funding is approved, we work with the vendor to create the change request.

Clarifying Roles and Responsibility

One last key component to the success of centralized governance in our decentralized environment is clear communication of the roles and responsibilities of the parties using the system. One of the early decisions of the steering committee was the collegiate and business unit staff would be trained to use the registration system and manage their offerings and learners. Currently, the Academic Support Resources-IT department consists of six business analysts that provide administrative and technical oversight of the non-credit registration system. This includes:

• Vendor Relations
• Integration Partner Liaison
• Merchant Account Management – including PCI DSS compliance training and reconciliation
• Technical Support
• Product Training and Job Aids
• Governance Facilitation
• Communication and Change Management

New collegiate and business unit staff who onboard must go through training appropriate for the role they will have in the system. They are not provisioned in the Production environment without the required training. Their responsibilities include:

• Creation of their offerings in the registration system
• Managing registration activity
• Supporting their learners
• Active in governance

The Centralized Management Model Keeps Everyone Focused and Engaged

The model we’ve established strikes a good balance that allows colleges and business units to focus on their learners, programming choices and content delivery while freeing them from managing the administration of the registration system.

We’ve proven the value of the centralized system and even as there are grumblings about system functionality not being available, or that users have to modify their business process, they appreciate the overall benefit. The most important part of the story is the positive changes we’ve seen in the learner community.