SKUNKWORKS

In our first report, dated November 1994, the Skunkworks team outlined the first phases of its project. Our report included details of the team members, meeting guidelines, vision, mission, objectives, and a timeline. The report also detailed the Problem Identification Phase which included an extensive review of the current situation and flow chart of the process as it exists.

This report will describe the analysis we completed of the current situation, the potential solutions discussed, and the trial and tribulations of the team's group process. In addition, we will enumerate the difficulties we are having with completing the project and outline the steps we are about to take.

I. Analysis of Current Situation

We also knew from discussions with people around campus that the form could be pushed through all 101 steps in a few as 48 hours. We also knew that it could take as long as six weeks. We deduced from this that despite the number of steps listed, shortcuts were possible increasing the efficiencies in the process. We also concluded that the priority of the traveller and perhaps their status in the institution influenced the length of the process in terms of time.

In addition to the flow chart analysis, we also completed a detailed cost analysis (Appendix B). The methodology was to identify the people handling the form, how long they handled it, and their pay rate. Since the form is used for three distinct purposes (airline reservations, establishing a budget commitment and request for a cash advance), we tracked each item separately, calculating a estimated "contact cost".

We identified the number of each transaction processed annually and calculated a total direct processing cost. Using the federal governments suggested administrative indirect cost recovery percentage of 26% we calculated an estimated total annual cost of $89,571 for a staff travel form and $75,690 for a faculty travel form. Therefore, using this methodology we calculated an average annual cost of processing travel forms to be $82,631. This cost analysis is very limited in scope and should only be used to estimate the minimal cost involved in processing travel forms.

A root cause analysis of the process led us to make the following conclusions:

1. There were too many steps in the process.

2. There were too many signature authorizations required.

3. There were too many steps dependent on too few processors.
   

II.Solutions

1. Create a user-friendly, self-explanatory model.

2. Create a model which is accessible across platforms.

3. Capture the information once.

4. Have the data go to an existing system.

5. Include electronic signature capability.

6. Include an acknowledgement for processed forms.

7. Provide a way for people to give us feedback.

As we discussed possible electronic solutions, it became evident that obtaining the required signatures would be a serious problem. In our exploration of various methods, we attempted to thoughtfully address the following questions:

1. Are electronic signatures acceptable from an audit standpoint?

2. What authorizing signatures are required to meet federal requirements on grants and contracts?

3. What are the current UVM policies regarding authorization for travel?
   

Chuck Jefferis, Director of Audit Services, attended the January 13, 1995 Skunkworks' meeting. His position on the question of signature authorization is as follows:

1. Expenditures require the approval of a person authorized to sign on the budget.

2. The approval cannot be verbal.

3. Front-end authorization is important to settle disputes, lawsuits with vendors, etc.

4. Electronic codes or signatures are acceptable.

5. The authenticity/integrity of data or transactions being sent over the networks is an important issue. Having adequate network controls in place is imperative.
   

1. The traveller;

2. Supervisor of the traveller if the traveller is the responsible party on the budget; and,

3. Dean's signature for foreign travel.
   

We concluded that signature authorization for travel could be greatly simplified and therefore more adaptable to electronic format if we could accept travel authorizations and airfare using only the authorization of the person responsible for the budget to which the travel is to be charged. This would result in the need for the following changes to our current policies and procedures:

1. The traveller's signature would not be required on the travel form. If a cash advance is requested, the traveller would sign a form at the cashier's office when picking up the advance. The form would state that the traveller was responsible for the advance.

2. If the advance is by check, cashing the check which bears the description "travel advance" would indicate acceptance and recognition that the funds were for an advance.

3. We discussed these procedures with Lori Drumm, who felt these were acceptable procedures. We did not discuss these procedures with the auditors.

4. The only required signature would be the signature of the person responsible for the budget being charged. This would meet the requirement for restricted awards for signatures.

5. The supervisor's signature would not be required if the traveller is the responsible person on the budget. The supervisor would have to approve expenses submitted on the travel return before the traveller could be reimbursed.

6. The department would be responsible for obtaining any other signatures their internal policies require. These signatures would be written, and not part of the new electronic process.

   In this time of downsizing, and attempts to increase productivity, it seems that we can no longer use central administration to enforce departmental procedures, and that these procedures should be enforced at the department level.

7. Dean's office approval would not be required for foreign travel. Chuck Jefferis discussed this procedure with Bob Low and Ray Lavigne, and they agreed that this was an historical requirement which had outlived its purpose and could be eliminated.

