Skip to main content
Chapter 4: Findings, Conclusions, and Recommendations

During the conceptualization, construction, and testing of the New York State-Local Internet Gateway Prototype, state and local government professionals frequently commented that the entire project represented "a better way of working" compared to their current environment. This overall sentiment referred to both the Prototype itself and the project approach.

A vision for a better way of working

Field testers expressed high overall satisfaction with the Gateway Prototype. Of the 34 specific tasks tested, 97% were rated easy or very easy to complete. In terms of applications, all were rated easy or very easy to learn; they were rated high or very high for convenience, usefulness, and speed, as compared to their current way of working. During the focus groups, testers confirmed that a better way to conduct their everyday business entails having all relevant information and processes readily accessible through one common electronic work area.

In terms of the project approach, many people on the Prototype Team found the group modeling, analysis, and group decision techniques used by CTG and the corporate partners to be both novel and effective. Each working session made use of specialized techniques to foster discussion, promote exploration, achieve consensus, and ensure detailed documentation of the process and the underlying data. Most participants had never been involved as early, as deeply, or as collaboratively in previous projects. They welcomed the opportunity to participate in the project in this way and, for many, this type of engagement prompted them to think about the possibilities for more productive intergovernmental partnerships.

Similar to the Prototype Team, the field testers expressed the opinion that the Gateway Prototype represented a better way of working. We asked them during the discussion groups following the field test to pinpoint the most important lesson from the Prototype evaluation. Overwhelmingly, they commented on a sense of community and collaboration among state and local governments. One field tester concluded that "the technology is probably not the barrier; it's the management issues that surround something like the Gateway Prototype." Another went on to say that, "when you get state agency people and local government people in the same room, synergy starts to build and you get a better, more useful product at all levels. All future projects should be done this way."

Two broad themes emerged from the project experience and evaluation: the importance of investing in ongoing peer-to-peer relationships and endorsement of the principles of enterprise. As shown in Figure 5, relationships and enterprise thinking form the basic structure of effective state-local business relations. Both are necessary, but neither alone is sufficient. In addition, the project results suggest a set of practical strategies including governance, process analysis and field work that can be used to bind the structure together and reinforce the value of relationships and enterprise principles. Short descriptions of the findings are represented in Tables 1-3.

Photo of Prototype users


Participants in the project repeatedly emphasized the importance of long term, peer-to-peer business partnerships among state and local governments. They understood how active collaboration focused on a shared goal can yield high quality results. They also emphasized that mutual respect is essential and comes from recognizing that every participant has expertise to contribute and needs to be considered. Four important elements of effective relationships are discussed below.

Engagement. Serious engagement is a commitment to share resources, benefits, and risks in trying to reach a common goal. The entire project experience demonstrated that this kind of productive engagement is hard work. It demands more than periodic or one-way communication, attending meetings, or occasionally asking or being asked for advice. Instead, the people who participated in the project were deeply engaged with each other and with the ideas, goals, and products of the effort.

By intertwining strong commitment with the use of in-depth analysis, the Prototype Team was able to move from an idea to a robust, testable prototype representing the needs and interests of a wide range of organizations. To achieve this outcome, all team members were fully invested in the process and took active ownership of the products. They participated in 15 full-day, face-to-face, facilitated sessions, where they collectively performed business process analysis; developed modest, moderate, and elaborate alternatives for each application; generated and refined scope statements; specified system and user requirements; and reviewed work done on the Gateway Prototype and Applications.

Local representation. Two issues pertain to local government representation: obtaining agreement to participate and finding a way to deal with both large numbers and great diversity. With regard to participation, at the beginning of the Gateway Prototype project, the Advisory Committee agreed that at least six local governments and three state agencies should be included in the Prototype Team. The Advisory Committee was fully aware that the diversity of local governments is a crucial consideration, and particular attention needed to be paid to ensure selection of participants that roughly mirror that diversity. As the project became more fully defined and the Prototype Team was put together, we began to expand the initial target number. To capture more local diversity, the Prototype Team actually included representatives from 13 localities rather than the minimum number of six. During the field testing phase, the number of local governments was expanded again, and an additional 21 local governments and five state agencies joined.

