In decades past, the focus of quality was merely finding problems at the end of an assembly line and removing the defects before shipping to the consumer. If the product didn't meet specs, it was either reworked or scrapped; both expensive options. This approach is prone to human error and rarely finds all defects. And, this quality control approach only identified the defects found through random sampling, but actually did nothing to determine the root cause of the problem for resolution.

If preventive quality measures and rework are deferred until the testing phase, the cost of change may be 40 to 100 times greater than if the defect was fixed when it was created. The testing stage has the least recovery time for show-stopper problems or unexpectedly large amounts of rework. This unpredictability becomes a large contributing factor to why projects miss their schedules.

Quality Message

In the post-World War II reconstruction years, Dr. W. Edwards Deming introduced a quality program that simultaneously controlled the production and quality processes. Unfortunately, the United States did not adopt these principles until the 1980s with the introduction of the Total Quality Management System.

Deming's core message-that we should stop inspecting defects out of products and start building quality in-has remained. The common thread of various quality methodologies is that the project team will build quality into the system design and will address quality continually throughout the life cycle. The goal is to identify problems up front and early, allowing corrective action and quality prevention to take place to reduce the number of critical defects found at the end of the assembly line.

This goal can be met through software quality surveillance, which includes walkthroughs, peer reviews, inspections, and testing, as well as, any method that identifies quality problems, risks, and operational capability weaknesses as early as possible. Approaching quality in this manner provides early corrective action and promotes lower quality costs upfront and early, thereby reducing end-of-program cost overruns.

Risk Management

Today, we have gone a step further by identifying risks which may have the potential to change engineering requirements, operational capabilities, and the quality of the product. In the spirit of risk management, software developers can help prevent one of the most common causes of defects-ambiguous requirements-by writing comprehensive acceptance tests when recording each requirement. And, automating these tests, and running them as part of frequent integration builds, will help detect defects when they happen.

While common sense says that preventing defects or finding them when they are cheapest to fix is preferable to finding them at the end when they are many times more expensive, many software development projects fail to write tests upfront, do inspections, or perform frequent integration-despite the benefits.

Implementing quality processes is tedious, time-consuming work in most environments. And, time is money. There is document inspection and writing early tests for critical requirements at the beginning of a project. It is hard to keep the tests up-to-date as the requirements change and even harder when you realize that you have to inspect the tests. These strategies increase the cost of implementing quality and the return on investment is not always predictable with a high degree of reliability, especially when the requirements and design have not been frozen. Thus, it is mind-wrenching work to determine which of all the possible strategies for implementation will bring the best value to the project.

We're far too focused on product delivery, not process capability. We're too busy trying to get the product out the door. Granted, this is a market-driven phenomenon, but we'll have to change that deadline-driven attitude to one of good processes. If you get the process right, the product will have a far better chance at success. Unfortunately, many IT professionals still don't quite understand the concept of process management.

We do far too much pretending in software. We pretend we know who our users are, we know what their needs are, that we won't have staff turnover problems, that we can solve all technical problems that arise, that our estimates are achievable, and that nothing unexpected will happen. Risk management is about discarding the rose-colored glasses and confronting the very real potential of undesirable events conspiring to throw our project off track.

Risk identification requires a look into the future as to the potential success of the program. The challenge lies in the identification of risk versus current problems. Current problems require attention and action even if the immediate remedy is to defer corrective action until later. Risks realized may require actions that lead a project team to proceed in a different direction altogether or canceling the project entirely. Project teams must accept some risks due to other requirements, conditions, assumptions, or constraints; however, if a project team chooses to completely ignore risk, they greatly increase the probability of project failure.

Economic Status

A company's economic status is a significant factor when deciding what process to implement to track quality cost. The profitable nature of the business can make it more difficult to convince management of the need to track COQ. For example, having more engineers and fewer quality assurance people on a project can be great for a company's short-term financial success. However, if project staff members do not build in quality from the start, a greater reliance on product rework results.

Quality Problems

