| FROGS in Hot Water
Data Conversion Projects: "There's got to be a better way"
By Kenneth Turnbull You probably remember the story about a frog in a pot of water. Put the pot over a flame. As the temperature slowly rises, the frog is happy just to sit there, oblivious to its peril. It does not notice the slow change in temperature. As a result, frog legs are on the menu that night!
On the other hand, put a frog directly in hot water and he will jump frantically to safety. Is there a lesson here? I'm feeling like the fresh frog in a hot pot...and here's why. Out of the Pot
After being immersed in data conversion for twenty years, I had the opportunity to take semi-retirement. As a result, I was away from data conversion for seven years. In 1999, I felt the urge to dabble once again. The past several months have been spent catching up with old friends and learning where people are now. (Only a few of you are where you used to be.) Learning the "name changes" of companies has been quite a task. Seeing Hank's new tennis shoes at GITA 2000 in Denver was a real comfort.
Changes have been significant in terms of software capabilities, hardware performance, and Internet capacity. The volume of data available "for free" has dramatically increased. Mind you, the quality of this free data has not changed. It still must be thoroughly scrutinized before it is used.
Other things have not changed, specifically, the process of converting physical paper and tabular data into digital data with "intelligence." This process has moved disappointingly slowly, with no major breakthroughs at all, just the same old labor-intensive and meticulous processes!
Not surprisingly, now as before, no one actually knows where their data is located. Consistently and repeatedly, project managers report the single major task of implementing their project is locating their data! How can this problem have survived after a decade of attack by thousands of Spatial Information Management (SIM) professionals?
Attitudes have changed, but not for the better. The optimism and dreams that evolved in the late '80s have been dampened by the reality of the complexities, politics, costs, and slipped schedules in major conversion projects. This is very disappointing. Many people said last fall that the reason for the depressed state of affairs was the problem of Y2K. Come January, everything would be fine. Now we all know that the Y2K non-event came and went with no improvement to core circumstances. Expectations
My expectations were that the "process" would have been resolved, refined, and ultimately implemented. Corporate clients, consultants, and conversion service providers should now be working in unison to overcome these obstacles. Instead, there resulted a lot of finger pointing and many unhappy people. Contracts are now being written with penalty clauses as standard practice. I find this to be most unacceptable!
I anticipated instead that contracts would be written with incentive clauses to encourage service providers to deliver ahead of schedule, under budget, and over quality. Oh well, call me naive. But this is the only method by which our industry can develop "win/win/win" relationships, complete projects successfully, and continue to expand into other industries.
Why are we, as an industry, so slow to learn? Road and building construction projects are successfully completed by suppliers paid incentives for over-achievement. Mainly, their goal is to complete projects ahead of schedule. This is not a difficult concept, i.e., "It's the carrot, stupid!" Three Stooges
Consultants and converters blame clients for changing their requirements. Clients and consultants blame the converters for shoddy work and late delivery. Clients and converters blame consultants for unworkable specifications. Clients blame converters for missing data. Converters blame clients for poor-quality source documents. Consultants blame converters for slow delivery. Converters blame consultants for incomplete specs for data conversion. Everyone blames the programmers for late delivery of "untested" software modules. The programmers, in turn, blame poorly defined specifications, claiming that the actual data is different from the specified data.
Rather than celebrate and crow about our successes, the picture that emerged was not a pretty one. It contained three main elements: blame, blame, and more blame. This reminds me of the Three Stooges, poking their fingers into each other's eyes!
This lack of unity and cooperation within the GIS industry clearly stands out as an obvious problem. Let's be very clear. I am not referring to competition between software vendors, conversion bureaus, clients, and consultants. This type of peer competition is healthy and builds a stronger industry for us all. But, once this "team" has been selected for a project, competition immediately becomes a negative influence.
A team typically consists of a client with a project, a consultant with concepts to design specifications, and a conversion provider with the muscle to implement these specifications. If you find me oversimplifying things to make a point, please bear with me. There is no room, and no need, for competition among team members. By definition, team members must be cooperative and supportive. If any single team member puts his or her own needs above that of the team, the project will fail. This is exactly what is at risk in team sports.
The ability of the selected team members to work together in complete cooperation is an element that must be decided upon consciously. It does not just happen, and it cannot be left to chance. Solution
Why are teams failing? Why is cooperation not happening?
Project managers know that teamwork requires individuals who have both strengths and weaknesses. It requires a variety of personality types. In concept, let's say that Company A, Company B, and Company C will "team up" together. But, the fact remains that we cannot achieve this concept in practice at the company level. The reasoning here is simple. Companies do not bring forth "personalities." It is "individuals" within companies who own these personalities. Cooperation, therefore, must be implemented at the personal level.
Some of you must be thinking that our solution here is obvious. Let's have a single, integrated company that executes the entire process! Unfortunately it doesn't work this way, either. Merely substitute the term "company" with "department." Only the label has changed; the problem remains. Lack of cooperation between companies or between departments is the same problem.
Has anyone ever seen a project specification with a section entitled "COOPERATION?" Probably not; at least, not yet. We clearly have a need for all team members to cooperate, and to place the needs of the team above their own. How then can we do this? How can we write cooperation into the project specification?
Actually we can't, not directly anyway. But, we can specify and implement concepts and tools that encourage this cooperation to happen. Incentives
Penalty clauses in contracts must be removed. By definition, they say "compete." In place of penalty clauses we need to create incentive clauses. Incentives must be offered at two distinct levels.
Incentives must be tied to the most basic level of work. Furthermore, these incentives must include both a quantity measure and a quality measure. The quality measure must be attained first, in order to qualify for the quantity measure. This means that only work produced meeting the quality level can be added to the quantity of work completed. This incentive is 100 percent contained within each company or each department. Moreover, this incentive is specifically targeted to encourage cooperation among individuals.
The second measure must be applied at the team level. This is where the combined efforts of the client, consultant, and converters are required to attain the incentive. Having taken care of the "quality component" at the lowest level, this incentive is based on the "quantity component" to be achieved by a specific date. Phased implementation works well here, with benchmarks and milestones to break large projects into smaller phases, ones that can be both better controlled and better managed.
Recognition of achievement for each phase must be acknowledged. Whether this recognition takes the form of wall plaques, paperweights, theater tickets, donuts, or a party is unimportant. But there must be more than a verbal "atta boy." Take the time to acknowledge successful steps-as a team.
I wonder how the penalty clause originated? Its purpose is exactly 180 degrees away from the direction and message that a project should portray in order to be successful. Was it started by a client who had been burned in the past, looking for a Band-Aid to prevent future failures? Perhaps it was a consultant who found it easier to write a penalty clause rather than a proper pilot specification? Or was it a converter who was willing to offer a penalty clause as "proof" of the ability to produce? These reasons are all unfounded.
THERE IS NO UP SIDE FOR A PENALTY CLAUSE, not in any contract! It is simply an indication that someone is being lazy. This includes consultants-looking for a shortcut-who are not doing their homework, clients who are looking for cheap insurance, or converters who are trying to substitute credentials with hollow guarantees. By definition, the penalty clause offers nothing positive to the process, and it only serves to set the stage for competition. It creates a "them versus us" mentality, which is the exact opposite of team building.
If you want to complete a successful project, do it right. Do it with cooperation, teamwork, recognition of success, and incentives! Conclusions
Being outside the data conversion "hot pot" has given me the opportunity to see changes in the GIS industry over a longer time frame than most. Cooperation is the biggest missing ingredient in our GIS industry today. Cooperation must be insisted upon by all involved:
• incorporated by consultants who design project specifications
• supported by clients who supply raw data and reap the benefits
• embraced by converters who accept responsibility for each step of the project.
No single group, client, consultant or converter is either more or less responsible for making this necessary cooperation happen. This is a symbiotic relationship, and it is not a choice. It is the carrot, not the stick, which leads to success for the whole team. Author's note:
It was interesting for me to notice that the small frogs (workers) are more aware of the temperature of our hot pot than are the big frogs (executives). The reason for this is a mystery to me. My expectations would have been the opposite. I would recommend that the big frogs consider devoting more time listening to the small frogs in order to learn what is happening around them! About the Author:
Kenneth D. Turnbull is the vice president of business development for Genesys International Corp., Denver, Colo. He graduated from the University of Alberta in 1972, with a B.Sc. in Computer Science and a minor in Geology. He worked for Texas Instruments in Calgary, Alberta, and Dallas, Texas, before working on petroleum mapping applications in Tripoli, Libya. In 1980, he opened and managed the QC Data office in Denver. As a principal of QC Data, he was largely responsible for their decision, in 1986, to expand beyond petroleum into the AM/FM/GIS mapping industry. Ken is proud to say that he was programming surface-gridding software and generating his first computer contour maps as early as 1971. Back |
