CSQA CSQA Certified Software Quality Analyst Questions and Answers

From a management perspective, processes are needed to:

Explain to workers how to perform work tasks

Transfer knowledge from more experienced to less experienced workers

Assure predictability of work activities so that approximately the same deliverables will be produced with the same resources each time the process is followed

Establish a basic set of work tasks that can be continuously improved

Provide a means for involving workers in improving quality, productivity, and customer satisfaction by having workers define and improve their own work processes

Free management from their activities associated with "expediting work products" to spend more time on activities such as planning, and customer and vendor interaction

From a worker perspective, work processes are important to:

Increase the probability that the deliverables produced will be the desired deliverables

Put workers in charge of their own destiny because they know the standards by which their work products will be evaluated

Enable workers to devote their creativity to improving the business instead of having to develop work processes to build products

Enable workers to better plan their workday because of the predictability resulting from work processes

1 – The major advantages are”

Relinquishment of control - The software is developed by individuals who are not employees of the organization, and thus it is difficult to oversee the development process. The contracting organization cannot direct the employees of the other organization, nor have control over the many day-to-day decisions that are made in developing software.

Loss of control over reallocation of resources - If work needs to be done to correct problems and/or speed up development, the contractor cannot take workers off one project and assign them to another project.

2 – The major disadvantages are:

Cultural differences - There may be a significant difference in the culture and values between the contractor and the offshore organization.

Communication barriers - The language of the offshore organization may be different or difficult to comprehend which causes difficulty in communicating the needs and desires of the contractor.

There are four main testing stages in a structured software development process. They are:

Unit Testing

These tests demonstrate that a single program, module, or unit of code function as designed. For example, observing the result when pressing a function key to complete an action. Tested units are ready for testing with other system components such as other software units, hardware, documentation, or users.

Integration Testing

These tests are conducted on tasks that involve more than one application or database, or on related programs, modules, or units of code, to validate that multiple parts of the system interact according to the system design. Each integrated portion of the system is then ready for testing with other parts of the system.

System Testing

These tests simulate operation of the entire system and confirm that it runs correctly. Upon completion, the validated system requirements result in a tested system based on the specification developed or purchased.

User Acceptance Testing

This real-world test is the most important to the business, and it cannot be conducted in isolation. Internal staff, customers, vendor, or other users interact with the system to ensure that it will function as desired regardless of the system requirements. The result is a tested system based on user needs.

The plan will be outlined in four steps. Those four steps are:

-Creating Messages

- Understanding Audiences

-Planning Transfer Methods

- Defining Impacts.

Using defects to improve processes is not done by many organizations today, but it offers one of the greatest areas of payback. NASA emphasizes the point that any defect represents a weakness in the process. Seemingly unimportant defects are, from a process perspective, no different from critical defects. It is only the developer’s good luck that prevents a defect from causing a major failure. Even minor defects, therefore, represent an opportunity to learn how to improve the process and prevent potentially major failures. While the defect itself may not be a big deal, the fact that there was a defect is a big deal.

Based on the research team findings, this activity should include the following:

Go back to the process that originated the defect to understand what caused the defect

Go back to the verification and validation process, which should have caught the defect earlier

Not only can valuable insight be gained as to how to strengthen the review process, these steps make everyone involved in these activities take them more seriously. This human factor dimension alone, according to some of the people the research team interviewed, can have a very large impact on the effectiveness of the review process.

Level 1 – Constraint Requirements

This level involves staffing, budget, and schedule. The business requirements are frequently defined as a set of objectives described on several pages of narrative description. Thus, it becomes the role of the project team to expand the initial definition and build the software. However, management and the end user of the software will manage more by the constraint requirements than by the business requirements. The result is that the software put into production on the scheduled date may miss many key requirements, which will need to be installed after the operational date but under new budgets and schedules.

Level 2 – Business Requirements

This level places its emphasis on the functional and operating requirements. Level 2 establishes the criteria that the deliverables must meet in order to be accepted by the end user. At this level, standards are established for the requirements document which specifies the totality of requirement attributes that must be included for the requirements to be considered complete. These often include defining how the requirements will be tested, the objective of the requirement, the problem that the requirement is designed to solve, a detailed description of the requirement, and how the requirement is related to the objectives to be accomplished. Many information organizations at this level introduce uniquely identifying requirements, and then utilize processes that trace requirements through the entire software-building process.

