Tuesday, March 31, 2009

Appraisal work – CMMI

The appraisal process is guided by something called the Method Definition Document (MDD). If you are not familiar with the appraisal process already (which you aren't 'cause you're asking the question), you don't want to try to read this unless you're doing some whacky exercise in self-hypnosis.

The MDD is based on a requirements spec called the Appraisal Requirements for CMMI (ARC). And, reading of that document is strictly forbidden without a prescription or special medical dispensation.

The documents are available for download from SEI's Web site and are actually well-written and really useful if you're a Lead Appraiser or studying to be one, but otherwise it's gonna sound like gibberish. Don't say we didn't warn you.

Just so you understand that the complete answer to this question is ordinarily delivered in 2 days' worth of training. We're obviously limited in what we can explain here.

We're going to pick up the appraisal with the portion of the appraisal that most people think about: the on-site period. It's that period of time when there's an appraisal team at your company and they're looking at your evidence and conducting interviews (or performing some other accepted form of verbal affirmation). It's at the end of this period that a company gets the results of the appraisal and, when all goes well, a rating.

Appraisal Team Members & Process Improvement Consulting

Every Appraisal for a rating is done by a team. The minimum number of people is 4 and that can include the Lead Appraiser. Every person on the team must meet certain individual pre-requisites and contribute to certain team-wide qualifications. It is best if the team's constituents include people from your company as well as outsiders.

At the appraisal, if you don't have (and can't create) qualified people in your company to be on the team, then you will need to bring in outside team members. (Most Lead Appraisers keep these in their back pockets -- kinda.) Outside team members are essentially consultants and charge as such. You're doing well if you can get outside team members for $1000/day. This would be very high-value. And, if you're only charged for a day where 1 day = the date on the calendar, and not 1 day = 8 hours, you're doing VERY well.
If your organization needs to get up to speed on CMMI, you'll probably do one of two things: (1) Look to hire an employee with the expected expertise, or (2) Look to hire a consultant with the expertise.

Which you choose to do depends on your organization's needs. The pros and cons of either approach are a basic matter of business and strategy. Either way, there's a cost. As for consultants, they're a lot like Lead Appraisers. And yes, many Lead Appraisers are also consultants. So, what and how they charge is largely up to them.

Lead Appraiser

The Lead Appraiser will need time to meet with you to plan the appraisal, perform some preliminary evidence review (called "Readiness Review") and then to perform the appraisal.

They also charge for all travel expenses as well as time they spend away from your site to do their preparatory and concluding activities. Also, they will often work by the "book". Meaning, a guidebook exists that assists with planning appraisals. The guide suggests that, based on the scope of the appraisal, appraisals be scheduled for a certain duration and not be condensed into fewer days and longer hours. Lead Appraisers are free to charge whatever they want. not many charge the way SEI does.

Someone will also need to provide Appraisal Team Training to the people you plan to have on the Appraisal Team. This takes 2 days and is usually done by a Lead Appraiser, and best if done by the Lead Appraiser you plan to have doing your appraisal.

Models for Assessment and Baselines

A baseline is a current level of performance. An assessment determines the baseline against the model (goal to be accomplished). In addition to the baseline and the model, the third criterion required for continuous improvement is a method for moving from the current baseline to the desired goal.

The assessment against the model characterizes the current practice within an organization in terms of the capability of the selected processes. The results may be used to drive process improvement activities or process capability determination by analyzing the results in the context of the organization's business needs and identifying strengths, weaknesses, and risks inherent in the processes.
Sequencing of the improvements is determined by the organization, and then assessments are used again to show whether or not performance is being accomplished.

Many organizations put new programs into place without a model, and, as a result, have no means of determining whether performance has changed. The effective use of a model, including determining baselines and regular assessments, can help IT management continually improve effectiveness and efficiency.

Implement CMMI

There's what we call the blunt-object (or silo'd or stove-piped) approach, which is, unfortunately, what seems to be the most common approach. In this approach CMMI is implemented with the grace and finesse of a heavy, blunt object at the end of a long lever -- impacting development organizations and project managers' collective craniums.

And then, there's the reality-based approach. In which, processes are implemented in such a way that project personnel may not even know it's happening. Can you guess which one we advocate?

The blunt-object approach resembles what many process improvement experts call "process silos", or "stove pipes". This approach is also often implemented *to* a development team *by* some external process entity with brute force and very extreme prejudice.

So, not only does the blunt approach employ some very unsavory techniques, subjecting its royal subjects to cruel and unusual process punishment, it also (in its design) is characterized by a "look and feel" of a process where each process is in its own vacuum, without any connection to other processes (or to reality, for that matter), and where the practices of the processes are somehow expected to be performed serially, from one to the next, in the absence of any other project context.

Models for Assessment and Baselines

A baseline is a current level of performance. An assessment determines the baseline against the model (goal to be accomplished). In addition to the baseline and the model, the third criterion required for continuous improvement is a method for moving from the current baseline to the desired goal.

The assessment against the model characterizes the current practice within an organization in terms of the capability of the selected processes. The results may be used to drive process improvement activities or process capability determination by analyzing the results in the context of the organization's business needs and identifying strengths, weaknesses, and risks inherent in the processes.
Sequencing of the improvements is determined by the organization, and then assessments are used again to show whether or not performance is being accomplished.

Many organizations put new programs into place without a model, and, as a result, have no means of determining whether performance has changed. The effective use of a model, including determining baselines and regular assessments, can help IT management continually improve effectiveness and efficiency.

Staged Versus Continuous Models

Staged models - Staged models are comprised of a number of distinct levels of maturity. Each level of maturity is further decomposed into a number of processes that are fixed to that level of maturity.
The processes themselves are staged and serve as foundations for the next process.
Likewise, each level of maturity is the foundation for the next maturity level. The Software Engineering Institute’s Capability Maturity Model is a prime example of a staged model.

Continuous models - In the continuous model, processes are individually improved along a maturity scale independently of each other. For example, the project planning process could be at a much higher capability level than the quality assurance process. ISO/IEC TR 15504 (SPICE) is an example of a continuous model.

Processes in CMMI

Process Areas (PAs) in CMMI, and we're not being obtuse or overly pedantic about semantics. It's an important distinction to understand between processes and Process Areas (PAs).

So, there are *no* processes in CMMI. No processes, no procedures, no work instructions, nothing. This is often very confusing to CMMI newcomers. You see, there are many practices in CMMI that *are* part of typical product development and project management practices.

Sometimes they are almost exactly what a given project or organization might do, but sometimes the practices in CMMI sound the same as possible typical product development and project management practices in name only and the similarity ends there. Despite the similar names used in both typical development and management practices and in CMMI, they are *not* do be assumed to be referring to one-in-the-same activities.

That alone is enough to cause endless hours, days, or months of confusion. What CMMI practices are, are practices that improve existing product development and project management practices, but do not *define* what those product development and project management practices must be for any given project or organization.

Capability Maturity Model Integration - Three

Furthermore, CMMI is just a model, it's not reality. Like any other model, CMMI reflects one version of reality, and like most models, it's rather idealistic and unrealistic -- at least in some ways. When understood as *just* a model, people implementing CMMI have a much higher chance of implementing something of lasting value.

As a model, what CMMI lacks is context. Specifically, the context of the organization in which it will be implemented for process improvement. Together with the organization's context, CMMI can be applied to create a process improvement solution appropriate to the context of each unique organization.
Putting it all together:

CMMI is a model for process improvement from which (astute) organizations will abstract and create process improvement solutions that fit their unique development environment

Capability Maturity Model Integration - Two

Before we get too off-track... CMMI is meant to help engineering development organizations improve on their capability to consistently and predictably deliver the products their customers want, when they want them and at a price they're willing to pay. From a purely inwardly-facing perspective, CMMI helps companies get from estimates to actuals in the black.

Without some insight into and control over their internal business processes, how else can a company know how well they're doing before it's too late to do anything about it? And if/when they wait until the end of a project to see how close/far they were to their promises/expectations, without some idea of what their processes are and how they work, how else could a company ever make whatever changes or improvements they'd want/need to make in order to do better next time.

CMMI provides the models from which to pursue these sorts of insights and activities for improvement. It's a place to start, not a final destination. CMMI can't tell an organization what is or isn't important to them. CMMI, however, can provide a path for an organization to achieve its performance goals.

Software Process Improvement Capability dEtermination (SPICE)

ISO/IEC TR 15504:1998 provides a framework for the assessment of software processes that is appropriate across all application domains and organization sizes. This framework can be used by organizations that plan, manage, monitor, control, and improve the acquisition, supply, development, operation, evolution, and support of software.

The SPICE standard provides a structured approach for assessing software processes by, or on behalf of, an organization with the objectives of:
Understanding the state of the organization’s processes for process improvement (establish process baselines), Determining the suitability of the organization’s processes for a particular requirement or class of requirements, Determining the suitability of another organization’s processes for a particular contract or class of contracts

