Penn Computing
Computing Menu Computing A-Z
Computing Home Information Systems & Computing Penn
Please note: This material is no longer current and appears online for archival purposes only.
Use the search and navigation tools above to locate more up-to-date materials, if they exist.

RESTRUCTURING COMPUTING SERVICES
ACROSS PENN

November 7, 1996

CONTENTS

  1. Penn's new structure for computing
  2. Why a new model?
  3. Effect on costs
  4. The "social contract": Assumptions and principles
  5. From old to new: An overview (four charts)
  6. Next steps
  7. Pilot projects
  8. Challenges

Appendices

  1. Task Force to Restructure Computing across Penn
  2. Implementation Steering Group
  3. Frontline support: Choices and responsibilities
  4. Building blocks for budgeting
  5. Selling services where markets exist
  6. Proposal to support students where they live
  7. Technology refreshment of public labs
  8. Services for local providers of computing

ABSTRACT

Computing now touches everyone at Penn. Demand is soaring and Penn's investment is sure to expand. Those who use and those who provide computing services recognize that support can be improved. A task force has developed a new campus-wide structure to make computing easier and more cost-effective for those who use it. The new model will guide organizational change over the next several years.

The new structure clarifies a division of labor that lets the schools and the central computing group each devote more effort to the things it does best. Schools and administrative units take on full responsibility for the frontline support of their members. They also provide local systems, services, and innovations. In turn, the central computing group, Information Systems and Computing, will concentrate on infrastructure (networking, core business systems) and put more effort into services for local computing providers and into standards.

Both the central computing group and the schools are more accountable. Schools bear major responsibilities and in return get greater control over costs and level of support. Penn can't magically increase the total amount of money available for computing, but we can ensure that funding decisions are made as close as possible to the people affected by them and made along with other decisions that will determine Penn's future.

This document. This document describes the new model from the point of view of funding, always a hot issue at Penn. It outlines reasons for the new approach, describes its impact on costs, sets out principles, and describes the funding and delivery of services. It reviews next steps and challenges. Sections 1-8 serve as an overview, with detail in a series of appendices.

More information. More information about the project can be found in its Web site at http://www.upenn.edu/computing/restruct/.

RESTRUCTURING COMPUTING SERVICES
ACROSS PENN

Computing now touches everyone at Penn. Demand is soaring and Penn's investment is sure to expand. Those who use and those who provide computing services recognize that support can be improved. A task force has developed a new campus-wide structure to make computing easier and more cost-effective for those who use it. This document describes Penn's new structure for computing services from the point of view of funding, always a hot issue at Penn. It outlines reasons for the new approach, describes its impact on costs, sets out principles, and describes the funding and delivery of services. It reviews next steps and challenges. Sections 1-8 serve as an overview, with details in a series of appendices.

1. Penn's new structure for computing

Penn's new structure for computing services puts the user at the center. Each person should have a local computing "home" and take all computing questions there. Beyond this circle of frontline support are expanding circles of secondary services, provided by the schools and the central group, Information Systems and Computing. But the map of services is irrelevant to recipients: the frontline support person navigates that landscape for them.

Schools and administrative units take full responsibility for the frontline support of their own members. They can provide it themselves or buy it from each other or from ISC. ISC, in turn, provides a more focused and delimited set of secondary services: networking, core administrative systems, standards, and services for local providers. New strategies promote responsiveness and give the community a stronger voice. The network, for example, will be run as a "regulated public utility," with service agreements, campus standards, and a governing board drawn from Penn's schools and units. In other areas, the model encourages ISC and others to put services to the market test, selling them where demand exists.

The model offers a potentially powerful way for Penn to take action at the University level; a few cross-cutting processes will be funded directly and managed across traditional organizational boundaries.

Section 5 contrasts the new approach to Penn's current system. An earlier document, published in Almanac, also describes the new approach in some detail. It can be seen at http://www.upenn.edu/computing/restruct/model.html.

The new approach doesn't claim to do everything. It doesn't ignore history. It's a way of doing business that gives members of the community the chance to make Penn better and exposes each of us to the costs of bad decisions and the benefits of good ones.

An evolving framework. The new structure was developed in the fall of 1995 by the campus-wide Task Force to Restructure Computing Services at Penn (Appendix A) and vetted across the University. An Implementation Steering Group (Appendix B) carries on the work of the task force. It developed the funding strategies reported here, with the help of seven pilot projects (Section 7) that are testing aspects of the new structure. The funding strategies will continue to evolve with lessons from the pilots and consultation with the community.

2. Why a new model?

Penn exists in a world fueled by information. The vitality of research and instruction have come to depend in large part on information technology. Penn's computing facilities are a competitive factor in recruiting faculty, and increasingly in recruiting students. Penn's ability to save money in administrative areas for reinvestment in the academic mission likewise depends on computing. The network, to take an example that applies to all these cases, is Penn's link to an interconnected world and key to the success of other investments across the University.

Penn's structures for computing support can be improved. Some things are needlessly complicated. People don't always know where to go for help. Gaps in service are frustrating. It's hard to tell what things cost. Changing these things won't be easy--demand will continue to soar, technology changes relentlessly, and Penn is a very complex place. But we have accepted the challenge to make computing work better at Penn.

Each of Penn's twelve schools supports the computing needs of its faculty and students in different ways--and the principle of Responsibility Center Management requires us to expect the schools to pay their own way. Some, but not all, of Penn's administrative divisions have their own computing staffs. Over time the central computing group has come to provide a catchbasin of services ranging from infrastructure to frontline user support. Central/peripheral tensions are played out at several levels, from ISC and the schools to the schools and their departments. The Library is caught in the middle. And everywhere people need more and better support. In short, we have had Responsibility Center Management in principle, but a messy situation in practice.

3. Effect on costs

Computing is an area of growth and leverage at Penn, one that helps the University save money elsewhere. Penn's campaign to restructure all core administrative activities over the next few years, for example--and apply the savings to the academic mission--is largely predicated on the capabilities of modern information systems.

From a financial perspective, Penn's new structure for computing has three aims: targeted investment, cost-effectiveness, and greater control for schools and units. The model promotes a more rational division of labor--and makes both ISC and the schools more accountable. Overall costs in this expanding area will not decline, but the new structure should help Penn spend its computing dollars in the right places and help Penn get more for each dollar it spends. Money saved in some areas of computing can be reinvested in others.