8. Currently, Grant and Contract Accounting approves all travel prior to the trip. This is to ensure the travel is allowable on the award, the travel meets all award requirements, and there are funds to cover the expected expenditures. A policy change would be necessary to allow GCA to transfer unallowable expenses either to the department or to salary reduction if the unallowable charges are not removed from the grant by the P.I. in a specified period of time.
   

No formal meetings were held with Susan Brooks, Lori Drumm, Steve Stoddard or the external auditors, KPMG, concerning the signature process, because we had not yet determined the direction our form would take.

No discussions were held with the Provost, or other university officials concerning the policy changes outlined above, with the exception of the foreign travel authorization.

If an electronic form is to be devised, the signature process is an important issue which needs to be addressed. Signatures currently required for travel more extensive than those required for most university expenses. If policies can be put in place to address the process, these same policies should be easily adaptable to other paper forms which may become electronic forms in the future.

During this Phase, the Team entered into what we now refer to as "a funk." Team members felt stressed, overloaded with other work, unable to make clear decisions, and unable to balance competing priorities. Working together during a brainstorming session, we decided to condense the Solutions Phase using a retreat format. The Team met off campus for nine straight hours to develop a list of alternative solutions. The retreat proved very worthwhile in restoring confidence and energy to the Team while generating a variety of possible solutions. They included:

1. Traditional host-terminal

2. E-mail
   
   
3. Voice activated

4. Client-server

5. World Wide Web

6. Debit / Credit card
   

After testing each alternative against criteria established early in the project, the Team enthusiastically pursued a voice activated system which would allow anyone in the University community to access the process from any telephone. After further exploration, it was learned that the University did not have the capability to implement such an advanced system.

At this juncture, the Team lost its member with the most background in computer programming. We also were feeling that we had nearly reached our capacity in exploring and understanding the landscape of electronic forms capabilities. The Team decided that it would invite another person to join the Team with an extensive background in computers. That decision was not made lightly as everyone recognized that the dynamics of the team would change. At the beginning of the summer, the Skunks were pleased to welcome Roger Lawson to the team as its newest member.

In exploring the use of electronic forms at UVM, we learned that the University has been seeking a system that would allow the replacement of paper packets handling with electronic packets. Ideally such a system would allow information to be collected, distributed, filed and retrieved electronically. Unlike paper forms, electronic forms can have built-in intelligence, i.e. the system can be programmed to accept only valid codes and automatically distribute the information as desired. And the collected information should not have to be reentered into another system as we so frequently do with paper forms. This has a tremendous potential for both productivity and service improvements at UVM, but such a system will take substantial thought, planning and implementation resources.

An ideal system should have the following characteristics:

1. Easy to implement: minimal programming should be required.

2. Supportable by existing desktop devices: Windows, DOS, Mac, Unix and terminals. Costly, high-end configurations should not be required.

3. Secure and auditable: proper authentication and encryption should be included where necessary. Forgery should be virtually impossible. Questionable transactions should be reliably traceable.

4. Low in cost: preferably having no incremental cost for the end users.

5. Easy and fast to use: the system should not require end users to terminate programs that they are already running or initiate new programs that require a lengthy initialization or complex security/authentication steps.
   

Unfortunately, no such ideal system currently exists in the marketplace. However a number of possible approaches do exist and depending upon the problem to be solved, some are more suitable than others. If we were to attempt to find the "perfect" solution, we would end up spinning our wheels and never make any meaningful improvements. To that end several possible, though imperfect, methods were considered and are described below.

A.Traditional Host/Terminal Systems such as CICS, VM/CMS or Unix programs.

1. Advantages
   
   
   1. Everyone with a terminal or terminal emulator can get to the application with little or no incremental cost

   2. Access to UVM databases is generally facilitated (i.e. no need to replicate databases or send them across the net)

   3. Information can be edited for validity, etc.

   4. CIT AIS staff have a considerable experience with these systems.
      
   
   
   
2. Disadvantages
   
   
   
   1. Mainframe systems are notoriously complex to build and maintain.

   2. The user interface is usually limited to character based interactions.

   3. A relatively expensive resource (the mainframe) is required.

   4. UVM currently has no one available to do the programming, i.e. the demand for mainframe programming services exceed the current, diminishing staff resources.

   5. For each additional form implemented, considerable programming effort is required.
      

