Navigating a Governance Process around Enterprise Computing
Welcome to the April 2005 issue of Bridging Technology and Learning! Imagine three businesses: one sells computers, a second builds custom houses and a third provides personal counseling services. Now imagine that in six months, they will share a common hiring process, will use the same set of reports to manage their finances, and can only pay for goods and services one way. Welcome to the world of higher-ed enterprise resource planning (ERP) projects.
How can an institution best set itself up to meet the needs of autonomous business units and still manage them effectively as one entity? In this issue, we will explore how to navigate a governance process, one that meets the needs of a central administrative group, while taking into account the concerns and desires of autonomous business units across a college or university.
Best,
Howard
In higher-ed institutions, enterprise computing projects are caught between a rock and a hard place. While departments perceive the need to conduct business in unique ways, there is an ever demanding need to standardize business practices across the entire institution. Although there are huge technical challenges in bringing consolidated financial, HR or student systems to this business environment, an even greater challenge is taking into account the perceived needs and concerns of semi-autonomous administrative and academic departments.
At the heart of successful enterprise efforts (not just turning on the switch) is the creation of a thoughtful governance process, one that facilitates central, campus and project team dialogue.
Definition
Governance can be defined as “The process through which organizations make strategic decisions, determine whom they involve and demonstrate accountability for the results of their actions.” Ideally, the governance process achieves agreement between differing interests to reach a broad consensus on what is in the best interest of the enterprise.
Although executives, faculty, and administrative staff each have a unique role to play, they ultimately desire the same thing: to be able to focus on their primary jobs with as little bureaucratic disruption as possible. Among these groups, self interest boils down to: faculty wants to focus on teaching and research, administrative staff want to keep the offices running as smoothly as possible and management wants to keep the peace between the two. Anything that impinges on these primary roles cause personal frustration.
The Challenge
And therein lies the challenge. Faculty did not sign up for managing their own expense accounts or filling out online requisitions. Administrative staff already know how to keep their offices organized and don’t need new business processes.
And management didn’t sign up for the chaos of helping everyone through the discomfort of change. Integrating enterprise computing forces these disparate groups to take a holistic approach on getting work done, one that benefits the institutions health but not necessarily individual needs. So where do you begin?
Let’s assume a good mix of faculty, executives and managers are identified as key stakeholders and through careful planning, a governance structure with this group is established. This is the easy part. It’s navigating these groups in the planning and design stage of a project that poses the most challenge.
The Goal of Governance
What are the critical elements to pay attention to in navigating a governance process? It comes down to artfully managing expectations. The goal of a governance process is to keep those most affected by the change in the loop so they can influence the change to their liking and most importantly, feel that they have been heard.
What often happens instead is a need for change gets communicated (outdated systems, lack of reporting), promises get made about what the new system will do (management cannot afford to not have stakeholders onboard immediately), and periodic meetings are scheduled to update the governance team along the way.
On the surface, establishing this case for change, promising needed benefits and scheduling governance meetings are all critical. However, the breakdown of a governance process comes from a failure to artfully communicate the following three elements:
- Communication with the governance team will be straightforward, honest and precise.
- Improvements will come in stages (whole benefit will not happen at once)
- The changes will meet some of your needs, not all.
Point 1: The Straight Scoop
In working with a governance team, it’s critical to build and maintain trust. When communicating plans and scope changes, feedback should be characterized in one of three ways.
- A decision about a process or system design has already been made and the project thinks it’s important you know about it.
- The project team has a plan but to best meet your needs, they request your input to make sure it works for you.
- The project does not know what’s best for you and is gathering information to make an informed decision.
Too often the request for feedback is left open to the listener’s interpretation, and invariably leads some to perceive a commitment to something that was never spoken. This is where the trust can break down. It may be difficult to tell a group that they don’t have a choice (“this is the way it is”) but it’s better than waiting for them to discover it themselves. Pay me now or pay me later. It consistently costs more to pay later.
Point 2: Improvements Take Time
The reality of enterprise computing is not only that changes come in stages, but scope changes are more fluid than communicated. At every level on a project, the most difficult yet powerful statement that can be made is “We don’t have an answer to that right now” or “We don’t know.” The more stakeholders understand how fluid the scope changes are in the design phase, along with confidence that it is being managed effectively, the more flexible they’ll be in negotiating their individual needs.
Point 3: The Judge Wapner Rule
What happens when Judge Wapner renders his best decisions? Both parties recognize the fairness of the outcome and most importantly-neither side gets everything they wanted. In enterprise projects, stakeholders who appear to want the world often just want to be heard and do not expect everything. The mistake is not listening to them for fear of having to act on every request. Willingness to listen and communicate back what was heard will go a long way to appeasing groups that seem to want it all now.
In conclusion, governance structures in large institution are an invaluable mechanism to move technology projects forward. Don’t underestimate the value of being straight about what will and won’t be done, communicating the fluid nature of the project scope in the context of the timeline, and balancing everyone’s needs while not promising the farm. Believe it or not, people can handle the truth.
Presentation Tip of the Month
When watching a movie, you have a sense when the end is coming. In many presentations I’ve observed, the end of the presentation sneaks up with people shuffling papers and quietly moving toward the exit. Because your final words will be most remembered, inform your audience what’s about to happen. “Before we end today, we’re going to take a few final questions, then synopsize the key points.”
This does two things. One, it let’s people know to organize their thinking to articulate any final questions and two, it increases the chance you’ll be able to end with a cohesive group. Those ready to jump out of their seats will give you a few extra minutes to wrap it up.
Speaking Engagement
If you are interested in a copy of the presentation given to the Boston Product Management Association, send me an email and I’ll forward it to you. The title of the presentation was “Minimizing Pain From Cross-Functional Communications.” Email me at hteibel@teibelinc.com.
