__________

PO Box 9752
Boulder, CO
80301
303.541.0231

Guidelines

Project Phases

Pre-launch
Assessment and Planning
Design and Development
Implementation and Evaluation

Pre-launch

• Determine what you are trying to achieve
  Most institutions have information online about their student services regardless of whether these services are available online or not. The next step for the institution is to decide whether to develop some new or improved online student services or put existing student services online as-is. There is a huge difference. Can you commit to the latter at this point or do you need to take the interim step? Each institution will have to make this fundamental choice based on their mission, campus culture, and resources.

• Secure support from the top leadership
  Without buy-in support from the top leadership — provost or above — you should not proceed. This project will require campus-wide cooperation and possibly changes to the technology infrastructure, campus culture and structure, along with both a short- and long-term financial commitment. It is unrealistic to think that these changes will occur without the support of the top leadership. The more emphatic that support, the faster the progress will be.

• Take the time to do it right!
  In developing new Web-based student services, technology is the easier part. The hard part is identifying the key stakeholders, sponsors, and champions; creating the new vision for campus services; addressing the critical policy, political, turf, and procedural issues that arise; achieving buy-in for the final vision; and securing the funding. Depending on the scope of the project, this can take several months or even years.

  • It is important to resist the pressure to just get existing services up on the Web quickly as-is. In the rush to do so, it is likely that technology will be bolted on to existing practices and inefficiencies and inadequacies will result. Just as this approach often has failed for e-learning on the academic side of the house, it is likely to fail on the e-services side as well.

  • In some cases, the campus culture and structure will be affected. These changes take time and to rush them can be devastating to the project.

• Select the “right” project director
  Developing an array of Web-based student services is a complex and long-term project that requires a project director who is a creative thinker, understands the big picture, and recognizes that “the devil is in the details.” This individual should have the ability to motivate a “volunteer workforce” of student services staff and others who, in most cases, have full time jobs without this extra project. The project director should understand the campus culture and politics and be well respected by both the leadership and those in the trenches. He or she should be a good communicator and able to set and control realistic goals and timelines. It is critical that the project director be given adequate release time to manage the project. It is vital that this project director solicits opinions in advance from students and strives to achieve student-based and student-oriented services.




• Assemble a cross-functional vision team to provide project oversight
  The Web provides a platform for merging a wide range of student services to provide more efficient, customized, and personal services. This new “vision” requires changing the way the institution has traditionally thought and operated. By assembling a cross-functional team with wide representation from the campus community (including students and staff), you set the stage for thinking about student services in a new way. Critical players on this team should include key campus leaders, the registrar, student services staff, marketing, human resources, faculty, and IT representatives – and, lest we forget, students as well. These individuals should be open minded and creative thinkers who can help others see the benefits of change and also identify staff with critical expertise to serve on the more focused design and implementation teams. To see the good composition of the LAAP campus vision teams, go to the partners section.

• Be inclusive
  Good ideas come from many sources. Although the size of the core vision team must be limited for management purposes, mechanisms should be in place to receive input from others. Web-based suggestion boxes, surveys, and focus groups help to ensure that all interested parties have an opportunity to be involved.

• Approach the project in phases
  All projects have their limitations and it is important to set realistic expectations — internally and externally — from the start. By approaching the project in phases (that is, through staged implementation) — assessment and planning; design and development; implementation and evaluation — the project becomes more manageable. It is important to identify well-defined tasks and a proper and achievable timeline for each stage and to publicize your success when appropriate. This will help keep internal participants motivated and others interested in the project.

• Communicate about the project regularly
  It is critical to inform to all constituents of your progress along the way — those on the project teams as well as those in the broader campus community. By providing regular updates in newsletters and presentations to various constituencies, you help prevent misunderstandings and unrealistic expectations that can cause delays or even derail your project. For example, to keep everyone informed of the project’s progress, Regis University established a special Web site.

• Engage an outside expert
  Outside experts bring knowledge about best practices at other institutions and outside organizations along with an objective ear and voice to your project. By scheduling regular visits, they can help you keep your project on track by providing the incentive to accomplish certain tasks in advance of visits. In some cases, staff may be more comfortable expressing their concerns to an outsider who can ensure privacy while relaying the critical information to the vision team.

  • In the LAAP project, WCET scheduled visits by outside experts to each of the campuses as the projects progressed. Areas of expertise included institutional change, online student services, accessibility for students with disabilities, and technology. At the concluding partners’ meeting, project directors identified this as one of the most critical components to their successes.

