Whose System Is It, Anyway? Partnering with Faculty in Administrative System Projects

About five years ago, we began to think about replacing our aging student information system at the University of Saskatchewan. We had recently completed the implementation of a human resources system, and it would be fair to say that the campus community had never embraced the project or the system that resulted from it. Although neither of us was involved in the HR project, we were both members of the university community when the HR system was implemented. Like many others, we didn’t feel a strong stake in it.

The absence of community support severely disadvantaged the HR project and continues to do so. As we began to plan for the new student project, we realized that we needed to learn from the experiences and struggles of the project that had gone before. The way the HR project was received by our campus community taught us some valuable lessons and led us to seek a radically different approach—one that would make partners of our campus colleagues.

Both of us came to this project inexperienced in implementing enterprise resource planning (ERP) systems. We were—and probably still are—somewhat naïve about how to approach a large software project, but we came to this exercise with considerable experience in both academic and administrative roles. We have made our careers in and with academic processes and collegial culture. This meant that we were not naïve about things like the importance of consultation and process in a university setting, and the disastrous consequences if you don’t prepare the ground. Although our inexperience with ERP projects might seem like a disadvantage, in retrospect it was probably an asset—we knew we had a lot to learn, we had few preconceptions, we looked at what other universities did, and we weren’t committed to any particular project management methodology.

We learned a lot about project management along the way but also began to see areas where classic project management needs to be modified to work in a university setting—most specifically, it needs to accommodate the "faculty factor." Universities are unique places of business, and the collegial system defies some of the expectations and assumptions that project management books talk about, such as the assumption that there’s a chief executive officer in a position to make decisions and insist that the rest of the institution comply.

This article does not focus on either the technical side or the project management side of implementing administrative systems. There is no shortage of literature on how to put together an implementation team and deploy hardware and software to support your administrative processes, and a good consultant can go a long way toward helping you in this area. We saw our challenge as much larger than just implementing software. Because this project would need campus-wide engagement, we had to get an entire academic community on board. To do this, we had to identify and reflect the special values and characteristics of that community. Consultants (and vendors) understand software implementation projects, but people steeped in the culture of a university best understand how such a project is likely to be received in that environment and what approaches are likely to bear fruit.

Administrative systems renewal isn’t something your faculty will ever get excited about, but we believe there is much that can be done to render the academic community more receptive and even supportive. In this article we use the implementation of our SIS (and a new portal through which we will deliver its services) as a case study to illustrate how we approached this task, but we think that our experience is more broadly applicable. After all, whether it’s an HR or finance system, a portal, or a new approach to configuring computer labs on campus, administrative system renewal is undertaken not for its own sake but because of what it can do to support the institution’s academic mission—the goals of teaching, learning, and research.

Climatic Conditions

It would be easy to assume that because universities are places of cutting-edge research, higher learning, innovation, and new ideas, they will naturally be receptive to new technologies for administrative systems. But, as a recent EDUCAUSE Center for Analysis and Research (ECAR) study¹ showed, universities are not particularly supportive of new and innovative IT initiatives. When faced with the purchase price of a new computer system or any other capital expense, our academic colleagues are quick to ask "How many faculty positions or journal subscriptions could that pay for?" They tend to downplay, or not to have thought through, the connection between the goals of higher education and the value that a good administrative system can bring to a university. In short, the university climate is far from ideal for the seeding and cultivating of large administrative projects.

All universities share a number of defining characteristics and values that contribute to their climate:

• Universities are some of the oldest, most venerable institutions in the world, and they have preserved a medieval decision-making structure that makes them highly resistant to change.
• Autonomy is a central value of the of the university but also of departments, colleges, and individual faculty members. There are many voices, many points of view, and many constituencies whose needs and concerns must be taken into account.
• Faculty members tend to identify more strongly with their disciplines (and thus with their departments) than with the institution. The argument that "the university needs this" is neither sufficient nor compelling.
• Faculty members strongly emphasize process. This results in dozens of committees with participation by scores of people—far more than in the private sector. These bulky structures affect the efficacy with which decisions get made, and it is tempting to try to short-circuit the process. But academics value consultation, and any attempt to bypass the consultative process in the interest of expediency can doom a project.
• Faculty are in the business of critical thinking. Every position can, and will, be vigorously argued, but argumentation should not necessarily be interpreted as opposition or hostility.
• Administration is not an activity held in particularly high regard in the academy. Research and teaching will always take priority for faculty, so the climate will be particularly cool when it comes to any administrative initiative. In fact, when we asked one faculty member at our institution where a student information system would be on his list of priorities, he responded, "It’s not even my second-last priority!"

