It's the Journey and the Goal: The Argument for Process Control of Deliverables

A 365Kb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE

I have often thought of surveyors as the only honest professionals because they will openly admit to error. Surveyors readily admit that error exists. They have specifications for how much error each type of project can have. They have procedures and requirements for the methodology and equipment required to meet, or exceed the allowable error. Why then does the survey profession have such a difficult time providing quality deliverables to mapping professionals, who for their part, are notoriously bad at quantifying their spatial error?

I have been asked many times by mapping groups to manage the surveyors that have been contracted. The mappers use me to communicate their requirements to the surveyors. They do not know how to get the surveyor to provide data that doesn’t need extensive reformatting and cleanup. What do I do that so markedly changes the nature of the surveyor’s quality and profitability? It’s called Process Control. Everyone has a process they use to get their work done, however, very few people are conscious of their process and therefore are not managing it. And, there is no Quality Control without Process Control.

What is Process Control?
Process Control is the method by which you define:
1. What you will do (tasks)
2. How you will do it (specifications and procedures)
3. What you actually did (quality control)

You can minimize problems and incrementally improve the quality of the work by breaking a project down into its basic elements. A well-defined process increases the probability of achieving project objectives by narrowing variables. When problems occur, they stick out. So, how do you begin?

Needs Assessment
The minute your company is selected to do the work you need to schedule a Needs Assessment. This is the how mapping people define their data specifications. A Needs Assessment is different than a scoping exercise in one important way–mapping clients expect to pay for it! The purpose of a Needs Assessment is to create a detailed specification that defines all aspects of the deliverables, and the acceptance criteria (allowable error) used to review them. This exercise will crystallize the client’s expectations and alert you to any unrealistic (out of scope) expectations. The Needs Assessment is your best insurance for achieving quality and profitability.

What if the Project is Underway?
If a project is already underway I conduct a Process Audit. I list every task the survey staff performs. Next, I document specifications and methodology that are being applied to each task. Finally, I examine how well the deliverables meet the specifications. What I usually find is that the staff understands which tasks must be completed, but is unclear as to the order of those tasks, and the specifications and methodology that should be applied to complete each task. In other words, they know what to do but not how to do it. Most alarming, the results of tasks are not audited, only the final deliverables are reviewed. When I ask why a particular specification or methodology was applied I am usually told, "That’s how we always do it." These are Mistakes One and Two:

Mistake One: Without a specification that fits the current project, one is assumed and applied from a past project.
There is only a small probability that these will meet the needs of the current client. The client is left with two alternatives: reject the data, or rework the data.

Mistake Two: Without a process everyone on the team goes it alone; blame reigns.
Without clear direction any way of doing the work is as valid as any other. Staff defaults to familiar ways of getting things done. This rarely meets the client’s requirements. Effort is spent ($$$!!!) creating unnecessary or unacceptable deliverables. Blame and fingerpointing ensue when deliverables are unacceptable to the client. Frustration and tempers flare when managers who didn’t provide detailed direction criticize staff for not making better assumptions.

Now it’s the survey manager’s turn to be audited. I endeavor to glean the manager’s understanding of the specifications for the deliverables that have been contracted. Predictably, the manager does not know what the client wanted, but assumed it was a lot like some other project the company had done–Mistakes One and Two again. Hopefully, all of my questions are causing the survey manager to begin to realize that something is missing.

I return to the mapping client and tactfully report that the surveyor doesn’t completely grasp the requirements. I now proceed to do a Process Audit on the client. Guess what? The client also does not know what he wants, but had assumed that the surveyor’s professional training would enable him to intuit the deliverable requirements. This is a bad situation since the client’s unspecified expectations have already been priced and contracted. The surveyor and I must now define a specification that meets the budget and satisfies the client. The chances of both happening at this late date may be mutually exclusive.

Define the Process

You may begin to define your process when you have completed your Needs Assessment (or Process Audits) and clearly understand what deliverables the client expects and the acceptance criteria that they will apply. Start by making a list all of the tasks that will be done. Make a diagram of each task with arrows showing the flow of data. Your flow diagram needs to be linear even if tasks are overlapping or concurrent A flow diagram for Process Control could be as simple as this:
1. Needs Assessment
2. Task Listing
3. Specifications/Procedures
4. Audit Methods
5. Feedback/Refinement

Next, apply specifications and procedures to each task. Make sure your specifications and procedures accurately represent the standard conventions of that industry, or more importantly, how your client is applying those conventions.

For example, surveyors use the naming convention of Northing and Easting to describe the coordinate position of points on the y- and x-axis, respectively. Most mapping software uses the x,y format. If the surveyor provides coordinates in the y,x format, the mapping client will have to fix the data. Deliverables should meet the client’s requirements, not the surveyor’s.

Sometimes a client adapts a convention improperly. A common example is the use of a number and letter matrix to index map features. The client may adapt this convention to the naming of Sections and name S12, T24N, R5E something like "C3" instead of "122405." You must provide a credible (diplomatic) argument for implementing a new, unfamiliar standard. For example, "Your number/letter matrix convention will limit the system’s ability to reference property descriptions, and will be confusing to the public." Be sure you clearly understand any professional standard that you apply. Be careful not to assume that a standard that a past client required was the industry standard, (Mistake One). You must also facilitate the client’s transition to any new standard (for example C3=122405). The following is an example of a simple Process Control Plan for a utility project.