One important feature of this model is that it produces a profile of all the assessed processes with a capability level rating for each, rather than simply a pass/fail rating. During the trial period these profiles are being used to determine target profiles, which apply to different sized organizations and domains. Suppliers can then use the target profiles for process improvement goals and acquirers can use the profiles to set acceptable standards for proposals.

CMMI - Capability Maturity Model Integration

CMMI stands for "Capability Maturity Model Integration". It's the integration of several other CMMs (Capability Maturity Models). By integrating these other CMMs, it also becomes an integration of the processes and practices within the model in ways that previous incarnations of the model(s) didn't achieve. The CMMI is a framework for business process improvement.

It is NOT an engineering development standard or a development life cycle. Please take a moment to re-read and reflect on that before continuing.
The business processes of developing engineered solutions are the focus of CMMI. This helps understand why it is most widely applied in software and systems engineering organizations.

But, where it is applied is a significantly distinct matter from being anything even remotely akin to a standard or certification mechanism for the engineering or technology required to develop products. If an organization chose to do so, CMMI could be applied in the construction or even media production industries.


An important purpose of TickIT, which is supported by the UK and Swedish software industries, has been to stimulate software system developers to think about: what quality really is in the context of the processes of software development, how quality may be achieved, and how quality management systems may be continuously improved.

Although certification of compliance to ISO 9001 is a contractual requirement for software suppliers in certain market areas, it should be a by-product of the more fundamental aims of quality achievement and improvement, and the delivery of customer satisfaction.

With regard to certification itself, the objectives are to: improve market confidence in third party quality management system certification through accredited certification bodies for the software sector, improve professional practice amongst quality management system auditors in the software sector,
publish authoritative guidance material (the TickIT Guide) for all stakeholders

Control of Nonconforming Product

Control of Nonconforming Product (SOP 83-01) establishes a standard method for documenting nonconforming product disposition and reprocessing. The key here is to prevent nonconforming raw materials, parts, components, in-process materials, and finished products from being inadvertently used. Just because you have nonconforming product doesn’t mean an automatic business loss. Look for ways to rework it, use for alternative applications, and return if possible to the vendor. Use Form 83-1, Nonconforming Product Record and Form 83-2, Nonconforming Product Tag to document nonconforming products.

Utilize statistical techniques for establishing, controlling, and verifying process capabilities and product characteristics per SOP 82-03, "Statistical Techniques".

At the beginning of each calendar year, the management team (President/CEO, Quality Assurance, Administration, Sales/Marketing, Operations, Engineering) determines goals and objectives for improving your operations. Encourage personnel at all levels to provide ideas for improving products, processes, systems, productivity, and the work environment per SOP 85-01, Continuous Improvement and use Form 85-1, Improvement Suggestion Report to document improvement suggestions .

Internal Quality Audits

Internal Quality Audits

Internal Quality Audits (SOP 82-02) establishes a standard method for evaluating your quality assurance system. Quality audits must be performed by qualified yet independent personnel. Very often, persons qualified to do audits are not independent. Such as, a Production Manager audits Process Control activities. Instead, the Production Manager could inspect the Engineering Department.

Remember follow-up audits are always necessary, unless justified. Use Form 82-2, Internal Quality Audit Report and Form 82-3, ISO 9001 Audit Checklist to document internal audits.

Statistical Techniques (SOP 82-03) establishes a standard method for applying statistical techniques to achieve consistent quality. Various statistical techniques used for establishing, controlling, and verifying product / process capability, e.g., x bar charts, Cpk, and AQL levels are commonly used. Use your judgment on what is best for your company.

Control of Monitoring and Measuring Devices

Control of Monitoring Measuring Devices (SOP 76-01) establishes a standard method for controlling and documenting the maintenance of all monitoring and measuring devices (MMD). All MMD equipment must be calibrated, used, and stored properly.

Make sure MMD equipment is immediately removed when found out of calibration. Also, ensure accuracy and precision requirements are established for MMD equipment. Ensure accuracy and precision requirements are established for all MMD equipment. Use Form 76-1, Equipment Calibration Record to document equipment calibrations if calibrations are performed in-house.

Servicing (SOP 75-09) establishes a standard method for documenting service requests. Make sure service personnel do not service notes on pieces of paper, note pads, and Post-Itä notes. They can easily be lost under stacks of paper, fall behind desks, or get stuck in end boxes. Use Form 75-4, Service Record to help you document all service requests

Inspection and Testing

Inspection and Testing SOP 75-05 establishes a standard method for controlling inspection and testing activities. Raw materials parts, components, and in-process materials must be inspected and/or tested to ensure they meet specified requirements.

Use Form 74-2, Component Receiving Log to document inspections and/or tests of incoming parts and raw materials. Also establish a standard method for controlling inspection and test activities on incoming parts, in-process materials, and finished products.

The inspection and test status of product must be maintained at all stages, including raw materials, parts, components, in-process materials, and finished products. Note: only products passing required inspections and tests distributed. Use Form 75-5, Passed Required Inspections and Tests to document test status.
Handling, Storage, Packaging, & Delivery (SOP 75-06) establishes a standard method for handling, storing, packaging, and delivery of finished products.

Focus your resources on ensuring delivery methods prevent product damage and ensuring First-in First-out (FIFO) product distribution methods are used.

Purchasing & Product Identification and Traceability

Purchasing (SOP 74-01) establishes a standard method for conducting purchasing activities and Verification of Purchased Parts (SOP 75-02) establishes a standard method for verifying purchased parts conform to specifications. Spend resources on vendors that provide custom or critical parts for your company’s operations.

Also, don’t forget to include vendors that provide services, such as, pest control service, shipping companies (UPS, FedEx, etc.), and consultants. Use Form 74-1, Supplier Self-Evaluation to document supplier self-evaluations, use Form 74-2, Component Receiving Log and Form 74-3, Quarantine Tag to document receiving activities.

Product Identification and Traceability (SOP 75-04) establishes a standard method for identifying all parts or components that enter into your quality system. Product ID and Traceability starts with receipt of raw material and ends with issuance to finished products. Use Form 75-2, Component Traceability Tag to identify lots or batches of incoming parts and raw materials.



The organization needs to ensure that purchased products and services meet purchasing requirements. The purchasing group must establish criteria for how they evaluate and choose suppliers. These criteria must be based on the suppliers’ ability to provide products and services that meet order specifications, especially product and service quality requirements.

The extent of the controls depend on the importance of the purchased goods in the finished product. Finally, records must be kept showing how purchased products and services were evaluated.

Clearly describe on purchase orders the product or service being ordered. Consider including the following specifications:Review and approve purchasing requirements before sending them out.Carry out a plan for verifying that purchased services and materials are adequate, i.e. meet purchase specifications.

Customer-related processes

The Standard requires the organization to determine product requirements. These requirements can come from the customer, may be mandated by laws or regulations, and include generally accepted standards within your industry or market.

Requirements are established by standard contracts or oral agreements that the sales department uses in discussions with customers, and other sources.
After gathering preliminary product requirements, these requirements need to be reviewed to be sure that the customer understands them and that the organization is meeting these requirements.

This review must ensure:Routine orders for items described in a catalog of products are considered reviewed when the relevant product information is reviewed.

Human resources

Human resources

People performing work affecting product and service quality must be competent to carry out that work. This competency is attained through a combination of education, training, skills, and experience.

The infrastructure for a QMS includes the building, workspace, equipment, and the supporting services involved in creating the organization’s products or services. The organization will needs to determine, provide and maintain the infrastructure needed to achieve the planned results.

The work environment of the organization must not interfere with the ability of employees to perform effectively in order to meet quality requirements.

Measurement Analysis & Improvement

This clause covers the wider monitoring, measurement, analysis and improvement of the quality management system. The organisation shall plan and implement the monitoring, measurement, analysis and improvement processes needed to demonstrate conformity of the product/service, to ensure conformity of the QMS and to continually improve the effectiveness of the QMS. This shall include determination of applicable methods, including statistical techniques, and the extent of their use.

The organisation shall apply suitable methods for monitoring and measuring the QMS processes. These methods shall demonstrate the ability of the processes to achieve planned results. When planned results are not achieved, corrective action shall be taken, as appropriate, to ensure conformity of the service.

There is considerable overlap between this clause and the previous one. In many cases the same monitoring or measurement procedures will be adequate for the purposes of monitoring or measuring both processes and products / services.

Product Realization

Product Master Record (SOP 71-01) establishes a standard method for initiating and changing quality system documentation. A Product Master Record is the compilation of records containing the procedures and specifications for delivering a finished product or service.
Contract Review (SOP 72-01) establishes a standard method for performing contract review activities. A contract includes any written, verbal, or electronic order accepted by a company from a customer. Ensure that all people who take orders have immediate access to product catalogs, price lists, and shipping costs. Have a second person review the contract or order for clarity.