1. Advantages
   
   
   
   1. Electronic mail (e-mail) might be the easiest method for systems that require information transfer only.

   2. Electronic mail is already used by many, perhaps most, in the University community.

   3. From a forms origination point of view, it can be relatively simple to implement (depending upon the e-mail system being used): a standard ASCII forms documents can be made available for each email environment; and end users can customize their own copy to avoid repetitively filling in the same information (like photocopying a partially completed paper form).
      
   
   
2. Disadvantages
   
   
   1. There are many e-mail systems in use at UVM (e.g. PINE, Pegasus, ELM, Note, CCMail, MS Mail, Eudora, and PROFS).

   2. The data, if it is to be processed by computer, must be parsed to extract the pertinent information; this requires additional programming that would likely be challenging.

   3. E-mail is not difficult to forge.

   4. There is usually no application intelligence in the e-mail programs (budget numbers cannot be checked for validity, for example).
      

This approach uses the telephone as an input device and is especially appropriate for applications that can be defined to allow entry of numeric codes, such as course codes.

1. Advantages
   
   
   1. Everyone has access to a telephone.

   2. Accessibility via ordinary telephone makes this approach especially useful for clients who are not on campus.
      
   
   
2. Disadvantages
   
   
   1. Specialized hardware and telephone lines are required. This hardware exists at UVM but would have to be augmented for new applications.

   2. The telephone keypad is a very limited input device, e.g. no good alphabetic capability and no backspace for error correction.
      

D. Electronic Forms Packages