Level 3 – Relational Requirements

This level emphasizes relationships within an information system and between information systems. Level 2 defines relationships, but normally at a much lower level than Level 3. Level 2 relationship specifications tend to be within an individual application system. Level 3 relationships focus on organizational databases, processing sequences and priorities, intersystem relationships, and processing cycle relationships. Data relationships help eliminate data redundancy and help assure consistency of use of data throughout an organization. Processing relationships address processing priorities and processing sequences. The system relationships deal with interfaces between systems and changes to systems. The larger challenge is assuring that all systems are changed concurrently when they are impacted by a common change(s). The processing cycle or timing relationship assures that all data that belongs in a particular accounting processing cycle is processed during that cycle.

Level 4 – Quality Requirements

Quality requirements are the characteristics surrounding the functional requirements that facilitate end user satisfaction. An example of quality requirements is ease of use. The functional requirements deal with the data specified for a particular product, but if it is very difficult to use (i.e., not meeting the quality ease of use requirement); the end user tends to be dissatisfied.

Level 5 – Reliability Requirements

Reliability primarily deals with mean time between failures. To achieve reliability requirements necessitates building a database of processing information and performing adequate statistical analysis on that data. Then a statistical prediction of reliability can be made. While the end user needs to specify reliability requirements, they can only be measured and achieved through the use of statistical tools. Figure 44 shows the best practices for deliveries process.

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.

For example, financial goal statements from the Eastman Kodak Company are:

“To rank among the top 25 U.S.-based multinational companies in net earnings”

“To approach a return on equity of 20 percent”

The concerns that arise in maintaining a relationship of harmony and good will include:

Contractor obligations met - The contractor should meet their requirements as specified in the contract.

Customer obligations met - The customer should meet their requirements as specified in the contract.

Need met - It is to the benefit of both parties to have the customer satisfied with the application system. Even when the initial deliverables meet the customer’s need, there will be ongoing maintenance required to meet the continually evolving needs of the customer. The methods of doing this should be specified in the contract, and those requirements should form the basis for both parties specifying and delivering new contractual obligations.

Limits on cost increases - The cost specified in the contract should include provisions for ongoing costs. In an inflationary economy, it may be advantageous to have limits placed on cost increases. For example, if service is provided at an hourly rate, the increases in that rate might be specified in the contract.

Baselines should be quantitative even if it is a subjective measure, but quantitatively subjective. For example, because quality conformance and nonconformance must be defined by people, we are looking for ways to put this information into a quantifiable format. This does not convey a lot of information, but it is indicative of a problem. However, if we develop a five-point scale for unresponsiveness, and ask your dissatisfied customer to complete that scale, we now have conveyed a lot more information. If our scale rates “1” as very poor service, and “5” as very good service, there is a great deal of difference between a “1” rating and a “3” rating for dissatisfaction.

The workbench transforms to the input to produce the output. The workbench is comprised of two procedures: Do and Check, which correspond to the Do and Check phases of the PDCA cycle. If the Check procedure determines that the standards for the output product are not met, the process engages in rework until the output products meet the standards, or management makes a decision to release a nonstandard product. People, skills, and tools support the Do and Check procedures. A process is defined by workbench and deliverable definitions. A process is written with the assumption that the process owners and other involved parties possess certain skill and knowledge levels (subject matter expertise).

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-13 at 2.13.25 AM.png

The QA analyst has three roles in integrating new technology:

Determining the Risks

Each new technology poses new risks. These risks need to be identified and prioritized and, if possible, quantified. Although the QA analyst will probably not perform the actual task, the QA analyst needs to ensure that a risk analysis for the new technology is undertaken and effectively performed.

Assuring that the Controls are Adequate to Reduce the Risk

The QA analyst needs to assess whether the controls proposed for the new technology are adequate to reduce the risk to an acceptable level. This may be done by line management and reviewed by the QA analyst.

Assuring that Existing Processes are Appropriately Modified to Incorporate the Use of the New Technology

