March 2000
Volume 15
Number 12
Always Planning
The trouble with Astrategic planning@Cbesides the fact that many people are not sure what the term actually means C is that once one of these plans is finished nobody wants anything to do with planning until memory of the ordeal fades away. Many an extensive planning process has had the paradoxical effect of resulting in massive, ungainly plans that are soon left to gather dust on the shelf. If the 1980s and 1990s were the golden age of strategic planning, the 00s are characterized by movement to a more reasonable and workable process model. Today, the most common approach to planning is to do it continuously; always planning turns out to be both more successful and more bearable than periodic, exhausting campaigns to produce blockbuster plan documents.
Planning for information technology is a more-or-less continuous process. As soon a plan is complete and in writing, it changesC both the technology and the needs of end users force this to happen. Planning is also a highly participative process and much better done by a representative committee than by a single individual, even one who is very knowledgeable about technology. By the same token, the committee should be a standing committee that develops, refines, and maintains a practice of planning that melds into the life of the institution. Extraordinary planning committees created just to produce the plan and then dissolve themselves are often more trouble than they are worth. They have a long learning curve, and then they tend to hand off a plan that they know they themselves will not be the ones to implement or revisit. Standing committees tend to produce a different kind of planCone more gradual and realistic, more in synch with the normal rhythms of the college or university. Once the plan is on paper, the challenge will be to keep the momentum going and to keep the plan fresh and useful.
The planning committee
Who should serve? First and most importantly, all who serve on this kind of
committee must be very clear that they need to balance representing their areas
with careful attention to the best interests of the institution. The committee
cannot be composed solely of the champions of computing. Nor can it be populated
with the loudest complainers. And it s membership need not represent every
department, school, or other organizational unit merely for the sake of
consistencyCmindless formalism is one
of the hobgoblins of committee makeup.
With those caveats in mind, the committee can be populated with fifteen to twenty people drawn from approximately these categories: senior administration, faculty, mid-level administrators, students, and the IT leadership. Others, such as consortium members or alums may be considered as well. The committee must not be packed with IT staff; nor is it necessary that the CIO chair the committeeCthat choice needs to reflect the local realities in leadership and skill to chair the committee.
The committee should also be constituted so as to be easily renewed by replacement members. The test of a good committee is whether it can go through changes and successions in membership without upheaval. Continuity over time and through changing issues is eventually one of the strong ancillary contributions to planning that this committee can provide.
Recommended process
A reasonable way to proceed would be the following: Every three years, go
through a complete planning process: a compilation of IT needs of the whole
institution, a strengths-and-weaknesses analysis, a prioritization by the
committee of the most important items (usually the ones that will affect the
most people) and an approval of the funding from the appropriate authorizing
body. This is a formal process, with a deadline, a responsible party, and a
written result. The basic ingredients for this plan should be:
The strategic needs of the institution Is the institution planning to add
new educational or instructional programs? To enter a different competitive
arena for students? To deliver its instruction in a different manner, such as
through distance learning? To expand the physical facilities significantly?
These strategies should always be the drivers for IT plans.
End-users= needs and objectives.
Does the faculty need access to networked services in the classrooms? Will
applications for admissions be coming in over the web? Are there web-development
software tools the faculty are interested in using?
External technological trends. How should the rapidly improving price/
performance ratio of desktop microcomputers affect how they are deployed and how
frequently upgraded and replaced? Are the expanding resources of the Internet of
value to the students? Should web-based information access be the standard for
administrative computing?
The campus=s technological
situation and outlook. Is the IT staff keeping up with user demands? Will
the network have sufficient capacity for anticipated uses? Is the information
architecture up-to-date? Is the infrastructure robust, with little, if any,
downtime?
Budget information. How much of the institution=s
resources is it reasonable to commit to IT over the next three years? Are there
ways to use resources more wisely? Is it time to look at different budgetary
strategies, such leasing instead of purchasing equipment?
Once this formal, three-year plan is in place, it should be revisited every year to make sure the remaining efforts are still in line with the original intentions. This phase of the process need not be as extensive as the effort that takes place every three years, but it should not be perfunctory either. While the off-year reviews are not a formal process, they too should have a deadline and a responsible party.
In both cases, the goal is to reach consensus among the committee members. Nothing undermines a plan faster than any hint that the committee could not come to genuine agreement. Consensus is not the same as unanimity; rather, it is a zone of common thinking within which differences can be respected.
And a plan is not plan if it is not public, accessible, and officially accepted. Good work can easily be wasted if any of these elements is missing after the committee does its work. Of course, committees are not able to control these factors, so they fall to the responsibility of senior administration. Posting the document on the web with a prefatory letter from the most senior administrator with responsibility for IT is an example of an easy method to Apublish@ the plan. Accessibility also has an intellectual dimension: the plan should be written so as to educate and inform the entire campus communityCand this does not mean dumbing it down. Some extra care in explaining concepts and defining terms is what is needed. If the plan is good, it will be the measure against which all IT decisions can be evaluated. LF
The Edutech Report is a monthly publication of Magna Publications
The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President:William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.