Assessment and Planning

Assessment

During this phase, focus on developing a working relationship among members of the vision team. For some, this may be the first time they have worked outside their primary areas of campus responsibility. They may be unsure of the expectations and cautious (or even suspicious) about their involvement.

Work through this phase at a high level, establishing common understandings and trust where possible. Remember that the goal is to “re-imagine” student services for your campus, not just to Web-enize current practices. Thus, you should avoid getting bogged down in detail and offending members of the team who may be defensive about the current system.

This phase is usually the most awkward and difficult. Accept that this is part of the process caused by the anxiety in approaching the unknown. Do not despair; progress will happen in time.

• Define student services
  Establish the exact meaning of each of the “student services” for your campus. What is included? Use the LAAP web of student services to initiate discussion.

• Identify users
  Define the constituencies for your new online student services. In addition to the wide range of students, who else will use these services? Staff, faculty, parents, others?

• Assess available technology
  Inventory existing campus technologies supporting student services — campus-based and online. Distinguish between isolated pocket and enterprise-wide solutions. What solutions are integrated? What are the major successes and limitations so far?

• Scan the environment
  Identify related initiatives — campus, system, state, and other technology initiatives — underway to develop or enhance online services for your constituencies. For example, these might include the purchase of a new student information system or the implementation of a portal or a single sign-on program.

• Evaluate your current services
  Review services offered face-to-face and remotely. You may want to involve an outside expert as a facilitator and to add an outside perspective, to provide a neutral voice, and to stimulate your thinking.

  • Survey stakeholders

  • Conduct focus groups

  • Use the quadrant priority exercise
    
    

• Think big
  Concentrate on building awareness for what is possible. Examine some of the best practices in online services at other campuses.

• Keep communicating
  Establish a communications system to keep team members continuously informed and engaged. Broadcast email, listservs, and Web work sites are efficient and effective. A word of caution here: Make it easy for your team to participate by delivering information to them either in its entirety or as a link. Don’t expect them to go spontaneously to a password-protected project site to get updates or to participate in threaded discussions. Rather, use the site as a repository of information for reference purposes and include ease of collaboration across the repositories. A repository sitting idle serves nobody.

• Support your institution's goals
  Review your institution’s strategic plan, budget and long-term fiscal plans and projections for investments in technology.

• Stay on task
  Determine and publish the project scope and timeline regularly.

Planning

Each phase is important, but this one is probably the most so. It is likely to be the longest and the most difficult. It is wise to move at a measured pace in order to avoid the $1 planning error that will cost $1M to correct later.

• Refine the goal(s) for the project
  Now that you have assessed your current student services and established an understanding of the scope and timeline for the Web services project, determine what is realistically do-able for the short and long terms.

• Adopt guiding principles
  Guiding principles serve to align the team’s thinking and help to ensure that the project stays on track. The LAAP partners adopted a set of guiding principles to adhere to in developing their student services solutions both independently and in working together.

• Think differently

  • Think holistically
    Historically, campuses have added various student services as the need for them arose. As a result, most services operate in silos with separate and independent infrastructures, policies, and procedures. Today, new technologies and the Web make it possible to integrate these services (and the supporting hardware/software and other infrastructures) to provide more effective and efficient services for all students across the full spectrum of their relationship with an institution — from prospective student, to graduating senior, to alumni, to lifelong learner.

    Some of the early adopters in e-learning who began teaching online long before the campus was ready to adopt a strategy, had to change their course platforms or other solutions as the campus made enterprise-wide decisions. Likewise, some divisions, departments, and colleges that have taken the lead in putting their services online may need to make changes as campuses develop comprehensive plans for Web-based student services. This will be particularly true for services designed as extended silos whose technical infrastructure is not compatible with that supporting other services or ones that the campus cannot sustain because of scaling, staffing, or cost issues. Any single service that goes it on their own is in danger of operating in an isolated environment.

    Think about how your campus can integrate related functions of multiple services to provide customized “one-stop” services for each and all students. Example: Enrollment services which merge components of registration, financial aid, and student accounts. For more information on integrating functions and customized service, see the introductory chapter to Innovation in Student Services, edited by Darlene Burnett and Diana Oblinger.

  • Think out-of-the-box
    Technology makes it possible to offer a level of service that is not possible (or even thinkable) manually. By automating many routine tasks and some of the complex analytical tasks, you can free staff to spend more time on the “high touch” services students want. Take this opportunity to imagine new student services, rather than “Web-enizing” current practices. Remember: If you automate bad or inadequate services, the result is simply automated bad or inadequate services.

    A good example, Kapio’lani Community College asked: "Why not think about academic advising and orientation services as special use cases of tutoring? After all, they have many of the same components: assessment, information, instruction, messaging, and tracking. Is it possible that some of the same technical solutions that support tutoring can be used to support the other services? Are these always discrete services or can they be blended into a more integrated model of 'learning support services'?"
    
    Another good example, Regis University asked: “How can we provide the just-in-time kind of orientation services students want rather than the overwhelming one-time data dump traditionally provided by campuses? How can we use technology to deliver orientation like slow-release medication across the full spectrum of a student’s relationship with the institution just as it is needed?”

