The idea that one day we will be able to integrate many types of data across an enterprise is seductive. It is common sense; it meets myriad business needs. But despite much effort, the vision has remained tantalisingly out of reach.
This paper reviews the effort in South Australia, where for more than 12 years, departmental officials have pursued this vision.
The first attempt at data integration in South Australia was the 'Hub Concept' of the South Australian Land Information System (LIS) in the late 1970s. The next step was the AURISA award-winning 'LIS Nodal Concept' in 1982. Both foundered on the inability of the technology to deliver the results it promised.
In 1991 the technologists in charge of the state's Land Ownership and Tenure System and the Digital Cadastral Data Base began developing a data access and delivery tool that became known as LISA (Land Information System Architecture). Initially it was focused on delivering GIS-friendly data from the Legal/Fiscal and Geographic LIS nodes.
LISA was designed as a series of network services, database services and application systems within an open system framework. The data delivery environment provided by LISA connected users to data suppliers in a transparent and seamless manner. In addition, by 1993 LISA was able to demonstrate ArcInfo and Intergraph interfaces to its potential users.
But a prerequisite for LISA was the storage of the source LIS data in LISA-compliant databases. This meant data had to be converted at significant cost. A positive business case was not found, so LISA never moved from a pilot to a production system.
In 1996, the South Australian government developed a vision under which the state's spatial information industry would become a recognised centre of excellence. Two of its objectives were using spatial information within government and the South Australian economy to achieve better processes and to promote development; and providing community empowerment through improved access to government data.
Both required the means to better use spatial data. To satisfy this need, the Spatial Information Integration Services (SIIS) project was initiated. SIIS had two development objectives: a data integration and delivery infrastructure, and a technology that would be internationally marketable. The close match between the aims of the project and the government's industry development goal meant that considerable funding was available. Through the development of a system incorporating some of the broad concepts of LISA, but with the ability to access data stored in a diverse range of formats, the first of these objectives was achieved by July 2001. However, as this technology was delivered some two and a half years later than expected, the opportunity to market the product internationally had been lost to other commercial offerings. Although the data integration and delivery infrastructure was operational, it required some further development to fully meet the needs of users, who (aware of the commercial situation) made little operational use of its capabilities.
Andersen Consulting were engaged to determine the viability of any further development of the SIIS technology and to develop an action plan to progress the project should any justifiable developments be identified. Their report, delivered in December 2001, reasserted the need for a data integration capability for the state but recommended that there be no further development of the SIIS project.
With a broader range of data in its sights, the Integration Services Project (ISP) was established in September 2002. The ISP confirmed the business needs articulated by Andersen, documented the data access and data integration needs of state government agencies and produced an information technology architecture that both recognised current technology constraints and was open to the maturing of web services technologies.
The funding for this project was in two parts: sufficient funding to develop this capability was provided, with the understanding that users would fund its ongoing operations. However, the user agencies soon indicated that they were unable to fund their use of the service, and the ISP closed in February 2003.
There are some common threads that can be teased out of this history. In the beginning, projects were conducted within an immature information technology environment. This led to concepts and operational issues not being considered, or pursued. But by and large, the barriers were not technical.
The concept and drivers for LISA came from the technologists managing and developing the state's land administration systems and the delivery of land-related knowledge products. From such a perspective this was a justifiable research and development activity. Support for this development also came from the technologists in other agencies who were developing and maintaining spatial systems, but that support never percolated up to senior executive level.
The SIIS project, on the other hand, was conceived in a supportive environment created by an IT-aware premier, with a government eager to work with the private IT sector. In the mid-1990s, this environment of optimism and grand visions included an understanding by senior ministers of the value of spatial information and its associated technologies. SIIS came to grief, however, over the inability of state and private sectors to find a mutually satisfying model within which to work.
The ISP, our third model, was brought to a halt by inter-departmental rivalries. The project gained the support of the state's spatial technologists, but most agencies chose to fund their own existing services rather than an additional and unproven service.
One conclusion from all this is that the same result has come from projects driven by technologists, ministers and senior bureaucrats. Furthermore, it doesn't seem to matter whether private or public sector expertise drives the project.
What then are the common elements in all three projects that have led to the same disappointing result? Apart from the final attempt, the primary focus of the earlier projects was on the development and deployment of a data access, delivery and integration tool. For these projects, the failure to have the administrative environment for the deployment of the promised tool in place led to project failure. This result reflects a focus on the technology by the champions of the project. Further, project leadership was in the hands of spatial technologists, who value these technologies because they think the technology can address the issues frustrating them in their roles.
However, if the faithful are to enjoy the fruits of their labours, they need to be attentive to the needs and values of the 'spatial sceptics'. For many of the spatial faithful, the archetypical sceptics are the resource-controlling executives. It is these sceptics who challenge and denigrate the work of the jurisdiction's faithful.
One conclusion is that rather than relying only on the true believers to direct and populate projects, the project teams should also include sceptics.
A second conclusion is that a data access, delivery and integration tool will not produce an operational system. Rather, the primary issues to be resolved are the administrative arrangements that serve the business needs of the organisation.
These arrangements include an approved and rigorous business case that has the support of the users of the service. It needs a project management structure committed to ensuring that the project will deliver the benefits identified in the business case, and, naturally enough, a commitment by the enterprise to ongoing funding for the service.
The ISP had its primary focus on seeking to resolve all these issues. In this quest the project successfully gained agreement on every one of these items except a commitment to the ongoing funding for the service.
This experience is not unique in industries where major projects consume significant resources over many years without delivering the expected product. There have been equally spectacular failures in private sector projects. Research and analysis of such failed projects has identified a common basis for their failure.
The root cause identified by this research begins with the seductive appeal of collective belief. This collective belief in the expected product is so strong that it is not shaken by project setbacks.
This belief begins with a few individuals who are convinced that the project will succeed. Then, should the ultimate success of the project be greatly desired across the enterprise, the belief becomes contagious - and collective.
Once the collective belief takes hold, it tends to perpetuate itself. Dissenters are drowned out, to the point where they stop raising their concerns. The true believers drive themselves harder and harder when setbacks occur, and exhibit 'technological relentlessness' in their search for a workable solution. Given the emotional intensity of the true believers, this kind of passionate behaviour is not surprising.
As a consequence, managers suffer a form of blindness in assessing the project's performance. The persistence of their collective belief undermines basic organisational procedures and safeguards. There are lenient project reviews. Control becomes almost nonexistent.
There are two safeguards that can be put in place to avoid these dangers. The first is to avoid cheerleading squads, and the second is to establish an early warning system within the project control processes that is very carefully defined and very thoroughly enforced by the organisation.
One of the dangers inherent in a project team is that all too often the group is self-selected. People volunteer when they share the initial enthusiasm and are excited by the project. While you need people who believe in the value of a project, you also need to include sceptics from the outset.
Unless sceptics are included, the team will ignore any warning flags as they all cheer for what they believe in. The creative tension between the true believers and the sceptics will drive the project towards the objectivity required for success.
An early warning system is essential. It needs to include criteria for evaluating the progress of the project. These criteria need to be rigorous and clearly defined, and then they need to be used. If the project fails the evaluation, it must be either revised - or closed.
When a project has begun to deliver its early products, it is time to introduce an exit champion. The role of the exit champion is to gather the hard facts that remove any ambiguity about the success or otherwise of the project. It is important to note that an exit champion is not sent by senior management to kill a project. The role of the exit champion is to provide the objective assessment necessary for continuing senior management support. Hence an exit champion's role complements that of the project champion.
Collective belief is not a barrier to project success. If the project protagonists do not believe in it passionately, it has little chance of success.
However, the challenge for managers in a 'can do' culture is to distinguish between belief as the key driver of success, and belief as something that warps judgement. This is not easy, but the good news is that experience has given us some tools we can apply to test ourselves.
The Holy Grail of the spatial information true believers may yet be grasped, but only if we enthusiastically engage the sceptics and embrace the use of standard business process controls to establish and monitor our projects.
Allan Barnes