Figure 5. A vision for a better way of working

Figure 5. A vision for a better way of working

Because one of the goals of the project was to determine whether there was, in fact, a size threshold for participation in e-government, we made a special effort to recruit smaller and more rural jurisdictions. We found that many people from smaller jurisdictions incorrectly assumed they needed special technical skills to be able to participate in the project. While some were simply not interested, we also encountered very enthusiastic people such as the clerk of a small city who said to us, "When someone asks you to be a part of the process, you need to seize the opportunity. If you are not a part of the development and refinement, you can't complain about the final product." All considered, obtaining the agreement of this many local governments to participate was a daunting task in which literally hundreds of phone calls and emails were exchanged between CTG staff and potential participants.

The second issue was dealing with both the large number of local governments and their diversity. In New York State, local governments vary dramatically in size, wealth, capacity, and responsibilities.

Table 1. Findings -- Relationships

Necessary elements
Current issues
  • Long-term peer-to-peer business relationships
  • Joint ownership of process and results
  • Analytical tools necessary to elicit, evaluate, and use pertinent information
  • Effective models are in use but not yet institutionalized
Local representation
  • A fair and realistic representational scheme for local engagement in G2G efforts
  • Number and diversity of local jurisdictions
  • Reluctance of local officials to speak for each other
Vendor roles
  • Rationalization and coordination of multiple vendor roles in state, local, and intergovernmental systems
  • Multiple vendors playing multiple roles in the state-local environment add substantive and administrative complexity to any effort to streamline or coordinate
State agency coordination
  • Coordination of applications, standards, implementation schedules, and infrastructure requirements across state agencies
  • A method for cost sharing
  • Separate legal authority and funding for different programs
  • Lack of regular communication among state agency initiatives that involve local governments

They range from a small town government which consists of, perhaps, one part-time town clerk who performs a variety of tasks, to an office with many specialized professionals working in a highly sophisticated technological environment and serving a community of several hundred thousand individuals. Building an intergovernmental information system that accounts for such diverse needs is clearly challenging. Because of their sheer number, direct involvement of all localities in the development of an intergovernmental system is not feasible. Even if all localities could be accommodated in a project, the very limited staff and resources of many does not allow them to attend numerous meetings or extensive design sessions. At the same time, however, local government officials often emphasize their reluctance to speak for each other. This reluctance makes it difficult to work through a representative model.

Nevertheless, the project revealed an essential need to develop an acceptable representational scheme. The one-to-one, personalized communication and relationship building efforts used by the CTG staff worked for the Prototype, but would be unrealistic in a full system effort. The broad local representation achieved for this project, and the positive reactions of field testers who had not themselves participated in design, both indicate that carefully constructed local representation can work. Working together, local and state officials must develop a realistic method for adequate representation in intergovernmental initiatives. This requires local governments to accept the idea of representation and will require careful criteria for selecting which local governments will represent others. Local government professional associations may be especially helpful in achieving this goal.

Vendor roles. Baseline data gathered from state and local governments clearly indicate the importance of understanding vendor relationships in G2G work. In building the Gateway Prototype, a conscious decision was made to engage two corporate partners to develop separate pieces of the Prototype and then integrate them together. This was done to simulate a real world environment in which multiple vendors are engaged in developing systems and adding new elements at various points in time.

As state and local governments move toward a more coordinated way of working, they will be affected by the many ways in which different vendors support both infrastructure and applications. Furthermore, if more standardized and coordinated G2G work becomes the norm, the nature of government relationships with vendors will likely change. One-to-one relationships may be replaced by a myriad of interconnected relationships across the public and private sectors. Current relationships include the following.

  • Vendors are contracted separately by state and local governments to build, maintain, and support both applications and infrastructure.
  • Vendors are contracted by local governments to develop applications for strictly local programs and for use in their transactions with the state government.
  • Several vendors may work with one state agency or large local government.
  • Individual vendors work simultaneously with a number of agencies -- as well as with local governments.
  • Wide variability exists in the degree to which local governments depend on and are satisfied with their vendors' products and services.

