When the telecommunications equipment supplier that I work for found that it was contractually obligated to become ISO 9001 certified, it faced a number of challenges. One of the most daunting was in determining just what needed to be done in order to pass the pending ISO audit, which would be conducted in just eight weeks’ time by an independent auditing firm that would award the certification or provide a list of items to be remedied.
Another obstacle was the fact that the project requiring certification was a multisite development effort to enhance an existing network element system that required some hardware and software redesign. It included an addition of new features and physical design changes that enable "universal" configurations of hardware. In fact, the project lead site had been newly created and only recently staffed.
To become ISO certified, an organization must define the scope of its registration (entire company, an organization, etc.) and be able to demonstrate to a third-party auditor that it has satisfied the requirements contained in the ISO 9001:2000 standard. This involves developing a quality management system manual, documented processes and procedures, and providing records as evidence that the processes and procedures are being followed. The intent is to satisfy customer requirements and continually improve the effectiveness of the quality management system.
To meet these challenges head-on, upper management decided it was vital to prep the in-house development team to help the project pass, given the discipline that would be needed to meet ISO requirements. To get the internal team up to speed, they decided to bring in an outside consultant.
My role in the certification process was to create Web-based documentation for the ISO audit process and work closely with the outside experts.
Call in the experts
The consultant, who had an extensive quality management background, was dubbed the “quality coordinator.” Then, senior management appointed the development team’s technical project manager to serve as the project quality manager. That role was key in making things happen, especially getting through organizational roadblocks for the quality coordinator.
The quality coordinator’s first order of business was to meet with the business unit’s (BU) quality manager, who was well versed in the company’s quality policy. These two decided that the company needed to practice for the real thing by conducting an internal audit. The BU quality manager had been through a number of audits and knew what the ISO auditors would scrutinize, such as the organizational quality manual, system development processes, and quality records of outputs.
Through the internal audit, the team could correct any deficiencies that became apparent, or at least could put an action plan in place to demonstrate that they were being proactive.
Obsess with process
The first order of business to satisfy the ISO standard was to have well documented development processes in place. At the onset, it was clear that this would be the most painful part of getting prepared. It finally took a heavy hand from the project sponsor (who was quoted as saying, “the whining stops here”) to force the development managers to write up process documents for their functions (software development, systems engineering, etc).
What helped with this exercise was the fact that the quality coordinator had them use a common template to document each process. The key areas that the internal audit focused on were the system input/output process, and identifying which quality records the company must retain.
For all the moaning and groaning, documenting the processes actually turned out to be a positive experience for those involved. The process document reviews, which began as rather sleep-inducing sessions, soon turned into spirited and lively debate. These debates really got the development team to think about what they do. They then focused on what was really necessary and what wasn’t and looked for repetition of tasks in other areas. It also got the functional area teams to learn about one another, which was especially important since they were a new team.
The second challenge mentioned earlier, the remote development site, was well versed in developing the project’s earlier releases. They claimed to have been already ISO compliant, but when asked to produce their processes, they proved to be a bit weak. The project leaders decided both teams would use one set of processes, since it didn’t make sense to have separate ones for a single project.
A dry run: Internal audit
Armed with the latest version of the ISO 9001:2000 standard, the quality coordinator and BU quality manager tailored the corporate quality guidelines for the project under certification. This new document became known as the Quality Manual. To keep all of the documents generated for the audit in a central place, they used a Web-based project tracking system. The company was already using this system as a central documentation repository, which was something they knew the auditors would love.
The team conducted the internal audit at the end of the eight weeks and found few surprises. Since no documented processes were in place for the new project lead site, all would need to be created and approved by the project development managers. The internal audit also prepared the team for that fact that the ISO auditors might interview random team members and ask them to demonstrate that they could locate the process they were using to do their job.
The real deal
Judgment day finally arrived. An ISO auditor showed up at each location and worked closely with either a quality team member or the software developers to review the organization and ensure that the requirements contained in the standard were being satisfied. Since our organization was in the "formative" stages of developing our quality management system, we did not undergo a "tough" audit. Future audits will be more difficult as we will have to produce records that demonstrate that we are satisfying the requirements contained in the ISO standards.
They looked through our Web-based tracking system and printed documentation for the system. The auditors spent several days working at each location. The quality coordinator was a bit nervous, but the team was ready. Nearly everything was in place.
The internal audit had paid off. Between the two sites, the auditors only found a few minor problems, pertaining to the lack of certain quality documentation. However, we had prepared the auditors for this because we were still developing our quality process. The auditors gave the two development teams ample time (several months, in fact) to make the changes.