The new structure does not bring a reduction in the allocated costs that schools pay ISC, but it brings savings for reinvestment in campus initiatives. ISC will post savings as it stops providing general frontline support (except on a contract or other special basis), as it retires debt service on the original network infrastructure and mainframe, and as it consolidates activities and streamlines practices. These savings can be returned to the Provost's budget for investment in strategic computing initiatives across Penn.

The new model clarifies and delimits the services ISC will provide under allocated costs, as later sections will show. And it gives the Penn community a stronger voice. The network, for example, will be run as a regulated public utility, with service agreements, campus standards, and a "public utility commission," or campus governing board. Made up of school computing directors, faculty, and other customers, the board will set priorities, approve rates and service levels, and help make decisions about technology direction.

The chart below outlines ISC's current allocated-cost budget, with expected trends. The model neither proposes nor assumes changes in the formulas for calculating allocated costs.


Expected trends in ISC's allocated-cost budget under new model

Current
ISC Service
Current Allocated- Cost Budget Expected Trend
Core admin. systems
and data
$8,200,000

(62% of allocated- cost budget)
Penn will invest heavily in new systems. Allocated costs for new systems are expected to be budgeted largely through the central business units whose functions are at stake (as with FinMIS). Funds would flow to ISC on a direct-charge basis, increasing the accountability of both ISC and the central unit.

ISC's allocated-cost budget would continue to be devoted largely to Penn's installed base of systems.
Networking $2,100,000

(16%)
topic
of study
Designing a fair and strategic funding model for the network will be a first task of the soon-to-be-launched network "public utility commission" or campus governing board.
Standards,
emerging
technology
$400,000

(3%)
ISC will devote more effort here, reallocating from other areas.
Services
for local
providers
of computing
$1,000,000

(7.5%)
ISC will devote more effort here, reallocating from other areas.
Frontline
support
to end-users
in schools
and units
$680,000

(5%)
ISC will no longer provide general frontline support to the Penn community except on a contract or other special basis.
ISC-wide
admin,
planning
$890,000

(6.5%)
ISC will seek efficiencies in this and other areas.

The model puts services to the market test where possible. It encourages ISC (or entrepreneurial schools or units) to sell services where markets exist. The intent is to establish, over time, enough of a marketplace to help control costs and create a focus on the customer. Two services, for example, that ISC will offer on a contract basis are frontline support-on-site and facilities management of computer systems. Appendix E contains guidelines for small businesses such as these, which the task force has been calling "service bureaus."

Schools and units will have greater choice and control in other areas as well. They take on full responsibility for the frontline support of their members. This is good for their members, who get help from people who know their needs and histories. And it's the fairest place in the institution to make tradeoffs between service and cost; local providers can do a good job of telling users what things really cost and helping them make responsible decisions. It also ends current incentives to perceive allocated-cost support as unlimited. (Schools can provide frontline support themselves or buy it from another unit. Several schools and the President's and Provost's offices, for example, already buy support-on-site from ISC. Many departments buy support-on-site from their school's central computing group.)

The model's new cross-University "process teams" offer a way for individual units to contribute a little and get back a lot. Process teams are an invitation to confederation at its best. The model encourages confederation in more everyday ways as well. In one approach to services targeted to local providers of computing, for example, the model builds on one of Penn's great strengths, a flourishing informal network of campus experts who help each other solve problems and work together on campus projects. From ISC, the model calls for more explicit and sustained coordination of these confederated efforts. And from all participants, the model calls for more explicit definition of roles and responsibilities.

The new model promotes incentives (financial where possible) for standards that contain support costs and help people work together. Such efficiencies, in a climate of exploding demand, can help contain the growth in computing costs at Penn.

All in all, the new structure tries to unite responsibility and authority where they've grown apart, to reveal real costs where they've become obscured, and to return choice to purchasers where it has been eroded.

4. The "social contract": Assumptions and principles

The flow of funds makes concrete the relations between people and organizations. Those relationships can be thought of as a "social contract." The terms of the social contract inherent in the new structure for computing are set forth below, followed by principles and guidelines for the funding of services within the contract. Applying the principles and operating guidelines to a collection of pilot cases has yielded the funding strategies described in this document.

Assumptions. The funding framework, like the entire model, rests on two assumptions about computing. First, computing isn't something that happens "somewhere else." It's inseparable from Penn's mission and touches every member of the University community. Second, funding for computing is everyone's business. The computing infrastructure is part of the campus infrastructure and should be factored into budgetary and fundraising strategies. The model affirms Penn's structure of Responsibility Center Management and tries to unite responsibility and authority where they have drifted apart.

Terms of the contract. Each party has a role in making Penn's new structure for computing work:
  • Providers will offer services at agreed-upon levels and make sure users know what support is available and how best to use it.

  • Users of services will fund those services at agreed-upon levels, through direct charge, allocated cost, or other arrangements.

  • Users and providers will use shared principles, such as those below, to decide when and how to fund computing services. Each decision will strengthen or weaken the social contract.

Funding principles. The framework is guided by five funding principles.

Link choice and responsibility.

Schools and units should be able to make choices about how to meet their own computing needs. With this choice comes responsibility for the consequences on finances, customer satisfaction, productivity, and learning--and for the effect on others in the Penn community.
Reserve central funds for the benefit of the enterprise as a whole.
The new computing structure draws on allocated costs (taxes) for services that are strategic to the institution as a whole, that sustain the infrastructure and standards that make Penn a single enterprise, or that offer clear economies of scale.
Put services to the market test where it makes sense.
The computing framework calls for direct charges where markets exist for custom or specialized services or where the institution has an interest in exposing services to the discipline of the market.
Fund processes directly.
To overcome barriers and boundaries, fund where possible the process or activity itself, not the traditional organizational unit.
Seek leverage.
Take advantage of existing resources and larger campus initiatives. Add value by funding targeted expertise. Apply seed money and matching funds.
Operating guidelines. Funding guidelines also inform the framework:

  • Make costs visible. Identify tradeoffs.
  • Clarify expectations.
  • Take life-cycle costs into account.
  • Encourage standards.
  • Recognize economies of scale.
  • Keep it simple.

5. From old to new--An overview

Four charts below contrast the new framework to Penn's current system. The first chart describes frontline support. The next two charts outline secondary support. A fourth chart describes cross-University process teams that focus action at the University level. This section is an overview, with details and open issues in a series of appendices.