Ensure your company can meet the demand. If you cannot, inform the customer. Revise shipping dates as necessary. No specific form is provided for contract review. However, a company’s invoicing system must be documented and included as part of the contract review system. You must ensure that all changes to contracts, orders, etc.… are clearly documented and reviewed and approved.

Customer Complaints and Feedback (SOP 72-02) establishes a standard method for documenting customer complaint and conducting corrective and preventive actions. The key here is to ensure collection of all complaints. Very often, complaints are written on pieces of paper, desk calendars, and Post-Itä notes. And, lost under stacks of paper or end boxes. Use your Form 72-1, Customer Complaint Record to document complaints.

Resource Management

Management needs to determine and provide the resources needed to implement and maintain the quality management. Management needs to continually improve its effectiveness and enhances customer satisfaction. Use SOP 54-01, Quality Planning and SOP 82-01, Customer Satisfaction to help.

The goal here is always hire competent personnel. Personnel competencies should be based on appropriate education, training, skills, and experience. Maintains records of education, training, skills, and experience of all staff. Manage your human resources per 61-01, Resource Management.

Also identify employee-training needs via Job Descriptions. Conduct training for all personnel per SOP 62-01, "Training" and periodically evaluate the training provided per SOP 62-01, "Training".

Because of the revolving company door with respect to employees, and inevitably employees will be on vacation or sick when training occurs, there will always be gaps in training.

Management Review

Management Review (SOP 56-01) establishes a standard method for documenting management reviews of the quality system. Management should review all reports and trends related to the overall state of the quality system.

Such reports and trends include back orders, non-conforming finished product lot, customer complaints, and Internal Quality Audit trends. After reviewing these quality data, management must describe the steps to be taken to resolve these issues. Use Form 56-1, Management Review Record for documenting management reviews.

Define the responsibilities and authorities of staff at all levels per SOP 55-02 & SOP 55-03, Department Personnel and job descriptions where additional specific responsibilities and authorities are described.

Also define the interrelation of staff per SOP 55-01, Organizational Charts. Each department: Quality Assurance, Administration, Sales/Marketing, Operations, and Engineering are responsible for updating their department responsibilities, as the organizational structure changes.

Quality Policy & Quality Planning

A quality policy is the overall intentions by management with regard to quality. Accomplish this goal by listening to customer's needs and translating those needs into continuously improved products and services. Then translate into a quality policy is understood, implemented, and maintained at all levels. This is accomplished through one-on-one and/or group training of all employees.

Quality Planning (SOP 54-01) establishes a standard method for documenting, and maintaining all activities affecting the quality system. Quality System reviews must be performed prior to the addition of significant new products, projects, or contracts that have an impact on the company’s quality system.

Examples include moving facility locations, addition of personnel, and addition or expansion of product lines or servicing operations. Use Form 54-1, Quality Planning Record for documenting significant changes affecting the quality system.

Management Commitment & Customer Focus

Management Commitment & Customer Focus

Management defines, develops and implements the quality management system per SOP 51-01, Management Commitment. Conducts weekly staff / departmental meetings and discusses the importance of meeting the Customer requirements,

Quality objectives, Statutory, legal, and regulatory requirements, and Continuous improvement goals.

Management ensures that customer requirements are determined and fulfilled per SOP 82-01, Customer Satisfaction and 85-01, Continuous Improvement.

Document Records, and Data Control

Document and Data Control (SOP 42-02) establishes a standard procedure for controlling documents and data and to assure that only valid information is available for use. Documents and data applies to all information manually or electronically recorded that describe attributes of the quality system. Form 42-1, Master Document List is a documentation aid to help a company keep track of documents currently available.

Change Control (SOP 42-03) is intended to establish a standard method for initiating and changing documents affecting the quality system. Use Form 42-2, Change Control Record for initiating and changing quality system documentation.

Proper Documentation Practices (SOP 42-04) is intended to establish a standard procedure for properly documenting information. Good record keeping practices are necessary since records are usually the only means to assure compliance to ISO.

Control of Quality Records (SOP 42-05) establishes a standard method for identification, collection, and storing quality records. Quality records absolutely must be accurate, legible, and stored in a permanent medium. Also, when asked for a given quality record, you should be able to produce the record within 5 - 30 minutes. Unwarranted delays cast doubt on the document retrieval process. No form is provided for this section.

ISO 9000 series standards

The ISO 9000 series is a set of five individual, but related, international standards on quality management and quality assurance. They are generic, not specific to any particular products. They can be used by manufacturing and service industries alike. These standards were developed to effectively document the quality system elements to be implemented in order to maintain an efficient quality system in your company.

The ISO 9000 Series standards do not themselves specify the technology to be used for implementing quality system elements. There are several benefits to implementing this series in your company

The ISO 14000 family, of which the first standards were published in September and October 1996, addresses various aspects of environmental management
The ISO (Internationale Organisation pour Standardization) was formed in 1947 and is based In Geneva, Switzerland.

The ISO consists of a worldwide group of government representatives that establish minimum requirements for manufacturing products and/or providing services. These requirements are collectively grouped into quality management system models.

ISO - The International Organization for Standardization

Standards are documented agreements containing technical specifications or other precise criteria to be used consistently as rules, guidelines, to ensure that material, products, processes and services are fit for their purpose

The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies from some 130 countries, one from each country.
ISO is a non-governmental organization established in 1947. ISO is made up of approximately 180 Technical Committees.

The purpose of ISO is to promote the development of standardization and related world activities to facilitate the international exchange of goods and services, and to develop cooperation in intellectual, scientific, technological, and economic activity.

The results of ISO technical work are published as international standards. The standards discussed here are a result of this process

Traditional Management to Quality Management

Most managers practice traditional management. They have been taught to control their organization and employees, using an “I’ll tell you what to do, and you’ll do it” mentality. Many mangers look at the short-term because their commitment to the organization is short range.

The culture change required to build a quality management environment is significant. Manage­ment must change its philosophy, practices, and assumptions about work and people. The biggest mistake usually made when implementing a quality management environment is underestimating the cultural changes that must occur and the time required for accomplishing these changes.

It is usually felt that only a few control charts are needed, and little effort is made to change the culture of the organization.

The programs needed to change from a traditional to quality management culture must be customized for an organization and its current culture. Figure 4-3 illustrates cultural changes that can be made.

Establishing Mutual Trust

One of the first questions employees ask during quality management implementation when management is asking them to help improve quality is, “Can we trust management?” Mutual trust is mandatory for building management-employee process improvement teams.

Management must trust employees enough to ask for their help and to share with them the responsibility for continuous process improvement. Employees must trust management enough to respond to this request by contributing their knowledge and their ideas.

Actively listening down, not talking down, can be the first step in establishing trust. Listening down helps establish two-way communication, and carries two-way responsibility. Those being listened to should have something constructive to say. Ideas for improvement, not yesterday’s complaints, are needed. Those doing the listening need to be ready to react to the ideas that will be generated. Pushing responsibility down the organization also helps build trust.

Decisions for process improvement should occur at the lowest possible level in the organization. Decisions that must be elevated should be responded to in a timely manner. If an idea cannot be used, an explanation should be given to those making the recommendation. A timely “no thank you because” will be accepted.

Awareness Training

Understanding precedes behavior change. It is difficult to understand and deal with a new concept without being aware of its existence. Awareness training should create knowledge of the defined topic and initiate some action associated with that topic; however, these objectives do not have to occur simultaneously.

For example, create awareness about the effectiveness of a software inspection technique, and start the process to implement that technique a few weeks later. The delay allows time to assimilate the concept before beginning action. Until people understand an area and its impact, they are not prepared to act.

Task 1: Select awareness topic - The topic is usually a problem or a new approach to doing work and is normally related to accomplishing the organization’s mission. Sample topics include the number-one cause of operational problems, or a new work approach, such as implementing quality principles in the IT group.


Leadership and management are two different things. While a manager works within the system following the accepted practices of the system, a leader determines where the organization needs to be, and then does what is necessary to get there. In a business context, leadership is the ability to build the commitment of employees, to endow an organization with a positive perception of itself, and to give employees a positive perception of their role within the business.

While programming experience, technical prowess, and management ability may be important qualifications for top-level IT management, leadership ability is the critical element.

Traditional management techniques focus on employee behavior, not the employee. Feelings of achievement, recognition for good work, and a sense of meaningful professional advancement are foreign to many workers, as managers do not know how to make employees feel valuable. Without such messages, it is impossible to build employee commitment.

Too many managers lack the formal training, or sometimes even the common sense, to understand that most employees need realistic feedback on their performance. While performance appraisals can be used as a tool to encourage better work behavior, true leaders provide this type of feedback, naturally, in their day-to-day action.

