The Prototype applications were selected from existing business processes that involved multiple levels of government. Each Prototype Development Team was made up of government professionals who performed or held responsibility for tasks along these business processes. Among these team members were professionals from state and local governments with a wide range of job titles and areas of responsibility. A key component of the software development process was an end-to-end business process analysis conducted by teams of people who actually did the work as part of their job functions, such as the town, village, and county clerks, assessors, and information and technology officers from all levels of government. These teams participated in workshops where they mapped out the details of every step in their business process spanning all levels of government.

As a result of this in-depth analysis, each team member gained an understanding of the whole process and how their portion fit into the larger process. In addition, they acquired a better appreciation of why and how the process is carried out. The business process analysis contributed to a better group understanding of the process and its problems.

Within this framework, the results of the business process analyses were focused on reducing complexity and solving problems that could be solved within the scope of the project. The teams developed scope statements for each Prototype application that described its function and purpose and specified its attributes. They defined goals and objectives that clearly stated the purpose of the application, the intended customers, and the subsequent benefits. These process maps and accompanying statements served as a way to communicate among the team members and also served as a documentation guide for the software development team.

The business process analysis also created a learning time for the software development team to build a relationship with the business process owners and develop a joint understanding. The process maps informed the technical specifications which together helped to define the overall scope of the Prototype. Avenues and mechanisms were established for the software developers to communicate their understanding of the business process back to the users and to describe the software that would support those processes.

For many of the team members, this project was their first exposure to any form of software development. Many had not used a prototype previously. CTG’s prototypes are systems that are meant for learning by simulating a real system. They have a very short development cycle, that identifies only enough of the business requirements necessary to build a limited system to support the evaluation of an idea. The selection of software and system architecture is based on available resources and their ability to produce fast results. Usually, the software from these prototypes is not further developed into complete systems; rather it is used as a practice system to inform the possible future development of a production system.

Some participants in the project initially found it difficult to accept that a prototype itself would not expand into a full system. However, after becoming more familiar with the software development process, terminology, and prototype concept, they understood the value of this approach and were able to participate fully in the development process. When the prototype development process was completed, the teams were quite excited to see the system they helped design operating with data they knew and understood.

The users also saw considerable benefit in using real data in the Prototype. Even though it makes prototype development more complex and time consuming, using real data is worth the extra effort. It gives the participants a familiar and specific perspective on the data issues that need to be addressed when planning for the design, development, and deployment of a production system.

Using real data also made it easier to train field test users on the use of the Prototype. There was less to learn from their perspective. They knew the business process. They understood the data. The field test was therefore a matter of understanding how the Prototype supported the business process. Identifying errors (which resulted from the data migration or integration) was quick and easy for those familiar with the data.

The willingness of the team members to participate in the development of the Prototype demonstrates that state and local governments are open to new relationships and new software systems that would enable the sharing of data even if the result would mean less individual control over business applications, as long as the development process considers all aspects of the process and the roles that various organizations and users play.

Although user acceptance testing is not normally part of Prototype development, this Prototype required it because it was needed to be evaluated in a simulated business environment as part of the learning process. Testing to ensure that the applications supported the required business functions needed to be performed by members of the prototype team before the application was rolled out to the field testers who had never seen it before.

The corporate partners and CTG staff provided training and support to field testers. Each field tester was required to attend one of five three-hour regional training sessions prior to beginning the field test evaluation. During these training sessions field testers were given an overview of the project and its goals and then a demonstration of each application. Each user was assigned a user name and password and shown the role(s) that he or she would have during the test. A workbook consisting of 34 tasks and an opinion survey was distributed and explained. The only hands-on component of the training was practice to make sure testers could sign-in to the Prototype using their user name and password.

The test was conducted from each person’s place of work although a few later reported testing from home for lack of time during the workday. Support was provided for the field tester by phone and email during normal business hours. The support team was able to guide users through any difficulty using the Prototype and was prepared to involve software development teams as needed. However, no issues required the involvement of the software development teams. Online help and Frequently Asked Questions (FAQ) were also built in to the Prototype to assist users in answering questions on their own, although it does not appear that these features were used extensively.

For the majority of users this training and support model worked well enough considering the very limited resources available to conduct them. A few users needed more help than the support model could accommodate. From these few users, the support team identified the portions of the Prototype design that caused the most issues and the need for more training in basic Windows and Internet skills. Both of these issues resulted from the limited resources available in the Prototype project. A production level State-Local Gateway would have gone through more than one refinement process, fixed the design issues, and given more time and resources for users to receive additional training.