Any movement toward a more coordinated G2G strategy for New York State needs to be cognizant of this multiplicity of vendor arrangements and interdependencies.

State agency coordination. The Prototype Team and Advisory Committee recognized and promoted the need for intergovernmental governance, standards, and coordination. However, both state and local participants agreed that state-level coordination of applications, standards, implementation schedules, and infrastructure requirements is needed for any robust G2G program to succeed. In the focus groups, many people cited the difficulties of working with multiple state agencies following separate development agendas and funding strategies.

While a certain amount of difficulty is inevitable given separate legal authority and funding for different programs, a more concerted effort to identify and coordinate state initiatives would benefit everyone. For example, the town-level computing infrastructure made possible by DECALS, the hunting and fishing license system deployed by the NYS Department of Environmental Conservation in August 2002, offers a platform for more state-wide applications. This infrastructure could be reused for additional applications for other state programs that link to town clerks. However, doing this would also entail agreement and coordination among state agencies regarding implementation, upgrades, training cycles, maintenance, and other aspects of operations, as well as the introduction of a mechanism for sharing costs.

Finding the right kind and degree of coordination will not be easy. Even though it would be desirable from a local perspective to package state initiatives into regular and predictable activities, many state programs are constrained by separate legal mandates and time tables. On the other hand, by adhering more closely to the enterprise concepts discussed next, coordination can be improved over the current situation in which each state agency often acts on its own, without knowledge about the others and their collective impact at the local level.

Enterprise approach

The second broad theme of the project is the concept of enterprise as applied to government. Enterprise thinking emphasizes the interdependencies among the different domains, organizations, and levels of government. It seeks to capitalize on the relative strengths of different players and to tie them together through the use of standards, partnerships, and shared resources. Enterprise thinking focuses on the broad purposes of government and relies on a complete understanding of the business processes that accomplish those purposes. An enterprise approach focuses on coordinating the design, development, implementation, and operation of multiple functions regardless of where any particular activity or task takes place. Often functions or applications are grouped by programmatic area, such as human services or financial management. The Prototype experience demonstrated that an enterprise approach must include intergovernmental governance as well as joint design, development, implementation, and operation.

The NYS Office for Technology recently adopted an enterprise policy for state government that encourages state agencies to include local needs in their IT planning and operations. Although the policy was not available to guide this particular project, it confirms the key principles that were used. These principles address the cost effectiveness of IT efforts, reduction in the complexity of the state's IT environment, information sharing, data standardization, business process reengineering, interoperability and integration across applications, modular design, and scalability. These key elements of an intergovernmental enterprise framework, together with the Prototype experience, highlight both benefits and challenges for infrastructure, identity management, data management, usability, and information policies. These key elements are summarized in Table 2.

Table 2. Findings -- Enterprise approach

Enterprise approach
Necessary elements
Current issues
  • Statewide existence of basic hardware, software and networking capabilities at the local level
  • Basic local infrastructure exists, but telecommunications capabilities rely on the public Internet rather than the state's preferred internal network
Identity management, role-based security, and single sign-on
  • Distributed identity management and role-based assignments with centralized authentication of users and access to applications
  • Effective models are emerging and need to be evaluated and regularized
Data considerations
  • Policies and standards regarding data content, quality, ownership, management, and integration
  • Distributed data management using uniform policies and procedures
  • Lack of standards for defining common data elements
  • Lack of quality control for many data sets
  • Need data ownership strategies and rules
  • Lack of a coordinating entity
  • Familiarity with browsers and office applications
  • Help features and support for learning
  • Accessibility features
  • Lack of baseline user knowledge of standard technology in some localities
  • Custom applications need sophisticated Help features
