Effective Implementation of ISO 9001/TickIT
Malcolm L. (Mike) MacfarlaneGetting ISO 9000 certification in a software company is difficult at best and subject to a wide variety of disbelief and discouragement. Despite the hurdles, real and imagined, the payoffs are worth it. This is an "in action" report from the ISO front at the seventh largest software company in the world, and the only independent to be ISO 9001/TickIT certified in 80%+ of its engineering in the United States. While some of the information is software-specific, most is relevant for anyone involved in implementing the ISO standard in a technical environment.
Any talk about ISO is almost guaranteed to boost attendance at quality seminars. Most attendees show up with an agenda they intend to confirm at the meeting: "ISO is worthless"; "ISO will restrict my creativity"; "ISO is not rigorous enough to help me get under control"; "ISO will take so much effort it will retard my high priority projects"; "ISO is a passing fad." Generally speaking, when you go to confirm a prejudice, you get it confirmed. Everyone walks away happy. Yet the continuous pressure from the market plants another seed of doubt that drives the attendee back to the next meeting, just in case.
None of this is helped by some consultants too willing to help you get ISO certified. The barrier to entry is low, the requirements few, and the mystique so thick you can't cut it with a chainsaw. "ISO takes 18 months to 2 years, and I'll be with you all the way"; "I can guarantee you a certificate in 3 months; just use my software (my book, my flowcharts, my binder, my templates, my motivational tapes, etc.) and it's a snap"; "ISO is hard and it'll cost you a lot of money -- I'll be happy to do it for you." Right. The manufacturing heritage of ISO coupled with the exposure to some consultants with more experience on the shop floor than in front of a workstation reinforce the prejudices of the software community: "This standard is for companies making anvils, not software."
Objective evidence is to the contrary. To the software group willing to make the honest investment in ISO 9001/TickIT, benefits accrue rapidly. The first evidence appears when the engineer in the fourth cube who violently resisted the training and audit comes to you and says, "you know, it's really nice to always be able to get a current copy of the functional spec." Evidence mounts when proposed management shortcuts are publicly vetoed by engineering saying "that isn't the right way to do it, and we've got to stick to the process we agreed on." No quality shortfalls. Weak areas get identified by audit and required fixes are put in place on a time schedule. Things get better -- all over. No magic, just a company in alignment with its customers and a shared direction for improvement.
Companies who have held on to their certificates for three years or more have enjoyed startling improvements. One improved their defect rate by an order of magnitude. I asked them how they did it. "First we got ISO 9001," they said. "What was the next step?" I asked. "Holding management accountable for their metrics," was the response. Process and measurement are the two fundamentals required before TQM or BPR (or any other three letter quality acronym connoting a distinction without a difference) can make a significant contribution to the well-being of corporate processes.
Assuming that you're part of a software company that wants to get a meaningful ISO 9001 certification, here's a three-point strategy that works:
If you're the champion of ISO 9000 in a software company, be prepared for a deluge of ridicule, some good-natured, and some not. Scott Adams' Dilbert has some classic strips about ISO 9001 ("Big honkin' binder" that management will treat like "a dead raccoon"). Take it in stride. The best way to begin orientation is to show some of the humor surrounding ISO 9000 and enjoy it. We even went several steps further, putting up our own posters going for a laugh as well as a lesson about the audit process or quality policy. Taking umbrage at programmer humor is like King Canute ordering back the tide. Enjoy it, and use it to your advantage.
The humor will turn vicious, however, if you are rigid about writing your procedures for the standard rather than for your own company. A technique followed by many companies is to write their "big honkin' binder" to fulfill the standard, regardless of whether it does them any good or not. The ISO golden rule is "if the process doesn't make long-term business sense, stop. Rethink your interpretation of the standard and reconsider your alternatives. The purpose of ISO is to create prosperity, not engender bureaucracy." It's a little long for a golden rule, but you get the drift. Any process written for ISO and that does not make sense to you should be rewritten.
Turns out that the kind of thinking that writes unuseful but compliant processes encourages "policeman-like" audits, or audits by folks eager to display their knowledge of the standard rather than to investigate how well your own useful procedures comply. It's important to pick a registrar that will do more than police compliance to their expectations rather than yours. Several registrars which shall remain nameless here have a reputation of unbending, slavish adherence to their own interpretation of the standard, rather than a proactive investigation of procedures with the standard as a guide. Investigate registrar candidates, and pick the one that will provide flexible but firm added value to your company.
Make new mistakes. I know that this goes against the traditional approach to developing software where every new programmer reinvents the mistakes of the last 30 years, but it's a lot more fun. The way to find old mistakes is to ask companies successful in getting their registration "what was the biggest mistake you made along the way?" Here are some of the answers we got, and some of the old mistakes (OMs) we avoided (or almost avoided):
OM1. Setting schedules too long. This seems a strange mistake to make, but it was at the top of the list of one major company. "We set our schedule for the whole company at two years," they said," and for the first year we did nothing . We started worrying about it in the first quarter of the second year, and actually got our certificate in the beginning of the third year." After discussion, they recommended that we set our schedules at 9 months and try to meet them. It had an amazing effect of focusing us rapidly on the practical issues.
Another side effect of long schedules punishes the industrious and rewards the lazy. Groups ready for early certification had to wait for the rest, and lost momentum without recognition for their initiative and achievement.
OM2. Delegating responsibility for the success of the ISO 9000 project too low in the organization was a popular mistake, particularly when the person was an outside consultant with no skin in the game. Management often wants to treat ISO like a bag on the side, rather than integrating it into the overall process of doing work. "Quality system" is an unfortunate term, because it connotes something extra or on the side, rather than simply a series of processes by which everyone works.
Make sure that a senior manager in each major group to be certified is assigned at least half time to the ISO project, and is held accountable for its local success.
OM3. Trying to train and certify the company all at once. This is another mistake common to large companies or organizations. It's often combined with OM1 above, and can waste a lot of time and resources. "Eating the elephant one bite at a time" is the philosophy that works. By leading with a few groups then adding to the scope of the certificate, the trailing organizations can leverage the early work, use existing documentation, and in general shorten their implementation schedules even further. After one pass, the leading best practices can be merged into the quality system, and the result is something much stronger than if everything was done at once.
Training an entire company is perilous. In the early days of TQM, one large company trained all employees on statistical process control, then waited for spontaneous combustion. Nothing happened. The same can be true of ISO 9000. If you train everyone in the company all at once, not much will happen unless you have an army of facilitators to get started on the entire project.
OM4. Assigning procedure writing to someone already 100% committed to other projects is another popular mistake. Often the expert most needed to get a project out the door is the person who knows the process best, and is assigned to getting it written. This leads to all kinds of delays, frustrations, and a generally dark attitude towards a corporate approach to ISO 9000 by line management. A technical writing resource dedicated to the team is a better approach (see CSF4).
OM5. A corollary to OM4 is failing to plan for reviews, training and other ISO-associated activities in the budgets and project plans of the company. These things take time and you have to get it from somewhere. Managers responsible for delivering projects to schedule again take a dark view of ISO if the effort is not planned in from the beginning.
Another drain on resources is the internal audit process. Unless you use the central auditor organization (not recommended, best practices is a group of internal auditors from all over the company) the time required for internal audits needs to be budgeted, both in project plans and departmental budgets. No cross-charging because each group gives and receives in proportion to their size.
OM6. A very common error, particularly in a software organization, is writing too much. When you do get engineers interested in describing their work processes in detail, sometimes you can't shut them off. Work instructions get confused with processes, and the pages turn out by the hundreds. In the most egregious case I've seen at one of the companies we benchmarked with, the "big honkin' binder" for one process (I think it was Build and Test) covered 167 pages. No one could ever follow a process this long, and it was destined to become a dust catcher. What the auditor wanted and what would have worked much better for the company, would have been two pages -- one of them a flow chart. A rule such as "processes are no longer than 5 pages, no exceptions" works really well to discourage this misdirected enthusiasm.
OM7. Not training enough is another error made by some companies, who believed that simply writing the procedure and making everyone aware of its existence was enough. Turns out that for success you need to train everyone involved in performing the procedure and on taking an audit. This will boost confidence during the audit, and will answer any questions they might have but that haven't hit until now.
One of the interesting things that happens if the procedure was written outside the group, is that the folks who carry out the work say "this isn't how we work at all." This makes it real entertaining for the implementors, who, if they're smart, will immediately solicit the group's help to clean up any misconceptions and errors.
OM8. The final old mistake is treating ISO like a "bag on the side" as mentioned in OM1 above. Executives expressing interest only once a quarter and ignoring the process for the rest of the time shut down urgency and interest in the rest of the company. "If they're not interested in this, why am I doing it?" This question comes up more often than you'd like. You can lose more than a quarter in a quarter when project momentum dies.
Avoid these old mistakes, or make them with eyes open to their pitfalls. This advice doesn't always work -- one of our teams made several of the mistakes above, and took several months to recover. They rediscovered you can't make an outsider ultimately responsible for the success of the implementation. Not, at least, without a great deal of management and maybe not even then.
There were a few factors that really made us successful. In 10 months, start to certificate, our first engineering group was successful, along with all the support functions such as technical support, computer services (internal support), legal, human resources, order entry, and so on. Within the next 6 months, over 80% of our engineers were working under ISO 9001/TickIT certified processes.
Here are the things about our ISO 9001/TickIT registration process that we think made us successful:
CSF1. We ate the elephant one bite at a time. The project was broken into small, distinct units, and schedules for the units were staggered. The first group into the process was our manufacturing group, that was certified 9002 within 6 months of their start and had no non-conformities at the end of the project. We started several of the engineering units two months after Manufacturing, leveraging the work on the policy and policy manual that had gone before, as well as experience with internal and external auditors. The staggered schedule let groups learn from each other and leverage early work, picking the best in class to go forward with. The schedules also made it possible for a relatively small group of experts to act effectively within different groups at critical times such as document preparation and pre-audit.
CSF2. We got early, temporary help from a consultant who knew what he was doing, transferred the ISO language and attitudes, and wound down the contract. It's important to not rely on someone else to do the job, but it's equally important to get a strong dose of information quickly to get off the ground.
CSF3. Our executives were strongly involved. We established a steering committee that met every two weeks, composed of three members of the executive staff as well as local experts and management. There were eight of us. Each week we had a presentation by one of the project leaders of one of the staggered projects, and invited back early and often those projects that were lagging behind. Incremental success was recognized early and the company made aware of incremental success as well as final successes as they occurred. Executives identified with success within their spheres of influence and made sure their groups had the resources to go forward.
CSF4. Tight project management was vital with so many groups working to different schedules. We developed a scoring strategy which awarded points for each increment of preparation. We tracked the progress of each group continuously. Groups reporting the same score week after week were invited to the steering committee to discuss their issues and in several cases, to get additional resources to get back on schedule. Schedules were maintained intentionally tight.
CSF5. Early progress was made on documentation by blitzkrieg approaches and dedicated writing resources. The Quality Policy Manual was written in first draft in two weeks, by the expedient of bringing together experts in each section in a two-hour meeting where they interactively reviewed a template and immediately contributed their comments and suggestions that were recorded in real time and displayed on the screen. Twenty meetings were held, one for each section of the standard. Another example of the blitzkrieg approach was a one-day off-site during which we flowcharted all internal system maintenance and support processes.
Resources were dedicated to completing the documentation on a tight schedule. On the principle of "eliminate excuses" technical writers were funded outside the organization for the first groups through the process. After the concept was proven, organizations paid for their own. The requirement was for a dedicated, knowledgeable technical writer assigned to the project to complete the documentation, perform the review process, and implement the documentation delivery system for the organization. This avoided asking fully dedicated people to perform the writing chore, and also removed the temptation to write too much.
CSF6. Managers were held accountable for success in their areas. As a consequence, they took a vital interest in progress, and made sure resources were properly allocated to completing the job.
CSF7. Metrics were determined early and made highly visible to the organizations getting ready for certification. Emphasis was placed on quality metrics (defects, cycle time and productivity) rather than on "feel-good" metrics (revenues or volumes). Establishing success metrics early in the process provided the feeling that ISO would really improve something rather than just be a documentation exercise.
CSF8. Added-value audits were established as standard, rather than rigid audits of mindless conformance. In both internal and external audits, the auditors were requested to first understand the system then provide feedback to ISO 9000 conformance. Where it did not conform, auditors were encouraged to provide examples of conformance within other organizations. The auditor code of ethics prevents them from suggesting methods, but examples of successful implementations -- particularly when they are in the existing organization -- make a lot of sense. In several cases, ego-maniacal auditors not providing useful feedback and engaged in police-type audits were asked not to return.
Using the three-point strategy of (1) maintaining a sense of humor and proportion, (2) making only new mistakes and (3) driving the critical success factors, you can get from start to registration within a year, with a strong quality system. It took us some initial consulting costs to get off the ground, then an investment of one or more tech writers, at least half a manager in each of the groups undergoing certification, at least 6 hours of training for each person in each group being certified, and the contribution of internal auditor resources. It's worth the cost.
ISO 9001/TickIT provides a vehicle for introducing permanent change, measuring its effects, and making it stick. It provides common direction and a common language for process and measurement. Long term, it provides significant positive contributions to customer satisfaction and therefore the bottom line. Maybe most important, the engineer in the fourth cube can always find the current copy of the functional spec.