Work processes that will utilize new technologies normally need to be modified to incorporate those technologies into the step-by-step work procedures. This may be done by the workers responsible for the work processes, but at least needs to be assessed or reviewed by the QA analyst.

Level 2 organizations have installed basic management controls. Policies for managing a software project and procedures to implement those policies are established. Planning and managing projects is based on experience with similar projects. Realistic project commitments are based upon the results observed on previous projects and on the requirements of the current project. Project managers track software costs, schedules, and functionality. Problems in meeting commitments are identified when they arise. Software requirements and the work products developed to satisfy them are baselined and their integrity is controlled.

The capability of Level 2 organizations is summarized as disciplined, because the ability to successfully repeat planning and tracking of earlier projects results in stability. To be certified at Level 2, organizations must document (define), practice, enforce, train, measure, and improve the following six key process areas:

Requirements Management

Software Project Planning

Software Project Tracking

Software Subcontract Management

Software Quality Assurance

Software Configuration Management

Management must convey the message that integrity and ethical values cannot be compromised, and employees must receive and understand that message. Management must continually demonstrate, through words and actions, a commitment to high ethical standards.

The control objectives for this attribute are:

Existence and implementation of codes of conduct and other policies regarding acceptable business practice, conflicts of interest, or expected standards of ethical and moral behavior.

Establishment of the “tone at the top” – including explicit moral guidance about what is right and wrong – and extent of its communication throughout the organization.

Dealings with employees, suppliers, customers, investors, creditors, insurers, competitors, and auditors, etc. (e.g., whether management conducts business on a high ethical plane, and insist that others do so, or pay little attention to ethical issues).

Appropriateness of remedial action taken in response to departures from approved policies and procedures or violations of the code of conduct. Extent to which remedial action is communicated or otherwise becomes known throughout the entity.

Management’s attitude towards intervention or overriding established controls.

Pressure to meet unrealistic performance targets – particularly for short-term results – and extent to which compensation is based on achieving those performance targets.

A mission statement explains 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.”

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 products and services as well as in newer industries 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.

The steps below describe a sample defect tracking process. Depending on the size of the project or project team, this process may be substantially more complex.

1. Execute test and log any discrepancies.

The tester executes the test and compares the actual results to the documented expected results. If a discrepancy exists, the discrepancy is logged as a “defect” with a status of “open.” Supplementary documentation, such as screen prints or program traces, is attached if available.

2. Determine if discrepancy is a defect.

The Test Manager or tester reviews the defect log with an appropriate member of the development team to determine if the discrepancy is truly a defect, and is repeatable. If it is not a defect, or repeatable, the log should be closed with an explanatory comment.

3. Assign defect to developer.

If a defect exists it is assigned to a developer for correction. This may be handled automatically by the tool, or may be determined as a result of the discussion in step 2.

4. Defect resolution process.

When the developer has acknowledged the defect is valid, the resolution process begins.

Actual experience with measurement suggests that recurring costs of 2 - 3% of direct project costs are adequate for data collection and analysis and for project tracking and monitoring. This small price buys real help in meeting project goals, and in increasing project control through better budgeting, problem anticipation, risk reduction, and incremental process improvement.

In order to participate in the various aspects of contracting for software development, it is necessary to establish an acquisition life cycle for contracted software. This life cycle contains the following three activities:

Selecting an Outside Organization

Selecting a contractor is similar to systems design. It is a time of studying alternative contractors, costs, schedules, detailed implementation design specifications, and the specification of all the deliverables, such as documentation. The selection of an outside organization may involve the following individuals in addition to the quality control reviewer:

Systems analysts

User personnel

Internal auditor

Purchasing agent

Legal counsel

Contract Negotiations

In some organizations, the purchasing agent conducts all the negotiations with the contractor; the other parties are involved only in the needs specification. In other organizations, there is no purchasing agent, so the data processing department deals directly with contractors for the acquisition of application systems.

Operations and Maintenance

The maintenance and operations of purchased applications may be subject to contractual constraints. For example, some contracts limit the frequency with which an application can be run without paying extra charges, and limit an organization’s ability to duplicate the application system in order to run it in a second location. In-house personnel can maintain some purchased applications, but others do not come with source code and thus are not maintainable by in-house personnel. There may also be problems in connecting a purchased application from one contractor with purchased or rented software from another contractor. It is important that software from multi contractors be evaluated as to its capability to work in the same operating environment.