Information policies
  • Policies for stewardship, access, security, and use
  • Need to review and refine information policies for an intergovernmental context

Infrastructure. The Gateway Prototype led to one extremely important finding regarding infrastructure -- New York State local governments (regardless of size, location, or type) have the computing and telecommunications capacity to use the public Internet for secure G2G information, communication, and applications. This is a significant change from just five years ago when local technology infrastructure was highly variable and prevented many smaller jurisdictions from participating in standardized intergovernmental systems.

Two factors account for the change. First, the burgeoning use of the Web in all sectors of society has introduced many local governments to email and the Web. This is not to say that all local governments are now capable of offering their own Web-based services. The human resources and technical investments needed to do this are still beyond the reach of many jurisdictions. However, during the field test, all sites were capable of conducting intergovernmental business over the Web, although slow connections existed in places without broadband services.

Second, statewide applications (notably DECALS) placed computers and dial-up services in town clerks' offices all over the state. This effort brought both computing and telecommunications to places unlikely to obtain them on their own. For this reason, basic computing and communications capabilities are already in place nearly everywhere in the state.

The implications are significant. Because the IT and Internet infrastructure is already in place, it is possible for all or nearly all government entities to participate in electronic G2G business. The focus of future planning for G2G work over the Web could now shift to issues of governance and policy, as well as organizational and operational factors influencing intergovernmental work. However, it is important to note that most local governments are not connected to New York State's private Intranet, the NYeNET, which is the State's preferred network for electronic intergovernmental communications. Consequently, the relative roles of NYeNET and the Internet need further consideration as G2G efforts unfold in the future.

Identity management, role-based security, and single sign-on. The Prototype offered substantial lessons about the importance, and pointed out some of the difficulties, of identity management as the basis for secure role-based access to diverse applications. The current practice review revealed that other states faced significant identity management problems associated with people changing jobs or leaving agencies. Lack of uniform procedures to change or terminate user rights of access caused directories to quickly become inaccurate. In these cases, users had access only to information resources and email, not to applications. In an environment in which secure applications are involved, managing identity and role changes is even more important. The most challenging parts of identity management appear to be the initial design and deployment of a standardized framework and the subsequent management of changes in user roles.

Once identity and roles are in place for users, one of the most visible enterprise framework benefits becomes possible -- single sign-on. A major attraction of the Gateway Prototype was the promise of a single sign-on for all the applications users need to do their jobs. Field testers explained the frustration of continually signing in and out of applications managed by different state agencies during the course of the day. An additional source of aggravation was the requirement to have multiple user names and passwords. Baseline data collected during the project show that most participants sign on one to four times per day, with some signing on up to 15 times per day. By contrast, during the field test they gained access to the applications with only one sign-on. Testers readily understood the process and experienced very few support issues related to user names and passwords. Although the Prototype encompassed a small number of applications, users could readily envision how this feature could be deployed to all the applications they use and were enthusiastic about the potential simplicity and efficiency.

For the purposes of the Gateway Prototype, identity management, authentication, and role assignments were handled as completely centralized activities. Users were identified and their roles were assigned and maintained through a single user management function. Even with only 56 testers, this was a large and complex task, one that clearly cannot be handled in a centralized manner in a real operation. A realistic alternative is a system with distributed identity management and role-based assignments with centralized authentication of users and access to applications.

The approach taken by New York State's CentraPort, is a good model for distributed identity management. CentraPort is a portal which co-locates access to related human services applications on a single Web site. It represents a logical step along the way to comprehensive integration. Each individual's rights are assigned and managed by that person's employer and all participating organizations use the same rules and procedures. CentraPort co-locates both Web-based and older legacy systems. Users still need to sign on separately to the legacy systems, but they do not have to leave CentraPort to use them.

Data considerations. In each of the three applications in the Prototype, data was shared in new ways which revealed issues with standardization, quality, integration, and ownership.

