Policy on Policies

If Cornell was not the first, it was among the first to have a "policy on policies." The name never goes by a group of newcomers to the area without nervous laughter. Among those imbued in it, it can be an eye-roller. What is it about this concept that creates a strong reaction, and how best can an institution structure it to meet the Goldilocks test of a "just right" happy medium?

The key is in the question: structure. Back in the day, Cornell pioneered its program when Vice President Fred Rogers worked out an agreement with then President Rhodes to delegate his policy authority to the finance office to formulate and promulgate university policy ... at least in the financial area. No surprise that at many institutions, finance spearheads policy. Regulatory pressures to create comprehensive external reporting requires harmonized internal processes. Often the process spills over to other administrative areas, such as human resources or facilities. The progression was natural. The need to bring policy to widely distributed areas of a university, especially one leaning towards the "TUBS" model, together with the regulatory pressures to speak as one voice to external entities appeals across the administration. As much as any one unit may not have wanted to engage in the process, or engage in a process under the auspicies of another unit, the benefit outweighs the disadvantages. A structure is born, and with it, a policy on policies.

I have studied many an institution's "policy on policies." While much depends on the culture and tradition of the institution, there is common ground. The process almost always has three parts.

Vetting the concept before senior leadership is the first part. That group should review it for fit to the institution, make at least a rough cost/benefit analysis, and request the inclusion of specific groups. For example, when we brought a web accessibility policy forward, senior leadership insisted that we include students in the editorial process. It was a pleasure to do so, and, as expected, they added a lot to the discussion. But that group, which was ad hoc, does not have standing for all policies. Finally, senior leadership also provides the authority to go forward. If the policy is controversial, and the policy driver meets backlash, that support is essential to maintaining momentum througout the process.

The next step, middle level review, is always the most lengthy, and has a number of subparts. It begins with an editorial group. Choose wisely three to five special advisors who will help you draft the policy. Those participants may be the technical staff whose assistance is necessary to implementation. Staff outside of your organization whose buy-in you require anyway is also helpful; in fact, like the old adage about corrupt voting, get their buy-in often and early. There are also some people who, by dint of personality, rise to an "elder" level in the community (no matter what their age) and you are always wise to bring them into the process. For example, I invite folks from the university library at Cornell whose opinions I trust, Elaine and Eileen, and a colleague from human resources, Lauran, who has good "devil's advocate" ideas, and my colleague from university counsel, Pat. Joshua, from the policy office, is the standard bearer. Given a high level of mutual respect and trust among us, we can all disagree without being in the least disagreeable while working through complicated issues. I value the gift of their time, expertise and reputation in the community enormously.

Stakeholders ... this group may not be in your small editorial group but they are equally critical to the process. Timing is everything. If you bring them in too early, before you have a substantial enough draft, they may feel as if you are wasting their time. If you bring them in too late, they may feel left out. So be sure that you, perhaps with the assistance of your editorial group, identify at the beginning of the process who the stakeholders are, how to get in touch with them (some require handling via intermediaries, a feature that as a rule is more true the higher in the institutional organization that you go), and use good judgment to determine when is the right time to consult them.

Constituents ... are different from stakeholders. They are groups, mainly faculty, staff and students, who must be consulted for every policy. They may not have as much of a stake in the policy as, well, a stake holder. But given their fixed role in the community, they must be brought into the process somehow. In a perfect world, a representative from each of those groups should be in the formal middle level review body. At some institutions that is not the case, however. Cornell is one of them. For example, there are no student representatives anywhere in the policy process, perhaps a hold over of policies concerning administrative areas that genuinely did not involve them, such as capital assets. Consequently, the policy driver must reach out on his or her own.

(If distinguishing these two groups is confusing, think of the solar system. The policy is the sun. Stakeholders are the inner planets, and constituents outer ones. All of a piece, some are closer to the policy than others, and of course, it all depends on the policy. A network registration policy requires input from everyone, because everyone's devices require registration, but it will be more important to have network and system operators at the table than students for whom registration is automated. A policy on responsible use that is the foundation for judicial action on copyright infringement might require more student input, and so in that case the order is reversed.)

The last substep of the middle level review is to go before a formally established review body. That body does not have the authority to say "yea" or "nay" about a policy, but to review it for readability and ease of implementation. As in any writing proces, sometimes the meaning is clear only to the author(s); having someone else read it helps to make it accessible. Also, if people throughout the institution find that the policy is not realistic to implement either technically or administratively, then it should be sent back to the drawing board. In one case at Cornell (before my time) there was a data access policy that failed for this reason. In fact, the policy was not really a university level policy, but more an operational one. Confusion about the kind of policy exacerbated the concerns about implementation. The result was consternation. In the aftermath of this failed policy, a data stewardship policy later emerged that still serves as a a framework for administrative systems from PeopleSoft through Kuali.

Once the middle level review is finished, often with many edits in between, it is back to senior management. One might imagine that the final step would be easy sign-off because so much work has gone before it, but perhaps because IT policies are so new to the game it has been my experience that even at this last stage policies can be subject to substantial revision. Take it in stride. Be gracious. Even if you are ready to explode from the boredom of reading or explaining the policy for the 4,000,000,000th time, be patient. For the person to whom you are explaining it, it is not only the first time that they are hearing about it, it may be the first time they are absorbing the form and function of a university-level information technology policy. Most important, don't frustrate yourself with pride of authorship. If properly formulated, the policy will go through more versions than Carter has little liver pills. It may still be about the original idea, but it will read nothing like it did before any previous iteration. If you enjoy authorship, go take a creative writing class. Don't hold hopes for personal expression in institutional policy.

When given the green light to promulgate, your work ... has just begun. It is time to educate the community as a whole, and perhaps do some training with relevant personnel. But that matter awaits another blog entry!