GISdevelopment.net ---> GITA 2001 ---> Direction for Data

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"

Do not let unrealistic time frames or sales pitch rhetoric force you into a high risk, careerimpacting situation. Give honest answers to the following questions:
  1. What was the basis for the executives' deadline for your project?


    • Did you have input to the date?

    • If the date is firm due to regulatory or SEC requirements, what can be done to meet the

    Requirements while not necessarily completing every aspect of the project? Often you can deliver specific functionality to meet such dates and then go on to deliver the remaining functionality.
  2. How will your consultant/contractor help you meet the required date? Do they have a track record of meeting schedules with other clients?

  3. Have you done a detailed implementation plan that clearly defines all deliverables and milestones for all participants?

  4. How much work needs to be done with the end user work processes to fully leverage the new technology functionality? How much change management and training will be required to implement the streamlined processes?

  5. Have you done a risk identification and mitigation exercise?
Vendor products always need to be tested for your specific configuration in your specific environment. Demonstrations and prototypes are well suited to test concepts, prove suitability, and to educate the project team and end users; however, production systems are the lifeblood of an organization and must be thoroughly tested to ensure that critical business process and services are not adversely impacted.

An advantage of thorough production readiness testing is that it is an opportunity to get the end users involved in a manner that facilitates taking ownership.

What needs to be done?
Quality processes are really just a matter of having people take responsibility and be actively involved. The first step to success is to incorporate the following quality process characteristics into your project:
  1. Quality processes are used for the entire project lifecycle, from requirements gathering through acceptance testing and training of end users.


    • Requirements gathering is based upon end user work processes (as envisioned to be improved and enabled by technology).

    • End user work process improvements are defined using a methodology that is facilitated

      • by subject matter experts who can present detail level straw man best practices for each end user process rather than an approach that starts with a clean sheet of paper. When and where possible, actual demonstrations of the end result of a GIS systems integration is a very powerful and fast way to educate end users and help them to visualize the final improved end processes. System integrators and consultants should be using these demonstrations as a tool to move through the business process modeling exercise in an efficient manner.
    • Work process improvement sign-off based upon review sessions that are held with a reasonable cross section of the organization (different regions and districts; i.e., rural areas as well as urban areas) and where employee feedback is solicited.

    • Clear definition and sign-off on acceptance criteria based upon use cases.


  2. Quality processes must involve everyone in the organization as well as consultants and contractors. If your consultant/contractor has a quality plan, make certain that you review and approve it. If they do not have a documented quality plan, then contractually bind them to adopt yours.

  3. Kiss and make up - quality processes cannot be held hostage to internal politics. The executive sponsor and steering committee must be committed to quality and must communicate it to the organization. Involve an IT technical manager as soon as possible and realize that everyone has to contribute to an enterprise level project.

  4. The project must have a clear definition and documentation of quality in the context of the work to be done and the final deliverable products.