In the Dog Licensing Application, local officials reported information to the state agency and had full access to the statewide data base. For the first time, they were able to see not only their own data as it was represented in the state files, but they were able to look across jurisdictions to check for duplicate records or locate owners of lost animals. The Parcel Transfer Verification Check Application allowed county officials to see all the data for the towns within their borders and allowed ORPS to look at data for the entire state. While this aspect was not new, the Application gave state, county, and town officials the new benefit of electronic edit checks that applied uniform business rules to the data. The Application provided assessors with feedback on which transactions needed further checking to verify accuracy or correct errors. Moreover, when the town clerks saw the parcel application during testing, they immediately understood how edit checks could be useful in the Dog Licensing Application and began to discuss how better data quality would assist them in other activities.

The Contact Directory is the most instructive with regard to data issues. Although directories exist in many places, the idea of a single authoritative directory was entirely new. All agencies and local governments in the project cooperated in the creation and maintenance of this shared data resource. The process began by integrating contact data files from the three state agencies to create a single unduplicated database. This process revealed that each agency had its own standards for some of the most fundamental information about government. The three state agencies in the Prototype use three different coding schemes to identify local jurisdictions. In addition, different conventions are used all over the state for names, addresses, and phone numbers. Accuracy was an important additional problem partly because so many directories are compiled by different organizations.

In the baseline data, local officials identified more than 30 different organizations that ask them to supply rosters of contact information. These rosters of local officials are submitted at different times of the year in a variety of formats including paper, fax, and electronic submissions, with paper being the most common. The overwhelming majority of project participants also keep their own files of this information, again most often on paper. Consequently, there is no single trusted source of statewide contact information for state and local officials. Each person appears to have his or her own favorite, usually a paper directory published by a professional association which is marked up by hand as new information and changes become known.

The Prototype design addressed these issues by using a distributed data ownership model in which each state organization or local government was responsible for the accuracy and completeness of its own contact information using a standard data format. This distributed approach to data ownership placed the responsibility for accuracy in the hands of those who have the greatest stake in data quality and are most likely to give it the appropriate level of attention. This approach to management of data content helped assure that the best quality and most timely information was available about each agency and jurisdiction. Centralized maintenance and management of the shared database complemented distributed data ownership, taking advantage of both technical and financial economies of scale.

Usability. Through the Prototype field test, we learned about four important aspects of usability: familiarity with standard office applications, user-oriented and content-specific help, adaptation associated with changing existing applications, and accessibility.

In terms of familiarity, the Prototype used standard browser technology as the user interface. Most aspects of the Prototype applications followed normal conventions for Web navigation, and testers were quick to point out frustration with the few instances where the Prototype departed from these norms. For example, the "back" button did not work as they expected in both the Dog Licensing and Contact Repository Applications. Rather than use "back" to return to a previous page, users were instructed to use the navigation within the page they were working on. While this is not unusual in Web applications, it was a surprise to some, and many disliked it. In another instance, one highly rated aspect of the Contact Repository Application was the ability to generate a mailing list from the database. However, this required an understanding of spreadsheets and familiarity with Microsoft Excel®, which was not the case for some users. The Help feature provided advice regarding this capability, but not everyone found it or found it useful. These two experiences highlight the need to adhere as much as possible to standard features of well-known software and to make certain that users are familiar with standard office applications that may be embedded in a Web-based service. For those who could not use Excel, or understand the Help associated with it, one of the most useful features of the Prototype was unavailable. And while the developers paid considerable attention to Help features, their ability to be comprehensive was limited by time and staff resources. A fully functional system would need more extensive, context sensitive help features.

We also observed that entirely new applications were easier to learn and more satisfactory to users than applications that changed familiar ways of working. This is not surprising since a process of "unlearning" has to take place as users adapt to a different version of an application they are already using. In the Dog Licensing Application, for example, some users wanted the screen to look like the paper form they use for this function. This need to adapt a familiar way of working for a new environment is an important consideration for training and support, as well as for gaining acceptance of the application. This concern is further complicated by the fact that many local governments have implemented different home-grown or vendor-supplied versions of the same application.