The relationship of probability and impact are not linear, and the magnitude of the risk typically makes a difference. For example, consider the risk of spending $1 for a 50/50 chance to win $5, vs. the risk of spending $1,000 for a 50/50 chance of winning $5,000 vs. the risk of spending $100,000 for a 50/50 chance of winning $500,000. In this example, the probability of loss is all the same (50%) yet the opportunity cost of losing is much greater.

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:

1. Establish a desired situation or goal statement.

2. Brainstorm and list all possible driving forces.

3. Brainstorm and list all possible restraining forces.

4. Determine the relative importance of reaching consensus on each force.

5. Draw a force field diagram that consists of two columns, driving forces on one side and restraining forces on the other.

6. 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.

7. Proceed to a plan of action on the forces selected in the previous step

Some guidelines for selecting and sequencing change approaches are:

Select approaches that are most acceptable to the culture (poor approaches that are acceptable may be more effective than optimal approaches that are resisted).

Select approaches that have the highest probability of success, first.

Select approaches that will provide both short-term and long-term results. Select an implementation strategy that will use the best people and the best projects, as opposed to trying to improve the poorest projects with the least effective staff.

Implement the prerequisites to the approach before implementing the approach.

Use tools such as risk ranking, analysis, or return on investment.

Preventive Control

Preventive controls are located throughout the entire IT system. Many of these controls are executed prior to the data entering the computer programs.

Source-Data Authorization

Once data has been recorded properly, there should be control techniques to ensure that the source data has been authorized. Typically, authorization should be given for source data such as credit terms, prices, discounts, commission rates, overtime hours, and so forth. The input documents, where possible, should have evidence of authorization and should be reviewed by the internal control group in data processing. To the extent practical, the computer should be utilized as much as possible to authorize input. This may be done through programmed controls.

Data Input

Data input is the process of converting data in non-machine-readable form (such as hard-copy source documents) into a machine-readable form so that the computer can update files with the transactions. Since the data input process is typically a manual operation, control is needed to ensure that the data input has been performed accurately.

Detective Controls

Detective controls alert individuals involved in a process so that they are aware of a problem. Detective controls should bring potential problems to the attention of individuals so that action can be taken. One example of a detective control is a listing of all paychecks for individuals who worked over 80 hours in a week. Such a transaction may be correct, or it may be a systems error, or even fraud.

Data Transmission

Once the source data has been prepared, properly authorized, and converted to machine-processable form, the data usually is transmitted from the source department to the data processing center. Data transmission can be made by conventional means (such as messenger and mail) or by data transmission devices which allow data transmission from remote locations on a much timelier basis.

Control Register

Another technique to ensure the transmission of data is the recording of control totals in a log so that the input processing control group can reconcile the input controls with any control totals generated in subsequent computer processing.

Corrective Controls

The following two corrective controls will be discussed in this chapter: error detection and resubmission, and audit trails.

Error Detection and Resubmission

Until now we have talked about data control techniques designed to screen the incoming data in order to reject any transactions that do not appear valid, reasonable, complete, etc. Once these errors have been detected, we need to establish specific control techniques to ensure that all corrections are made to the transactions in error and that these corrected transactions are reentered into the system.

Audit Trails

Another important aspect of the processing cycle is the audit trail. The audit trail consists of documents, journals, ledgers, and worksheets that enable an interested party (e.g., the auditor) to trail an original transaction forward to a summarized total or from a summarized total backward to the original transaction. Only in this way can they determine whether the summary accurately reflects the business’s transactions.

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.

2. 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.

3. 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.

4. 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).

5. 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 feelings of each employee.

Quality is a multifaceted concept driven by customer requirements. The level of quality can vary significantly from project to project and between organizations. In IT, the attributes of quality are examined in order to understand the components of quality, and as a basis for measuring quality. Some of the commonly accepted quality attributes for an information system are described in the following figure.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 7.38.30 PM.png

There are four main testing stages in a structured software development process. They are:

Unit Testing

These tests demonstrate that a single program, module, or unit of code function as designed. For example, observing the result when pressing a function key to complete an action. Tested units are ready for testing with other system components such as other software units, hardware, documentation, or users.

Integration Testing

These tests are conducted on tasks that involve more than one application or database, or on related programs, modules, or units of code, to validate that multiple parts of the system interact according to the system design. Each integrated portion of the system is then ready for testing with other parts of the system.

System Testing

These tests simulate operation of the entire system and confirm that it runs correctly. Upon completion, the validated system requirements result in a tested system based on the specification developed or purchased.

User Acceptance Testing

This real-world test is the most important to the business, and it cannot be conducted in isolation. Internal staff, customers, vendor, or other users interact with the system to ensure that it will function as desired regardless of the system requirements. The result is a tested system based on user needs.

Automatic

When performing a Do procedure, automation is the only way to force compliance. Some tools, such as CASE tools, automatically enforce task completion and sequence, and deliverable standards.

Self-Checking

This is when the process owner (author) uses a method other than the Do procedure, to crosscheck his/her work. Methods in this category are:

Analysis tools, which parse and analyze deliverables after they have been created, such as spelling checkers, writing analyzers, and code analyzers (e.g., standards compliance, complexity analyzers, and cross-reference tools).

Checklists, which are worksheets containing a list of questions oriented towards determining whether the standards have been adhered to. They are designed to provide a summary-style self-check for the author. Checklists often mirror policies, standards, and procedures, but address each compliance issue in the form of a question. A "yes" answer means that the author has followed the process and has produced a result that matches the intent of the policy statement. A "no" answer indicates noncompliance.

Desk-checks, where the author or owner reviews the product against specifications and standards. It is uncontrolled and subject to the time requirements of each individual.

One-on-one reviews, which are informal reviews conducted between the author/owner and one other person. The objective is to review against specifications and standards.

Tests, which validate that the actual results are the expected or desired results.

Peer Reviews

One or more process owners review the results of the author. Typically, quality problems are noted, and the author corrects them. Various methods exist, from informal to formal.

Supervisory

The author’s supervisor reviews the work and ensures that defects found are corrected. This is problematic because it takes responsibility for quality away from the worker, and may be ineffective because the supervisor is not sufficiently skilled or knowledgeable about the work to make intent or judgment calls regarding compliance. It may also influence the supervisor unfairly regarding a worker’s performance. Supervisors may use the informal walkthrough, checklists, or testing for control methods.

Third Party

An independent group evaluates the product. As with supervisory controls, this is problematic because responsibility for quality is taken from the worker and the third party may not have the skills or knowledge about the work to determine compliance. Examples of independent groups are quality functions and independent test teams. Methods used by third parties include informal walkthroughs, checklists, testing, analysis tools, and sampling.

1. Create Consistency of Purpose in the Company

In quality-oriented companies, quality should be the cornerstone of the corporation. All units within the organization should work toward common goals and purposes. Within IT this can be translated to mean that the training department teaches the standards, operations is working for the same goals as systems programming, and systems programming is dedicated to improving application performance. Assuring quality involves:

Innovating new approaches and allocating resources for long-term planning, such as possible new service, new skills required, training and retraining of personnel, satisfaction of the user.

Putting resources into research, education and maintenance.

2. Institute Modern Aids to Training on the Job

Training must be totally reconstructed. Statistical methods must be used to learn when training is finished, and when further training would be beneficial. A person once hired and trained and in statistical control of his/her own work, whether it be satisfactory or not, can do no better. Further training cannot help. If their work is not satisfactory, move them to another job, and provide better training there.

3. Drive Out Fear

Most people on a job, and even in management positions, do not understand what the job is, or what is right versus wrong. Moreover, it is not clear to them how to find out. Many of them are afraid to ask questions or to report trouble. The economic loss from fear is appalling. It is necessary, for better quality and productivity, that people feel secure.

Another related aspect of fear is the inability to serve the best interest of the company through necessity to satisfy specified rules, or to satisfy a production quota, or to cut costs by some specified amount.

One common result of fear is seen in inspection. An inspector records incorrectly the result of an inspection for fear of overdrawing the quota of allowable defectives of the work force.