These are the conditions under which our project operates and that we had to work to accommodate. We expect that the same conditions prevail at most institutions. This article takes you through the phases of our project as we describe the obstacles and opportunities that emerged from our collegial context and explain how we addressed them.

Preparing the Ground

We hired a consultant on a very short contract (about a month) to advise us on assessing our needs in replacing the SIS and framing an appropriate approach. At this point we hadn’t decided whether to buy, build, port, or outsource, and we knew we needed help to decide. The consultancy was very helpful, partly because it introduced us to a project management approach and gave us a roadmap to follow but also because it helped us begin to realize the limitations of the classical project management approach in a university setting. We began to see that while a consultant could bring many good things to this effort, there were important things that only people inside the university could know and appreciate.

We started our project with a needs and options phase, spending almost a year canvassing our community for their needs and establishing the best way to meet those needs. We hired another consultant during this phase, one whose experience and credibility in the higher education sector helped take us through the needs assessment and selection process. Looking back, doing a needs and options phase was an enormously worthwhile investment of time and money in other ways, too. It helped us identify the various stakeholders of the system (this is not as easy as it sounds—it’s easy to forget someone on the first go-round); it got us campus awareness and campus buy-in (including buy-in from the senior administration and the Board of Governors); it gave us a chance to sell the idea that this was a university-wide project; and it gave our fledgling project team a chance to establish credibility and confidence within the user community.

We also began to think about approaches to governance and communication. It’s important that the governance structure for a major project reflect and reinforce institutional values (such as collegiality, representation, and accountability), and we designed our structure accordingly.

Our first task was to create a steering committee to provide oversight and advice to the project. We knew it would be important to have faculty representation in the form of deans and chairs of the major university committees, and we knew it would be important to have student representation as well (we found out later just how valuable that was). Other things we looked for as we set up our governance for the project included the following:

• We made a concerted effort not to duplicate decision-making structures and bodies that already existed. Our strategy was to co-opt existing structures and bodies wherever possible because it was important that the project be situated (and be seen by the campus to be situated) within the existing structure rather than have a separate identity outside it. We drew on our experience to know which formal bodies are charged with what decisions and then approached these bodies (and individuals) with relevant information and requests for decisions.
• We wanted a strong academic presence to ensure that academic values were reflected and respected and to communicate that to the campus community.
• We were also determined to connect our project strongly to the senior administration. We recognized that it would be important for us and for our colleagues to know that the senior administration was fully behind the project and to have endorsement at the highest level for any requests we needed to make of the community. Getting our provost to be the project’s executive sponsor was a critical step.

One further thing we began to appreciate more and more during this phase: a major project of this sort is not just about software. If you think what you’re doing is simply a matter of deploying software and hardware and overseeing a project team, you will encounter considerable community resistance and risk missing out on many good opportunities for

• Discovering things about your institution that nobody remembers the history of, or the reason for.
• Rethinking the way you do things.
• Reevaluating your institutional decision-making processes.
• Reconfiguring your governance structures.
• Identifying (and sometimes altering) the formal and the real authority for your policies and processes.

We also knew that effective communication would be critical to our success and began to formulate our strategy early in our project. We’ll have much more to say later on about communication.

Sowing the Seeds

Our needs and options phase concluded after a year with a recommendation to the university’s Board of Governors that we purchase and implement a vendor product. Upon receiving board approval, we entered an eight-month product selection phase. The vast majority of the effort expended in product selection goes to developing the request for proposal (RFP), the purpose of which is to select a product. But the exercise of creating this document is a further opportunity to refine and think through the institution’s needs. It thus demands a continuing focus on process.

Site Visits