These packages (such as Novell's "InForms") are designed to meet this precise need. Unfortunately, there are significant barriers to their implementation.

1. Advantages
   
   
   
   1. These systems are designed to do exactly what we have in mind, automate forms development and handling.

   2. These systems are relatively easy to implement.
      
   
   
2. Disadvantages
   
   
   
   
   1. A fairly high per station cost; a per station license is typically required; many desktop stations would have to be upgraded or replaced in order to participate.

   2. Not all desktop platforms in use at UVM are supported.

   3. A certain level of standardization would be required. While this would have benefits, the selection process would be very time-consuming and might not achieve consensus.

   4. There would be a significant learning curve associated with using them.
      
      
   5. Based upon what we have seen so far, most (if not all) are not ready for prime time.
      

E. Client Server Systems

The client server approach encompasses many technologies. However, for our purposes we considered systems where the best features of the host (typically the server) and the desktop system (typically the client) are exploited. Typically the host (server) is used to provide database storage and integrity and the desktop (client) is used to provide an easy-to-use interface.

1. Advantages
   
   
   1. A well-developed client-server system could meet both the requirements for ease-of-use and database integrity.

   2. By putting the burden of presentation and user interface on the desktop the load on the server is lightened.

   3. This technology is overtaking traditional host-terminal systems in the marketplace.

   
   
2. Disadvantages
   
   
   1. Additional software (potentially costly) for clients and in most cases, the server(s) would be required.

   2. More powerful desktop hardware are needed than with traditional host-terminal systems; many UVM desktops would have to be upgraded or replaced.

   3. Client-server systems tend to require even higher levels of expertise not widely available at UVM and in high demand in the job market.
      

F. World Wide Web (WWW)

This is perhaps the newest capability and, like the Internet itself, is growing rapidly. Though this environment continues to evolve, our understanding of its current advantages and disadvantages are:

1. Advantages
   
   
   1. Because there is a tremendous amount of interest in this new environment, it is very widely supported. Most companies are getting involved, and virtually all institutions of higher education are maintaining a presence on the Web.

   2. WWW client software is usually free or at least low-cost. The servers are generally either free or have low cost educational licenses.

   3. Common platforms are supported (Windows, Mac and X-Windows).

   4. Security (including authentication and encryption) standards are being developed and deployed.

   5. The forms development language (HTML) is fairly easy to use. Relatively little programming expertise is required to develop forms. (Processing the output from the forms is another matter entirely).
      
   
   
2. Disadvantages
   
   
   
   1. Many desktop systems at UVM are not up to running the popular Web client software.

   2. While applications involving simple information transfer can be relatively easy, more sophisticated applications require a component to accept the information collected by the WWW "form", interact with other systems / databases and do something intelligent with the information. This requires programming expertise in C or Perl, languages not typically used by most business applications programmers at UVM or elsewhere.

   3. Because each WWW client-server interaction starts without knowledge of previous interactions, the programming tends to be challenging for some applications, and in cases where multiple interactions are required, it may slow the interactions.

      The World Wide Web electronic form solution is currently the most forward looking and strategically sound solution given the future of information transfer. While it is relatively easy to develop a WWW form, the processing of the data collected will require significant computing resources ‹ especially if it is to serve as a model for other UVM forms processing applications. In addition, it is our feeling that for the form itself to be useful to the University community, the interface for this form and other forms, must be consistent and well organized. The creation of a UVM forms bank available through the UVM Web pages would be appropriate.
      

Recent Activities...

1. There was an interest in CIT and elsewhere in exploring the capabilities.

2. This facility could also be used to generate electronic mail.

3. CIT was willing to fund up to 100 hours of student labor for this purpose.
   

Future Prospects

1. Travel Card Project
   
   We understand that there is considerable interest in implementing a personal liability credit card that would remove the need for travel advances in many, if not most, cases. While we feel that this idea has considerable merit and we enthusiastically support the intent to eliminate the basic requirement for the travel authorization form, it is our sense that this is not likely to happen any time soon, and that when it does, there will continue to be some need for a travel and airline ticketing process.

   Therefore, when the travel card project is undertaken, an evaluation will be needed to explore the impact on any forms. In the mean time, we intend to continue to explore electronic forms facilities. We expect such systems to complement a personal liability travel card when and if it becomes available.

   
   

2. Interface with Travel Center

   Currently, the Travel Center receives paper documents (travel form) and uses them to process billings to UVM. General Accounting receives paper reports from the Travel Center (invoices) which are manually booked into FRS (Financial Records System). Ideally, a full implementation would include an electronic interface with the Travel Center.
   
   

3. Other Projects
   
   Clearly there are many other UVM forms that would benefit from streamlining and/or replacing with electronic systems. Therefore, we feel that it is essential for the Skunkworks Team to have the support necessary to complete this project so that others may learn from our experience.

   
   

   III. Lessons Learned

   During a mid-term debriefing, the Skunks gathered to discuss what aspects of the project were working well and what they would change. The responses were as follows:

   What worked:
   
   

   1. Facilitator was essential to the process.
      
      
      1. Providing training in a "just-in-time" approach.
         
      2. Providing specific direction.
         
      3. Helping/guiding team to set specific objectives, goals, and meeting guidelines.
         
      4. Introducing the Storyboard concept and use.
         
      5. Keeping the team on track.
         
      6. Balancing participation and creating a safe environment.
         
      7. Guaranteed that healthy group process would continue during "defunking".
         
      8. Managed the "shared leadership" model the team chose.
         
      9. Showed interest and willingness to learn a process and brought an objective eye to that study.
         
      
      
   2. Support from Stephanie Woods

   3. Willingness on the part of the team to participate, pursue new methods, and endure a long project while doing their other work.

   4. Learning and using the tools: flow chart, survey, and Pareto Diagram.

   5. The Retreat: changing the format of meetings, going off-site, and brainstorming a solution all worked well.

   6. Keeping a customer focus.

   7. Willingness to struggle and stick with it.
      

What would we change?

1. Have Stephanie Woods ask for departmental support and release time so all Skunks could be away from the office with fear, overload, or repercussion.

2. More meetings would be held at the beginning.

3. More visibility earlier in the process. Would obtain a server and invite people to read the minutes and make comments. To do that, Skunks would also need to be able to accept criticism.
   

1. Make sure Stephanie's vision is shared by departments supporting staff involved in the project.

2. Future projects should include some original Skunks trained specifically as facilitators.

3. Have funding available for the process (surveys, materials, testing, and facilitator).
   

IV. Current State of Affairs

In some cases, that means that priorities will need to shift and release time granted if this experienced team is to conclude its work. However, there is a sense that the ultimate effort and expertise needed to fully implement the long term solution is bigger than Skunkworks. In order to complete the project, even to develop a functioning prototype of the solution, a decision would need to be made to put some resources into the project in terms of programming staff, release time and funding for hardware and software.

Conversations around campus with individuals and groups have conveyed support for the work of the Team and have indicated that users and handlers of the form want to reap the benefits of the projects' efforts. Many hold the team out as a model for quality improvement on campus and seek to reproduce its processes to seek solutions to other university-wide problems. We hope that the work that has been done on this team can serve as a model for similar endeavors, learning both from our successes and failures.