A Project Managers Guide To Data Conversion (Or, Six Things Your Mother Never Told You)

A Project Manager`s Guide To Data Conversion (Or, Six Things Your Mother Never Told You)

By Chuck Rogers, GIS Manager, South Carolina Electric & Gas

Data conversion is only a single component of a robust GIS implementation. Depending on the size and complexity of the conversion effort, though, data conversion can represent a significant portion of the entire GIS budget. Unless the only focus of the GIS project is to convert the data, there are other critical factors that will determine the success of the GIS implementation.

Management support for the GIS project is vital. Without it, the project is destined to falter. Project managers must make decisions rapidly and decisively if the project is to have a chance of succeeding. Lack of management support can cause the withdrawal of funds or can add endless red tape and “approvals” for every decision. If possible, start with management support. If you don`t have it, get it before you do anything else.

Customer support is also vital. That means involve your customers at all phases of the implementation. If you think you can simply bring an outside expert or two into your GIS team to represent the customer`s needs and desires, you open your project up to a greater chance of failure. It is important that there is effective communication with the actual customer. Even if your customers don`t bring any new insight into the GIS development (highly unlikely), their involvement will make them “participants in” rather than “recipients of” GIS. This is another step on the road to success.

While converting your data, you should develop, maintain, and cultivate management and customer support. Their support will help you over the rough spots–and trust me, you are going to have rough spots. When you start to convert your data, I learned six lessons (that my mother never told me) that might help you. Unlike me, you don`t have to learn each of these lessons the hard way.

Lesson #1: Study Your Source Data

If you are anything like most new GIS team members, you don`t know anything about your data. You just think you do. Study all of your source materials. Ask questions about symbols. Find out what information on the drawings you are naturally inferring. The conversion vendor won`t have your years of experience with the data necessary to infer information that is not obvious on your maps. Every inference is really a rule, a rule that you need to understand and communicate to your conversion vendor. The vendor`s options are to charge you more money, lose money, delay deliverables or all of the above.

Don`t wait until you start data conversion to become an expert in your source materials. Take the time to make sure each GIS team member is an expert in your data before you do anything else. Later, each member can help with database design, ensuring that each component of the project that uses the data has its needs met.

What happens if you don`t put in this time up front? You will be constantly changing your database design and data conversion specification. This stops or delays the conversion process while you solve the latest problem uncovered by your conversion vendor that is not adequately covered in your specification. These changes can also add cost to what is potentially the most costly part of your project.

Invest the time in your source materials. If the most expert people aren`t on your implementation team, bring them in to live with you for a while. Pay their expenses. Buy them lunch. Their expertise will be invaluable. All of the time and money that you invest in your source data is money in the bank. It will draw interest for the duration of the project.

Lesson #2: Determine Your Applications

At this point, most people move into database design. It didn`t work for me. Now you know what your data is, how it was compiled, where it is weak and where it is strong. What do you want to use it for?

Making maps is important. So many people are telling us that GIS is not about making maps. It is easy to forget that GIS has to make maps. Often, maps are significant portions of the data that we capture. We certainly need to consider producing or replacing these source maps with GIS produced maps. How do your users use the maps today? How would they like to use them in the future? What map scales do they have or want? Can they agree on common symbols that work with GIS?