Schedule Metrics & Change Metrics

Schedule metrics basically provide you with schedule variance for projects – scheduled completion, actual completion date and the number of days of variance.

It gives at one place, all the schedule completion dates – assists in ensuring that projects are on schedule. This used in conjunction with Project Progress, gets independent info to senior management to effectively intervene to ensure that all projects are delivered on time.
Change Metrics provide how stable the requirements are.

Function Point per Change help us in envisaging the impact of the change requests being placed on the organization.

ategory-wise changes facilitate our understanding of areas that need more focus. Especially when these metrics are used in conjunction with Effort Metrics – phase-wise effort spent, throws light on areas that may have been neglected.

For example, if we find that more change requests have been received in the change category of “Requirements Change” and we find that relatively lesser time is spent on Requirements phase, we know that we need to focus more on Requirements engineering

Effort Metrics

Employees spend effort on various activities most of which are productive and desirable and some of which are unproductive and undesirable.

It is also common fact that developers spend more time in coding than in other significant areas like requirements, design and testing.
This data when used in conjunction with defect metrics can throw significant light on areas that need more focus.

For example, if defect metrics show more defects in requirements area, and effort metrics show that relatively less effort is spent in requirements analysis – it becomes obvious that the organization has not been focusing on requirements analysis as much as it should and that balance is out of order.

Then the course of action is clear – spend more effort on requirements analysis and restore balance.

Productivity Metrics

Productivity may be roughly defined as the rate of working. In software realm, productivity is specified differently as –LOC per PD (Lines of Code per Person Day)
Person Hours per Function Point / Use Case Point, Number of Pages per Person Day – for requirements, design etc.

Number of Test Cases per person Day So on, Productivity metrics tell us the efficiency of working. It is one thing to deliver the and it is another to deliver profitably. Productivity helps us to benchmark our organization with comparable organizations and find out if there is room for improving the efficiency of the organization.

For example, we are achieving 50 LOC per PD and industry benchmark is 60, we realize that there is an opportunity of improvement for us to see that we achieve 60 LOC per PD.

PMPal provides productivity metrics for all attributes (Java, VB, Documents and so on) in a easy manner at the click of a mouse button so that you can benchmark your organization vis-à-vis others in your sphere.

Quality Metrics

Statements about organizational efficiency are incomplete without an assessment of quality. Six Sigma philosophy allows three defects in a million opportunities to err. In software parlance, three defects in a million lines of code is acceptable. Measurement of defects, and analyzing their origin are key to improvements in development process. PMPal, provides defect metrics in –Defects by origin – like coding, design, requirements etc. so that the specific software engineering areas can be improved upon.

Defect by category – PMPal comes with about seventy defect categories which can be maintained (add, modify or delete) by the client. This will facilitate defect analysis - such as ABC analysis - A (70% of defects due to 10% causes), B (20% of defects due to 20% causes), and C (10% of defects due to 70% causes) and effect targeted improvements in development processes to eliminate defects.

Severity of defects – PMPal gives three classes defects – Critical, Major and Minor – so that more effort can be dedicated to analyzing Critical defects and improvements can be brought about, Defect Metrics for employees – PMPal gives defect metrics for any selected employee – there by efforts can be focused on those employees who are injecting more defects.

Function Points

Counting lines of code is but one way to measure size. Another one is the function point. Both are surrogate indicators of the opportunities for error (OFE) in the defect density metrics. In recent years the function point has been gaining acceptance in application development in terms of both productivity (e.g., function points per person-year) and quality (e.g., defects per function point).
In this section we provide a concise summary of the subject.

A function can be defined as a collection of executable statements that performs a certain task, together with declarations of the formal parameters and local variables manipulated by those statements (Conte et al., 1986).

The ultimate measure of software productivity is the number of functions a development team can produce given a certain amount of resource, regardless of the size of the software in lines of code.

The defect rate metric, ideally, is indexed to the number of functions a software provides.
If defects per unit of functions is low, then the software should have better quality even though the defects per KLOC value could be higher—when the functions were implemented by fewer lines of code. However, measuring functions is theoretically promising but realistically very difficult.

The Defect Density Metric

Although seemingly straightforward, comparing the defect rates of software products involves many issues. In this section we try to articulate the major points.

To define a rate, we first have to operationalize the numerator and the denominator, and specify the time frame. As discussed in Chapter 3, the general concept of defect rate is the number of defects over the opportunities for error (OFE) during a specific time frame.

We have just discussed the definitions of software defect and failure. Because failures are defects materialized, we can use the number of unique causes of observed failures to approximate the number of defects in the software. The denominator is the size of the software, usually expressed in thousand lines of code (KLOC) or in the number of function points.

In terms of time frames, various operational definitions are used for the life of product (LOP), ranging from one year to many years after the software product’s release to the general market. In our experience with operating systems, usually more than 95% of the defects are found within four years of the software’s release. For application software, most defects are normally found within two years of its release.

Product Quality Metrics

Intrinsic product quality is usually measured by the number of “bugs” (functional defects) in the software or by how long the software can run before encountering a “crash.” In operational definitions, the two metrics are defect density (rate) and mean time to failure (MTTF). The MTTF metric is most often used with safety-critical systems such as the airline traffic control systems, avionics, and weapons.

For instance, the U.S. government mandates that its air traffic control system cannot be unavailable for more than three seconds per year. In civilian airliners, the probability of certain catastrophic failures must be no worse than 10-9 per hour (Littlewood and Strigini, 1992). The defect density metric, in contrast, is used in many commercial software systems.

The two metrics are correlated but are different enough to merit close attention. First, one measures the time between failures, the other measures the defects relative to the software size (lines of code, function points, etc.).

Second, although it is difficult to separate defects and failures in actual measurements and data tracking, failures and defects (or faults) have different meanings. According to the IEEE/ American National Standards Institute (ANSI) standard (982.2):

Software Quality Metrics

Software metrics can be classified into three categories: product metrics, process metrics, and project metrics. Product metrics describe the characteristics of the product such as size, complexity, design features, performance, and quality level. Process metrics can be used to improve software development and maintenance. Examples include the effectiveness of defect removal during development, the pattern of testing defect arrival, and the response time of the fix process. Project metrics describe the project characteristics and execution.

Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity. Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process metrics and project metrics.

Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project. In general, software quality metrics are more closely associated with process and product metrics than with project metrics. Nonetheless, the project parameters such as the number of developers and their skill levels, the schedule, the size, and the organization structure certainly affect the quality of the product. Software quality metrics can be divided further into end-product quality metrics and in-process quality metrics.

The essence of software quality engineering is to investigate the relationships among in-process metrics, project characteristics, and end-product quality, and, based on the findings, to engineer improvements in both process and product quality. Moreover, we should view quality from the entire software life-cycle perspective and, in this regard, we should include metrics that measure the quality level of the maintenance process as another category of software quality metrics.

Process Compliance

A process may act as a guide for project teams based on accumulated best practices from experience, but it may also serve to ensure that essential procedures have been followed. These may be application security practices, corporate governance requirements, or procedures mandated by an engagement, such as health care or government contracts.

There may be a significant investment in engineering rigorous processes which capture these requirements, but they may not be adhered to in practice.

Process compliance has traditionally been assessed through audits, which are costly and often inaccurate. With the emergence of process automation through IRIS Process Live, on-demand compliance reports can be generated from real enactment data.

Teams are empowered to take corrective action earlier rather than discovering problems later where penalties may result. Compliance reports can be provided to customers to document that critical procedures have been followed.

A company that can not only capture important practices, but demonstrate that they have been followed is at a significant competitive advantage for critical projects.

The Cycles of PDCA and PDSA

The continued improvement of total quality management should be based on a circular system rather than a continuous single line because quality should not be thought of as having an ending. Treating it as a linear path does allow businesses to reach a specific goal, yet this stops them from continuing to search for places that need further improvement and thus prevents the creation of a new goal altogether.

When it is treated as a cycle the businesses will try to locate other faults and refine improvements because as one rotation ends another one begins. The cycle consists of stages. In sequence these are plan, do, check, and act. Shewhart first created this process in the early twentieth century and it held firm. It was revised by Deming from check to study, thus establishing its initials of PDSA.

Businesses using this cycle focus on productivity in the present and for the future using various diagrams, charts, and the like to plan, do, study, and act. Various diagrams include the activity network, affinity, cause and effect, matrix, scatter and tree diagrams and to a certain extent the interrelationships digraph.

Multiple charts of this nature include the control, flow, process decision program, Pareto, and run charts and the histogram. The prioritization matrix is another useful layout that businesses use to manage the quadrille cycle by organizing ideas into groups that may correspond to the relationships another similar item