FRONTLINE SUPPORT
The new model's great strength is frontline support close to the people who use computing. Penn's schools and administrative units are responsible for the frontline support of their own members, including support of the desktop computer (and its relation to the network) and projects and innovations that make the user's work easier. Schools and units can supply frontline support themselves or buy it from each other, from ISC, or from outside Penn.

Appendix C frames choices and responsibilities. Appendix D documents three building blocks for budgeting--support ratios, salaries for different kinds of computing staff, and costs of equipping a staff member.

  Current system New framework
  How delivered Who pays Why change? How delivered Who pays What's the benefit?
Frontline support of faculty, grad students, and staff Schools, units, ISC all provide.
  • Schools, units fund own efforts.
  • Provost's subvention for ISC's CRC helpdesk.
  • Allocated costs for ISC's First Call hotline.
  • Some schools, units buy support from ISC (on-site staff).
  • Some depts. buy from schools.
  • Demand will continue to explode; old structures can't scale up.
  • Blurred boundaries, gaps & overlaps between schools and ISC.
  • Schools and units provide own support or buy it from ISC, each other, or outside Penn.

    By July of 1997 ISC will stop providing general frontline support except on a contract or other special basis.

    Schools, units fund.
  • Customers get help from local people who know their needs.
  • Schools and units have more control.
  • Accountability is clearer.
  • Local level is fairest place to make cost/service tradeoffs.
  • Ends incentive to perceive allocated-cost support as unlimited.
  • Frontline support of under-
    graduates
  • Most undergrads are not directly supported by schools. Undergrads get help, inconsistently, from computer labs and a few courses and special projects.
  • Many use ISC's CRC help desk and First Call hotline.
  • Schools, residences, and Library fund own labs.
  • Provost's subvention for CRC helpdesk.
  • Allocated costs for First Call hotline.
  • Big gaps in undergrad support. Schools, VPUL band together to explore support in residence. (A few computing professionals augment work/study students, Grad Fellows, and Faculty Masters already in place.) Appendix F details the proposal.
  • Funds currently expended by VPUL leveraged with modest additional investment of professional staff supported by allocated cost or subvention: close consultation with Council of Undergraduate Deans to determine level of appropriate support and funding.
  • Schools, residences, and Library fund own labs.
  • Closes major gap in service at minimal cost.
  • Residences more attractive to students.
  • Secondary support complements and enables frontline support. The next chart describes secondary support provided by schools and units. The chart after that focuses on secondary support provided by the central computing group.
    SECONDARY SUPPORT (SCHOOLS & UNITS)
    Schools and units provide secondary support within their own domains--ranging from multimedia prep centers, statistical services, and online slide collections to local administrative systems.

    Computing at Penn is extremely decentralized, reflecting Penn's budget philosophy of Responsibility Center Management. Schools, departments, libraries, and other units provide most instructional, research, and workgroup computing as well as substantial administrative computing. These services, systems, and innovations vary enormously across the schools and units. While Penn seeks synergies and leverage, local secondary support is ultimately the province of the schools and units. It was not a focus of the restructuring task force and is not treated in any detail in this document.

      Current system
      How delivered Who pays What's the benefit?
    Local innovations,
    systems &
    services,
    both academic
    and admin-
    istrative
    Schools, units provide. Schools, units fund.
  • Fosters creative atmosphere that accommodates diverse needs.
  • Locates services close to users.
  • Schools and units in the best position to make cost/benefit tradeoffs.
  • The third chart, below, outlines secondary support provided by the central computing group, Information Systems and Computing.
    SECONDARY SUPPORT (CENTRAL COMPUTING GROUP)
    The central computing group, in contrast, provides secondary services that support the enterprise as a whole. The new model calls for a more focused set of secondary services from ISC: core administrative systems, data administration and information security, networking, standards and architecture, and other targeted services for local providers of computing.
      Current system New framework
      How delivered Who pays Why change? How delivered Who pays What's the benefit?
    Core
    admin-
    istrative
    systems
  • ISC implements in partnership with central business units; service agreements in place.
  • Increasing use of "process reengineering," in which business practices are streamlined to take advantage of technology.
  • Allocated costs budgeted through ISC. Increasingly, allocated costs for new systems are budgeted instead through the central business units whose functions are at stake (as with FinMIS). Build on current approach
  • ISC implements in partnership with central business units; service agreements in place.
  • Fuller use of "process reengineering."
  • For new systems, allocated costs budgeted largely through the central business units whose functions are at stake (as with FinMIS). Money flows to ISC on a direct-charge basis.
  • ISC's allocated-cost budget devoted largely to Penn's installed base of systems.
  • Modern info. systems key to Penn's massive campaign to restructure all core administrative practices and apply the savings to the academic mission.
  • Central business units & ISC both more accountable.
  • Network
  • ISC provides infrastructure and central services.
  • ISC installs and maintains most local wiring and electronics; a few schools handle their own.
  • Infrastructure and central services a mix of allocated and direct charges.
  • Local installation and maintenance direct charge. A few schools fund their own.
  • Room rents, student fees cover ResNet.
  • Penn wants a bullet-proof network.
  • Current chargeback structure undermines standards.
  • Run the network as a regulated public utility, with campus standards, service agreements, and a "public utility commission," or campus governing board.
  • A first task of the governing board will be to develop a fair and strategic funding model for the network.
  • Board will approve rates and service levels.
  • In a wired world, success of Penn's other investments rests on the reliability and capacity of the network.
  • Strong community voice in service levels and rates.
  • Fairer new chargeback structure will encourage standards.
  • Standards
    and emerging
    technology
  • Most standards set by collaborative task forces.
  • Few incentives for campus compliance.
  • Task forces: contribution in kind from schools & units; allocated costs to ISC. Penn spends more than it needs to, has trouble working across organizational boundaries.
  • Greater ISC effort in this area.
  • Build on participatory task forces, which have proven themselves in Penn's environment and are admired by our peers. More explicit ISC project management. Extend the approach to tracking and piloting emerging technologies.
  • Additional incentives for campus compliance with standards.
  • Task forces: contribution in kind from schools & units; allocated costs to ISC.
  • Central matching funds are particularly attractive incentives for compliance. Appendix G describes a new program that helps Penn's public computer labs replace their desktop computers at least every four years.
  • More widely observed standards to contain costs and help people work together.
  • Strong community voice in setting standards.
  • Services
    for local
    providers
    of
    computing


    Eg, vendor relations, bringing outside training to campus, interest groups
  • School, unit experts help each other.
  • ISC provides some services, coordinates others.
  • Contribution in kind from informal network of experts.
  • Allocated costs to ISC.
  • As local providers take on full responsibility for frontline support of their members, they themselves need more support. Greater ISC effort in this area. Four approaches:
  • Campus experts help each other; more explicit ISC coordination and project mgmt. (eg, for services like escalation of questions).
  • Formal teams; some "nomadic" ones solve specific problems and disband (eg, projects like gearing up for Windows 95).
  • ISC as provider (eg, services like tech support of problem- tracking software).
  • Units sell services where markets exist (eg, services like media conversion).
  • Contribution in kind from campus experts.
  • Allocated costs to ISC.
  • Direct charges where markets exist.
  • Give teams their own budget line where possible.

    Pilot team working to reconceive ISC's portfolio of services for local providers is looking for right mix of approaches from those described in Appendix H.

  • Depth and interconnections for Penn's distributed system of local support.
  • More problems solved locally or eliminated in the first place.
  • Second-tier support for standard products encourages units to adopt standards.
  • In practice, of course, the above distinction of "frontline" and "secondary" support is not a dichotomy, but a continuum of services appropriately sited. For example, an individual laboratory might support its own local area network (LAN), the academic department that sponsors the laboratory might handle LAN upgrades, a set of departments might share a LAN expert, and the central computing group might make available a network engineer. In our model, the frontline support person--not the user--navigates these complexities.

    The fourth chart, below, describes a new force in the overall structure, cross-University process teams.


    CROSS-UNIVERSITY PROCESS TEAMS
    A potentially powerful innovation is the direct funding of processes. The restructuring task force referred to this as funding the "verb," or activity, rather than the "noun," or traditional organizational unit. Penn will concentrate at first on a few high priority processes such as academic innovation and student services. Computing is one aspect of these larger activities.

    Several pilots are exploring the process perspective. The "New Learning Spaces" pilot, for example, draws together people from across campus to conceive and develop new kinds of classrooms and join them with public computer labs and libraries in a more coherent whole.

    Process teams will vary in their mission, and funding will come from many sources. The Steering Group has developed guidelines for evaluating candidate processes. These guidelines ask about the importance of the initiative and evidence of commitment to it. Process close-out is a key criterion; process teams should disband in the absence of a specific decision to continue.

      Current system New framework
      How delivered Who pays Why change? How delivered Who pays What's the benefit?
    Process teams Cross-unit teams exist, but are often weak. Cross-unit teams funded through organizational units. Hard to get things done at the University level. Projects falter at organizational boundaries. Stronger cross-University teams. Process "owners" manage the activity across unit boundaries.
  • Process teams funded directly.
  • Many sources, including central seed funds; outside partners attracted to the more visible of the process teams; and participants that bring people, dollars, and facilities to the table.
  • Offers a way to make "institutional bets" with high potential payoff for the University as a whole.

    6. Next steps

    Transition to Penn's new computing structure is well underway. Seven pilots, described in the next section, are testing the new model and creating reality on the ground. Progress, in brief:
    • "Service bureaus," or small businesses, already exist at Penn; two pilots focused on frontline support-for-hire and facilities management-for-hire are investigating the market, writing formal business plans, and seeking business opportunities.
    • The pilot to support undergraduates in residence has proven successful in Van Pelt College House and is exploring ways to scale up to all first-year and college houses by Sept. of 1997.
    • As a first step toward running the network as a regulated utility, a proto "public utility commission" is rationalizing the PennNet central services fee, which covers network infrastructure.
    • ISC is in the midst of a major internal restructuring that includes increased attention to services for local providers of computing, increased attention to standards and emerging technology, selling services where it makes sense, transitioning away from general frontline support except on a contract basis, laying operational groundwork for running the network as a public utility, and serving as catalyst for process teams.
    • Penn is putting in place infrastructure to link participating help desks across campus. With this software, called "Apriori," dispersed help desks can share problems and solutions.
    • Residential Living, the Library, and four schools have each replaced at least a quarter of their public lab machines, taking advantage of the matching-fund program launched in June of 1996.
    • Process teams are becoming a new way of doing things at Penn; the Provost and others welcome the funding guidelines proposed here.
    The Steering Group is consulting broadly to see if the funding model presented here is workable at Penn. Visits to Deans, for example, and to Penn's senior advisory groups are underway. Pilot teams and the Steering Group continue to work out the implications of the new framework. Benchmarking (begun in the fall of 1995 and now an ongoing, though less intense, program) is a key source of ideas and contacts.


    7. Pilot projects--nutshell descriptions

    Seven pilots are testing aspects of Penn's new model for computing services. The Implementation Steering Group (Appendix B) guides and integrates the pilots.

    1. New kinds of learning spaces (process team): Begin creating at Penn a range of technology-based "learning spaces" such as classroom/lab hybrids. Build on the success of the Provost's Classroom Committee; seek outside funds.

    Team leaders:
    James O'Donnell (ISC/Arts & Sciences)
    John Smolen (University Life)
    Donna Milici (ISC)

    2. Support-in-residence for students (process team; frontline support): Pilot the viability of moving to residence-based frontline computing support for undergraduates; lay groundwork for transition. Begin with one or two residential units and closely coordinate with broader efforts to restructure student services across the University.
    Team leaders:
    Al Filreis (Arts & Sciences)
    Larry Moneta (University Life)

    3. Network as a public utility (service-level agreements; public utility commission): As a first step toward running Penn's network as a regulated public utility, rationalize the "central services fee," which covers network infrastructure. Determine the appropriate services, service levels, and fee and explore more strategic approaches to billing. Establish a pilot "public utility commission," or governing board, to make these decisions in consultation with the Penn community.
    Team leaders:
    Ira Winston (Arts & Sciences/Engineering)
    Gerry McCartney (Wharton)
    Mike Palladino (ISC)

    4. Link help desks across campus (process team; frontline support): Link help desks across campus by sharing software that tracks problems and solutions. Set common standards and practices for using the software. Arts and Sciences and ISC will initially deploy the software; The Library and the Engineering and Medical Schools will help shape the implementation.
    Team leaders:
    Katie McGee (Arts & Sciences)
    Mike Kearney (ISC)

    5. Frontline support-for-hire (service bureau; frontline support): Review and adapt for broader implementation ISC's distributed staffing program, in which local units contract with ISC to locate computing support staff on-site. Explore market needs and develop a formal business plan.
    Team leaders:
    Mike Provost (Veterinary Medicine)
    Don Montabana (ISC)

    6. Services for local providers of computing (secondary services): Begin putting in place a coherent and effective set of services directed to local providers of computing. Determine organizational structures to deliver those services. Define performance measures, service-level agreements, and formal ways to get customer feedback.
    Team leaders:
    Mark Aseltine (Fine Arts)
    Mike Kearney (ISC)

    7. Facilities management-for-hire (service bureau): Improve, expand, and formalize ISC's program of facilities management, in which ISC provides technical and operational support for computer systems that belong to clients. Treat the recent contract with the School of Dental Medicine as a pilot to learn more about running this service as a business.
    Team leader:
    James Galbally (Dental Medicine)

    8. Challenges

    The restructuring of computing at Penn has not provided naive solutions to complex problems nor has it wished them away. It has created instead a framework in which rights and responsibilities can be negotiated rationally, openly, and fairly.

    For consumers of computing services, the new model's great strength is frontline support at the local level. Frontline support close to users of computing also exemplifies the challenges that face the model. It will take hard work to make help easy for users. And frontline support implies secondary services that can be drawn on by local providers when needed. The level of those secondary services will, in part, determine the resources required to provide frontline support. Tensions will result. Units that apply greater than average resources will feel they are paying through allocated costs for central services they don't need. Those that dedicate fewer resources will find that ISC is no longer a provider of last resort and users may suffer.

    Success depends especially on two aspects of Penn's social contract for computing. The first is the ready acceptance of responsibility by individual units for providing or purchasing frontline support for their members. The second is the close coordination of services across the University so that secondary support from the central group meshes well with support provided by schools and units and represents a reasonable allocated cost to Penn.

    Creating a workable structure will not be easy. By establishing the terms of a social contract for computing, however, Penn has begun to put the hardest task behind it. It will now be possible to negotiate funding with a new clarity and devote our energies to designing the most responsive--and responsible--support structure for the people who use it.


    Appendix A: Task Force to Restructure Computing Services across Penn

    In the fall of 1995, Penn's Provost and Executive Vice President appointed a University-wide task force to make computing easier and more cost-effective for those who use it. Our charge was to design a new structure for organizing, staffing, and funding computing services across Penn.

    Sponsors: Stanley Chodorow (Provost)
    John Fry (Executive Vice President)

    Chairs: Peter C. Patton (ISC)
    James O'Donnell (ISC/Arts & Sciences)

    Project Mgr: Linda May (ISC)

    Task force: Noam Arzt (ISC)
    Carl Abramson (ISC)
    Noam Arzt (ISC)
    Mark Aseltine (Fine Arts)
    Robin Beck (ISC)
    Eric Clemons (Wharton)
    Wilson Dillaway (Library)
    Mike Eleey (ISC)
    Al Filreis (Arts & Sciences)
    Jim Galbally (Dental)
    Ben Goldstein (Arts & Sciences)
    Janet Gordon (EVP)
    Pat Harker (Engineering)
    Bob Hollebeek (Arts & Sciences)
    Liz Kelly (Law)
    Michael Klein (Arts & Sciences)
    Mark Liberman (Arts & Sciences)
    Linda May (ISC)
    Donna Milici (ISC)
    Steve Murray (EVP)
    Gerry McCartney (Wharton)
    Katie McGee (Arts & Sciences)
    Bob Pallone (Development)
    Warren Seider (Engineering)
    Susan Shaman (Provost's Office)
    Al Shar (Medicine)
    John Smolen (University Life)
    Lyle Ungar (Engineering)
    Dan Updegrove (ISC)
    Frank Warner (Arts & Sciences)
    Ira Winston (Engineering)

    Models
    Workgroup:

    Mike Eleey (ISC), captain
    Gerry McCartney (Wharton), captain
    Noam Arzt (ISC)
    Wilson Dillaway (Library)
    Jim Galbally (Dental)
    Bonnie Gibson (ISC)
    Liz Kelly (Law)
    Mark Liberman (Arts & Sciences)
    George McKenna (ISC)
    Bob Pallone (Development)
    Al Shar (Medicine)

    Communication
    Workgroup:

    Al Filreis (Arts & Sciences), captain
    Katie McGee (Arts & Sciences), captain
    Ira Winston (Engineering), captain
    Helen Anderson (Engineering)
    Mark Aseltine (Fine Arts)
    Kristine Briggs (EVP)
    Randall Couch (ISC)
    Edda Katz (ISC)
    Teresa Leo (ISC)
    Jill Maser (EVP)
    Don Montabana (ISC)

    Benchmarking
    Workgroup:

    Donna Milici (ISC), captain
    Ben Goldstein (Arts & Sciences), captain
    Pat Adams (ISC)
    Chris Cieri (Law)
    Mike Guilfoyle (ISC)
    Joe Harris (ISC)
    Mike Palladino (ISC)
    Nancy Rauch (ISC)
    Susan Shaman (Provost's Office)
    Debbie Sokalczuk (Arts & Sciences)
    John Yates (Arts & Sciences)

    Center for
    Applied
    Research:

    Lynn Oppenheim
    Mario Moussa


    Appendix B: Implementation Steering Group

    In the spring of 1996, Penn's Provost and Executive Vice President named an Implementation Steering Group to guide pilot testing of Penn's new model for organizing, staffing and funding computing services across the University.

    Sponsors: Stanley Chodorow (Provost)
    John Fry (Executive Vice President)

    Chair: James O'Donnell (ISC/Arts & Sciences)

    Project Mgr: Linda May (ISC)

    Members: Noam Arzt (ISC)
    Robin Beck (ISC)
    Wilson Dillaway (Library)
    Mike Eleey (ISC)
    Al Filreis (Arts & Sciences)
    James Galbally (Dental Medicine)
    Bonnie Gibson (Provost's Office)
    Elizabeth Kelly (Law)
    Mark Liberman (Arts & Sciences)
    Gerry McCartney (Wharton)
    Susan Shaman (Provost's Office)
    Barry Stupine (Veterinary Medicine)
    Al Shar (Medicine)
    Ira Winston (Arts & Sciences/Engineering)
    Ira Schwartz, "of counsel" (Social Work)

    Funding
    Workgroup:

    Bonnie Gibson, chair (Provost's Office)
    Fran Seidita (Budget Office)
    James Galbally (Dental Medicine)
    Patrick Burke (Engineering)
    Carolynne Martin (University Life)

    Benchmarking
    Workgroup:

    Donna Milici, chair (ISC)
    Mike Palladino (ISC)
    Mike Guilfoyle (ISC)
    John Yates (Arts & Sciencess)
    Pat Adams (ISC)
    Nancy Rauch (ISC)

    Center for
    Applied
    Research:

    Lynn Oppenheim
    Mario Moussa


    Appendix C: Frontline support: Choices and responsibilities

    This appendix organizes information published earlier or found elsewhere in the document. The appendix is for the convenience of deans and others who wish to understand their choices and responsibilities for frontline support within the new model.

    Local computing "home." The computer user--faculty, student, or staff--is at the center of Penn's new model for computing services. Each user has a local computing "home" and takes all computing questions there. All frontline computing support takes place at the local level, as close to the user as possible. (This includes first-line support of the desktop computer and its relationship to the network, of mainstream productivity software, and of specialized software commonly used by that group.) Beyond this circle of frontline support are expanding circles of secondary support, at both the local and central levels. But the map of services is irrelevant to recipients; the frontline support person navigates that landscape for them.

    For faculty and students, the local computing "home" is designated and supported by their school. For staff, this home is designated and supported by the school or administrative division in which they work.

    Different homes have different resources. Level and type of resources are decided by the school or unit with which the user is affiliated. (Schools or units that delegate budget responsibilities to departments may, of course, delegate decisions about computing services as well.) At the same time, the task force urges that guidelines for basic frontline support levels be set and that Penn institutionalize ways to keep these levels moving up.

    Funding. Schools and administrative units are responsible for funding frontline support for their communities. As with other budgeting decisions, Deans, department heads, or unit managers can decide how to trade off computing against other needs. To help evaluate options, Appendix D documents three "building blocks" of funding: support ratios, median salaries for different kinds of computing staff, and costs of equipping a staff member.

    Staffing. Schools or units can provide frontline support themselves, buy it elsewhere, or join with others to provide it more efficiently. A unit can buy on-site support from ISC, for example; Appendix E describes small businesses such as this one at Penn. And the residential pilot (Appendix F), for example, is testing what may be a more efficient way to deliver frontline support to undergraduates.

    Training. Schools or units may choose to train their frontline providers and end-users to different levels of competence, and they may choose to provide this training themselves or buy it inside or outside the University.

    Secondary support. Secondary services, as described in Section 5, complement and back up frontline support. Many secondary services are provided by the school or administrative division. The central computing group concentrates on core administrative systems, data administration and security, network infrastructure, standards, site licensing, and services targeted specifically to providers of frontline computing support. For the computer user, the frontline support provider is the link to these services.

    In practice, the distinction of frontline and secondary support is not a dichotomy, but a continuum of services appropriately sited. For example, an individual laboratory might support its own local area network (LAN), the academic department that sponsors the laboratory might handle LAN upgrades, a set of departments might share a LAN expert, and the central computing group might make available a network engineer. In our model, the frontline support person--not the user--navigates these complexities.

    Principles. Because frontline support is key to our model, we have described the ideal, our target, in some detail below.

    Frontline support is accessible.

    The computer user knows the frontline support provider and has easy access. Frontline providers are physically located with their clients if possible. If clients are remote or scattered, the frontline provider is accessible by email, telephone, or pager.

    Frontline support owns its problems.

    Frontline providers "own" the problems encountered by their users (for supported products and within the support limits set by the unit). A working principle is that a provider never says, "I can't help you, " but says instead, "I'll find the answer or find someone who can."

    Problems are documented and structured.

    The frontline provider works with users to structure their problems. This helps the provider understand the problem, and allows problems referred elsewhere to move more effectively through the support system.

    Frontline providers have content knowledge.

    Frontline providers know the operating systems of their users' desktop computers and how to link the desktop systems to the network. They know mainstream productivity software, as well as the specialized software commonly used by their clients. (Special arrangements might be needed to support clients who are more technically sophisticated than their frontline provider.)

    The client base is well defined.

    Frontline providers are not only empowered, but required, to tell those who fall outside their client base to go elsewhere for support. To the extent possible, providers know where to direct those people.

    Campus units that choose not to provide frontline support to their members should expect to pay a premium for their members' access to second- and third-tier support elsewhere in the institution. This is fair because the unsupported user is likely to bring small problems to expensive places and may not have exhausted cheaper remedies.

    Problem escalation and referrals are handled smoothly.

    Clients have paths to management when their problems are not well handled. Clients are, directed, however, back to the frontline provider if they attempt to work around their immediate support structure and access second- or third-tier support without prior arrangement.

    Mechanisms are in place to refer problems that a frontline provider alone cannot solve. Sources of second- and third-tier support are clear, and means of access are well defined.

    Frontline providers share information with each other.

    Frontline providers know the activities and problems of their clients--and often learn of things outside their own domain. Both kinds of information are systematically shared across the broader support system.


    Appendix D: Building blocks for budgeting

    In keeping with the model's emphasis on local control, three "building blocks" for budgeting are documented here: support ratios, salaries for different kinds of computing staff, and costs of equipping a staff member. Penn's schools and units can combine these building blocks in ways that make sense for the unit.

    Building block: Support ratios. What is the appropriate number of end users per support staffer? The Gartner Group, a technology consulting firm, recommends 75/1. Penn, however, might be able to get by with a general ratio of more users per staff member, since student support can help reduce the need for professionals. Faculty, with their specialized research and teaching needs, will need more support than administrators, who will need more support than students.

    Building block: Staff salaries. The table below lists mid-point salaries for different types of computing staff at Penn. These figures can be used to help estimate the costs of support.


    Median salaries for computing staff at Penn (FY'97)

    Title Job Grade Median
    Salary
    for Grade
    Median
    Salary &
    Benefits
    for Grade
    Work-Study Student @35%
    Work-Study Supplement
      $2.22/hr.
    $2-6/hr.
    $2.22/hr.
    $2-6/hr.
    Part-Time Student  $6-12/hr. $6-12/hr.
    Drexel Co-op  $9-13/hr. $10-14/hr.
    Office Systems Asst. G10 $25,713 $33,710
    Office Systems Coordinator G11 $27,866 $36,530
    Office Systems Administrator P02 $29,098 $38,150
    Information Systems Specialist P03 $31,982 $41,930
    Office Systems Administrator II " " "
    Help Desk Analyst P04 $35,123 $46,050
    Info. Mgmt. Specialist I " " "
    Info Systems Specialist II P05 $38,677 $50,700
    Info Management Specialist II P06 $42,591 $55,840
    Senior Help Desk Analyst " " "
    Help Desk Coordinator " " "
    Computer Technology Spec. II " " "
    Info. Systems Specialist III P07 $46,814 $61,375
    LAN Specialist " " "
    Computer Technology Spec. III " " "
    Info Systems Specialist IV P08 $52,015 $68,200
    Managers/directors P09 $57,217 $75,000

    Building block: Equipping a staff member. The table below estimates the annual cost of equipping a staff member.


    Equipping a staff member

    Type of expense Annual $Source
    Computer (3-year amortization) $1,000 Mac or $833 Windows Campus standard
    Software $700 Current supported packages (estimated)
    Ethernet connection
    (10-base T)
    $267
    One conference or training course/year $1,800- $3,000 Local courses could reduce costs
    Telephone, supplies, space varies by setup and location.


    Appendix E: Selling services where markets exist

    Penn's new model encourages selling services where markets exist. The task force has been calling these small businesses "service bureaus." Service bureaus can help defray the cost of a unit's strategic investments, make special expertise more widely available, and expose services to the discipline of the market. Service bureaus are already found at Penn; Wharton Reprographics, ISC's contract support-on-site, and ISC's contract facilities management are three examples.

    PROVIDERS AND CUSTOMERS

    Providers. Any school or unit may set up a service bureau in Penn's evolving economy. The most likely providers are units that make large capital investments that produce excess capacity. For example, a school might buy expensive multimedia equipment to meet its teaching needs and then hire out related expertise and support to other units.

    Customers. Customers will range from schools and units to workgroups and individual faculty members. The ability to pay for services will depend on unit operating budgets, individual grants, and any available special funds. Explicit contracts--service-level agreements--are key to clarifying customers' expectations for service and support.

    The voice of the customer. From the customer's point of view, service bureaus are worth using only if they are better, cheaper, or easier than the alternatives. A service bureau will know it is successful if customers show up and continue to show up. An open question is how much time and marketing to give a start-up service bureau before deciding to pull the plug. Successful service bureaus will put effort into market research to anticipate needs and trends.

    PRICING

    Full cost. Pricing is a business and policy decision that service bureaus will face. Service bureaus might opt to charge fully burdened costs that recover management, marketing, billing, and other overhead expenses, including future-oriented costs such as investments in new technology. Unlike a free-standing business, they would add no profit margin to the cost.

    Subsidized cost. Depending on market demand and other constraints, service bureaus might choose to recover through direct charges less than the full cost of doing business. A school might charge below full cost, for example, to get customers that defray the cost of an underused capital asset. Or ISC might charge customers only marginal costs where Penn has an interest in encouraging the use of a service; this partially subsidizes the operation through allocated funds. (With ISC's contract support-on-site, for example, Penn's interest lies in offering schools alternatives to ramping up their own computing support staffs.) The Steering Group notes, however, that such subsidies should not be used as a way of transferring funds from one school to another--that is, they may be applied only to services of general interest and use--not to services with narrow appeal.

    LIMITS AND CONSTRAINTS

    Legal guidelines. Service bureaus ("service centers" in Penn's chart of accounts) are subject to Federal A-21 guidelines for reporting time and effort. A very specific justification of all charges must be approved by the Federal compliance unit of the Comptroller's Office. The most informal service bureau (say, a department selling expertise on the margin) might operate outside these guidelines. Formal service bureaus with many customers and with both direct and indirect costs, on the other hand, will need to meet the Federal guidelines--particularly if Federal grants are to be charged.

    Problems of scale. Like any small business, service bureaus that succeed in growing may run into problems of scale. A particular resource may be the limiting factor. For example, ISC's contract facilities management service could run out of floor space in the machine room. Or a service bureau might be limited by its ability to hire and train additional staff in time to meet demand. Similarly, adding staff may require additional management strength that is either unavailable or too expensive.

    What business are we in? The comparison with small businesses goes only so far. Units are committed to their core mission and are unlikely to invest in ventures in hopes of generating new revenue sources or whole new lines of business. Service bureaus are likely to remain a fairly small part of Penn's overall economy. They are an important Trojan horse, however, exposing the institution to the discipline of the market and the pressure to please the customer.


    Appendix F: Proposal to support students where they live

    The framework seeks innovative ways to deliver computing support as close to the recipient as possible. One pilot, for example, is testing the idea of supporting undergraduates in residence, drawing substantially on students themselves:
    It just makes good intellectual sense at a residential university. It empowers students to help students, and to see themselves formally in the business of teaching and advising in an area where they have largely untapped expertise. It strengthens the self-sufficiency of a collegiate community.
    The proposal is in the early pilot stage, testing the concept at Van Pelt College House. The proposal calls at minimum for students living in residence to get their computing support in residence. (Currently almost all first- and second-year students and a fair number of upperclass students live in the dorms.) As Penn's emerging collegiate system takes shape, support might extend to all undergraduates, through their affiliation with a residential college (the Provost's 21st Century Project).

    With such a moving target, the pilot team is seeking an interim strategy at the same time it takes concrete steps toward a long-term solution.

    Support for students today. Most undergraduates are not directly supported by their schools today. They get help with computing, inconsistently, by virtue of their association with some courses, some special projects, and some computer labs (in the schools, Library, and residences). Many undergraduates use ISC's Computing Resource Center and First Call hotline, which, under Penn's new model, are being transitioned away from general frontline support to the Penn community.

    Leverage. The proposal makes leverage a funding strategy. It makes use of work/study students, graduate fellows, and faculty masters already in the residences. It organizes them to respond to most requests for help and refer a few problems up the line to computing professionals. If the work/study students are "electronic paramedics," the graduate fellows are "nurse practitioners," and the computing professionals are "doctors."

    Most of the staff and most of the funding are already in place. The proposal adds a few computing professionals to the local ecology (an estimated four FTE professionals to serve an eventual eight collegiate clusters). Funding for the professional staff will be at a level set in consultation with the Council of Undergraduate Deans and provided by allocated cost or subvention (TBD).

    Links to larger efforts. The pilot is linked to larger efforts such as the current restructuring of student services across Penn; many kinds of services (counseling, academic advising, etc.) are likely to be delivered in residence. It also builds on the evolving residential college system of the Provost's 21st Century Project. In some ways, the pilot is shaping both those efforts, with computing as the perfect "late night" activity to help people think concretely about the benefits and possibilities of delivering services in residence.

    Details. Details of the pilot can be found in its Web site (http://dept.english.upenn.edu/Rescomp/). Schools such as Stanford and Northwestern have active programs of support in residence.


    Appendix G: Technology refreshment of public labs:
    A matching-grant program

    Standards help Penn save money and make it easier for people to work together. Financial incentives for standards are often the most effective ones. The matching-fund program described here helps public labs replace their desktop computers on a four-year cycle. The program, designed by the "New Learning Spaces" pilot, was launched in June of 1996.

    Terms. The program offers a 1:2 match ($1 of ISC funds for each $2 of school, Library, or residence hall funds). Labs that accept matching funds agree to:

    • Remain public.
    • Adhere to Penn's desktop hardware standards for new purchases. Commit to a four-year replacement cycle.
    • Help develop annual recommendations for productivity and communications software (eg, ResNet suite) and support of software for large undergraduate initiatives (eg, Maple)--and comply with those recommendations as a minimum standard.
    • Install virus protection software and hardware security.
    • Enforce University policies and federal laws (eg, ethical behavior and copyright).
    • Participate in the Lab Administrator Special Interest Group.
    • Describe how funds were spent in an annual report to ISC.
    The matching component is funded for the next four years. Penn has about 540 public desktop computers. A quarter of them can be replaced each year for an annual investment of about $340,000 ($113,000 of which is ISC's matching portion). Each school or group can expect that a quarter of its public computers will be eligible for matching funds in each of the next four years. If need exceeds the pool, a priority scheme will be developed.

    The current situation. Organizations vary in their current approach. Some groups budget for a two-year replacement cycle, while others have no budget for equipment replacement. ISC has played no role before now in funding for public labs. Commonwealth and vendor equipment grant programs ended several years ago.


    Appendix H: Services for local providers: Strategies for funding

    Services specifically for local providers of computing add strength to the campus-wide system of computing support. These services are aimed at creating infrastructure for support provided locally. The emphasis is on helping solve problems locally, or, better yet, keeping problems from happening in the first place. The services are meant to complement and enable frontline support, not to substitute for it. The services encourage standards; the availability of good second-tier support for campus-standard products should serve as an incentive for units to adopt those standards.

    Clients. The clients of these services are local providers, campus-wide process teams, and other information technology professionals. End users are not generally direct clients.

    Links. The people who provide these services will almost always have other operational duties as well. They are experts because of those other responsibilities. Synergy with campus-wide development of standards is particularly strong.

    Status. As local providers take on full responsibility for frontline support, they themselves will need more support. ISC, in turn, will devote more effort to services for local providers as it moves away from frontline support. A pilot team is working with the Penn community to reconceive ISC's portfolio of services for local providers. The team will inventory existing services, assess client needs and priorities, identify best practices elsewhere, and recommend organizational and funding strategies. Implementation is expected in the spring of 1997.

    A framing typology. The pilot team is looking for the right mix of approaches from among those outlined below.


    Five approaches to services for local providers

    Approach Who pays? Example services
    from current portfolio
    Features
    Campus experts help each other. ISC coordinates or project manages. ("Facilitated confederation")
  • Contribution in kind from campus experts including ISC
  • Allocated funds to ISC for coordination
  • Questions escalated beyond frontline
  • Interest groups (PCNet, MacNet, Super Users, Lab Admin SIG, DMP, etc.)
  • Vendor relations
  • Builds on Penn's flourishing informal network of campus experts. Model calls for more explicit coordination or project management from ISC. From all participants, model calls for more explicit definition of roles and responsibilities.
    Formal campus teams As with other campus-wide process teams, funding comes from many sources: contribution in kind, allocated costs, central seed funds. Preferred strategy is to establish a budget line for the team itself.
  • Handle the "Fall Crush" of getting students connected and ready to use their computers
  • Some teams are ongoing. Other "nomadic" teams solve specific problems and disband.
    ISC as provider Allocated funds to ISC
  • Support for problem- tracking software.
  • Support for network distribution of software
  • As with other uses of tax dollars, the pressure is to focus and delimit these services and to negotiate explicit service levels.
    Entrepreneurial units sell services where markets exist Direct charges
  • Facilities management of computer systems
  • PennBack backup
  • Data & media conversion
  • Appendix E describes small businesses, or "service bureaus," at Penn.
    Mixed strategies One approach: Allocated funds to ISC for doing or coordinating the service. Direct charges for the product itself (eg, site- licensed software).
  • Site licensing
  • User guides for campus-standard products (such as ELM email)
  • Some publications (such as PennNet Passport
  • Bringing training (for local providers) to Penn.
  •  

    Principles. The team is guided by two sets of principles, below.

    Service delivery Funding
  • Support local providers.
  • Map what's there.
  • Link authority and responsibility.
  • Avoid referral and escalation.
  • Keep it simple.
  • Encourage the informal structure.
  • Track usage.
  • Promote standards.
  • Identify tradeoffs.
  • Expertise arises from actions.
  • Communication is critical.
  • Leverage existing resources.
  • Allocated funds for central group that coordinates, but is not sole provider.
  • Fund and staff support for local providers as part of the base process or service.
  • Fund services and teams (not units) where possible.
  • Allocated funds where integrity of University data and systems is at stake, standards are encouraged, or for the good of the whole.
  • Service bureaus where markets exist for custom or specialized.
  • OK to mix allocated and direct charges.

  • restructuring     model     pilot     taskforce     data    
    Please note: This material is no longer current and appears online for archival purposes only.
    Use the search and navigation tools above to locate more up-to-date materials, if they exist.
    top

    Information Systems and Computing
    University of Pennsylvania
    Comments & Questions


    University of Pennsylvania Penn Computing University of Pennsylvania Information Systems & Computing (ISC)
    Information Systems and Computing, University of Pennsylvania