The organization will eventually pay for the inadequate quality as customers identify problems with the product or service. Engineering changes must take place before the customer deems the product usable. These engineering changes late in the development process may result in a product or service that does not quite meet the original intent on the capabilities delivery; this, in turn, can lead to lost business. If this happens on a recurring basis, the company may experience competitive and financial difficulties. If so, a company may be more open to performing an assessment in an attempt to get back on track.

Then, after collecting and analyzing data that reveals a quality problem, the company finally decides to track quality costs. This may also be the time when the company experiences total failure. They know something has to be done, but don't have a well thought-out plan. They make knee-jerk decisions, such as simply canceling the project and not addressing the underlying quality problems in their processes; that, in turn, causes unintended conflict within the organization.

Cost of Quality

Not having a clear understanding of the actual value of Cost of Quality also hinders the adoption of quality processes. There has been a persistent misconception in the business community that the COQ is a cost over and above that of developing and producing a project to meet a specific and required outcome and schedule. The COQ, regardless if it is software or hardware, is the price of not creating a quality product or service.

If the development process was perfect with no problems and there was no possibility of substandard service, failure of products, or defects in their manufacture, then organizations would have no COQ expenditures. The Cost of Quality is the sum of costs incurred in maintaining acceptable quality levels plus the cost of failure to maintain that level (cost of poor quality), and typically ranges from 15-25 percent of total cost.

Quality is Free

Philip B. Crosby's "Quality Is Free" concept, identified two main categories of quality costs: conformance costs (cost of good quality), and nonconformance costs (cost of poor quality).

Conformance costs include prevention and appraisal costs; nonconformance costs include internal failures, as well as, external failures. A defect found early in the project prior to customer delivery is termed an internal failure. A defect identified after the product has been deployed to the customer is an external failure. External failures can also include incompatibility of the software with legacy software installed in the field, or a lack of commonality between redundant systems.

Quality Knowledge

Beyond not clearly understanding COQ concepts, key decision makers in an organization may lack knowledge in determining quality costs and the principles for collecting quality costs. Without knowing what quality principles are, an individual or organization may have no idea where to place their focus to obtain quality costs. The organization can remedy this either by ensuring that a quality curriculum is included in the training for project staff and senior leadership, or by hiring a quality consultant to guide the organization.

Conclusion

At first glance, an individual might be prone to think that collecting quality costs is expensive, adding unnecessary costs to the product or project. Quality is not free, in that you have to make an up-front investment in time, money, and effort. However, if performed properly over the full life cycle of the project, you can recoup the resources expended for quality processes by avoiding rework later in the project life cycle.

By communicating the quality story in terms of dollars, you can enlist the help of senior management to infuse quality processes throughout the project life cycle and contain project costs for the long haul. Collecting quality costs is like project planning; it is cheaper to properly plan than it is to plan a little and fail a lot.

Note: This article was based on a November 2008 article in Crosstalk. For more on how to put a COQ system in place, see the article by George Webb and Nanette Patton, "Quality and Cost - It's Not Either/Or: Making the Case With Cost of Quality".

TickIT is a quality-management certification program for software, supported primarily by the United Kingdom and Swedish software industries. However, ISO 9001 certificates under TickIT have been issued in more than 50 countries, including the European Union, USA, Canada, Mexico, Brazil, Australia, China, India, Japan, South Korea, and Taiwan. The TickIT name is derived from the "Tick" or check mark, along with IT for Information Technology.

TickIT was introduced in the early 1990's as a sector scheme under ISO 9001 to provide a practical framework for managing the quality of software development. TickIT addressed the need for qualified auditors with IT experience and competence, provided guidance on interpreting ISO 9001 requirements, and introduced rules for accreditation of certification bodies practicing in the software sector.

The TickIT scheme is now being updated to become TickITplus. A new and more adaptable approach was deemed necessary to keep pace with changing technology and the need to provide more demanding IT solutions.