A very important aspect of this phase were the site visits we made to other universities. We went to five different universities having relatively recent implementations with different vendors and implementation partners. We got a little bit of push-back about doing these site visits before the RFP—some people thought it would prejudice our product selection. We don’t think it did because the focus of our visits was far less on the particular product these institutions had implemented than on how they organized their projects—what they thought they did right or wrong, how they managed to get approval for their purchase, and how they got buy-in from their community.

We talked to people in many different positions at these visits—CIOs and IT directors, project managers, deans and deans’ office staff, registrars and assistant registrars, and project team members. The information we gathered and the contacts we made proved their worth, since we later found that faculty colleagues often ask "What are they doing at other universities?"

The conversations also made us realize that just as not all products are the same, not all universities are the same, and we saw very different approaches to system implementations. Decision making at some institutions is quite distributed, while others take a more centralized approach; some budgeted their entire project up front, while others took an incremental approach. Our visits opened our eyes to a broad range of possibilities in a number of areas.

We’re not going to say much about the development and evaluation of the RFP except that we invited substantial community involvement in the on-site demonstrations that the short-listed vendors put on for us. More than 250 people (faculty, staff, and students) attended one or more of these demonstrations, helping build enthusiasm for our project and what it might bring for everyone.

Board Presentations

Two of the high points of our first two phases were the two board presentations we made, first to gain approval to go ahead and shop for a new system, and then a year later to confirm the choice we had made. Three things stand out about the first presentation we did:

• The importance of the student and faculty support we had developed
• The "Prophets in their own country" syndrome
• The big obstacle: cost

Student and Faculty Support. Our 12-member Board of Governors includes one student member and one faculty member. We didn’t fully appreciate how important it would be that we had included the president of our student union on our steering committee until we got to the board. One particularly skeptical board member had concerns about the expected cost of the project that were completely defused by an impassioned endorsement of the project by the student member of the board. The faculty member of the board was not on our steering committee, but he was also supportive when the project got to the board, based on his knowledge that we had consulted widely with his colleagues.

"Prophets" Syndrome. We said earlier that one thing we learned about consultants is that they know only half the equation—you can’t rely on them to understand your institution or your business. Paradoxically, some decision makers in your institution will listen much more carefully to an outside voice than to voices from within the institution. Having our consultant’s stamp of approval on our process—an independent assurance to the board and president that we had done our homework and were making a choice based on solid research and a duly diligent process—was invaluable.

Cost.We knew the cost of the project was going to be a shock. One of the lessons urged on us by the HR project team was that we needed to be up-front about the costs—not to make any claims that this project was going to save us money in the long run (it won’t) and not to be talked into agreeing to try to do the project for less than we knew it was going to cost (we can’t). Here again, our consultant was a big help in ferreting out the real costs and providing industry-standard cost estimates. Still, the first time our president heard the ballpark cost of a new SIS, he paled.

A year later, when we came back with the results of the RFP, including firmer costs that were within a few percent of our initial estimates, two things happened: the president, who had had a year to come to terms with the cost, didn’t look shocked at all, and the skeptical board member who had been so swayed by our student union president’s advocacy of the purchase a year earlier rose to propose the motion to approve the purchase, congratulating our team for the accuracy of our original estimates.

Effective Communication

As mentioned earlier, we knew from the earliest stages that effective communication would play a big part in community acceptance of this project. A project communication strategy has many dimensions. Too often we tend to think that the only thing we need to communicate is a kind of status or progress report—that we’re "on budget and on schedule." This is important, and it’s certainly information that your board and steering committee will want to hear, but other messages are vital if you want to build your community of support and make allies of your colleagues. They need to be continually assured that this is a worthwhile investment of scarce institutional resources, that the project will further the academic mission of the university, and that their trust in the project team to deliver on promises is well placed.

An effective communication strategy must recognize some very different audiences within the university community. We worked hard to understand what different audiences want and need. Examples follow of the characteristics of different university constituencies that a communication strategy must take into account in order to be effective:

• Students: Students are comfortable with technology and expect anytime, anywhere access to services. They don’t want to wait until the project is completely signed off to use it. They need continual assurance that new services will come within the relatively short time that they are part of the university community. They don’t want (or need) to know who provides a service; they simply want the service.
• Faculty: The comfort level with technology varies substantially across the spectrum of faculty members. Faculty members like to do things for themselves (so self-service will be appealing), but they resist being trained (so introducing a new system can be problematic). Above all, faculty members do not like to be surprised. They need to be well prepared in advance for anything that might affect what they do.
• Deans, Department Heads, and University Committees: These folks are very concerned with authority and responsibility: who has the authority to make what sorts of decision, and who has the responsibility to make something happen. They can have great concern about "downloading" work (so the self-service message has to be properly framed), but they are very sensitive to institutional efficiencies.
• Administrative Staff: Although administrative staff have a high level of technical sophistication, a change in the way they work can be threatening. They need to know that adequate training will be available. The prospect of benefits like increased system speed and fewer keystrokes can be persuasive. Staff also are concerned about which office or person has responsibility for what.

A key message involves communicating a vision and goal for the project—what it is you are trying to achieve and how this vision lines up with the goals of the institution. For a message like this to be effective, you can’t assume that the goals of the institution are monolithic. Different parts of the institution have different goals and priorities—no amount of institutional visioning and strategic planning exercises will change this. So it’s important to try to understand the goals and priorities of each sector or unit and show how your project can help them meet those goals in the particular area that your system functions. It may be, for example, that the ability to run ad hoc reports and specify different parameters for them is vitally important for your deans but holds little or no interest for faculty members who want the same information every year at the same time and who are perfectly happy with a canned report. It’s a mistake to bore people with information about functionality that they’re not likely to find of any interest or relevance.

Another important message has to do with the image of your project and team. You may already know that your project team is a capable, enthusiastic, positive group of people who are committed to institutional goals and priorities. But you need to make sure that the university community knows and appreciates this and understands that the project team is attuned to the institution’s needs and culture. This kind of trust takes time to establish. It helps if you have some trusted people from within the institution, especially from the academic ranks, on your project team. You also need to get the faces of the people on your project "out there"—in photos in your campus newspaper, at product demonstrations, at needs assessment sessions, and anywhere else that they can get to know the stakeholders around campus.

A third important message is that your project is a university project, not "just" an IT project, nor "just" the registrar’s project. You need to put your implementation on the big stage, make it visible all the time, and allow other units to take ownership. For this to happen, it’s vitally important that you elicit the expectations of the community and provide them with opportunities for real input. For us this meant involving the community on our academic, technical, and administrative advisory committees and inviting them to participate in vendor on-site demonstrations. It also meant inviting some people who weren’t on our project team to accompany us on site visits.

All this involvement requires a substantial time commitment, one that will be met with resistance by faculty already overloaded with work. Such objections must be met with respect for the sacrifice involved and a sincere commitment not to waste their time—but also with a gentle reminder about the potential impact on them down the road if they are not involved.

Throughout the process, it’s important to listen and keep listening. You need to take your stakeholders’ issues seriously and reassure them that their needs, expectations, and concerns are important and will be addressed.

Tending the Crop

The third phase of our project is the implementation of the software purchased. We’ve been in this phase for more than a year and expect to deliver the first modules within a few months. Implementation is a huge undertaking, and you will need all the resources and techniques of formal project management to keep your project on schedule and on budget and to support your project team. For the purposes of this article, though, we’re not looking inward to the work of the project but outward toward the external community.

It’s vital that you avoid the tendency to "hole up" during implementation—that you continue to grow, nurture, and coax your community of support and to manage the tension between excitement and expectation. Being out in the university community is not a task that you can ask your project manager to undertake—he or she will be far too occupied in the frenzied activities of process analysis, system configuration, data modeling, conversion, training, prototyping, documentation, time tracking, status meetings, and all the other activities that go into such a project. You can’t burden the project manager with the role of change management and ambassador for the project, but you do need to ensure that you have someone who can take this on because you’re going to continue to need the support and understanding of the community.

We sought to build this into our project in several ways:

• Creating the outwardly focused position of project director to complement the inwardly focused project manager role. Both these full-time roles were in place throughout the needs assessment, product selection, and implementation phases.
• Persuading one of our colleges to donate a half-time faculty position to fill the role of academic liaison to the project. This was a three-year commitment.
• Establishing a standing committee on communication whose members were primarily not part of the implementation team and so would not be distracted from the task as the project heated up.
• Hiring a training coordinator whose role was to hire, train, and deploy a cohort of "coaches" who would be attached to academic units a few months before go-live to provide support, encouragement, troubleshooting, and liaison back to the project team.

Eliminating Weeds and Pests

As every farmer knows, tending a crop involves living with the prospect of infestations of gophers, plagues of grasshoppers, hailstorms, lightning strikes, drought, tornadoes, noxious weeds, and a host of other hazards that threaten the successful harvest of the crop. Some of these are beyond your control, but others can be managed and even defeated, providing you know something about your enemy. The risks to a successful administrative system implementation project are less tangible, but no less real. Some pests will spring up in the form of myths, misconceptions, and rumors, and you can (and must) see them coming and address them. Here are a few that we encountered and how we dealt with them:

• System as tyrant
• System as agent of corporate control
• System as black hole

System as Tyrant. This construct is often phrased as "your system is making us change our academic policies." This one is best faced head on. We counter this perception with the proposition that the institution has invested in a powerful tool that we need to make the best possible use of, and that the project provides us with an opportunity to do some things that we might have been wanting to do for a long time but hadn’t taken the time to address. We continue to differentiate project from product and stress that most universities need to find ways to improve processes even when they’re not doing a systems implementation.

System as Agent of Corporate Control. This one may come in the form of "your system is turning our university into a corporation" or "we’re turning our control over to central administration" At the root of this accusation is a fear that the individual faculty member and/or academic unit is being disempowered. A Web-based service model can actually accomplish quite the opposite. Distributing access enables users to take complete ownership of their data and processes. We also point out that a good system can stimulate collaborative approaches and revitalize the collegium by getting rid of "silos."

System as Black Hole. Usually framed as "this money could be much better spent on other things—like hiring faculty, purchasing journal subscriptions for the library, or conducting lab or classroom renovations." The basic premise here is that this project is taking money away from the central mission of the institution—that we could hire x faculty members for this price. There’s an opportunity here to combat "us" and "them" mentalities and to invite faculty to consider us as colleagues and allies. We reassure faculty that we understand and share their anxieties, that we welcome—and share—a critical approach to our project. We talk about jointly held values rather than cost and emphasize that our common goal is to help students learn while enabling faculty to find better ways to advise their students and better tools to help them manage their courses. We also try to find good analogies for the costs to counteract the assertion that an expenditure of this much money represents so many faculty positions. We recast the costs in terms of the price of renovations to some of our buildings, or the cost of utilities, and remind them that an SIS directly supports the central teaching and learning mission of the institution. In short, we continue to work to inspire confidence in us and what we’re doing, demonstrating that this project will bring value to our faculty colleagues and that there are good things in here for them. We continue to work to generate excitement about the outcome.

Harvest

At the time of writing we are still some months from delivering our new student system, but we released our portal more than a year ago. We made a conscious decision to deliver in "tiny bubbles" rather than a "big bang" and so are ever watchful for quick wins. This helps us maintain the perception of accomplishment, productivity, and achievement; reinforces the sense of project momentum; and sustains community and team excitement.

We were given good advice in the area of expectation management—to under-promise and over-deliver—and we have put that into practice. We also embraced a soft roll-out approach that means our releases have little initial fanfare ("roll out with a whimper, not with a bang"). This helps us manage expectation (the "Is that all there is?" element of a big bang) and reduce the risk of community disappointment or disaffection. The implementation of our portal is a good example. No one even knew we were thinking of putting a portal into place until just before we went live, and even then we did a quiet roll-out to allow people to find the portal themselves and try it out before we announced that we were launching it. The campus community’s rapid and enthusiastic acceptance of the portal has been enormously encouraging. We have gone from roughly 7,000 users during its first term of operation to more than 20,000 a year later.

Thanksgiving