Top level checklist to implement quality processes for GIS systems integration projects
The following checklist is meant to be a guide for implementing quality processes. The extent to which each item is implemented may vary from project to project; however, none of the steps shown can be eliminated or bypassed without significantly increasing the risk to your project.
  1. Define quality for the project.

    2. The following definitions are required for establishing a quality process:

    • Project organization Quality Positions and Quality Policies
    • Quality Procedures that will be used to control quality
    • Quality Audits that will be used to ensure that the Quality Processes are being followed
    • Quality Metrics to determine the effectiveness of the Quality Processes

  2. Recommended Quality Positions

    3. The following positions are required to effectively implement a quality process for a GIS systems integration project:

    • Executive Sponsor and Steering Committee
    • Project Director*
    • Project Manager*
    • Project Administrator
    • Business Process Owners
    • Team Members

    *Separate positions will not be required for smaller projects

  3. Recommended Quality Policies

    4. Quality starts at the top of an organization with a policy that emphasizes the importance of quality processes, the fact that quality is everyone's responsibility, and a statement that employees are encouraged to bring quality concerns and issues forward. It should also clearly state that employees who report quality issues will not be reprimanded for doing so.

  4. uality Procedures

    5. It is important to have a quality process diagram showing the steps in the process and their interrelationships. At a high level, the quality process begins with the creation of a Project Charter that defines the vision and objectives for the project and proceeds through the final testing and acceptance and finally the training and organizational change management tasks to deploy the new system to all of the targeted end users. Ideally the quality process should then continue into the support and maintenance phase of the system's lifecycle. It is also important to conduct periodic audits of project procedures to ensure that quality processes are being followed. We suggest that you consider bringing in an outside consultant to perform this task, and as a client you should also be prepared to audit your consultant or contractor to verify that the agreed upon quality processes are being adhered to. We recommend that the initial audit(s) be conducted between three and six months, and that a subsequent audit be performed on an annual basis.

  5. Recommended Quality Documents

    6. The following list shows the typical quality documentation that results from the implementation of quality processes. All project deliverables (written documentation and software, including installation and configuration of COTS products must go through the quality definition review and final acceptance process. The documents are loosely arranged by category.

    1. General


      • Project Charter: A statement of vision and objectives that has been reviewed and approved by the executive steering committee.
      • Meeting Agendas
      • Written Deliverable Definition and Acceptance Criteria and Signoff Form: A document that provides a high-level description, purpose, audience, review list, distribution list, review schedule dates, and detailed table of contents for the written deliverable to be created. The document author, Project Manager, and Project Director, each signoff on this document two times. The first signoff is upon acceptance of the definition and the second signoff is upon final acceptance.
      • Written Deliverable Quality Acceptance Review Form: This is the cover form for documents being reviewed. Used to record dates, revisions, comments, resolution of comments, and team signoffs.
      • Project Manual: A detailed scope of work with roles and responsibilities for deliverables.
      • Deliverable Quality Acceptance Process: This document describes the tasks, roles, and responsibilities for each team member from a quality perspective.
      • OCM Plan: OCM prepares the organization for the new work processes and organization (if required). The OCM plan begins at the IBPM (integrated business process modeling) process when the work processes are defined across the enterprise and then reviewed and improved within the associated subprocesses.

    2. Engineer and Build Software


      • Software Deliverable Definition and Acceptance Criteria and Signoff Form: This form includes a high-level software description (including a list of modules to be built and/or installed), delivery, acceptance test and documentation review schedule dates, and a list of software documentation to accompany the delivery (release notes, user manuals, system administration manuals, code listings, etc.). This form should be designed for three signoffs; one for the deliverable definition, one for code escrow certification (if used), and one for final acceptance.
      • Functional Requirements: A document derived from the IBPM process. The functional requirements record how people, processes, and technology are envisioned to interact in an efficient way.
      • Use Cases: Detailed scenarios describing how each business work process will work. Includes end user actions and interactions between systems and applications and data.
      • Design Specifications: Functional requirements and use cases combined into programmer level language.
      • Coding Reviews: Peer reviews of an individual's coding deliverable. Coding reviews should be done at both a unit and a system level.
      • Test Plans and Scripts (peer testing, unit testing, operational testing, and acceptance testing)
      • Configuration Management: This document defines the tools and processes used to manage versions of code during the software development lifecycle.
      • Technical Administration Manual: A manual that provides a technical description of the new system. This document will help in the care and feeding of the new system, and provide support for troubleshooting.
      • Quality Certification/Deliverable Signoff Sheets: The software engineer, consultant, or contractor certifies that the software meets the requirements and specifications, has completed a code review and testing, contains no known defects, and was produced according to the governing quality process.

    3. Engineer and Build Data


      • Data Conversion/Migration Plan
      • Data Specifications: These include a from/to matrix, identification of primary data sources, and documentation of rules for interpretation or calculation of values.
      • Data Acceptance Test Plan and Scripts

    4. Deficiency Reporting and Corrective Action Documentation


      • Deficiency Report Form: Used to record specifics of the deficiency: records the requirement, requirement reference, and a high-level description of the defect. Includes space for a tracking number and dates submitted, reviewed, and resolved. A detailed description of the deficiency is attached to this form (if needed). All pertinent project team members participate in the review and signoff of the deficiency and planned corrective action plan. The final signoff is by the person assigned responsibility for the resolution. Procedure steps are included as a part of the form for easy reference.
      • Corrective Action Plan: This form is used to respond to the Deficiency Report by documenting the root cause of the deficiency and a corresponding corrective action plan to cure the deficiency. Interim preventive actions are defined as required. Mitigating actions are also defined for any deliverables that may have been accepted prior to the discrepancy being discovered and reported.
      • Request for Corrective Action: This document is used to elevate an issue that is not/cannot be solved at the project level to the Executive Steering Committee. An example of when this form is used is when a written or software deliverable has proceeded through the maximum number of redeliveries (usually two) without being accepted. Another reason to use the form may be when a consultant or contractor chronically misses scheduled delivery dates, or appears to have resourcing problems that adversely affect your project.

    5. Quality Metrics:

      6. Last, but not least, how do you gauge that quality processes are being followed and that they are effective? The list below is recommended as a starting point to measure you quality processes.

      • Written deliverables submitted versus approved
      • Software deliverables submitted versus accepted
      • Defects found during acceptance testing
      • Defects found in previously submitted deliverables
      • Process deficiency reports initiated
      • Total open deficiency reports
      • Corrective action requests issued
      • Total open corrective action reports
Conclusion
In today's business environment that focuses on speed to market and immediate access to enterprise data for employees, partners, and customers, there is a great temptation to bypass and do without quality processes. We contend that quality processes are needed more than ever due to the complexity of the GIS systems integration projects being planned, developed, and implemented, and due to the relatively high incidence of documented project failures. The risk of losing customers is very high if the interaction that you design and implement to help them is difficult or confusing to use.

Speed and content do not have to be sacrificed, and, in fact, they are supported by the incorporation of quality processes into your project.
© GISdevelopment.net. All rights reserved.