TickITplus adds a new dimension by combining industry best practices with International IT standards. It provides ISO 9001 accredited certification with a Capability Grading for all types and sizes of IT organizations. In addition, it will provide optional certification scope extensions to cover additional IT standards, such as, ISO 20000: IT Service Management, and ISO 27001: Information Security Management.

At present, when an organization decides to obtain TickIT certification, it develops its quality management system and IT processes, has these evaluated by an accredited certification body, receives a certificate if that evaluation is successful, and the certification body follows this up with regular surveillance audits. The organization may do very well and achieve certification with no problems, or it may struggle and require several audit visits before the certificate is issued. And, that situation, doing very well or barely managing to meet the certification requirements, may continue for some time. Under the existing TickIT program (and the same is true for ISO 9001 certification), it is a simple pass-or-fail measure: it conveys no indication of the true quality maturity of the certified organization.

TickITplus is expected to be different, much different. An easier-to-use, redeveloped, and structured set of support and guidance documentation will be available on-line, some of it free. A defined process library will be available to aid development of a process model and to ensure consistent assessment. Regardless of whether or not an organization is seeking certification, large and small organizations will be encouraged to obtain and use the information to develop and build IT processes that conform to international standards requirements. They will also be able to select the process capability level at which they want or need to operate, and if desired, obtain an ISO 9001-based TickITplus certification that recognizes that level. As an added bonus, the methodology is applicable to all business processes, not just software development.

TickITplus Features

• A means of assessing the process capability of an organization, similar to the approach used by CMMI - the 'Capability Dimension'.
• A wider range of processes and IT related standards to be covered within its framework and by ISO 9001 certification - the 'Process Dimension'.
• A clear and concise definition of an organization's scope of activities - the 'Process Reference Model' derived from a standard 'Base Processes Library'.
• A more structured approach to assessment planning with improvement targets built in to these plans.
• A clarification of the specific requirements of certification under ISO 9001 and TickITplus, with a clearly structured set of documentation, rather than relying on guidance material only.
• Self Assessment, a route that organizations can adopt without the need for third party certification, but which can lead to eventual transfer to the full certification scheme.
• Skills Profile, a framework and infrastructure for the training, qualification, and development of TickITplus Auditors and Practitioners.

TickITplus Grading

The most obvious outward appearance of TickITplus is that certificates will be awarded a capability grading of Bronze, Silver, Gold, or Platinum. These grades will equate to levels 2 to 5 of ISO 15504: Software Engineering - Process Assessment, the standard used as a basis for capability maturity assessments. Current TickIT certification is approximately equivalent to TickITplus Bronze.

TickITplus is not intended as a direct competitor to CMMI type assessments; there is a different approach to assessments and ongoing maintenance and improvements. TickITplus is seen as a potential bridge in this direction and more suitable for either smaller companies, not wishing to take the CMMI step, or those who embrace both approaches.

TickITplus Launch

The launch of TickITplus as the new accredited scheme replacement for TickIT is scheduled for June 2009. Before that, trials will have taken place with selected organizations, with any lessons learned incorporated into the scheme details. Following the launch there will then be a 3 year period to allow organizations and auditors to migrate to the new scheme.

You can read more about TickITplus at their new web site.

The Institute of Internal Auditors (IAA) has published its latest Global Technology Audit Guide, which provides guidance on business continuity. According to the guide, the goal of business continuity management (BCM) "is to enable an organization to restore critical business processes after a disaster has been declared."

The guide focuses on how BCM is designed to enable business leaders to manage the level of risk the organization could encounter in the case of a natural or man-made disruptive event that affects the extended operability of the organization. The guide includes disaster recovery planning for continuity of critical information technology infrastructure and business application systems.

In the course of running a successful business, executives spend a lot of their time analyzing the marketplace, developing and implementing strategies, establishing performance and financial goals, developing and executing business operations plans, reporting financial results, and communicating to stakeholders. However, business continuity management is not high on every priority list.