• Create a vision for what student services should be like
  Technology is evolving so rapidly that what is impossible today may be possible tomorrow and ubiquitous in a short time. So ignore the limits for now and involve your team in crafting a “high level” vision to put your campus on the cutting-edge of service to students. Don’t worry if it can be done; just imagine it and let the IT professionals worry about implementations or adjustments to your demands later. Capture this vision in narrative and use this document to inform and educate others about the project. See The Art of the Long View for excellent information on scenario building to introduce improved or new services.

Some factors to consider:

• Are the services designed from the student’s point of view, but tempered with the knowledge of veteran staff?

• Are they seamlessly integrated, as appropriate?

• Are they interactive, providing real services online — not just information online about using available offline services?

• Do they provide an appropriate degree of self-service with easy access to live support?

• Are they personalized to subtract away superfluous information?

• Are they customizable (as appropriate) by the student?

• Do they include the appropriate level of self-service?

• Do the services accommodate all users — students, staff, and others as appropriate?

• Do the services take advantage of new technologies and functionalities such as event triggers to both “push and pull” services to and from the student?

• Are they conceived to deliver the just-in-time service that students want and deserve?

• Are the services flexible to accommodate customization by various departments or colleges?

• Will the services automate tasks to free staff to spend more time on personal services?

• How will job responsibilities and skill requirements change?
  

• Weigh the vision against key policies, practices and attitudes
  The new vision is likely to require changes in policies, practices, campus culture, attitudes, and perhaps even people themselves. Identify as many necessary and desirable changes as possible and what will be involved to make them occur. Are there some that are set in stone? What is the timeline for changes to the others? Develop strategies to change those that you can and begin working toward those goals. See policy challenges.

• Revise the vision and/or the timeline
  Sometimes it is necessary to modify the original vision, but it is important to be cautious when doing so. Change, although not easy, is often inevitable. It just takes time and effort. Can you identify workarounds that would remain true to the original concept? Could you rollout the vision in versions, addressing limitations over time? That is, you can stage the implementation of online services over time.

• Determine the priorities for your initial focus
  There are several ways to determine where to start. To develop personalized and customized student services, integration with the student information system (SIS) is key. If the SIS is stable — i.e., no plans to change it in the near future — it makes sense to start with the administrative core services. These services are usually centralized and operate on established rules and laws. Many institutions have developed “one-stop” enrollment services merging registration, financial aid, and student accounts as their first step in designing student-centered online services.
  
  Some institutions prefer to start with the services identified during the assessment phase as the most important and which the institution is doing well. These can usually be put online quickly and help to generate interest in the possibilities for other more complex services later on. Others prefer to tackle those services identified as important which the institution is not doing so well. These require more effort in the planning stage, but also have the potential for creating the most satisfaction among users. Some might want to follow the order determined as priorities in research by the Southern Regional Education Board (SREB).

  In the LAAP project, students responding to surveys and participating in focus groups at the three institutions identified academic advising as the most important service. In itself, academic advising is a huge service and institutions may find it necessary to address it in stages. One way to approach this is to identify the various components of academic advising on your campus and ask stakeholders to evaluate how important each is to students and how well the institution does it. It is also important to contrast academic and other types of advising to better define academic advising. Again the choice might be to focus on those that are important and that the institution does well to do something quickly or to focus on those that are important which the institution does not do so well to make a bigger difference.