Point XIII & XIV: Encouraging education and Self-improvement & Taking Action to Accomplish the Transformation

Deming advises that businesses should promote the institution of vigorous programs of education and self-improvement for every employee at all levels . Employees who have a career within a certain corporation are more than likely to change positions due to newly created jobs or the decline of out-of-date ones rather than changing to gain an increase in pay.

This is the main reason why there will presumably always remain a need for educating employees. As employees advance in knowledge both within and outside the criteria of their jobs, they gain satisfaction in this opportunity, which adds increased self worth and dignity that in effect brings forth improvements in themselves and the company as well.

The final asset of Deming’s Fourteen Points is to put everyone in the company to work in effort to accomplish a successful transformation. It basically sets forth the motivation to implement the previous thirteen points with vital patience. He emphasizes that change takes time, but its long-term outcomes are worth the initial costs and wait. He summarizes these approaches by a revision of Shewhart’s Plan, Do, Check, Act Cycle into his own quadrille cycle.

Once this cycle is set into motion by the leader, the only one who can start it, partnerships created from involvement form and the latter springs from the former generating a self-sustaining project for the future of the corporation.

Point XII: Removing Barriers that Rob People of Pride of Workmanship

Abolishing annual performance appraisals promotes self worth and pride in employees because it creates improved ways for individuals to receive increases in pay.

Instead of basing the pay increase on achieved results without taking into account the possible barriers outside the control of the employees or overseeing their work, the increase is solely based on how much it would cost to hire a new employee with the same skills to replace the position.

Handling pay increases in this manner prevents unneeded competition between workers and promotes teamwork since all will reap the benefit of the increase rather than a few favorites.

In addition, by eliminating the annual rating or merit system, tension is relieved creating room for pride in workmanship, which contributes to further improvements

Point X: & XI Eliminating Slogans, Exhortations, and Targets for the Workforce & Eliminating Numerical Controls for the Workforce

Pointless signs hanging throughout the company in an attempt to promote corporate objectives is useless to employees and a waste of money to the business. Providing employees with company policies and purposes is essential but doing so in a tactful manner in memos and letters is less insulting and ignored than are the tacky posters dispersed throughout the organization in no particular order.
Presenting such necessary information in the latter manner only proves failure of the management to express company goals and objectives adequately and professionally, thus using signs to speak to employees rather than by personal confrontations.

Eliminating numerical quotas for the staff and numerical goals for the management increase quality because each employee is no longer based on the statistical average worker but on their own performance without comparative judgements making it easier for management to advance individuals who work to the highest potential. This in effect encourages the actual above-average half especially to work to their full potential at all times rather than merely work to meet the proposed numerical objective before halting their efforts or working slower than is necessary to prevent reaching the set number before the desired time.

Also setting numerical controls prevents all employees from producing further effort after the established standard has been met because they essentially relax after meeting the objective rather than attempting to go beyond the requirement as to not disrupt the controlled amount. From results such as these, it is difficult to base pay advances since all employees work with the same minimal potential to simply reach the standard rather than exceed it.

Point VIII: & XI: Driving Out Fear & Breaking Down Barriers between Staff Areas

Fear is always present within individuals and in the company to which they are apart. Removing fear allows the free flow of ideas throughout the corporation. It will not vanish completely from any organization where decisions of a higher body revolve around employee advancement and pay, which is an important part of business.

It is possible to drive out this fear from individuals who are afraid to converse their real ideas to management and replace them with false impressions to secure their current position in good standing or precede further.
This is possible by replacing the fear in the most substantial form as insecurity with planning, analysis, and ultimately honesty without the possibility of loosing ones position or room for advancement. Doing away with a vast degree of fear between levels and within management itself allows the company to improve because exchanges of influential contributions in the corporation will be able to blossom.

The employees from each level of the corporation must work well with the other levels in order for the company to function at its best potential. This includes understanding the problems among the various branches of the business at each level. Only after a high level of awareness and commitment exists between them can change initially develop because cooperation requires this earnest fundamental transition.

When managers share information with employees, they recognize that a complication exists that inhibits employees from providing statements, presenting opinions or ideas, and asking questions in large group settings. Once realized, the managerial staff can prompt the specific brand of trust and interest needed by the certain group of individuals to promote an honest exchange of ideas between levels without these barriers of communication.

Point V: & VI : Improving Constantly and Forever the System of Production & Instituting on the Job Training

Improving every process concerning planning, production, and service provides better products for the consumer and higher profits for the business. The standards set forth under this point are the basis of the reengineering process, which is not merely an improved process as associated with Kaizen in Japan, but a completely new one altogether.

Kaizen literally translates to the English meaning of improvement. It incorporates continuous growth through small gains in improvement of current processes while reengineering focuses on eliminating processes that are no longer needed to increase improvements and are actually to some degree preventing it.

Deming urges that every level of the system be trained for its specific tasks. The laborer responsible for performing the manual tasks may misunderstand it, despite how it might seem easily to be understood by the requester in management.

When new employees are hired they should receive total quality management training in groups at the company, departmental, and local level before they begin working alone in order to prevent such misunderstandings.

Point VII: Adopting and Instituting leadership

Deming rationalized that at the expense of leadership, management had over-expressed organizational control, thus devoting a majority of their time worrying only about outcomes. He pushes them to concentrate their efforts in improvements by making company visions actual actions of the corporation.

Corporate leaders should center their attention on finding the source of any problems and correcting them in the system rather than blaming certain individuals for these inefficiencies. In correcting wrongs in this sense, a horizontal focus is formed between all employees because managers seek advice from all levels and give equal insight to their opinions. In effect management focuses on larger issues rather than minute details which saves time and money in the long-term.

This also prevents management from depriving the lower levels of their opportunities to promote their abilities and assume accountabilities for their performances. Without the stress of overseers rating them while they are working, these employees usually perform at higher standards because they feel management trusts their skills.

Allowing them freedom of performance creates extra time for managers to perform urgent managerial duties such as correcting essential problems and adhering to the demands of higher levels without the extreme pressures felt under vertical hierarchies.

Point IV: Ending the Practice of Selecting Suppliers on the Basis of Only the Price

Deming suggests that businesses should minimize their long-term costs rather than minimize the initial cost.

Instead of generating business based on price alone, management should minimize the total cost by working with a single supplier. Using a sole supplier prevents added variability from multiple suppliers and forms a bond between the supplier and corporation creating a strong partnership as if the two were actually only one larger business.

Once a bond with a single long-term supplier has been established, it is easier for the business to request what it needs from the supplier and for the supplier to respond accordingly to meet these needs, thus reducing costs for both parties. The supplier will send to the business consistent materials at a set price.

This consistency produces a better outcome of the final product than competing with various suppliers for the cheapest price on the cheapest materials available at the time the transaction takes place.

Point III: Ceasing Dependence upon Mass Inspection

A chief asset of management is to cease dependence upon inspection to achieve quality
. In other words, quality is derived from improving the system rather than inspecting for quality. Once the system is improved then the quality will also.

When many inspectors are hired to inspect the individual products the problem of passing defective products to consumers worsens because nearly every inspector assumes to some degree that a minimum inspection of so many products is enough. The usual mindset to a certain extent is that a past inspector should have already found the defect or future inspectors should find it if he or she had missed the mistake.

Plus an inspection cannot put quality into a defected product. It can only stop the defected product from advancing further. However, when a product is designed with quality, it can pass an infinite number of inspectors who rank it as high quality.

The reason the product is a defect depends on the design that promotes the quality instead of the inspectors noticing the defects (Drummond, 1992, p. 24). This in no manner means that inspection should cease, but it does provide that the dependence on inspection should.

Point II: Adopting the New Philosophy

This so-called new philosophy advocated by Deming is central to the ethics of total quality management because it represents the new economic age of industrialization, which is irrelevant under the old philosophies. For example under these post-philosophical ideas, the long-term investment was considered a loss for management because only later successors would reap the benefits.

This is seemingly a ridiculous thought in the recent economical age because Deming practically claimed the opposite was true in order to reach the goal, which is essentially the same outcome. This new philosophy is nothing more than businesses taking the time to notice and prevent the further production of defective products or services, which in effect will lead to increase profits in the long-term.

As Deming summarizes under this point, defects are expensive, unnecessary, and not inevitable. He argues that they are a product of the system traceable to a cause or chain of events concluding in these defects. The most significant problem is the managerial career structures. Usually members of this level of the corporation are highly educated resulting in employees that are only planning to use this position as a short-term advancement to reach the one they would rather hold.

This creates a weak foundation for the lower levels since the next highest position does not attempt to find or correct problems. They do not try to change things because they may risk their chance of promotion if the problems worsen instead of improve.

The Quality Philosophies of Edward Deming

Point I: Creating Constancy of Purpose for Improvement of Product and Service :The main message that Deming is trying to express under this point features two key aspects. These are customer obsession and strategic planning.