Disasters in recent history have elevated the awareness of business continuity risks and their impact on corporate finances and operations, but there are still companies fail to heed the warning signs and are unprepared for a disaster or a business disruption. Man-made and natural disruptions to businesses may be unpredictable, but the impact can be managed if an effective BCM program is part of the overall governance framework.

The goal of BCM is to enable an organization to restore critical business processes after a disaster has been declared. It is a simple matter of risk management designed to create business continuity capabilities to match likely risks based on business value. There are companies of all sizes that are not adequately prepared for incidents which could render their business, or part of their business, inoperable for an extended period of time.

Documented cases demonstrate how companies, or entire industries, have sustained significant financial damage due to their lack of preparedness for unforeseen disasters. Whether due to economic downturns, lack of informed management, or other corporate cost decisions, recommendations for improved BCM tend to be ignored or deferred far into the future.

The key challenge is engaging executives to make BCM a priority. Any executive is likely to say that BCM is a good idea, but when it comes to taking action, some struggle to find the budget necessary to fund the program, as well as, an executive sponsor that has the time to ensure its success. The IIA guide document is intended to help communicate business continuity risk awareness, and support management in its development and maintenance of a BCM program.

Business continuity management (BCM) is one of three elements of an Emergency Management Program:

Emergency response (ER) is the first action that focuses on avoiding, deterring, and preventing disasters and preparing the organization to respond to a disaster. The goal of ER is lifesaving, safety, and initial efforts to limit the impact to asset damage.

Crisis management (CM) focuses on managing external and internal communications, and senior management activities, during a disaster. Even in an environment where ER and CM are mature and effective, BCM may remain inadequately addressed.

Business capability management (BCM) is focused on the recovery of critical business processes to minimize the financial and other impacts to a business caused during a disaster or business disruption. It must be integrated with ER and CM, but should be a separate program.

The bottom line is that the CAE should be able to answer these three simple and important questions related to business continuity:

1. Does the organization's leadership understand the current business continuity risk level and the potential impacts of likely degrees of loss?

2. Can the organization prove the business continuity risks are mitigated to an approved acceptable level and are recertified periodically?

3. If an unacceptable business continuity risk exists, but top management has decided to assume the risk, are the organization's owners, business partners, and other constituents aware of the decision not to mitigate the risk? And, has the decision to accept the risk been properly documented?

If the answer to any of these questions is "no," the IIA Guide can help. Specifically, this guide aims to help audit program managers understand the BCM program, risks, and controls, as well as, prepare them with information for executive discussions. The value of this guide is that it provides a high-level summary in straightforward business language for executives and detailed guidance for internal auditors in audit assessments.

To download the Guide in PDF format, go to this IIA Web Page. Also, refer to my March 2008 newsletter article on ISO 25999 for Business Continuity.

Have you heard of "Cloud Computing? The technology firm Gartner has it in second place on their top ten technologies that will dominate for the next three years. And, a search for the term on Google will yield millions of references.

Cloud computing is defined on Wikipedia as an Internet-based (Cloud) development and use of computer technology (Computing). As we can see, Cloud is a metaphor for the Internet, based on how it is depicted in computer network diagrams.

Cloud computing is a style of computing in which IT-related capabilities are provided as a service. It allows users to access technology-enabled services from the Internet without knowledge of, expertise with, or control over, the technology infrastructure that supports them.

Cloud computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on your computer. Since customers do not own the infrastructure and are merely accessing or renting it, they can forego capital expenditures and consume resources as a service, paying instead for what they actually use.

To learn more about cloud computing, see these articles in TechNews World:

Cloud Computing, Part 1: Some Breaks in the Fog

Cloud Computing, Part 2: A Who's Who

Did you know your organization may qualify for a reduction of up to 30% in the auditor days paid for third-party audits?

To be eligible for the Advanced Surveillance and Recertification Procedures (ASRP), you have to demonstrate that your quality or environmental management system is effective over a period of time. Under this ASRP program, the certification body can place greater reliance on your internal audit and management review processes, as well as, targeted surveillance topics, to evaluate the conformity of your management system.

Eligibility Criteria