If your SIS is going to change, then you may want to start by developing a standalone or outsourced service since spending the time and money to integrate a solution with the current SIS would be wasted. At Kapi’olani where this was the case, the team focused on a pilot group of 90 medical assisting students. They developed a small database that acted as the SIS for service modules they developed in the LAAP project. This experiment prepared them to refine the modules before integrating them with their new SIS (implemented in the final stages of the project) to serve the larger campus community.

For more information on personalized services and student information systems, see Bill Haid's webcast.

Design and Development

Design

This is the exciting stage. Using your holistic (that is, complete) vision as the context, you can now drill down into specific parts of it.

• Assemble a design team
  At least some members of the vision team should serve on the design team (link to KSU team for example) to ensure that the design adheres to the recently adopted holistic vision (or, stated in software terms, the design manifests the architecture specifications). Other subject matter experts (SMEs), with expertise in the practical aspects of the selected service areas, should be added. If you are focused on decentralized student services, it is important to have representatives from the various departments or colleges providing the service(s). A few representatives of IT should also participate on this team, but primarily as resources. You should have at least one person on the team who can bridge the natural gap between education and IT professionals — or at least have periodic access to such a person.

• Focus initially on the WHAT, not the HOW
  This is the most important guideline. Technology should enable the vision, not define it. The SMEs should develop a vision for the selected service(s) in as much detail as possible. This may not be easy for some student services staff. Most went into the field because they like people. Some may be concerned that technology will interfere with that in some way — a few may even fear losing their jobs. Others are not sure how they can inform the process because they know so little about technology. Assure them that they don’t need to know what technologies to use. This will be the role of the IT staff in the development stage. For now, you want them to imagine WHAT a new service SHOULD be like — with both automated and manual components as appropriate. In short, SMEs define WHAT you want; IT defines HOW to do it.

  Visits by outside experts who can talk about best practices at other campuses and in outside organizations in the service area(s) can provide the inspiration needed to brainstorm new ways of operating. It is important to keep these discussions focused on what the new service should be like — not on how it is currently done or in the future will be done. Some demos from vendors may be appropriate at this time as a way to educate the design team about some of the possibilities enabled by technologies — not to limit the vision.
  
  Develop a narrative that captures this new vision and use it to inform stakeholders, to solicit feedback for revisions, and to garner early buy-in from campus leadership.

• Use a common language to work together
  Each discipline has its unique vocabulary. Many terms — even the most common ones — may have several different meanings on your campus. Develop a project glossary and record key terms (and labels for also known as (a.k.a.) terms). This handy reference will be particularly helpful as the project starts and progresses to help ensure that everyone is thinking about the very same thing. This step is time-consuming and frustrating but be patient to reap the rewards. Do not skip this step!!

  Another way to bridge the language gap among SMEs and IT staff, in particular, is to use scenario building and the Universal Modeling Language (UML) for expression of, and communication of, the scenarios. UML is a standardized graphical language that allows one to illustrate complex ideas in a simplified manner. See publications for more information about UML and scenarios as well as Burnie Blakeley's webcast on bridging the communications gap between student services and IT staffs.

• Use scenarios to describe the vision in more detail
  The scenario building process provides a way to focus on aspects of the vision in more detail so that descriptions of functional needs can be more concrete and well-defined. Writing a scenario is somewhat like watching a scene in a play. Actors (students, staff, others) perform on the stage. Behind the curtain (in the technology system), necessary activities occur to support the actors. The scenario expresses itself as a series of “message pairs” exchanged between the actor (the student, staff, or another) and the system (the student services online).
  
  The scenario is a series of steps initiated by the actor (through step 1 and subsequent odd-numbered steps) and responded to by the service within the system (through step 2 and subsequent even-numbered steps). Step 1 and step 2 constitute the first message pair. Step 3 and step 4 constitute the second message pair; and so on. First the actor “speaks” (sends a message to the system), then the system responds, not unlike a dialog in a play. Then one or more additional message pairs (or pairs of steps) are exchanged between actor and system until the intended goal of the scenario is accomplished.
  
  
  
  Every scenario has a goal of accomplishing some part of or all of a student service. For example, the scheduling of an advising appointment can be the goal of a scenario and the fourteen message pairs (28 steps) between actor and system can accomplish that goal.
  
  By writing scenarios to describe the most frequent and critical interactions between a user (student or other) and a service, you help team members to identify and clarify the commonalities and differences in their visions. This is especially helpful for services such as academic advising, which are distributed across campus.
  
  Moreover, scenario documents can be a useful way to communicate with the IT staff and prospective vendors about the kind of functions you would like to have supported by functionality. The functions are expressed in terms of the system user’s perspective, not in terms of the internals of the system itself. It is not important to define what the system is, rather use the term abstractly and focus on what the system should do. The more detail you provide, the less likely there will be misunderstandings in what you would like the system to do.

  For more information on scenarios, see how K-State used them and see a blank scenario form.