It’s important to celebrate successes at every opportunity. People need to be told that they are making a valuable contribution and that it’s noticed and appreciated. When we formally launched our portal, we had a big party at the president’s residence, to which we invited the president, the provost, our vendor’s CEO, and everybody involved in the project. We saw this not just as an opportunity to thank the project team and let them celebrate their successes, but even more as an opportunity to let the university know that something significant and worth celebrating had happened. Sometimes the best way to tell the provost or president that your team has done a good job is to get them to say so in a speech to the team. Once the words are theirs, they will internalize them. And why wait until the end of a project to celebrate?

Project Management and the Academy

We indicated earlier our belief that the collegial system (especially the faculty factor) defies some of the expectations and assumptions of classic approaches to project management. We would like to propose reconsidering four truisms of project management in the context of the academy. Following each truism is our suggestion for revising the usual dictates of project management in the context of a university setting.

Truism: You Need Buy-In from the Top

Yes, this is important—but not nearly as important as in the business world, where the top is readily identifiable as the CEO. Universities operate on a collegial model that is the opposite of the corporate model—an inverse pyramid structure in which decisions flow from individual faculty members through departments and colleges/faculties up through the council or senate and its committees. At a university you need to get buy-in from the bottom—that is, from the rank and file faculty and from key people within the collegial structures—as much as from the provost or the president. You need to be aware of, and know how to tap into, the nonhierarchical structure of university decision making.

Truism: Scope Creep Is Bad

It’s true that the better your grasp of scope, the more accurately you will predict timelines and costs. But opportunity sometimes knocks, and opportunity is a concept that academics understand very well. After all, most basic science—indeed, most research—happens through chance discoveries that lead to unexpected collaborations and hitherto-unlooked-for connections between independent concepts. It is inevitable that your faculty colleagues, who are used to making creative connections, will identify opportunities in your project to solve problems that they have wanted to address for years. They need to know that as ideas arise, you will be open to seizing opportunities, and sometimes these opportunities can be used to continue to build momentum and to obtain quick wins that will get your academic colleagues on board.

Truism: Customization Is Bad

It’s true that customizing a vendor system is expensive—but not customizing can cost you dearly too. Particularly in mission-critical areas like student systems and a portal, one of the purposes of your system is to serve and enable faculty and students in teaching and learning. If the system seems to get in the way of that, what you gain in going vanilla may be lost in support and buy-in of users. Of course we must scrutinize customization requests rigorously, considering process changes and "bolt ons" wherever practical to accomplish things that the software doesn’t deliver. But we must be mindful of the students and faculty that the project has been mounted to serve and whether they will consider the trade-offs we are asking them to make to be reasonable. The product serves the project, not vice versa.

Truism: Charters Contain Fixed Truths

The problem with charters is that they are texts. To academics, texts are things that you constantly revisit and reinterpret. Academics approach texts as artifacts: they like to think about things like subtexts and layers of implied meaning and reader response theory. Project managers like to think of texts, or at least charters, as a set of precise and fixed instructions. The root of this difference lies in the emphasis that academics put on process over product. In fact, for most documents produced at universities, it is the process of arriving at the document and not the document itself or what it says that lends them weight and value. This is not surprising in an institution whose business is to continually rewrite the truth, rethink the canon, and treat all texts as suspect. Administrators and project managers, however, need the assurance that the final wording means something. Both views are right, and each group must be encouraged to understand the other’s perspective.

Concluding Remarks

We have not yet finished implementing our new student information system or the changes to processes and practices that will follow. But we have had surprisingly little push-back, and we continue to get positive responses from our faculty colleagues. We believe that this is at least in part because of the steps we continue to take to engage faculty as partners in rethinking the way we support teaching and learning at our university. As we consider our practices and processes, we ask them questions like whether we really need to do things this way, when and why did we start doing it that way, what principle is behind that rule, do other universities do that too, and who would be in a position to change that? Then we sort through these questions together, figuring out which ones are really worth asking and which battles are worth fighting, doing our homework on them, and bringing the questions forward to the decision makers of our university with appropriate suggestions about how they might be addressed. All of this requires that we be attuned to the formal policies, the governance structures, the culture, and the mood of our institution—in short, to the climate and the condition of the terrain. We’ve set our course, and our team has the confidence and trust of our academic colleagues. We’re working hard to bring in the bountiful harvest they expect.