These two ideals converged under this first point to establish the appropriate direction for businesses to focus their attention. They should concentrate more on pleasing the customers than defeating any of their competitors.

Competition will always be present if the business remains successful and manages to stay at the top of production, yet the only way such will be feasible is if they continue to maintain customer satisfaction. However, Deming also adds that businesses should aim to become competitive, stay in business, and provide jobs, but in order to do so, they should focus their main attention on what the customers want rather than what they assume is wanted.

In effect the corporation will become a leading competitor that does not need to worry about competition, so there is no need to do so while reaching such a standard.

Total Quality Management

The terminology for total quality management is difficult to summarize into a simple sentence definition. However, as Peter Capezio and Debra Morehouse clearly state in their book Taking the Mystery Out of TQM: A Practical Guide to Total Quality Management, Second Edition, reference to it can be simplified “to a management process and set of disciplines that are coordinated to ensure that the organization consistently meets and exceeds customer requirements.

Therefore, it is basically a philosophy of business that founds its principles on customer satisfaction based on two objectives which are to carefully design the product or service and ensure consistency in the design. Orientating the excepting of these two major objectives by all individuals within the organization is necessary, thus the term total quality management .
In Total Quality Management, Richardson also adds that total quality management “is a plan and strategy to extend quality control efforts to every function of the company” and clearly defines each of the individual terms.

Total means that everyone participates and that it is integrated into all business functions. Quality means meeting or exceeding customer (internal or external) expectation. Management means improving and maintaining business systems and their related processes or activities.

Process Control

Process control identifies the appropriate types of quality controls needed within a process, and designs and incorporates them as Check procedures into the process.

Check procedures describe how to evaluate whether the right work was done (output meets needs) and whether the work was done right (output meets standards). Controls should be designed based on the criticality of the process and what needs to be checked.

Check procedures are defined in the same way as Do procedures. If the playscript format is used, Check procedures should be incorporated to the taskflow diagram or flowchart at the appropriate spot.

For example, a quality control checklist associ­ated with programming would have questions such as, “Was a flowchart produced that describes the processing of the program.

Process Defini­tion

The process that a team uses to scope a single process by defining its policies, standards, procedures, deliverables, people or skill requirements, and tools is called Process Definition.

The core activity of Process Definition is defining the process; but other activities include performing walkthroughs of the process before publication, piloting the process, marketing the process, etc. Only the core activity is discussed within the scope of this guide.

The core team should contain 3-5 members (typically process owners). When multiple people or units exist for the same role, a representative group should be used with the others acting as reviewers.

Team members should include a process owner, supplier, customer, process administrator, manager of the process owner, and a process auditor. Roles such as team leader, facilitator, and scribe should be assigned and the team should be trained in consensus building.

The Deployment Process

Initiating change is only effective when change is implemented through a process. This change process is called deployment. Deployment is the process of implementing a new or improved approach to completing a work task.
Deployment is normally only effective in an environment that uses processes. If there are no processes, there is no way of effectively implementing a change. In a software engineering environment, compliance to process is enforced, thus deployment is a critical component of making the software engineering environment work.

Dr. Curt Reimann, past director of the U.S. National Quality Award Program, stated that less than one percent of U.S. Corporations have an effective quality program. Most quality experts believe the cause of ineffective quality programs is attributable to poorly designed or nonexistent deployment efforts, coupled with the lack of measurement processes to assess the results of quality programs. Starting a quality management program forces management to rethink its quality responsibilities.

There are three deployment phases - assessment, strategic, and tactical. The assessment and strategic deployment phases represent the Planning component of the PDCA cycle. The tactical deployment phase represents the Do, Check and Act components of the PDCA cycle.

Control Chart

Control charts provide a way of objectively defining a process and variation. They establish measures on a process, improve process analysis and allow process improvements to be based on facts. Note: variation is briefly described here to put control charts in perspective.
The intent of a control chart is to determine if a process is statistically stable and then to monitor the variation of stable process where activities are repetitive. There are two types of variation:
Common or random causes of variation – are inherent in every system over time, and are a part of the natural operation of the system. Resolving common cause problems requires a process change.

· Special causes of variation – are not part of the system all the time. They result from some special circumstance and require changes outside the process for resolution.

Common causes of variation are typically due to many small random sources of variation. The sum of these sources of variation determines the magnitude of the proc­ess’s inherent variation due to common causes.

From the sum, the process con­trol limits and current process capa­bil­ity can be deter­mined. Accepted practice uses a width of three standard deviations around the population mean (µ±3δ) to establish the control limits. A process containing only common causes of variation is considered stable, which implies that the variation is predictable within the statistically established control limits.Control Chart

Run Chart

A run chart is a graph of data, in chronological order, that displays changes and trends in the central tendency (average). The data represents measures, counts, or percentages of outputs (products or services) from a process. Run charts are often used to monitor and quantify process outputs before a control chart is developed. Run charts can be used as input for establishing control charts.

Run charts can track events such as:
· Total failures
· Complaint levels
· End user satisfaction level
· Suggestion levels
· Training efforts
· Production yields
· Number of invoices
· Number of system errors
· Down time (minutes, percent)

The steps for developing a run chart are as follows:
Ø Decide which output of a process to measure
Ø Label the chart both vertically (quantity) and horizontally (time)
Ø Plot the individual measurements over time (once per time interval or as they become available), tracking the data chronologically in time
Ø Connect data points for easy use and interpretation
Ø Monitor the data points for any obvious trend

Pareto Chart

The Pareto chart is a special type of histogram, used to view causes of a problem in order of severity from largest to smallest. It is a simple statistical tool that graphically shows the 20-80 rules where 20% of the sources cause 80% of the problems. Joseph Juran refers to this Pareto principle as the separation of the “vital few” from the “trivial many”.

A Pareto chart is typically used early in the continuous improvement process when there is a need to order or rank problems or causes by frequency. The vital few problems and their respective root causes can then be the focus. This technique provides the ability to:

• Categorize items, usually by content (type of defect, position, process, time, etc.) or cause (materials, operating methods, manpower, measurement, etc.) factors
• Identify the causes or characteristics that contribute most to a problem
• Decide which basic causes of a problem to work on first
• Understand the effectiveness of the improvement by doing pre and post-improvement charts


A checksheet (also called a checklist or tally sheet) of events or occurrences is a form used to gather and record data in an organized manner. This tool records the number of occurrences over a specified interval of time to determine the frequency of an event.

The data is recorded to support or objectively validate the significance of the event. It may follow a Pareto analysis or cause-and-effect diagram to validate or verify a problem, or it may be used to build Pareto charts or histograms.

Check sheets can be used to record the following types of information:
· Project review results, such as defect occurrences, location, or type
· Documentation defects by type or frequency
· Cycle times, such as requirements to design or design to implementation
· Conformance to standards
· End user complaints of all types
· End user surveys
· Late deliveries


A histogram (or frequency distribution chart) is a bar graph that groups data by predetermined intervals to show the frequency of the data set. It provides a way to measure and analyze data collected about a process or problem, and may provide a basis for what to work on first.

Histograms are also useful for displaying information such as defects by type or source, delivery rates or times, experience or skill levels, cycle times, or end user survey responses. When sufficient process data is available, a histogram displays the central point (average) of the process, variation (standard deviation and range), and shape of distribution.

Histograms can explain graphically whether a process is in control or out of control, but they are not a substitute for statistical process control charts. They can also provide insight on the process capability to meet user specifications


A matrix is a structured, problem-solving technique used to show the relationship between groupings. It is also known as a matrix check sheet or a matrix diagram.

The matrix data analysis is frequently used to identify whether customer needs are being met, not being met, different, or no longer exist. For IT organizational teams, this approach could support the determination of system requirements, such as when teams need to understand and analyze customer preferences to drive out requirements or improvements on a product or service.

This tool helps view a problem as a whole for clarity, especially in conjunction with the JAD process.

For multidimensional problems, this approach focuses on the essential factors in problem areas. It helps teams sort language information for discussion and consensus, focus on what is important, and clarify the strength of the relationships. The matrix data analysis allows a team to test, evaluate, and develop strategies of multidimensional factors in solving problems.


Benchmarking is the process of determining how well a company’s products, services, and practices measure up against others. Benchmarking partners can be internal (against other company units), competitive (against competitors within the same industry), or functional (against “best in class” or “best in breed” within any industry). It is the highest level of performance that fully meets customer requirements.

Benchmarking enables a company to identify the performance gap between themselves and the benchmarking partner, and to determine a realistic improvement goal (some set higher goals) based on industry practices.

It helps achieve process improvement, measurement, motivation, and a management process for improvement. The use of benchmarking is not normally associated with cost cutting or a quick fix. Benchmarking should be integrated with an organization’s process improvement process.

