University of Illinois Logo Go to UIC homepage Go to Springfield homepage Go to Urbana-Champaign homepage Go to university administration homepage
white bar
red bar
blue bar
orange bar
Welcome to the University of Illinois UI-Integrate Web Site
This image is used as a spacer
University of Illinois
gray bar image
Link to Project Overview
Link to Newsletter
Link to Implementation Information
Contact Us
Home Page - UI-Integrate
Link to Search UI-Integrate Web Site
Link to Site Map
Enterprise Resource Planning

To view navigation as text

Location: >>Home>>Newsletter>>Articles Index

Back to Headline News

Headline News

What Is a Conference Room Pilot?

The UI-Integrate Project Team is conducting a series of Conference Room Pilots (CRPs). These CRP sessions will help the project's teams develop the models for business processes that will use the Banner software. The CRP sessions will also identify software gap workarounds and refine the configuration of the software. The focus of the CRPs is to understand not only the software but also the organizational and policy requirements that will be needed to realize the vision of the improved business processes that will be part of the UI-Integrate system.

All the campuses will be represented at the CRPs; attendees will be actual users of today's systems, and the focus will be on three objectives:

  1. knowledge transfer and knowledge building for project team members and other CRP participants;
  2. development of the future business process models showing how business processes will be accomplished using the new system;
  3. information-gathering, providing a forum for input from a cross-section of the University user community.

During a CRP, project team members will demonstrate the software and processes using realistic University business scenarios containing representative University data. The CRP sessions will center on walk-throughs showing the new ways in which these representative current business processes can be performed using the new system. The walk-throughs will cover each online form, report, and batch process related to a given transaction or scenario, and will provide an opportunity to get feedback from users on the proposed system configuration. This process will help to identify and document:

  • software gaps
  • impacts to the organization
  • impacts to policy and procedure
  • security issues
  • audit and control considerations
  • workarounds that can be resolved after the CRP, but while the teams are still in the design phase

CRPs will be used to ensure that the organization is properly equipped to handle the changes accompanying the new system. Additionally, the CRP may identify potential online help and training needs. Training and Communication team members will attend a number of the sessions, to understand the processes and issues and to incorporate organizational, process, and job role/content needs into project training and communication activities.

The CRPs will likely produce questions that must addressed with creative solutions, to meet the needs of all affected parties, for example, in resolving a software gap. Basically, a software gap is a difference between the way in which CRP participants envision a business process working, and the ability of the SCT software to support that business process. To close this gap will require changing the process or developing workarounds that conform to the new software's functionality. Because of this, open communication is essential during and after CRP sessions -- between management, functional, and technical personnel, and between the development teams and the user representatives. At the same time, all participants must be open to the ideas of changing business practices and procedures, and for supporting the project's guiding principles: no modifications to the software; and, using common business processes across campuses where possible.

Prior to the CRPs, project team members will receive Banner product training in order to understand the navigation within the Banner product and to focus on how the University will use it in the UI-Integrate system. In addition, all participants will receive training on the CRP process. CRPs are not a user training session, a system test, or a demonstration of exactly how the software will work in the final, implemented system. CRPs are working sessions during the project design phase, and as such the UI-integrate team will want feedback throughout the CRP sessions.

When the CRPs are complete, UI-Integrate project team members will be able to put together an updated Business Process Flowchart -- a documented inventory of software gaps for each module, along with proposed methods for closing the gaps -- and an inventory of reporting requirements for the business processes. Careful management and execution of the CRPs is critical to the success of the UI-Integrate project, because the feedback from the CRPs will provide a detailed understanding of the requirements for building and transitioning to these new UI-Integrate business processes.


What a CRP is NOT...

  • A user training session. User participants will not follow along on their own PCs.
  • A large data conversion effort to programmatically load production data into the CRP environment.
  • A joint application design (JAD) or prototyping session where the software values/code tables are configured or populated in the session.
  • Project team members going into the session cold without scripts and forethought. Draft to-be process flows and initial software configuration must be complete prior to the CRP.
  • A system test or demonstration of exactly how the software will be used at U of I. Participants must have an expectation that the project is still in design and are wanting feedback on key points.


What a CRP is...

  • A scripted and well prepared working session.
  • Project team members demonstrating the software and processes via multiple, realistic U of I business scenarios with U of I configuration data.
  • Demonstrations with small amounts of representative data (e.g., change the names to protect the innocent). Usually this data is hand-keyed by project team members.
  • An opportunity to ask users questions and get feedback on the proposed configuration and use of the software.
  • An effort to identify and document gaps and policy/process issues that can be resolved after the CRP, but while the team is still in the design phase.

Back to top