Want to build A GIS? The proof is in the prototype
Russell D. Chandler President, GeoData Solutions, Inc. 8620 Wolff Court, Suite 250 Westminster, CO 80030 email: rchandler@geodata-gis.com http://www.geodata-gis.com Abstract As AM/FM/GIS platforms have matured into their “next generation”, it is now much easier to create a working prototype AM/FM/GIS system and realize significant benefits in just a few months. Nothing generates more ideas and eventual corporate buy-in than real, working, demonstrable applications. This presentation will describe the process of identi~ing, defining, and developing fast return applications of an AM/FM/GIS system. A few case studies within the electric, gas, and telecommunications industries will be discussed. Introduction Essential to building a top notch AM/FM system is obtaining sufilcient tiding as early as possible. In this age of competition, justifying large expenditures strictly on the basis of cost benefit analyses, which are often very drawn out, is becoming increasingly more difficult. Cost benefit analyses are not inexpensive. In the end, what you windup with is lots of paper, nice slide show presentations, but very little benefit to actually demonstrate. As AM/FM/GIS platforms have matured into a “next generation”, it has become increasingly easier to utilize limited “investigation” budgets to actually create a working prototype AM/FM system that can realize a significant return on investment in just a few months. Where Should I Start? Where one starts is to a large degree dependent upon where the main user sponsors reside in the organization. On the one hand, efforts to build comprehensive, integrated GIS, driven mainly by the information technology group, often fail. On the other hand, when individual user departments have moved toward automation on their own, the goals have usually been too narrow and the tools too specialized to allow for future integration and efficiency. It is by now obvious that the more integrated and automated the technology processes within an organization are, the more efficient, cost effective, and competitive the organization can be. Visionaries among us realized this quickly and in many cases were given the opportunity to embark on this venture. Unfortunately, the venture was premature. The tools were too primitive and the organizations unready to meet the challenges. One thing that we learn very quickly in large organizations is that it is very difficult to get everyone to agree on things. In the past, it was necessary to bring several departments together and perform a long, detailed analysis before attempting to develop any software. Struggles over symbology, dictionary definitions, and departmental roles in the GIS would often paralyze the development, and result in splintering. 86.~ilecomprehensive approaches have ftiledor haveusually noteven beenseriously attempted (smart), theneed fortechology wittinthe userdeptiments hasintensified. Thetendency has been toward most of these departments spawning their own CADljob design systems, map production systems, home grown analysis programs, and entirely independent outage management systems (reality). This has resulted in increased automation for the individual departments, but has not introduced any real organizational efficiencies. Redundant database maintenance activities continue to persist, just as they always have. The lesson here is that in order to achieve true success in automation, the drive toward GIS in the company needs to come more from the users of the system - not the information technology group, and not even the mapping department, but the engineering planners, designers, and operations personnel. Without one of these departments driving the process, it will be prone to failure. Fundamental to the early success of a GIS project is how responsive it is to its initial charter. There is no point in trying to build an all encompassing system if the needs of the primary users are not met. Likewise, when building a GIS from the ground up, the overall vision for the organization should not be neglected. Just do Ittm From this point forward, I will proceed on the basic assumption that GIS technology is a keystone for the organization. Most organizations do not have the time nor the money to spend these days to try to justi~ it to the masses. Instead of spending the limited time and budget available on an enormous and politically risky effort to justi~ large expenditures, it is better instead to take advantage of the opportunity to prove something first. Limited cost-benefit analyses are useful, but for the same costs, a working system can be developed and implemented using the newer technology available today. Here are the basic steps to building a usefid, working prototype in a short time: Step 1. Briefly Identify Users and Applications and Pick One to Start Step 2. Gather Basic Requirements Step 3. Data Model with Awareness Step 4. Prototyping: Designing on the Fly Step 5. Implement the Imperfect Solution Step 6. Take the Show on the Road Step 1. Briefly Identifi Users and Atmlications and Pick One to Start It is not worth spending too much time and money identifying/justi@ing applications to the organization. The general “big ticket” application areas of GIS are well known: planning, design, and distribution automation. The primary applications within these main groups are network analysis, job design and estimation, work management, outage analysis and dispatch, and business geographic analysis. Notice that automated mapping was not listed. Mapping and database maintenance, however, is still a good entree application and therefore a good candidate for prototyping. The requirements fortheoverdl system, however, should not bedriven offtieneeds of mapping. Instead, the mapping function should be redefined as the corporate GIS database maintenance function. At this critical stage in the project, short and long term goals must be balanced. If the eventual goal is to build a GIS to support the entire organization, two things must be considered. First, the system must be able to support your immediate departmental needs, and quickly. Second, the system (or at least the data model) must be designed to support multiple finctions in the organization, longer term. Essential to success with this approach is to use the correct technology. It is best to avoid tools that are too specialized or software platforms that were designed originally to support narrow fimctions. The best way to achieve long term success is to adopt a platform that has an object-oriented language built-in and some kind of case tool to better enable data modeling. It should be based on a strongly integrated, open architecture approach. Most importantly, the system must support rapid application development. Obvious bias aside, it is also best to utilize a consulting organization that has had experience implementing applications on the platform and can quickly develop andlor customize software modules. To achieve the short term success necessary, it may even make sense to build a throw away data model and application to start, while developing the longer term solution in parallel. Also, it is critical that the application chosen can fmction with the available data sources. Applications cannot function without the necessary database to support them. Fortunately, in most organizations today, it is usually easy to identi~ existing digital data formats (from a legacy CAD or GIS) that can be fairly quickly translated into the system. If no such sources exist, it will be necessary to construct a pilot database from maps or even field inventory efforts. These efforts, however, have also become much faster and inexpensive. Step 2. Gather Basic Requirements of the Initial Atmlication The first essential phase in a development project is to gather the requirements of the application. This could be done in as little as a week. The key elements here are: the availability of a knowledgeable and insightful subject matter expert (SME); that the design team remains disciplined enough to keep the focus of the application sufficiently narrow while still achieving significant benefit; and that the requirements are documented clearly and concisely. The result of this phase should be a basic, first cut, functional design. The design will naturally evolve as the prototyping begins and both the SME’S and the developers become more educated. The fictional design document should be a working document. Step 3. Build a Basic Data Model but with Awareness The first cut of the data model should be as simple as possible while still supporting the necessary fmctionality. If existing data resides in a CAD or legacy GIS that must be converted, considerations must be made in the data model to enable straight forward translation and use of this data. The critical factor is that all of the essential elements of the network are captured and that a connective, topological model is defined. It should be maintainable by an operator with minimal software customization and application complexity required. Mapping requirements may dictate additional complexity to support graphics at a variety of map scales. This type of complexity is best avoided at the beginning. If mapping is required, as it usually is, focus should be put on one product, usually the underground location map (electric), gas distribution map, or strand map (telephone). This is mainly because of the relevance to designers who are accustomed to these map views. The data modeling step is one of the most critical steps, but decisions made at this stage are not irreversible. It is very important to stay disciplined during this phase. Problems can be fixed later, even after data has been translated or converted into the system (provided that the platform chosen easily supports model changes on live data). Once again, keeping both discipline and balance is important. Perfection of the data model is absolutely impossible, especially at this stage. Once the first cut of the data model is complete, it is possible to move onto the next stage. Making repeated changes during the data modeling stage before full prototyping will not save any time nor avoid inevitable changes in the model. Further tweaks can occur throughout the process, but do not necessarily provide immediate benefit and will hamper data conversionkmslation efforts. It will be necessary to defer major data model changes until after a working prototype has been completed and implemented. Step 4. Prototwirw and DesiminR on the Fly With the advances in graphical user interface (GUI) tools and object orientation in recent years, designing a system while developing iterative prototypes has become more feasible than ever. Furthermore, with object orientation, it is realistic and, indeed preferable, to utilize existing software modules in the development. This will greatly speed up development, provided that the software modules developed or used follow all of the rules of object orientation and are not too closely linked to a specific data model. It is important that the development team have experience with object-orientation. Another key to building a successful prototype, which will also be essential in the later stages of the project is to involve the SME’s early in the process and frequently throughout the development. The SME’S will be able to provide significant input, especially once they have had an opportunity to become familiar with the software platform and its capabilities. They will most likely take ownership of the software and will become champions for the project across the organization within a short time. The only caution here, again, is that the team remain disciplined. The system does not have to be perfect at this stage. As new requirements surface during the prototyping (as they inevitably do), they should only be incorporated if they bring significant pay back for the system and do not derail the schedule or budget. The system should be made to be easy to use, but “bells and whistles” should be avoided. All through the prototyping phase, the functional requirements can be fiuther refined and a complete system design created. This system design will become the basis for the full system, and should encompass many aspects of the prototype and its functionality. Also, while the prototyping phase continues, the system’s network infrastructure can be set up and the base software platform installed. Preliminary “work in progress” versions of the prototype can be installed at designated user sites and fimther SME involvement and feedback solicited. It is also important at this stage that a system administrator (or systems support group in larger organizations) be identified to develop and support the computer network. It is preferable that this fi.mction be integrated to the project team as opposed to being a part time fi.mction from someone elsewhere in the organization. Additional training on the software platform and its tools can also be undertaken. This will enable the support group to be well positioned to support the working prototype while the fill system is under development. Step 5. Imulementin~ the Imperfect Solution Once the prototype has been reasonably system tested and is completed sufficiently to a “version 1.0”, it should be straightforward to implement the system, initially with a set of “seed” users. The system implementation will proceed more smoothly if the infrastructure has already set up, during the prototyping phase. Adequate training and understanding of the system by its intended users are essential. The SME’s should be trained first, even prior to application development. When the application is ready to roll out, the SME’S should be able to play an active role in, if not teach, the training. They should also be heavily involved in, if not develop, much of the user documentation. Once the prototype has been installed, and is in actual use, there is likely to be significant feedback (if not, then something is wrong and the system is not being used). This feedback is crucial to the long term development and needs to be incorporated into the design and communicated to the development team immediately. Ideally, even after first implementation, the prototyping should be allowed to continue and incremental deliveries of more advanced functionality scheduled regularly. In many cases, the development and implementation can happen concurrently with each providing input to the other. Step 6. Taking the Show on the Road while Imtmoving or Redevelopiruz it Once a working prototype GIS application has been installed, there might be a temptation to call the system complete. After all, if the original charter has been met, even at the most basic level for the specific department that it was intended for, it may not be critical that the system be enhanced further and extended to fbnction throughout the organization. Realistically, from the project manager’s perspective, it might be the right time to move on and turn the system over to support. If the vision, however, is to extend the technology throughout the organization, and not only automate but introduce the real efficiencies of integration, there has to be corporate buy-in. Furthermore, this was only a working prototype, which was developed in a relatively “quick and dirty” fashion. To get the additional fhnding needed, however, it will be necessary to demonstrate the immediate benefits that were achieved through implementation of the prototype. The best way to achieve this is through marketing of the system and the vision throughout the organization. There is often a significant sales effort necessary to get a GIS project started in the first place. The selling will become much easier once a working example can be demonstrated to high level management across the organization. This is the best way to secure the additional funding that will be necessary to extend the prototype into a fully developed system. Meanwhile, provided that funding is immediately available, rework to the prototype (or even complete replacement) can be undertaken, and iterative deliveries scheduled. All of the data model changes, higher priority application enhancements, and even many of the lower priority enhancements that were deferred earlier can be introduced into version 2.0. Pitfalls to Avoid The biggest pitfall to avoid and the one most often encountered is not controlling scope. The best way to avoid this, as I have repeated throughout this paper is discipline and reassurance that the system does not have to be perfected the first time and that there will be time later for improvements. Another pitfall, once the working prototype is developed, is not treating the prototype as such. It may be very well worth performing a full overhaul on the system to reduce the longer term maintenance costs of the system. If the data model is flawed, this is the time to correct the problem and rewrite applications, as necessary. The beauty of prototyping, designing on the fly, and object orientation is that you never really have to throw away everything. Finally, it is important to use small development teams. The familiar adage that you cannot speed up delivery of a baby to one month by assigning nine women is painfully true. Furthermore, to use another clich4, too many cooks spoil the soup. Small teams are much more manageable and effective than large ones. An experienced software development team should require no more than twelve people. Examples Following are three real world examples that show where rapid prototyping has been utilized to realize quick, fast return, high visibility results early in the GIS project life cycle. Case 1. Lame Electric Utility At a large northeastern U.S. electric utility, many of the techniques described in this paper were employed to great success. Upon selection of a GIS platform, the project team immediately embarked on a rapid prototyping effort that involved creation of a throw away data model, utilized existing digital data sources, enabled the support team to become experienced quickly, heavily involved the SME’S, and made several incremental deliveries in the span of just a few months. The system was installed at several remote planning sites and, though it was only simple application, paved the way toward user and organizational acceptance very early. Simultaneous to this effort, much of the core functionality was developed and much of the feedback from the prototype system was incorporated into the functional design and core development. Likewise, much was learned by the development and support teams during the prototyping phase and many of the software modules developed for the prototype were able to be reused in the core system. The end result was one of the most robust, working AM/FM systems implemented to date. The championing and marketing of the system and its concepts throughout the organization have ensured that the AM/FM system will not only be used to automate but that it will also be able to introduce real, cost-saving efficiencies to the organization as a whole. Case 2. Medium-sized Gas Utilitv At a medium sized gas utility in Canada, in the span of only a few months, the company was able to implement a working map maintenance application for their drafting department. The system supported the complete life cycle of gas distribution facilities Erom the time of a “main extension request” from marketing through to the point where facilities are abandoned. To reduce the up front time and cost of data conversion, their distribution maps were scanned and raster images utilized as a backdrop. The success of this project has been due, in large part, to the fact that this application was rolled out as the first of several small self-contained phases, rather than as a whole. It was also made more successful due to heavy involvement by the users of the system, throughout development. Application development was further enabled by use of a GIS platform with a filly fictional object-oriented language. The project came in under budget and was able to further justifi itself on the basis of this success and the degree to which the technology could be used to enable additional functions that were outside of the engineering/drafting group. Case 3. Telecommunications Commuw A northeastern U.S. telecommunications company was able to develop a working prototype of a broadband engineering design application in less than six months. This was made possible through the use of very intense prototyping and “designing on the fly” that allowed for maximum flexibility during the development phase. This resulted in a surprisingly robust initial application that might have, under other circumstances taken ten times as long. Conclusion It is extremely difficult in today’s fiscal climate to justify large expenditures on GIS technology on the basis of cost-benefit studies alone. With the advent of object-oriented GIS technology that enables rapid prototyping, the existence of many existing digital data sources, and scanning technology that allows paper maps to be quickly brought into the system, it is at last feasible to build working GIS applications from scratch in a matter of weeks where it once took years. Prototyping and rapid implementation of a “quick hit” high visibility application very early in the project’s life cycle is the key to both early and lasting success for a GIS project. The corporate buy-in and extension of the system to other departments in the organization that results will ensure that the necessary support for the system will be kept up for many years in the fiture. Most importantly to the visionaries among us, there is the satisfaction of knowing that we were able to make a difference that actually saved the organization and its customers money and helped to make the operation more efficient and therefore more competitive in the marketplace. References Phillips, Larry, “Eliminating the Multi-Year Nature of AM/FM Projects”, AM/FM Proceedings 1995. | ||
|
|