GIS implementation at Provgas
Robert Ringman Providence Gas Company 100 Weybosset St. Providence, RI 02903 Telephone: (401) 272-5040 ext. 505 Fax: (401) 781-0638 E-mail: bringman@provgas.com Tom Gavula Providence Gas Company 100 Weybosset St. Providence, RI 02903 Telephone: (401) 272-5040 ext. 521 Fax: (401) 781-0638 E-mail: tgavula@provgas.com Introduction The GIS project at ProvGas has a long history as these projects typically do. In the early 90's a needs assessment was completed and the company was poised to begin a full-blown AM/FM/GIS project. Then as other needs within the company began to beg for technological solutions the brakes were put on the AM/FM/GIS project until consensus on priorities could be determined. Eventually that consensus pushed AM/FM/GIS to the bottom of the list. Finally in 1997 to timing was right and the AM/FM/GIS project was approved. Originally mapped out as an aggressive five-year project it was finally approved as an even more aggressive four year project due to be completed in 2001. The paper records being converted dated back to the mid-1800's. Information from those records had never been consolidated onto any kind of map sheets. Twenty-five different paper files were identified that contained different information about a facility. Much of the facility location information was in hand written descriptions and lacked any kind of graphical sketch. Records of abandoned facilities were mixed with active facilities. Gas main segment information was filed by date installed rather than by street. As bad as it was the users had come to understand the idiosyncrasies and deficiencies in the existing records and unconsciously developed ways to deal with and compensate those issues. They were anxious for the new technology but assumed that all the paper records with inherent errors, problems, and deficiencies would be fed into one end of the conversion black box and perfection would come out the other end. The reality is that in the end they do not see all the errors that did get fixed during conversion but they do see all the errors that remain or were created. Managing their expectations plus the added workload created during the transition from the old to new systems/processes was the major challenge of the project. User expectations and how we managed them Communicate, communicate, communicate; it's all about communication. Consider using communication mechanisms that include verbal, written, graphical, hands-on, listening, and participatory methods. The following are examples from the ProvGas project and how each was used: Monthly Executive Reports - Used to update the executives on project issues and status but also distributed to the project team and end users. By letting everyone read what was going to the executives there was no suspicion of any hidden agendas. Special notices - Used to notify end users of critical process changes. Notices were numbered and dated. AM/FM/GISette - Monthly general communiqué regarding the project status, user tips, up coming changes or events, etc. Users could contribute small articles to this publication. Wall Maps - Showed users what cities and towns were in the system and could be used in various processes. Provided information on overall status of data compilation, data QA/QC, and data deliveries. Policy/procedures document - Documented how various processes were to be performed before GIS, after GIS and in transition period Legend - Explained all the symbols that appeared on the maps How-to instructions - Simple instructions for users to perform specific functions Customized training manuals - Various levels of software training manuals customized with our data model & data Process flow charts - Showed new process flows so users could see where they fit into the picture. We livened up flow charts with clip art and identified specific individuals and vendors and specified exact roles of each person. This provided everyone with a clear picture of where they fit in and who was accountable for what. Company newsletters - General company communication that would contain periodic articles relating to things going on throughout the company. We made it a point to get frequent project related articles in the newsletter. Appreciation letters - Personalized letters of appreciation for individual's contribution to the project Weekly meetings - Meetings with project team, and key user groups to obtain status, get feedback and make decisions. Informal conversations during break times or while people are working also are extremely valuable and often less intimidating to people. Issues database - An access database accessible to everyone for documenting issues that they feel need to be addressed. It also showed priority and status information. Signs, stickers, stamps - Provided employees with information on the status of the old paper files. Graphs - Spending vs. data delivered, cost per service converted each month, data delivered vs. time, etc. Meeting minutes - Documented meeting discussions, decisions made, etc. Training room - Provided an area for formal training, informal practice, and demonstrations. Team survey - Allowed team members and non-team members to grade numerous aspects of the project team performance. E:mail - Day to day changes, notices, updates, tips, solutions to issues, data deliveries Lunches - celebrations of milestones, team building Data quality issues and how we dealt with them If only it were as simple as handing a vendor your records, getting them converted and then putting your new system into production. Nothing could be farther from reality. The simplest things end up being not so simple. Every conversion project is different so you really have to tailor the process to your particular needs. A lot of the general things to consider that are mentioned here will probably apply to most project. Our project involved the creation of our initial GIS from paper records, which dated back to the 1800's. We had a vector and orthophoto landbase developed from aerial photography. The major steps of our process to keep it very simple were:
Landbase We had a new vector and digital landbase developed from aerial photography. The RFP, part of the subsequent contract document, identified for the vendor the specifics of the deliverables. From that information the vendor was able to develop his own QA/QC processes. We then contracted out much of the QA of the landbase to another vendor who checked the aerotriangulation reports, ground control reports, ran automated routines on the vector data and visually inspected the digital orthos. One of our own employees compared the digital orthos to the vector files to check for streets and buildings that may have been missed during digitization. Data Compilation Data compilation was our process of consolidating the information from many disparate original records onto 1" = 40' map sheets and documenting the attributes of each item of plant for future conversion. The first QA/QC step here involved a detailed set of compilation procedures so that all compilers were on the same page. To be honest, this was a constant battle that took us forever to win. There was such uniqueness to our original records that new things kept coming up and new rules established. Just making sure that everyone received, understood and remembered each new rule was a chore. If we had it to do over again we would have created specialists rather than trying to have everyone learn everything. After compilation the map sheets were passed on to a QA team. They checked the work and would coach compilers who were struggling. Having these two groups working in the same room facilitated the feedback that was invaluable to continuous improvement. Data Conversion Here again a very detailed RFP and contract are critical. Assume nothing. Assume that you have to tell the vendor exactly everything that you want and expect because you do. No matter how experienced the vendor, do not fall into the trap of telling yourself that he knows what to do. Based on the information you provide regarding your expectations of the end product, as well as what you indicate your own QA process will entail, the vendor will develop his own QA/QC process. Visit the vendor; have him go through his process step by tedious step and try to shoot as many holes in it as you can. Each hole is a problem that will come back and bite him later. Insist on detailed documentation of his processes and some kind of verification and/or sign-off that he performed each QA/QC step with each data delivery. You will also need and effective feedback process so that issues you identify as the project proceeds result in the appropriate QA/QC process changes. "Final" Quality Assurance First of all, there is no such thing as the final quality assurance step, at least not on our project. We employed the services of a separate vendor to handle the final quality assurance prior to data being delivered to us. Details of what will be checked, how it will be checked and what is acceptable for data to "Pass", all needs to be established up front. It will take quite a bit of negotiation with all the parties to come to agreement on how acceptance will be measured. We had three general levels of in the QA process, cursory, automated and random. The cursory looked for more glaring errors. Automated naturally were things that could be checked programmatically. Random was a detailed manual check of a random sample of data. Each had its own acceptance criteria. An effective feedback process between the conversion vendor and QA vendor is critical. Data "in Production" When is the data ready for production? What is production? Maybe it is ready for use in certain processes but not others. We found a wide range of data quality. Data delivered early in the project left more to be desired than data delivered late in the project. Every group involved in the project process needs to learn as it goes along and improve its processes on the fly. Consequently, we needed to make sure our users understood that there would be errors in the data. GIS acts as a magnifying glass for errors. Errors that existed for years in your old paper records are now displayed for all to see. It's like hanging out dirty laundry. It is a pay me now or pay me later situation. You can drag out your data conversion and make sure that everything is perfect (impossible) or you can take a best effort approach, get data "in production" quickly and be prepared to address the issues as you discover them. We had a very aggressive timeline and took the approach that we learned from a gentleman at Texas Utilities. His philosophy was, "sooner is better than better." Better to have an early deliverable than to spend forever trying to make it perfect prior to delivering anything. But, be prepared to be addressing data quality issues long after your conversion is done no matter what approach you take. Here are some of the things we did to improve data quality after data was put into our production system: Auto-fix, Auto-find We identified as many issues as we could that could be addressed programmatically. In some cases code could be written to find and fix certain data issues while in other cases the code would only find errors which then had to be manually addressed. Empower Editors to Fix Errors We allowed the personnel who were charged with entering updates into the system to improve what they saw wrong. This is a tap dance between giving them too much rope & not enough empowerment. We tried to give them a lot of rope and then coach them on the types of things that were beneficial to fix vs. those that were more cosmetic. Utilizing Users We identified users who would utilize the GIS for specific job functions and had then review that specific data. This gave them hands-on training on the new system while at the same time improving or verifying data quality. They were then more confident using the system for their specific application because they had verified the data. Concentrate on One Process at a Time One of the first areas of duplication we wanted to eliminate was in the maintenance of our smallscale system overview maps (1"=400'). We had someone do a final comparison of the old maps vs. the new system just to verify that all gas mains and main valves were accounted for. Once that was done we could then stop maintaining our old paper overview maps and strictly use the GIS even though at a large scale the GIS may not have been correct. Field Checks We got outputs from the new system into the hands of our personnel doing mark-outs for Dig Safe (Our One-Call System) as soon as we could. They were instructed to mark up those plots with anything they discovered that needed correction. Our biggest problem here was and still is our lack of resources to handle the edits. Until we get further along in eliminating duplicate work our editors will continue to struggle to keep up. GPS We began using GPS to help gather data on new gas main installations. We hope this will cut down on the time our editors spend in getting new main geometry into our system. Of courses now we need a resource to operate the GPS unit. We are still experimenting with this process. Alert Rather Than Fix We have instituted methods that will alert users about potential data issues so that they can then use the information appropriately. One example of this involves the structure outlines on our landbase. Structures placed in an approximate fashion by our editors are distinguished, via symbology, from structures that were digitized from the aerial photography. Another example is a "confidence level" attribute that we use as annotation on certain objects. This gives users information about what data was verified by employees after data was in production, and what data was questionable even before data conversion. Orthophotos When used as a backdrop in our GIS these allow users to identify places where the service pipe locations in our GIS may be in error and require further investigation. The location of service lines was most often given as a dimension from the edge of the building. By convention, on residential homes our field personnel would take that dimension from the main body of the house and not from the side of the attached garage. On our vector landbase you cannot tell from the building outline where an attached garage might be so the service could have been converted with dimensions from the wrong place. Orthophotos allow users to see driveways and identify garages and catch errors that may have been made during the compilation process. Functionality issues and how we dealt with them ProvGas took the approach of keeping things as simple as possible initially. We did not go crazy trying to figure out in advance what all the users' needs would be or what applications we would need. We kept our data model simple to start with and did very little customization to the software. No matter how much time you spend planning how you want the system to work you will never get it right anyway. These projects are so long in duration that by the time you are done data conversion things will have changed. Better to keep it as plain as possible, get the data in, get used to the basic system and learn its capabilities and limitations for a while. This gives the users a better understanding of how the core product really works. After everyone has had a chance to play with it you will have a much more definitive answer as to how you want or need it to work to meet your needs. In our case there were two software upgrades released by the vendor before we completed data conversion. Functionality that we might have customized at the start of the project was standard in the core product by the time we were done. Transitioning from paper process to GIS Issues faced and our plan of attack It is essential to put together a rollout team/plan prior to getting your first data back from conversion and into production. A 'SME'(subject matter expert) should handle the critical transition phase with you drafters, researchers of distribution information and other end users. From 'day-one' when the first GIS info is accessible, there needs to be constant interchange and oversight as initial opinions get formed from "1st CONTACT" with GIS. Original team members who were involved in the determination of system parameters, critical data capture, etc., should be interjected in the daily process of 1st Touches with the GIS information. They can explain why some data was not captured at this time, but that eventually modifications could or would be incorporated to do that, such as corrosion data, historical leak data. As we have found in our implementation of GIS for mark-outs, the expectation to wait for GIS to be perfect never goes away. But with some hand holding, you can get by this and see how they begin to appreciate the power of the tool. They will be requesting it for areas not even ready for field utilization, just because it gives them a 'big picture' they never had the advantage of before, except for intersections or other special drawings created for complex areas. Let them have the GIS information even for areas not rolled out yet. It creates a momentum of acceptance that will allow the project to speed on its way. Our GIS roll-out team all volunteered to ride with the linewalkers as we began the field utilization part, to see first hand and show the commitment and concern we have for the project. Sampling 25-50 cases in the field to compare accuracy of GIS as compared to previous mark-outs completed, especially gave the roll-out team members a sense of confidence that it was READY for use, and would only get better as time went on. Our plan was to implement GIS on a town by town basis as it was ready to be used. This will create a multitude of problems with defining used for what???, and how???, and when???, and where????. As a famous person once said," success is in the DETAILS". You need to look at your project plan, and go over just how GIS versus paper will be utilized, and define the new processes for researching distribution records as you implement the project town by town. We made the assumption that we would archive records quickly in the plan, as we put towns into production, but soon realized that the word ARCHIVE means much more than we ever imagined. In fact we decided to bend to the first linewalker request to give him a cabinet of copied paper records to access from his truck in conjunction with the GIS information. We feel it will allow for faster buy-in but more importantly give us a mechanism for getting field corrections back, while depleting the paper as he completes each mark-out. We anticipate the paper will only be needed in the first 6 months of rollout. Backlog BACKLOG is a word you will wish would go away quickly. You must be careful to look at the how you will handle the two kinds of backlog that will be unavoidable. First is what we call the conversion backlog, created as the areas of the system are being converted by outside vendors, and changes received must be filed until the converted data is received. We suggest the vendor be responsible for this backlog and it be made clear the importance of getting it done on a very timely basis after initial conversion. Secondly, backlog will be created from daily work as you wrestle with the old paper system and GIS updates. Duplicate Work We suggest figuring out early on how to eliminate the duplicate work you might be doing to maintain the paper system, while GIS for the area is being reviewed and corrected. But this will require you to be writing up new 'processes' to handle this transition and constantly modifying them as you proceed along in the project. Clearly mark the old paper record systems as they become outdated and are replace with GIS. How will all the users of the distribution records look them up?? PC's for distribution system record access need to be planned for and located in those areas far in advance to allow for training of users. Especially important is to arrange periodic meetings with field personnel responsible for the collection of as-built information and the drafters/editors who maintain GIS. These sessions will give each group a chance to understand what the needs of the other are, and the significance or importance to each. Bottom line is the quicker you sever the paper system and go with GIS , the sooner you reach a successful conclusion. Union Issues Union issues and changes to job functions will be a constant. Open up the union discussions early in the project, defining the work to be done by the union versus outside vendors. In our case, we even had in-house management in charge of outside vendor support staff working in the same building doing editing of the distribution system, which clearly overlapped existing functions of our drafting group. The message communicated to the union is that this project needs to be a joint effort where flexibility is the key, and success demands it. It is no different than how many of us handle other short term peaks in the workloads using outside contractors to supplement our workforce. But also be calculating what the resource needs will be after GIS is in 'production'. It will be clear to the union how work previously requiring research and preliminary design, will now be done by the engineers and designers respectfully. The upkeep of the GIS and future modifications to integrate it into other systems and processes will require additional resources that hopefully can mostly be made up with the freed up time of your drafter/researcher group. Hardware issues faced Do your homework on this and be sure to allow for the future. We found the key issues are Ram(256 Meg or greater), Disk Size(10 Gig) , and DUAL MONITORS(21"). The monitor issue caused the greatest pain in our case, but persistence won out, and we got it. It is as we had to repeatedly state, a significant efficiency improvement allowing for editing of GIS while other related systems are running simultaneously preventing the multiple in and out motions with GIS previously required with the single monitor. MHz of 500 or greater is sufficient since the network architecture will be the ultimate key to the response time of your system. Your only hope there is to get on the good side of the IT department and incorporate outside expertise as advisors in the development of the specifications. What's next? Expand User Base At the same time that your getting the designers and engineers trained and using GIS, you need to look at all the other customers of the distribution system records. Customer service dispatch, customer relations representatives(call center), marketing, gas control, distribution, and system planning, all utilize the system records in some fashion. How to give them access will be a custom decision that each company needs to make depending on their operation. In our case, we are looking at an 'Oracle' interface with Smallworld to allow them to access the service records as they do now with a legacy database, that we plan to eliminate. Also, be sure that IT is aware of the rollout to other user groups so as to plan hardware requirements for each of them. System Interfaces The ultimate is to have your CIS, Network Analysis, SAP(financials), and Dig Safe(On Target) all connected and sharing common tables. But let's face it, we're DREAMING. At ProvGas we hope to tie in the On Target(Dig Safe) system initially to allow for all tickets to automatically grab the necessary distribution records. From there we hope we can eventually work into the link with Stoner(Network Analysis) which is also a target within reach. The ultimate prize will be the CIS to GIS link to finally have a way to produce outage information instantly without reconciliation in the field. Municipalities They will be all over you to get your digital orthophotos, so figure out a charge system to market it that will allow you to get the necessary updates within each of their respective cities and towns. Internet Access for Engineering Firms We hope to emulate a Michigan company who have their GIS on the web, and accessible to approved users such as the engineering firms. This should produce significant savings of research requests and remove any delays currently experienced by them. Conclusions
| ||
|
|