Flowchart and Process Map

A flowchart is a diagram displaying the sequential steps of an event, process, or workflow. Flowcharts may be a simple high-level process flow, a detailed task flow, or anywhere in between. They are standard tools for any IT organization.

Flowcharts are most useful when applied by a team to obtain knowledge of a process for improvement. The technique is used to develop a common vision of what a process should do or look like. Once the process is documented, inefficiencies and redundancies can be identified and reduced.

A process map is a more detailed flowchart that depicts processes, their relationships, and their owners. The display of relationships and owners helps identify wasted steps, redundant tasks, and events with no trigger activities.

Force Field Analysis

Force field analysis is a visual team tool used to determine and understand the forces that drive and restrain a change. Driving forces promote the change from the existing state to the desired goal. Opposing forces prevent or fight the change. Understanding the positive and negative barriers helps teams reach consensus faster. Following are sample processes that could benefit by a force field analysis:

· Implementing a quality function
· Implementing quality management in IT
· Developing education and training programs
· Establishing a measurement program/process
· Selecting a new technique or tool
· Implementing anything new
· Establishing meaningful meetings
· Empowering the work force

The steps below show how a team uses force field analysis: Establish a desired situation or goal statement, Brainstorm and list all possible driving forces, Brainstorm and list all possible restraining forces, Determine the relative importance of reaching consensus on each force,

Draw a force field diagram, that consists of two columns, driving forces on one side and restraining forces on the other, Select the most significant forces that need to be acted upon using the nominal group technique to prioritize and reduce the number, if there are too many, Proceed to a plan of action on the forces selected in the previous step.

Cause-and-Effect Diagram

Teams use cause-and-effect diagrams to visualize, clarify, link, identify, and classify possible causes of problems in processes, products, and services. They are also referred to as “fishbone diagrams,” “why-why diagrams,” or “Ishikawa diagrams” (after Kaoru Ishikawa, a quality expert from Japan).

Through understanding problems within the work processes, teams can identify root causes of a problem. A diagnostic approach for complex problems, this technique begins breaking down root causes into manageable pieces of a process. A cause-and-effect diagram visualizes results of brainstorming and affinity grouping through major causes of a process problem. Through a series of “why-why” questions on causes, this process can uncover the lowest-level root cause. Figure 5-6 displays a sample cause-and-effect diagram.

Cause-and-effect diagrams are applicable for:
· Analyzing problems
· Identifying potential process improvements
· Identifying sources of defect causes
· Analyzing improper use of test routines/testing problems
· Scheduling problems/cycle times

Nominal Group Technique

The nominal group technique is a structured, facilitated technique where all team members participate by individually ranking ideas, issues, concerns, and solutions, and then achieve consensus by combining the individual rankings. Sample ideas that could be ranked with the nominal group technique are:
· Which defect is the greatest?
· Who are our customers?
· What are our impediments to quality improvement?
· What new standards are needed?
· What are our key indicators?
· What tool is not being used effectively and how can we increase usage?
· How do we get a quality tool used?

Nominal grouping uses a round table (verbal) or index card (written) method for equal participation of teams or groups. It is a good technique to gather large amounts of information. The steps for the nominal group technique are:
Generate a list of ideas, issues, concerns, or solutions to prioritize. Brainstorming can be used if the list is not readily available.
If the list contains more than about 35 items, it may be desirable to shorten it using Pareto analysis to make it more manageable.

Affinity Diagram

The affinity diagram is an orderly extension of a structured brainstorming session. Teams use this tool to help create order out of chaos, by categorizing large numbers of ideas. Rather than having teams react logically to a group of ideas, this technique helps to identify more creative solutions or to structure ideas for a cause-and-effect diagram.
Possible topics or problem statements where affinity diagrams could help are:
· Why policies don’t exist
· Why standards are not adhered to
· Why QA failed
· Why objective measures aren’t used
· Understanding the leadership role in quality management
· Why employees are not involved or lack empowerment
· Why quality doesn’t work
· Improving teamwork in the workplace
· Understanding the issues to automation and use of CASE (Computer Assisted Software Engineering) tools

To generate affinity diagrams, continue with these steps after a brainstorming session:
1. Write each idea on a separate index card.
2. Randomly place each index card on a flat surface, wallboard or flipchart.
3. In silence, team members move the cards into meaningful groups until consensus has been achieved (the group stops moving the cards).
4. The team discusses and then labels each category with a title.The team discusses each category, using cause-and-effect diagrams if needed


Brainstorming is a technique used to quickly generate a quantity of creative or original ideas on or about a process, problem, product, or service.

A brainstorming session begins with a facilitator establishing basic ground rules and a code of conduct. Typical brainstorming rules state that all members have an equal opportunity to participate, there is no criticism or pulling rank, people should think creatively, no idea will be treated as insignificant, and there should be only one conversation at a time. Members need to be active participants, willing to share their ideas, opinions, concerns, issues, and experiences.
Next the team agrees on the topic to be brainstormed and whether to give ideas verbally or written on individual index cards, or any other easily manipulated medium.

Either a structured (round table) or unstructured (free-flowing) approach is selected. Ideas should be generated quickly (5-15 minutes) and are recorded clearly on a flipchart or board.
The process stops when ideas become redundant or infrequent.

Recorded ideas are reviewed for duplication and clarification, and eliminated when necessary. Remaining ideas are then evaluated with an open mind and may be used with the affinity diagram, nominal group technique, or cause-and-effect diagram.

Change Control Procedures

The nature of the proposed change should be explained in writing, and formally approved by a responsible individual. Major changes should be approved by the systems-planning steering committee, commonly called the CCB or Configuration Control Board, in the same manner as for new systems. Minor changes may only require the joint approval of the IT manager and senior personnel in the user department.

Documenting the proposed change clears up any initial misunderstandings that may arise when only verbal requests are made. In addition, written proposals provide a history of changes in a particular system.

Developers should make the program changes, not the operations group. Any change should be supported by adequate systems documentation. If the operators were authorized to make minor changes, it would greatly increase the difficulty of controlling versions and of maintaining up-to-date documentation.

Someone independent of the person who designed and made the change should be responsible for testing the final revised program. The results should be recorded on program change registers and sent to the IT manager for approval. Operations should accept only properly approved changes.

Finally, the documentation system should be updated with all change sheets or change registers and printouts.

Software Configuration Management

The dynamic nature of most business activities causes software or system changes. Changes require well-formulated and well-documented procedures to prevent the manipulation of programs for unauthorized purposes.

The primary objective of configuration management (or change control) is to get the right change installed at the right time. Change control concerns should be identified so that proper control mechanisms can be established to deal with the concerns. Some key points regarding changes include:

Each release of software, documentation, databases, etc. should have a unique version number. Changes should be incorporated through new versions of the program. There should be a process for moving versions in and out of production on prescribed dates.

Procedures should exist for maintaining the production and source libraries. They should address when to add to the library and when prior versions should be deleted. Care should be taken to regularly review libraries for obsolete programs, as large libraries can negatively impact operations performance.

Quality Values and Quality Policy

Values or guiding principles tell how to conduct business. They help define an organization’s culture and personality by clarifying what behavior is expected in order for the organization to achieve its vision and mission. Values are established by senior management and respect the integrity of the individual.

Examples of values are: customer-focused, quality management, innovative, employee empowerment, ethical, cooperative relationships, and risk taking. Values should be consistent with Dr. Deming’s 14 quality principles (see Knowledge Domain 1), and they should be integrated into the organization’s work program. If really believed, values help focus the organization on a shared behavioral model.

Executive management’s commitment to quality should be expressed in writing to all employees in the form of a quality policy. Manage­ment should work as a team to develop the policy, which must be aimed at the employees and written so they can understand it.

The policy should be concise and cover all aspects of quality. Eventually, every existing regulation, procedure, and policy letter should be reviewed to assure that it aligns with the new quality policy.

Quality Goals

Goals explain how the vision will be achieved. For example, if an organization’s vision is to produce defect-free software, a goal might be to have no more than one defect per thousand lines of code. Goals change as an organization moves closer to accomplishing the vision. Well-developed programs are necessary to achieve the goals.
Goals and objectives are often used interchangeably; however, goals tend to be more global and non quantitative. Objectives come from goals and tend to be more specific and quantitative.
· Are consistent with the vision
· Are established by operational management (manager of systems and programming, manager of computer operations, etc.)
· Must have management commitment
· Clearly identify the role each individual plays in accomplishing the goal
· Should be linked to programs established to accomplish the goals

Strategic quality management goals must focus on both the producer and the customer. Short-term goals should:
· Reduce defects
· Reduce cycle time (i.e., shorter schedule and less resources)
· Provide return on investment from short-term programs

Quality Vision