Finally, the Prototype was constructed using existing platforms and development tools. We made no special effort to build in accessibility features, but we did ask experts to review the Prototype and comment on its compliance with accessibility guidelines. They told us it met most basic requirements but was not fully accessible. For example, the Contact Repository Application and the Dog Licensing Application used color to highlight required data elements. In a fully accessible application some other cue would be needed to communicate this requirement to those who are blind or cannot see color. Full compliance with all accessibility standards would be necessary in a live system and would require additional development and testing.

Photo of Prototype users

Information policies. As with many technological applications, new policy questions arise because information becomes more readily available and accessible. While these core information policy components of an enterprise framework -- stewardship, access, security, and use -- were recognized as important by the Prototype Team and Advisory Committee, they were not developed in full detail for the Prototype. These issues would need explicit attention in any future G2G initiative.

The three Prototype Applications were selected because they represented local diversity, and the complex nature of state-local business processes. The fact that data sets were readily available to support them also played a role in the selection of the applications. During development, when issues concerning information policies arose, compromises were reached among the Prototype Team members that allowed the project to move forward. The compromises balanced the fact that the effort was a Prototype with the desire to provide the users with standard guidance for their activities. So, for example, we decided that certain data elements in the Contact Repository Application (such as cell phone numbers for elected officials) would be available only to the assigned data owners, not to other users. In addition, some information policy topics were not addressed at all. For example, records management was not addressed -- in a real system decisions would need to be made about what constitutes an official record of a transaction, which organization should be accountable for it, and how it should be accessed and preserved.

During the focus group discussions, one past policy issue was raised that deserves mention. During the implementation of DECALS, town clerks were asked to deny hunting and fishing licenses to applicants who were behind on child support payments. Because the information in the State's child support system could be matched to license applicants, child support payment arrears could be used to deny the license. Working through their professional association, the clerks refused to accept this responsibility, noting that they are not law enforcement officers and have neither the standing, the skills, nor the authority to act in this way. Instead, DECALS now prints a notice to the applicant that a license cannot be issued and gives a phone number for the applicant to call to resolve the problem. Because there are several reasons why a license might not be issued, the clerks simply direct the applicant to call the number. This experience underscores the importance of anticipating and understanding both the opportunities and the policy issues that can arise when information systems become more uniform and integrated.


The benefits of working in a carefully thought out G2G environment are amply demonstrated by this project. Moreover, the project highlights the realistic challenges of accepting and acting upon an enterprise view of government. These challenges include the need for joint governance, standard infrastructure, authentic identification and management of users, data quality and integration, usability, and some level of government-wide operational coordination. In this section, we offer some strategies that hold promise for addressing the challenges and reaping the benefits of this "better way of working."

State-local governance. Governance comprises the structures and processes by which policies are adopted and decisions made. For information systems and strategies to work well in a G2G environment, governance must include formal representation of the interests and needs of state, county, and municipal governments and active participation of both state and local officials. A key to successful joint governance is an acknowledgment that the participants are peers. Although their resources and responsibilities vary, each level of government and kind of organization must give and receive equal consideration to needs and capabilities of others. The existing Intergovernmental Communications Subcommittee of the State CIO Council, established in 2003, offers a suitable venue for pursuing joint governance.

Communication. Communication is one of the most important aspects of any collaboration, and the success or failure of a project may ultimately depend on how well a group communicates. Good communication practices ensure that all stakeholders (both those actively involved and those who will eventually be affected) are continuously and adequately informed. Just as important are good working relationships that encourage stakeholders to participate actively in giving and receiving information. Many techniques may be used to establish and maintain effective communication among project participants: status meetings, distribution of printed and electronic project materials, and formal presentations are just a few. Often one technique works better for certain audiences or project stages and quite frequently multiple methods need to be used simultaneously. It is equally important to communicate with a more general audience to keep the full community of state and local organizations apprised of developments that may eventually affect them in some way.

