Quality processes - How to build quality into project deliverables
Dean Zastava
Convergent Group,6399 South Fiddler's Green Circle
Suite 600, Greenwood Village, CO 80111
Paige Marlow
Piedmont Natural Gas, 1900 Rexford Road
Charlotte, NC 28233-3440
Introduction
It seems that quality is something we should be able to easily and quickly define because we use
quality as one of the major criteria for selecting items and services that we purchase. Quality is
also a major differentiator between offerings from competing suppliers. However, it is only after
we are asked to define quality that we realize quality is really a complex property, especially
when applied to technology solutions. Webster's definition of quality is a "degree of grade or
excellence," but the common definition is "I know it when I see it."
The issue confronting many organizations today is that there is a mandate to implement ever
increasing complex technology infrastructure in ever shortening schedules, even though the track
record of successful implementations for these projects is not particularly high. We believe that
many of these projects are in trouble because meaningful quality processes are not made an
integral part of the project. The real issue is that quality processes are not complete and are not
being followed.
Rationale for not using quality processes
There are, of course, many excuses given for not following and using a quality process. The
following list is a sampling of the most common reasons given for not implementing and
following quality processes for system integration projects:
- "We've integrated systems before - we know how to do it."
- "It's simply installation, configuration, and a few interfaces"
- "We don't need input from (insert IS or the End User Department names of choice) -these are our systems"
- "Our executives have said that this is the most important initiative we have and that it needs to be implemented ASAP - COTS systems don't need indepth testing; besides, the demonstration worked fine."
Debunking Rationale #1: "We've integrated systems before - we know how to do it."
You may have tied two or more systems together before, but unless you have already
successfully implemented an ERP system (on time, on budget, and accepted and being used by
the end users), you have no idea what you are in for. GIS systems integration projects generally
deal with multiple new applications and more interfaces than even an ERP system
implementation. Integration of multiple systems exponentially increases the complexity factor
and the opportunity for problems.
In our opinion, even if you are a consultant or systems integrator with successful ERP
implementations under your belt, you are not totally prepared for a GIS systems integration
project. Here are the reasons why we believe you are not prepared:
- GIS systems integration projects touch the heart and soul of an organization's business
processes and culture. These processes and cultures are different from company to company
even within a common industry sector. A quality process for a GIS systems project is to do a
thorough and speedy job of detailing "to be" processes. A top-level or second-level detail
view of the subprocesses is not adequate - the detail must drill down to the leaf level to
ensure adequate requirements gathering (and end user involvement and education).
- There must be a true partnership between the organization and the systems integrator, and
internally between departments within the organization.
Debunking Rationale #2: "It's simply installation, configuration, and a few interfaces."
GIS systems integration projects do utilize shrink-wrapped software to some extent, but project
success is much more than simply installing and configuring software products and building
some custom code and a few interfaces. As the client, you need to put everything that the vendor
sales person said through a pragmatic filter. Of course, the sales person didn't lie to you, but you
must remember that technology is only one side of the successful project implementation
triangle.
It is critical to keep reminding yourself that GIS systems integration is complex and will have a
major impact to existing systems and processes. There are many examples of IT projects that are
technological successes, but failures from a people/culture or process/business sense. It is good
to remind yourself of the feelings that you may have experienced when you were asked to
change to a new work process that had not been well communicated to you or that you had no
input into.
One last thought - just because this is your project doesn't make it easier or simpler.
Debunking Rationale #3: "We don't need input from (insert IS or the End User Department
names of choice) - these are our systems"
If you believe this rationale, then you have had your head in the sand. The days of isolated
departmental systems are gone forever. Competition is demanding unprecedented customer and
partner access to information that was previously defined as proprietary. Speed to market and
customer service is everything! To support the level of data sharing that is required, there can no
longer be any "departmental" systems; and by the way, end users and IS need to become like
Siamese twins because to be successful, they must completely trust and rely upon each other.
One pervasive attitude that must be eliminated to be successful is the "not my job" attitude.
Quality is everyone's responsibility, including your consultant's and contractor's. Senior
management from all participating entities must make it a policy that quality is the responsibility
of all employees, and that employees are expected to document all issues or problems that impact
quality of the project deliverables.
All new systems deployed by organizations from this point forward must exhibit the following
key characteristics:
- Single touch data
- Enterprise access
Debunking Rationale #4: "Our executives have said that this is the most important initiative we
have and that it needs to be implemented ASAP- COTS systems don't need indepth testing;
besides, the demonstration worked fine"
