John Sinclair sits in an IT operations room where he’s responsible for managing a team fielding user calls about server and application support issues. The ops room, which looks vaguely like a NASA control room, is full of digital displays monitoring critical processes and servers on a 24/7/365 basis. John’s team is highly trained on the key enterprise software applications and services being run throughout the entire IT organization. The team monitors Veritas backup scheduling, midrange UX, NT server, mainframe, and security. His capable team rapidly responds to calls from users worldwide. “It’s really a question of knowing what’s out there and that we can fully support it,” John said.
Unfortunately, the team doesn’t always know what’s out there. John recalled a Monday morning when all hell broke loose. The help desk call volume suddenly increased by 30 percent. Users complained that they could not access data or asked questions such as, “Did you guys maybe run backups on dev server JEDIDEV01l last Friday?”
John said this situation happens all the time. In this case, his team didn’t know anything about the project—not even the names of the contact people for that server or all the assets that were included for that project. Also, it was assumed his team would automatically manage the development environment for that specific project team. “No one bothered to tell us,” he said. “If we had used the quality gates technique, we would have been prepared, and all that heartache could’ve been avoided.”
Marc Dutton, an executive in portfolio management for a large pharmaceutical client, became similarly frustrated at how many project managers simply fail to transition projects properly between these project phases:
- Design to development
- Development to deployment
- Deployment to operations
At the end of the day, project management isn’t always about delivering a project as quickly as you can. Often, it’s about ensuring that the project has been well thought out technically and can be supported after it is deployed.
Understanding quality gates
Quality gates are basically acceptance criteria reviews that can be used throughout any project. Sure, managers of smaller, agile projects might say that this involves too much paperwork, but the nice thing about quality gates is that the strategy is fully customizable. It can be seen as a set of predefined quality criteria that a software development project must meet in order to proceed from one stage of its lifecycle to the next. (Figure A shows a typical schema of quality gates.)
Let’s illustrate this process using the following example: You’re appointed as project manager for a large CRM project during the development phase. Your design team e-mails the MS Visio diagrams of the architecture to the development team. The developers proceed to configure and customize the CRM application as per the design team spec. Later, you determine from the infrastructure team that the dev environment and infrastructure aren’t yet in place (e.g., there’s no database support, and IP addresses and DASD still need to be assigned). This oversight impacts the timeline. If you had utilized the quality gates process, you would have detected at the “design phase” gate that the project plan didn’t:
- Detail the development environment
- Address networking
- Determine external storage or disc to be assigned
You can avoid such problems if you’re familiar with the technology and do it on a day-to-day basis. But, in reality, many project managers move from one type of project to the next, and it is likely they will forget something. So, project managers tend to build elaborate project schedules that encompass everything and ignore the key gate reviews or checklists that make or break a project.
Here’s how quality gates work: You cannot proceed to the next gate until the previous gate has been completed. This will typically involve a checklist of deliverables, with some indication of the state of completion for each item. This checklist must be reviewed by the IT project manager and a senior executive or sponsor who is involved with the project. Quality gates therefore mean:
- Formal checklists are used throughout the life of a project.
- Formal sign-off and acceptance occurs at each gate.
- Assessment of the quality and integrity of the product takes place.
- Information is assured to be communicated to the correct stakeholders (i.e., deployment hands off to operations, etc.).
Quality gates can be highly effective on any project. There are distinct advantages that make quality gates so attractive. Those advantages include:
- Minimizing project risk through phase-by-phase checklists
- Enabling project managers to continuously communicate the process and build quality directly into the project
- Reducing development cycle time—getting it done right the first time
- Increasing focus on a well-designed product
Unlocking the gates
So, where do we begin implementing quality gates on a project? The most important thing to understand is that the quality gates concept is best suited for enterprises that have the desire to instill a quality approach to the way they manage projects. Sure, this article doesn’t address every single aspect and technique of quality management, but it ensures that you address many problems upstream instead of downstream. Companies such as AT&T, Lucent Technologies, and many others have successfully implemented quality gates. It’s a process that needs to be driven from the top down for all IT projects. This isn’t something done overnight, either. The reason is that quality gates need to be integrated with both the development and deployment processes of your IT project. If you would like to implement this concept from scratch within your organization and currently have multiple projects already under way, the best recommendation is to complete those projects and establish a policy that all new projects coming in after a certain date will use quality gates.
For each phase of the project—depending upon your organization—you need to develop a series of checklists, which is used during a formal review period (for example, the review format could be an hour meeting or a workshop). These reviews prompt the project team to evaluate technical progress, specs, and project milestones. These formal quality gate reviews can also be applied to measure project cost and schedule performance, and to provide checkpoints to enable the baselining of key project information. The quality gate reviews play a significant part of any project development cycle.
For example, if you are managing a software project and the development phase has just been completed, the quality gate concept will kick in by means of a formal meeting, which is held with individual members of the project. At this stage, the examination of the project would typically encompass the following:
- Code review: The senior designer (normally the tech leader) will concentrate on acceptable coding techniques and adherence to IT standards. The software design will be verified against the coding to identify any coding errors. Upon successful completion of the code review, the reviewing party will indicate required changes and corrections.
- Ops review: The project manager will work with the support or operational staff to review all support tasks needed to support the dev environment. For instance, the ops review will ensure that the necessary backup and restore procedures are in place, discs are available, escalation procedures have been created, etc.
- Sponsor review: The project manager will review the overall project performance with the sponsor. This review will determine the status of project costs and schedule and whether the scope is still accurate.
- Test review: The test lead and representatives from QA will attend the test review to see if all builds were tested correctly and make sure that all relevant questions have been posed to the development team.
Once these meetings have been held and all the questions answered and accounted for, the quality gate review team reports to the stakeholders that the project has signed off on all relevant items for that particular phase and that the project may proceed to the next phase. (For example, without gate reviews, one of the biggest areas we tend to neglect is turning over the system for support.) Figure B highlights sample checklist questions that need review once a system is handed off to production.
Ignore quality gates at your peril. It’s an important process for your project when transitioning from one environment to the next. Don’t torpedo your IT project by thinking that this is yet another series of useless documents to be completed. More and more IT organizations are now starting to compile and use such checklists on their projects.