• Determine key assumptions, requirements, and issues (ARIs)
  As you work through the scenario process, record the key assumptions (what you think to be true or anticipate to be true in the future), the requirements (what a system must do — automated and manual processes), and what the unresolved issues are.
  
  Document the source of the assumptions, if known, and validate these assumptions periodically throughout the project.
  
  Express the requirements in simple statements derived from the scenarios that have been written and express these requirements as USER requirements, not SYSTEM requirements. Express only user requirements and leave the technical requirements (to support the user requirements) to the IT staff. Always use an “outside-in” view and leave the “inside-out” view to the IT staff. Complete the scenarios and then digest the user requirements from those scenarios. The scenarios provide requirements details; the user requirements list (expressed as a list of single sentences, one for each requirement) summarizes the requirements.
  
  Work to resolve as many issues as possible by assigning them to a single member of the team or others outside of your team, as appropriate. Work to resolve as many issues as possible but if no resolution is found, then document these issues as possible risks. These documents can serve to inform your IT staff, be addendums to RFPs, and provide in years to come the historical perspective for why some decisions were made.

• Build in quality assurances
  Good student services support learner success and retention. What are you trying to achieve with your new services? How will you know that what you are planning to do will be effective with certain types or all students? What tracking mechanisms will be built in?
  
  With technology it is easier to track effectiveness than with manual processes. Determine the outcomes for your new services and define the metrics for evaluating them. When your new service is operational, this information can help inform your revisions, provide direction for staff training about the most successful interventions, or demonstrate how technology can enhance services and sometimes lower costs. See the K-State outcomes profile and Regis' cost savings.

• Think versions
  Usually it is not possible to do everything at once. By rolling out the functionality in stages, you have the opportunity to deliver some improved service more quickly and stably. This staged implementation serves to demonstrate progress and to stimulate interest and enthusiasm. It also gives you time to learn from the users and to revise your vision in ways you may not have imagined. A stronger end product can result.
  
  To do this successfully requires a plan. Determine exactly what functionality you will roll out in each version and develop a communications strategy to keep key stakeholders and users informed of what is in each version and why. This will help to manage expectations and ensure a smoother transition from current operations to the ultimate vision.

• Consult with the IT staff on HOW to support the new service
  The scenarios (and associated ARIs) provide a good basis for discussion with your IT staff about what you want the new service to be like. Specifically, the scenarios demonstrate exactly what is expected in the way of interactions between the student services system and the user. Each step (set of information exchanges) of the scenario identifies what the student (or other) user does and what the student services sytem does in response.
  
  By examining each scenario, the IT staff can begin to determine what kind of technical requirements would be needed to support each step of what you want to do for each step of the scenario. The technical requirements support the user requirements. The assumptions, requirements, and issues documents will also be very helpful to the IT staff professional to either understand or challenge each A (assumption), each R (requirement), and each I (issue).

  Once the technical requirements for the system are known, the IT staff can evaluate and recommend steps of the IT system implementation. Some of the considerations:

  • Does the software needed to support the scenarios (and each step within them) already exist among that which the institution owns?

  • Is there software already in the marketplace that the institution could buy to support the new service? Use EduTools to compare software.

  • Does the IT staff have the expertise and time to build an in-house solution? And, very importantly, to change and maintain it?

  • Should the institution partner with a third party (e.g., a vendor, another institution, or a consortium) to develop a solution?

  • Should the institution simply outsource the service to a service provider?

  What are the costs for each of the options above? What are the compatibility issues with the student information system, portal, and other technologies? Will an RFP be required? How would these options affect the time frame and staffing choices?

• Determine best option(s)
  For a high level and quick summary of the options, a technical options matrix can help facilitate the communication between the IT staff and the Design Team. For complex requirements, much discussion between the IT staff and the Design Team may be necessary to compare options at the level of detail necessary to make the best decision. In some cases the IT staff will need further work or additional scenarios to help narrow the choices. Tradeoffs in functionality are likely and it is critical that the IT staff make all choices known to the Design Team as they discuss their recommendations.

Development