Business process analysis. Intergovernmental information systems are electronic applications that support processes shared across state and local levels. One important step in the development of such systems is the mapping, analysis, and improvement of business process by those who actually perform the tasks. Participants' own operations and program knowledge should describe the entire process. This is particularly important if the business process crosses several levels of government or departments within a government. During the project, application design clearly moved more smoothly and swiftly when a shared understanding of the business process was created.

While working through the early design sessions, the Prototype Team engaged in thorough business process analysis. Before embarking on discussions about technology, the people associated with each application collectively mapped their detailed processes from end to end (i.e., from state to local levels and back, including the roles and tasks of all significant organizational units). Drawing the detailed business process across both organizational and jurisdictional lines provided a visual confirmation and understanding of the intergovernmental information and work flows. The team members sometimes marveled at the amount of information sharing that took place during these mapping sessions. Many people learned something new about their everyday processes and understood more clearly why things were done as they were and why certain problems existed.

While mapping out the process as it touched several organizations, the Prototype Team determined whether all those who needed to be involved in the process had been invited to participate in development. If a process included a government, department, or organization not represented on the team, more recruiting was done to bring that missing perspective to the table. By engaging in this laborious but necessary work, all participants came to better understand their roles in the larger process.

Table 3. Findings -- Strategies

Necessary elements
Current issues
State-local governance
  • Formal representation of the interests and needs of state, county, and municipal governments n Active intergovernmental participation in planning and decision making
  • Emerging governance frame works need to be institutionalized
  • Multiple forms of two-way communication
  • Good practices need to be institutionalized
Business process analysis
  • End-to-end mapping, analysis, and improvement of intergovernmental business processes by those who do the work
  • Need to adopt group-oriented process analysis activities and tools as part of all intergovernmental initiatives
Field work
  • Joint state-local fact finding missions to gain an understanding of the wide variety of local operating conditions
  • Local officials need support for travel costs for this and other design and development activities that take them away from their own offices
  • Need standard protocols for conducting field visits
  • Realistic, iterative mock-ups of processes and systems as aids to design and understanding
  • Need more ubiquitous prototyping and related evaluation skills
Project management
  • Specialized project managers who create an environment for collaboration and use group-oriented analytical tools
  • More project managers need specialized training, tools, and support for these kinds of projects
Training and support
  • Initial basic training followed by in-depth ongoing user support services
  • Current practices tends to emphasize training over support
Complete cost structure
  • G2G projects need cost structures that identify all costs to all participants including project management, communication, design, development, testing, training, implementation, adaptation, operation,and ongoing support
  • "Soft" costs of project management, relationship management, and communication are high, but often not included in budgets
  • Adaptation of local practices can be a substantial cost, not included in financial or time estimates
  • Hidden costs occur when standardized state systems replace some high-performing existing local systems
  • Revisions of existing applications can have additional "unlearning" and "relearning" costs

Field work. Any G2G effort, whether at the enterprise level or within the confines of a single program area, should include joint state-local fact-finding field visits to a representative set of local organizations. These fact-finding missions are invaluable for gaining an understanding of the wide variety of local operating conditions. They are not simply meetings where people make statements or presentations to each other. Rather, field visits may take several days and entail following and documenting work-in-progress, interviewing front-line workers and supervisors, and gathering documents that illustrate and govern activities and decisions. Where possible, field teams should include both state and local participants. One key purpose is to understand and assess local practices and capabilities. The teams should also become familiar enough with both local and state needs to make recommendations about aspects of system design where uniformity is essential and where a local option is a sensible alternative. Field work is especially difficult for local officials to participate in because of the travel costs. While generally small, the costs still exceed local budgets.