What about other applications? Your feasibility study should have included a high-level look at proposed applications. Now is the time to flesh them out a little. Don`t do detailed application development now. The reason for this exercise is to determine the data requirements for your applications. What does each application need? With what other company systems will your applications need to interface? What data needs to be stored in GIS and what data can be accessed? How will the answers to these questions affect performance?

Why are we doing this? All of these questions, and a lot more, determine the database design requirements. Don`t let your database design drive your applications. That is not why you are building a GIS. But remember, changing your database design later is painful and expensive (yes, even relational and object-oriented databases–don`t believe everything you hear). That`s why you perform this step now.

Lesson #3: Design Your Database Considering Lessons 1 & 2

Now that you have this step in the proper order, remember everything that you have learned and design your database. Take your time (not forever) and do it right. If you have looked ahead, you know what`s coming next. This step is an essential building block.

Everything that your GIS does, in a sense everything that your GIS is, will depend on your database design. Skimp here and everything that you do from now on will be “work arounds.” GIS is hard enough without building on a weak foundation.

Get some expert help from a database designer, but first train him or her in your GIS. A GIS database is a different animal from standard, corporate databases. Make sure that your database designer understands Lessons 1 and 2.

Consult with your applications vendor. That`s what you are paying them for. Don`t rely on the vendor to deliver a product to you in a vacuum. Share Lessons 1 and 2 with them also. Force your vendor to help you design a database that is right for you. Don`t buy someone else`s design intact. Even if the database design is working for another company, there are enough differences between companies to generate substantial database design changes.

Lesson #4: Create a Thorough Database Conversion Specification

This isn`t supposed to be a secret, but it seems as though enough people don`t know about it to justify including it here. It`s called RISK. Every data conversion vendor assesses risk when bidding on a data conversion job. If you write an incomplete or unclear data conversion specification, the conversion vendor`s risk goes up accordingly. Guess what happens to the bid when the risk goes up?

You may get a low bid from a hungry conversion vendor, even with a poor conversion specification. Don`t kid yourself. Low bids are great, but if you have a weak conversion specification, your boat already has a hole in it. This is the document that you use to tell the vendor what you want. Tell the vendor what your requirements are as clearly and thoroughly as possible. Attach a copy of the database design. Bring in the vendors that you have qualified and talk about it until the risk goes down.

Take advantage of everything you have learned in the previous three lessons and write a data conversion specification that communicates, as exactly and concisely as possible, the task for which you are seeking bids. This becomes the bible for the data conversion supervisor over the course of the conversion. You will surely make that person`s job much easier if your specification is well written.

Lesson #5: Partner With Your Vendor

There is a lot of talk about “partnering” with your vendor. The kind of partnering that I am talking about begins by understanding that you have the same goals. You want to get your data converted and pay the vendor for the work (I hope). Your vendor wants to convert your data and get paid for it (they hope). This is not, and should not ever be, considered competition.

A classic example of competition is when a company develops in-house software to check incoming data from the data-conversion vendor. There is an error rate that determines acceptance or rejection of deliveries. An overzealous “checker” delights in rejecting a delivery. This data is returned to the vendor for corrections and their conversion work stops while these corrections are made. This delivery is late and so are the next ones. What`s wrong with this picture?

Give the vendor any in-house software that you have to check their data. Then write some more. I know that this requires trust but it works both ways. Focus on the goals. Now, when you run your acceptance programs, you are only checking to assure yourself that the vendor ran them first. You still will have your visual (manual) checks. If you are worried that you are doing too much of the work, review your goals.

Lesson #6: Live and Die by Your Schedule

This is really a component of partnering. Most companies want schedules, deliverables, milestones, priorities, etc. Some companies even base a project manager`s pay on their timely completion. Everyone bases a project manager`s reputation on doing what you say you are going to do when you say you are going to do it.

One aspect of partnering is agreeing on a reasonable schedule before you ever award the contract. This means a schedule that both you and the vendor understand and can live with for the duration of the project–barring any unforeseen developments. Hold the conversion vendor responsible for any delays that are their fault. Be sure that the delays aren`t caused by your own company. Many times, skipping steps will stall your motor here. If you have done a good job in each of the previous steps, and your vendor still won`t (or can`t) meet a mutually agreed upon schedule, now is the time to assess your own commitment to the schedule and do what has to be done in these circumstances. If you are forced to sever relations with your conversion vendor, review the six lessons, move to the second vendor on your list of qualified vendors, and get on with your project.

Author Bio

Chuck Rogers is the GIS Manager for South Carolina Electric & Gas Company`s Retail Electric GIS Project. Since 1992, he has been responsible for the implementation of all GIS applications at SCE&G.

Click here to enlarge image

View of SCE&G`s electric circuit model.

Click here to enlarge image

Gene Hutto, Miner & Miner Engineers, performs editing and clean-up of converted data.

Author

  • The Clarion Energy Content Team is made up of editors from various publications, including POWERGRID International, Power Engineering, Renewable Energy World, Hydro Review, Smart Energy International, and Power Engineering International. Contact the content lead for this publication at Jennifer.Runyon@ClarionEvents.com.

Previous articlePOWERGRID_INTERNATIONAL Volume 1 Issue 3
Next articlePOWERGRID_INTERNATIONAL Volume 1 Issue 4
The Clarion Energy Content Team is made up of editors from various publications, including POWERGRID International, Power Engineering, Renewable Energy World, Hydro Review, Smart Energy International, and Power Engineering International. Contact the content lead for this publication at Jennifer.Runyon@ClarionEvents.com.

No posts to display