By Ron Younack

Anyone who has ever managed a project has a war story or two
to tell. A project that goes awry because the staff tried to do too much, too
fast, or too cheap happens much too often. Unfortunately, it’s the professional
project manager who often tries to juggle the time/cost/functionality/quality
paradigm on his or her own. Having been there, I know it gets very lonely.

For example, I recall one particular project on which
everything seemed to take twice as long as was originally estimated. The variations
were justifiable—the estimates assumed experienced resources, but the team
consisted of primarily junior-level resources. Equipment ordered did not arrive
on time. In addition, the business users were not available to meet with the
business analysts as required, thus, causing delays in the project. Of course,
while the workload was increasing, the one item that never changed was the end
date—it was fixed, and the team was told that they had to find a way to get the
system done within the original timeframes. Sure, more resources could be
added, but remember the adage that “nine women cannot make a baby in one
month”?

In what was a misdirected but valiant effort, the project
manager took a chance and decided to conduct multiple phases of the project concurrently
(parallel tasking) in an attempt to stay within the time constraints of the
project. He instructed the team to start coding before detailed design was completed, assuming that the amount of retrofitting required
to synchronize the two at a later date would be minimal. As you might imagine,
the manager’s worst nightmare resulted. The quality of the code was disastrous
because of the lack of detailed design information available to  the programmers, and retrofitting the
code to the finalized design was extensive. In the end, the team missed the
deadline. Everyone conveniently forgot any of the manager’s earlier warnings, so it came to be the manager’s fault. After all, the project
manager is accountable for the success of the project. Sound familiar?

So what went wrong? Very simply, one person, the project
manager, was allowed to unilaterally circumvent the software development
methodology that was being followed. There was no “gate,” or formal
completion criteria, that prevented the team from moving forward into coding
without having completed detailed design. At the very least, a risk assessment
should have been conducted for approval by the project stakeholders. If the
risk was warranted and the decision to move forward was jointly made, accountability
would have been shared by all involved. Instead, the project manager was
allowed to make that decision on his own accord. Yes, he was well meaning, but doing
right and doing the right thing are two very different things.

Quality control vs. quality assurance

Most software development organizations have quality control
processes in place. Many go as far as having independent test groups to ensure
that the final product released is of sound quality and meets requirements,
standards, etc. However, what is often missing are
adequate quality assurance processes—processes
to ensure that predictable quality is delivered. By definition, successful
quality assurance will result in reduced quality control failures. A very
important distinction that is often understated is that quality control without
quality assurance may find errors after the fact, rather than preventing errors
before they occur.

Q-gates

One of the techniques employed within quality assurance is a
quality gate (Q-gate) concept. A Q-gate process, when used in conjunction with
project management, helps manage the balance between software cost,
functionality, and quality. A Q-gate marks the formal end to a particular
process within the software development life cycle, a “gate” through
which the project proceeds when moving from one phase to another.

Each Q-gate process results in the certification that all
appropriate work products required to move forward to subsequent project
activities have been completed and reviewed, and meet quality expectations. Using
a set of predetermined exit criteria established for each phase or milestone
being certified, a Q-gate results in a pass/fail decision for moving forward. Time
and cost issues, as well as risks, are identified during the process. Based
upon the Q-gate results, key stakeholders associated with the project are
provided with the necessary information to make business decisions to take
action on any deviations. The benefits of the Q-gate concept are:

  • Project
    stakeholders share responsibility with the project manager for the project’s
    quality outcome.
  • Q-gates
    provide a mechanism for the project team to readily assess the quality of
    their work products throughout the project life cycle and improve quality
    at the source.
  • Q-gates
    ensure that intermediate work products meet the needs of downstream activities
    through a formal, disciplined process. Problems, their resolution, and
    opportunities for improvement are identified—and risk assessment or
    escalation procedures are invoked, if appropriate.
  • Q-gates
    enhance project communications, thereby resulting in improved management
    of the expectations of key stakeholders through their participation in
    Q-gate certifications.

In practice, the Q-gate is a fairly simple process—it formalizes
what already happens or should have been happening all along and ensures
communication to all stakeholders. It can be as simple as a checklist that
results in a pass/fail score. For each major milestone or phase within an
organization’s methodology, a Q-gate checklist would be constructed containing
a list of “exit criteria,” tasks and/or deliverables that must be
completed prior to moving forward to the next activity. Deliverables might be
mandatory or optional, and individual Q-gate exit criteria might be optional
based upon project attributes such as size, duration, or type of project being
executed. As is the case with all processes and procedures implemented for software
development, Q-gates must be flexible enough to allow customization on a
project-by-project basis.

Recalling the project manager’s decision to proceed with
coding even though design had not been completed, a formal Q-gate process would
not have allowed that to happen without proper communication, discussion, and
agreement. However, if the business risks in doing so were outweighed by the
potential benefits, at least that decision would have been jointly made based
upon a solid risk assessment instead of an emotional, unilateral decision. And
the project manager described would have continued his employment.