Prototype. As with field work, prototyping presents the opportunity to gather realistic information about a process or system. An ideal prototype conveys essential functionality and solidifies mutual understanding. Its testing and use reveal differences in expectations, and suggest improvements in architecture and applications. Prototypes take a variety of forms. The Prototype in this project was quite elaborate compared to most because it was designed to illustrate and test several kinds of complexity. Sometimes a prototype is no more than a story board; usually it is somewhere in between with some parts actually programmed and others merely described. In all cases, a prototype entails testing an idea or theory rather than trying to build a "killer app." In the New York State-Local Internet Gateway Prototype, the applications were mostly functional, but more importantly, the process uncovered key factors in designing and developing G2G initiatives. The Gateway Prototype project produced not only a technical prototype. In a sense, it also prototyped an approach to project management and joint decision making and communication.

Project management. Many participants attributed project success partly to the fact that it was managed and supported by people with specialized skills and a set of well-suited analytical tools. We believe a similarly organized concentrated effort, focused on the "seams" that hold a collaboration together, will be necessary to sustain any future G2G initiatives. More specifically, this means having several individuals broker the communication and relationships among all the stakeholders including state and local government representatives, vendors, and advisory groups throughout the life of the project. The New York State Project Management Mentoring Program might incorporate special attention to the unique needs of these kinds of projects as it trains the next generation of IT project managers.

Training and support. Comprehensive user training attuned to actual business activities is a good start in preparing users for a new way of working. However, ongoing support services appeared to have a more positive effect on user acceptance. According to the focus group discussions, it was more important to couple a basic level of training with very strong support than to have comprehensive training with limited support. While training is useful and effective, most learning comes after one starts using an application regularly. Access to user support resources reinforces participants' willingness to learn and use applications.

Complete cost structure. Intergovernmental initiatives impose both one-time and ongoing costs at both the state and local levels. In an effort that moves from concept to full implementation, the majority of state-level costs would be attributed to design and development. Local-level costs would be centered on implementation and changes in existing business processes. Clearly, local officials must participate in the development of applications but, much more than state officials, they must often change the way they conduct their daily work in order to take advantage of new applications. In many cases, these adaptations are improvements over current processes, but in some cases existing local operations are more sophisticated and offer more value than a new statewide application. In these instances, it is important to explore ways to retain superior local performance while still adopting enterprise strategies. Without attention to this situation, some of the best-performing localities will suffer the hidden costs of reduced performance. Moreover, local participation in Prototype design and development required local officials to travel to Albany or regional sites. When necessary to allow local representatives to participate, CTG supported their travel expenses through the AT&T Foundation award.

Table 4. Estimated direct costs of the Gateway Prototype by cost category and type of participant

Cost categories2
State and local partners
Corporate partners
Category subtotal
Percent of total
Project management
$ -
Relationship management
$ -
$ -
$ -
Prototype design, development and evaluation
Information dissemination
$ -
$ -
Participant subtotal
Percent of total

Table 4 presents the Gateway Prototype cost estimates that we were able to document. In all, the project cost about $950,000 in cash and in-kind resources. As the table shows, the costs of hardware and software (8 percent) were dwarfed by the "soft" costs of project management (14 percent), relationship management (8 percent), and Prototype design, development, and evaluation (58 percent). The cost of information dissemination (12 percent) is in addition to the communication costs embedded in project management. Project management responsibilities were shared by CTG, CGI, and Keane. The category of relationship management was mostly comprised of initial and ongoing engagement of local participants by CTG staff. User testing, field testing, and subsequent data analysis are all included in the evaluation portion of the Prototype design, development and evaluation. Information dissemination includes the preparation of reports, state and national presentations of project results, and preservation of the Prototype. Most of the state and local partner costs are attributable to local participants. In a regular project, the CTG share of total costs would most likely be borne by a lead state agency.

The distribution of costs documented in this project can serve as a guide for any future G2G initiative regarding the relative concentration of costs during design, development, and testing. The Gateway Prototype project ended with evaluation, so it does not include estimates related to refinement, implementation, or operation.