1. The management system must have been conforming to requirements for a period of at least one complete certification cycle, including initial, surveillance and recertification audits.

Note: The demonstrated conformity may be based on the outcome of the first recertification audit at the end of a recertification cycle.

2. All nonconformities raised during the recertification cycle immediately prior to the utilization of ASRP must have been successfully resolved.

3. For an environmental system, the organization must have been in compliance with applicable legal requirements and not had any sanctions imposed for the recertification period.

4. The certification body must agree on the performance indicators on which to judge the ongoing effectiveness of the system, and you must consistently meet the agreed to targets.

For a QMS, the performance indicators must address at a minimum the ability to consistently provide product that meets customer and legal requirements, as well as, include requirements for the continual improvement of the effectiveness of the system.

For an EMS, the performance indicators must address at a minimum the demonstrated ability to achieve its environmental policy, objectives, and targets; comply with legal requirements; and include requirements for the continual improvement and prevention of pollution.

5. The certification body must have an enforceable agreement with your organization to provide access to relevant information.

For a QMS, this information is all customer satisfaction data collected or otherwise available.

For an EMS, it is all the relevant communications from external interested parties, as well as, relevant regulatory authorities.

6. Your organization's internal audit process must be managed in accordance with the guidance of ISO 19011, with particular reference to auditor competence as defined in clause 7.

The internal audit process must be sufficiently coordinated and integrated so it provides an evaluation of the whole management system, not just the performance of individual components.

7. The certification body must have contractually enforceable arrangements to enable it to increase the scope, frequency, and duration of its audits in the event of a deterioration of your organization's ability to meet agreed performance targets.

If the certification body plans an individual ASRP program that reduces the auditor time to be less than 70% of the base level time in the IAF guidance, it must justify the reduction and seek specific approval from its accreditation body prior to implementing the plan.

For more information on the Advanced Surveillance and Recertification Procedures, see the IAF Mandatory Document for ASRP (MD 3:2008) at the IAF web site.

Root Cause Analysis

ISO 9001:2008
Understanding ISO 9001:2008
Implementing ISO 9001:2008
Quality System Documentation
ISO 9001:2008 Internal Auditor
ISO 9001:2008 Lead Auditor

ISO 14001:2004
Implementing an EMS
ISO 14001:2004 Internal Auditor
ISO 14001:2004 Lead Auditor

ISO/TS 16949:2002
ISO/TS 16949:2002 Internal Auditor
ISO/TS 16949:2002 Lead Auditor
Understanding and Implementing ISO/TS 16949:2002

Core Tools
Advanced Product Quality Planning
Design Failure Modes Effects Analysis
Process Failure Modes Effects Analysis
Production Part Approval Process
Statistical Process Control
Measurement System Analysis

AS9100B:2004
AS9100 Internal Auditor
Implementing AS9100
AS9100 Lead Auditor

ISO 27001:2005
ISO 27001 - Understanding an ISMS
ISO 27001 - ISMS Implementation
ISO 27001 - ISMS Internal Auditor
ISO 27001 - ISMS Lead Auditor

ISO 20000-1:2005
Understanding ISO 20000
Implementing ISO 20000
ISO 20000 Internal Auditor

ISO 22000:2005
Understanding ISO 22000
ISO 22000 Internal Auditor
Understanding HACCP
Implementing SQF Systems
Advanced HACCP

ISO 13485:2003
Understanding ISO 13485:2003
ISO 13485:2003 Internal Auditor
Implementing ISO 13485:2003
ISO 9001 Lead Auditor - ISO 13485 Emphasis

Capability Maturity Model Integration
Introduction to CMMI v1.2

Six Sigma
Introduction to Statistics
Green Belt Certification
Black Belt Certification

Books
See our list of ISO 9001, Auditing, and Six Sigma books. Includes book descriptions and links to Amazon.

© 2000-2009 Whittington & Associates, LLC

email: larry@whittingtonassociates.com

phone: 770-517-7944

web: http://www.whittingtonassociates.com