Project Objective
State the objective of the project, e.g.:
Field (spatially) locate and describe (attribute) storm and sanitary utility features so that the utility network can be mapped accurately.

Task Listing
List all of your tasks
in a flow diagram. e.g.:
1. Research
2. Field Survey
3. Data Processing
4. Drafting
5. Delivery

NOTE: Quality control is not listed as a task. It is a procedure that is part of every task. Many managers would list quality control as a task before delivery. You cannot inspect quality at the end of the process. It’s too late then, too many errors are imbedded in the product. Quality control must to be part of each task.

Apply specifications and procedures to each of the tasks that are listed in your flow diagram.

1. Research List the information sources to be researched, a naming convention for listing the items found, how documents will be copied and stored, and the format (hardcopy, digital) of the listing of information found. For example, your research list might be county plats (long, short, condo), boundary adjustments, and records of survey. You list data sources to document the expectation and agreement of research effort. Typically, the surveyor defines the minimum level of effort he can professionally defend; the client wants the maximum he can afford.

2. Field Survey The information to be collected in the field should already be defined by the deliverable requirements described by the Needs Assessment. If there are gaps, make sure you check with your client before assuming any specifications. Below are some specifications that may need to be defined.
• Measurement units (English/Metric)
• Datum(s) and projection
• Horizontal and vertical coordinate accuracy and representation
• Field equipment and methods to meet the accuracies required
• Structure type naming convention
• List of structure’s measurements to be taken
• List of structure’s materials

3. Data Processing Identify the software that will be used, the digital and hardcopy formats to be delivered, and how the source data and processed data will be archived.

4. Drafting Identify the software that will be used, what features will be added, what digital and hardcopy formats will be output, and how the data will be archived.
• map scale
• fonts types and sizes
• sheet template information
• the layering and symbol conventions

5. Delivery Develop a deliverable schedule, transmittal form, and a list of the contents required for each deliverable package, to whom and where it will be sent, and deliverable tracking scheme (dates for sent, accepted, rejected, redelivered).

Quality Control (QC)
QC procedures must not only trap error to correct deliverables, they must use that error information to correct the process. Auditing that only traps and fixes errors does not improve the process that creates the deliverables. Without some feedback as to the source of errors (poor procedures, specifications, operator training/implementation) the process continues to produce the error. Left unattended, individuals begin to tweak the process themselves (Mistake Two, again). Think carefully about how the results of each task can be verified. (See chart, right).

Complete a Pilot Project
The Pilot Project is the test of your process. You must be concretely aware of the specifications and procedures that form that process before starting work. Only then, is your process applied to a representative part of the project that will encounter the widest variety of data features. This test allows you to identify and solve deficiencies in your process and give the client a reality check before you take on the entire project.

The staff must be extremely literal in following the specifications and procedures outlined by the process. Creativity adds variables that cannot be quantified. The staff can make adjustments to the process during the Pilot Project, but not without informing the whole team. The results of the Pilot Project are deliverable(s) and the process that created them. Your efforts will be wasted if the specifications and procedures documented in your process are different than those used to create the deliverables.

The Pilot Project ensures that you and your client understand the results of the Needs Assessment in the same way. It also allows you to verify the validity of source data–is it as useful as the client said it would be? As for the client’s ability to provide services or materials in a complete and timely manner, the client’s involvement may save them money, but will it distort your process, cost you money, compromise deliverables? A Pilot Project is an excellent way to diplomatically inject reality into the process. The results tend to speak for themselves. Clients tend to be less defensive if the Pilot Project results identify unrealistic expectations with respect to the contract schedule and budget.

Refine the Process
The results of the Pilot Project will provide clear, direct adjustments that are needed to meet the client’s acceptance criteria. If your client wants to change the scope of the project based upon the results of the Pilot Project, a clearly defined process shows how the existing schedule and budget will be affected.

I have helped several survey managers complete large mapping projects using the Process Control techniques I have just outlined. Their biggest resistance to implementing process control on their projects is TIME. I see it as a "Pay Now, or Pay Later" option.

Here are some responses that should make them reconsider the merits of that effort.
Staff: Is this what the client wants? Is this? How about this? Am I getting close?
Client: I don’t mind if you do the work over and over and over as long as I get what I want on time.
Owner: How do we make money if clients are unhappy with our deliverables?
Me: How can you check deliverables for accuracy/ content/completeness without a detailed specification? Can you afford to assume what the client will accept? How will you defend your interests if the client thinks you should provide more?

Some survey managers that I thought were really sold on Process Control have surprised me. At the end of a complicated, two-year project a survey manager once told me, "Now that we have the Process we can do these projects for any client." "Oh no, Mistakes One and Two," I thought.

The expected consequences of implementing Process Control are satisfied clients and job profitability. The unexpected consequences are a more committed and motivated staff. People learn and perform better when they receive clear direction. Your staff wants to give you what you want the first time, too.

Karen Zollman is a Senior Project Manager for URS Corporation in Seattle, Washington. She specializes in building large cadastral and utility geographic information systems.

A 365Kb PDF of this article as it appeared in the magazine—complete with images—is available by clicking HERE