How this phase proceeds will vary with the option(s) chosen above. This section is written from the perspective of an institution that chooses to build its own “homegrown” solutions so not all of it will be relevant for the other options.

• Appoint a development team
  This new team — the HOW team — will be composed primarily of IT staff with the specific architecture, design, and programming expertise needed. It should also have SMEs from the Design Team to help guide the IT staff in discussions about the details of statifying the requirements, as such are expressed within scenarios.

• Establish a realistic work plan
  In most cases, each of the team members will have other responsibilities and this project will compete for their time and attention. The project director must work with the team to establish a realistic work plan with discrete checkpoints. To keep the project on track, hold regular meetings to report progress (to the team and to outsiders such as stakeholders), while adjusting the timeline or securing additional resources as desired or necessary. It is also critical to build in adequate time to seek required approvals and to keep track of these approvals.

• Develop the “storyboard”
  The scenarios tell the story at a high level and provide guidance about the overall framework and functionality needed in the system. The developers (programmers and designers) will need more detail at this stage. Storyboards (which can be viewed as a series of scenarios, somewhat like a collection of scenarios within an act of a play), are a set of consecutive depictions of important changes along paths through the system and provide a closer look. The more detailed the storyboards, the more likely the developers are to provide a satisfactory solution.
  
  In many cases, the team will want to meet with stakeholders to review the storyboards and may need to work through an intense period of short consultations to make the necessary modifications. For example, what directions will a student see on the screen for completing an application? When the student submits the application, what message will be displayed? Will the student also receive an email message confirming receipt of the application? If responses in the application trigger different paths in the system, will different messages be needed? If so, what should they say?

• Determine a common “look and feel”
  Work within the institution’s established or evolving guidelines for a common “look and feel” to establish a cohesive image for student services. Use identifying graphics to distinguish specific services.

• Create a prototype
  A mock Website can be very useful in demonstrating how the new online service will work. It does not need to be fully functional—it can be a “skeleton” and only appear externally to be complete. For example, if students will be able to search for classes, use a defined path with links to static pages to give the impression of search. This is a good way to test the concept with prospective users and stakeholders, refine current plans, and add requirements not identified in the design phase for incorporation at this stage or in later versions. This is an outside-in viewpoint.

• Refine the budget projections
  Now that the requirements are better known, a more specific budget can be determined. Be sure to include projections for scaling the service, maintaining it over time, and developing and providing staff/student training. In addition, project cost savings or the benefits derived from improved service so that decisions related to the budget can be made within the larger context of organizational change.

• Seek final approvals
  Ideally, key stakeholders have been involved along the way and can give or help to achieve final approvals. For those who have not been involved, develop short project descriptions with links to the prototype, FAQs, and other supporting materials. You also might use demos from outside the institution to stimulate enthusiasm for buy-in to any new technologies that are not familiar to the approvers.

• Refine the requirements
  Depending on the outcome of the budget and approval process, it may be necessary to scale back, restate, or expand the requirements one more time. Another possibility is to break the requirements up into versions, taking care to include as much of the infrastructure as possible in the initial phases.

• Develop and test an alpha version
  Develop a working version of the system and test it with different users . Be sure to include off-campus students and students with disabilities as well as staff. Keep a detailed list of change requests and determine which should be addressed now and which can wait for later versions.

• Create an internal marketing plan for the new service(s)
  Determine the best time to introduce the new service and begin to build awareness about the features it will include. Be careful to set realistic expectations.

• Pilot the new service
  By piloting the new service with a selected subset of the campus population, the developers will have the opportunity to fine tune the technology solutions before full roll out. This also allows the developers to observe the use of the service at different times during the academic year when simultaneous use and system load may make additional changes necessary before full deployment.

Implementation and Evaluation

• Train the users
  Prior to implementation, provide as much training as necessary to staff and students to use the new service successfully. In many cases, staff will require more training than students—especially when new job skills or responsibilities are involved. See article in Resources for more information.

• Deploy the new service
  Once appropriate revisions and expansions have been made to the pilot version, deploy the new service to the broader constituency. Be sure to include a feedback mechanism to amass input from users for problems, requests for additional functionality, and success stories.

Evaluation

• Begin again!
  Input from users, best practices at other institutions, and new ideas from staff are likely to keep new online services under construction for some time. New technologies will also make it possible to add features not yet imagined. Gather all this information and the vision team together to begin again on the ongoing path to best practice in online student services!