4. Look Carefully at Work Standards

Do they take account of quality, or only numbers? Do they help anyone do a better job? How old are they? Work standards are costing as much loss as poor materials and mistakes. In hundreds of companies any day, people stand around the last hour or two waiting for the whistle to blow. They have completed their quotas for the day. Is this good for the competitive position of any industry? Ask these people. They are unhappy doing nothing, and would rather work.

A list of five critical success factors required to evaluate COTS software is as follows:

Assure Completeness of Needs Requirements

Define Critical Success Factor

Determine Compatibility with Hardware, Operating System, and other COTS Software

Assure the Software can be Integrated into Your Business System Work Flow

Demonstrate the Software in Operation

A major premise of a quality management environment is an emphasis on continuous improvement. The approach to continuous improvement is best illustrated using the PDCA cycle, which was developed in the 1930s by Dr. Shewhart of the Bell System. The cycle comprises the four steps of Plan, Do, Check, and Act as shown in the following figure. It is also called the Deming Wheel, and is one of the key concepts of quality.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 12.54.11 AM.png

Plan (P): Devise a plan - Define the objective, expressing it numerically, if possible. Clearly describe the goals and policies needed to attain the objective at this stage. Determine the procedures and conditions for the means and methods that will be used to achieve the objective.

Do (D): Execute the plan - Create the conditions and perform the necessary teaching and training to ensure everyone understands the objectives and the plan. Teach workers the procedures and skills they need to fulfill the plan and thoroughly understand the job. Then perform the work according to these procedures.

Check (C): Check the results – As often as possible, check to determine whether work is progressing according to the plan and whether the expected results are obtained. Check for performance of the procedures, changes in conditions, or abnormalities that may appear.

Act (A): Take the necessary action - If the check reveals that the work is not being performed according to plan, or if results are not what were anticipated, devise measures for appropriate action. Look for the cause of the abnormality to prevent its recurrence. Sometimes workers may need to be retrained and procedures revised. The next plan should reflect these changes and define them in more detail.

Develop a matrix of process results and contributors to show which contributors drive which results. The results should come from the process policy. The contributors can be positive or negative, and involve process, product, or resource attributes. Process attributes includecharacteristics such as time, schedule, and completion. Product attributes include characteristics such as size, correctness, reliability, usability, and maintainability. Resource attributes include characteristics such as amount, skill, and attitude. A cause-and-effect diagram is often used to graphically illustrate the relationship between results and contributors.

Assure process results are aligned to business results. Processes should help people accomplish their organization’s mission. Alignment is subjective in many organizations, but the more objective it is, the greater the chance that processes will drive the mission.

Rank the process results and the contributors from a management perspective. This will help workers make tradeoffs and identify where to focus management attention.

Select metrics for both the process results and contributors, and create two tactical process dashboards: one for process results and one for contributors. These dashboards are used to manage the projects and to control and report project status. Normally results are measured subjectively and contributors are measured objectively. For example, for a result of customer satisfaction, contributors might include competent resources, an available process, and a flexible and correct product. Sometimes, as with customer satisfaction, factors that contribute to achieving the result can actually be used to develop the results metric. In other words, first determine what contributes to customer satisfaction or dissatisfaction and then it can be measured.

Please check the explanation for detailed answer.

Measurement Dashboards

Measurement dashboards (also called key indicators) are used to monitor progress and initiate change. A measurement dashboard is analogous to the dashboard on a car. Various key indicators are presented in comparison to their own desired target value (i.e., speed, oil temperature). Arrayed together, they provide an overall snapshot of the car's performance, health, and operating quality. Measurement dashboards help ensure that all critical performance areas are analyzed in relation to other areas. Indicators evaluated alone can lead to faulty conclusions and decision-making.

Key Indicators

Key indicators are the metrics used by management to help them fulfill their management responsibilities. Managers decide what key metrics they need. A dashboard is comprised of the total number of key indicators used by a single manager. The concept of “key” means the metric is considered important by the user in managing job responsibilities. Normally the key indicator is created from many different measures. For example, the Dow Jones Average is created from the combining of stock prices from approximately 40 different stocks.