Leaders provide a vision, which is a clear definition of the result to be achieved. Organizations without a vision flounder. The vision establishes where the organization desires to move from its current state. It gives everyone a direction to work towards. Senior management should establish the vision, ensuring how it contributes to the business is clear. A vision is simple and concise, and it should be understood and supported by all.
Examples of visions include:

· From the Quality Assurance Institute: “Our vision is to produce competent and successful quality assurance analysts.”
· From the Eastman Kodak Company: “We see ourselves now and in the future as a company with a strong customer franchise, known for reliability, trust, and integrity in all relationships. Our business will be based on technologies that have evolved over our long history, and which will give us unique advantages over our competition. These technologies will span our core businesses, and will also go beyond boundaries we can see today.”
· From the Ford Motor Company: “A worldwide leader in automotive and automotive-related prod­ucts and services as well as in newer indus­tries such as aerospace, communications, and financial services.”
· President Kennedy had a vision of putting a man on the moon before 1970.
· QA analysts should have a vision of improving quality, productivity, and customer satisfaction.

Quality Mission

A mission statement ex­plains why a company, organization, or activity exists, and what it is designed to accomplish. It clearly and concisely describes the work that is done, providing direction and a sense of purpose. The mission should focus on products and services and be customer-oriented. During implementation, the mission is constrained by the vision and values.

Examples of mission statements include:
· From Arco Transportation Company Information Services: “The mission of information services is to provide the appropriate computing network, products, and services and support of the strategies, goals, and objectives of the company.”

· From the Ford Motor Company (listed in their Ford Q-101 Quality Systems Standard, January 1986): “Ford Motor Company is a worldwide leader in automotive and automotive-related products and services as well as in newer industries such as aerospace, communications, and financial services.

Our mission is to improve continually our products and services to meet our customers’ needs, allowing us to prosper as a business and to provide a reasonable return for our stockholders, the owners of our business.”

Quality Consensus

During problem solving and process improvements, teams are faced with making decisions on a number of activities: what problems need to be worked out, data collection, steps to use, conclusions, solutions, recommendations, presentations, etc.

With the consensus technique, each member must accept the agreed-upon resolution and be willing to support it, even if it was not their favorite choice. Everyone participates and there is no voting. Using consensus provides teams an opportunity to reach high-quality decisions with total team commitment. Team members have an in-depth understanding of the underlying concern or issues, trust, willingness to explore, and mutual respect for each other.

An effective consensus process is best accomplished in a relaxed environment away from the work place, with a trained facilitator and a team of between five and nine people. A facilitator helps to seek out participation, draw out information, keep the team focused, provide encouragement, suggest approaches, and maintain order. The facilitator needs to be impartial and neutral with no stake in the resolution.

Consensus is the most difficult decision-making process compared to authority, voting, or avoidance (no decision).

Just-In-Time (JIT) Technique

Just-in-time (JIT) is a revolutionary production system developed by Taiichi Ohno, a Toyota vice-president. He examined and challenged a known manufacturing principle, and developed a disciplined system that placed Toyota a quantum step ahead of their rivals in the Western countries. This system, now known as, “the Toyota Production System,” has set the standard for world-class manufacturing. The concept may be adopted within IT.

The ultimate goal of JIT production is to supply each process with exactly the required items, in exactly the required quantity, at exactly the required time. There are two conditions necessary to reach this situation: large amounts of production flexibility, and very short lead times.
The basic difference between the old method of supply and the new system is that the concept of a one-process department is eliminated. The same work tasks are no longer all performed in the same work area.

These highly specialized departments are replaced with mixed lines of processing capabilities laid out in the sequence required to make the part or groups of parts. Parts having similar size, shape, material, and processing sequence are allocated to those lines by a system known as “group technology.” Parts are processed over these lines one at a time in very small batches.

The key to JIT production is the ability of the production area to quickly switch from job to job within a few moments. The manufacturing technique for doing this is known as SMED (Single-Minute Exchange of Dies). This technique of quickly changing work capabilities can significantly reduce the cost of doing work.


The organizational climate is the workers’ attitude toward their organization. It is a composite of human behaviors, perception of events, responses of employees to one another, expectations, interpersonal conflicts, and the opportunities for growth in the organization. The climate is crucial in creating and maintaining an effective organization, and, therefore, should be periodically evaluated to discover whether the satisfaction level of the employees is positive or negative. An evaluator can use the six steps below to assess the climate of a specific organization, group, committee, task force, etc.
1. Look at the organization (group, committee, task force, etc.) - Assess the mission and goals of the organization, what it is supposed to produce, and the overriding principles by which it operates.
1. Examine the jobs - Examine each job in the organization. Ask whether the job is necessary, whether it makes full use of the employee’s capabilities, and whether it is important in accomplishing the mission and goals of the organization.
2. Assess employees’ performance - Evaluate each employee’s performance in relation to the organization’s mission and goals. For each job being performed, ask if the employee is doing what should be done, is using his or her skills effectively, likes his or her job, and has enthusiasm and interest in performing the job.
3. Evaluate how employees feel about their manager or leader - Good organizational climate requires good leadership. Determine whether each employee within the group likes his or her manager, whether they follow or ignore the requests of their manager, and whether they attempt to protect their manager (i.e., make their manager look good).
4. Create a dialog with the members of the group - Interact with each employee asking a series of hypothetical questions to identify the employee’s true feelings toward the organization. Questions such as, “do you feel the organization supports your suggestions”, can help draw out the true feeling of each employee.

Quality Council

A Quality Council is composed of the organization’s top executive and his or her direct reports. It may also be referred to as an Executive Council. The Quality Council acts as the steering group to develop the organization’s mission, vision, goals, values, and quality policy.

These serve as critical input to process mapping, planning, measurement, etc. Some large companies opt for more than one level of Quality Council. When multiple levels exist, each organization’s mission and vision tie into that specified by the top council. Specifically, the Quality Council: Initiates and personally commits to the quality management philosophies and practices. Incorporates this decision into the strategic planning process, allocating resources in the budget for the deployment of quality management and ensuring resources are available for both ongoing and upcoming IT projects and internal process improvement projects.

Establishes committees at lower levels to focus on functional and cross-functional improvement efforts, develop or revise processes, and to oversee and manage the quality management process on a daily basis. They may develop charters to serve as job descriptions for the committees, or approve the committees’ charters.


The reason a quality management environment is established is to assure constancy of purpose in promoting quality as a major IT goal. There are two components to that environment: belief and commitment from management and staff, and the organizational structure and quality initiatives to support that environment. Part 1 focused on the belief and commitment of the management team. This part focuses on the infrastructure and initiatives.

No organization has a perfect quality management environment. All are striving to achieve the optimum management philosophy, and organizations can be anywhere along the quality management continuum. By forming a quality function, some level of commitment and organizational structure exists that could be called quality management.

In some organizations there is no choice but to begin implementation from the middle or the bottom. In these cases, demonstrated success will be required to get management’s attention. While all three approaches have been used and have been successful, the top-down approach is recommended, and is used for the remainder of this discussion.

For a top-down implementation of the infrastructure in a quality management environment, begin the process with executive management. Then facilitate the downward flow of the goals, values, structure, and training established at upper levels, to succeeding levels. Each level is linked to the other by the common objective of making people capable of combined performance.

Quality Management Champion

There is a need for one or more people to champion the cause of quality management. Ideally a champion will emerge during the planning for quality management implementation. This is the person who accepts personal responsibility for the success of quality management without being assigned the responsibility. The champion will be emotionally committed to quality management and will see it as a cause.
The champion should be respected in the organization, have high quality standards and believe that the organization needs to improve. This “can do” attitude may be the most important consideration. A management champion may assume the day-to-day management responsibility for successfully implementing quality management.

Champions happen naturally; they are not appointed. The enthusiasm and energy of champions are important factors in the success of an organization. Ideally the initial champion would be the top executive, but several managers may assume this role at different times. The need for a champion lasts a minimum of two to three years.

Implementing quality management requires a culture change. Learning new types of behavior leads to that change. Following are some new behavior modes:
Most managers practice traditional management. They have been taught to control their organization and employees, using an “I’ll tell you what to do, and you’ll do it” mentality. Many mangers look at the short-term because their commitment to the organization is short range.

Middle Management Commitment

As the slowest group to accept the process, middle management is the weakest link in most quality management efforts. Special effort is required to assure them they have a role as important players.

They should have input to the statements that executive management prepare, and be included in all aspects of quality management planning and implementation. One way to assure their support is to assign them the task of determining their own role.

How to include middle management is an important consideration for executive management, because obtaining quality management support from first-line managers and employees is relatively easy.

The standard must be applied to management before it is deployed to the rest of the organization. Executive management must personally strive for perfection, measure progress, and recognize those who contribute to error-free performance. Employees strive to meet expectations established for them, and model their behavior after management’s actions.