Section 5.8. Section 7. Product Realization
5.8. Section 7. Product RealizationSection 7 of ISO 9001 can be considered the technical heart of the Standard. You can think of the three previous sections4, 5, and 6as preparatory. Section 4 describes the requirements of the Quality Management System and the need for a documented Quality Manual. That's the foundation of your quality program. Section 5 describes the responsibility of management in providing for the proper oversight, reviews, resources, and communication channels required for the program's successful deployment. And Section 6 describes the requirements for providing the right human resources to manage the program, the right tools for the team, and the right environment for the team to work in. With those elements in place, the organization has an infrastructure that can support the rollout and ongoing evolution of the Quality Management System. Section 7, Product Realization, defines the core requirements regarding what the QMS (as reflected in the Quality Manual) should contain. It is your process program. Product Realization is all about steps for creating a quality product, steps that move from planning to requirements, all the way through to production and delivery. To describe it in adequate detail, Section 7 is divided into six subsections. These subsections are:
Let's take a brief look at each. 5.8.1. 7.1. Planning of Product RealizationPlanning is an integral part of the QMS management process. It should also be a cornerstone activity for any quality or process improvement program. Planning is a control and measurement tool. It helps you chart an intelligent course, navigate that course, and judge how well you are staying on course. When you begin a project under the requirements of ISO 9001, the first activity you undertake is to plan the project. This project plan should contain at a minimum the following elements. 5.8.1.1. Product requirementsThis is an essential set of data. Before you can really begin a project, before you can even adequately plan a project, you need to know what the requirements are. You need to know what it is you are going to build. When projects begin without documented requirements (and that is not uncommon in this business), they invariably run into trouble. In the technology business, it's commonly understood that bad, soft, or missing requirements account for about half of a project's problems. But the temptation to begin the work of product realizationthat is, building the productoften overpowers common sense. Speed-to-market concerns can push a team to set sail without a compass. This is a surefire way to compromise product quality. The ISO Standard emphasizes the importance of gathering and documenting accurate project requirements first. The requirements are not only a valuable planning reference, they should become a permanent part of the plan's foundation. 5.8.1.2. Required QMS processesAny plan is a series of activities or steps you take to reach a goal. The plan then becomes the methodology for achieving the goal. And so the plan here should identify the processes and procedures in the Quality Manual that will be used on the project. Some projects may use all of the contents of the manual, particularly if they are full-life-cycle projects. Other projectsoften of limited or smaller scopemay require that you use only a subset of the manual. Whichever path is indicated, the plan should clearly define just what processes and procedures will be employed. 5.8.1.3. Verification, validation, monitoring, and test activitiesAs you'll see in the next section (7.2), ISO 9001 places a strong emphasis on understanding, documenting, and meeting customer requirements. To achieve this, you will need to continually assess your progress to make sure that the customer requirements are being realized in your work efforts and in the ensuing work products. The project plan should reflect this. In the plan, you should identify when verification, validation, monitoring, and testing activities will take place, and who will conduct these activities. Verification is making sure the requirements are being built into the product properly. Validation means confirming that the end product will work well in the intended environment. Monitoring is the mechanism to make sure proper oversight is being applied to project activities. And testing is the way to confirm that development activities have resulted in appropriately built products and components. 5.8.1.4. Identify control recordsThroughout its scope, ISO 9001 identifies records that are required to be created, maintained, and kept up by the product team. Some of these records are for the purpose of managing the project. Some are for measuring and improvement purposes. But the critical onesthe ones you should identify hereare used to demonstrate that the finished product meets customer requirements. You can think of these as traceability records. These are the records that trace how the customer requirements have been verified at key phases of the project. Figure 5-5 illustrates the four categories required for product realization planning. Figure 5-5. Planning for product realization requires that four categories of activities and components be accounted for: the customer and product requirements; the QMS processes to be applied on the project; defined verification, validation, and test activities; and the identification of control records to be used across the project. 5.8.2. 7.2. Customer-Related FocusWe've all heard the movie phrase, "If you build it, they will come." There's an assumption there: they will come because you built what they wanted built. That's true to the spirit of ISO 9001, even though it's a little backward. (ISO wants you to first find out what they want, and then build it.) The ISO Standard requires you to demonstrate a sharp customer-related focus. The reason behind that requirement is a sound one: quality can mean different things to different people. And so it's the job of the business to find out what its customers want, what is important to them, what they will get value from. If we are content to build just what we want (what we think of as quality), we may end up being the only ones who want it. The 9001 Standard supports its focus on the customer with three requirements:
Let's take a look at each. 5.8.2.1. 7.2.1. Determination of requirements related to the productAs a technology professional, you've probably run into this issue before: the clients think they know what they want, but they have a difficult time articulating it. The Standard addresses this by requiring you to work with your clients to document their requirements. The first step is to document what they know they want. This should include not only what should be in what you deliver but what you may have to do after delivery to ensure the product works as planned. Next, you should work to document the requirements not stated but known to be needed. This is where your experience comes into play. You probably know more about technology than the clients, and so you should provide insight into what supporting requirements might be needed in order to bring about the desired end result. You should also work with the clients to document any statutory and regulatory requirements that may exist around the product. These kinds of requirements are becoming more and more common, and many specialized industries have no choice but to comply. Health care, finance, and insurance are just three industries in which technology products and services must meet strict statutory and regulatory rules. Finally, you should work with your clients to uncover and document any additional requirements you think should be met. These additions may come from brainstorming sessions or review sessions. They may or may not materialize, but the idea is to work through the requirements to make sure that the baseline you end up with is complete enough to meet the intended goal of the project, to produce a product suitable to its anticipated use. 5.8.2.2. 7.2.2. Review the requirements related to the productThe requirements definition process is one of the more amorphous activities in technology development. It rides the fence between concept and conception, and so it's common to feel somewhat ambiguous as to when you're done or not. On top of that, a project may end up with thousands of requirements. Different people may have been responsible for collecting different requirement sets. All this can make the final productthe requirements specificationa daunting document. For these reasons, it's important to review the completed requirements with your client prior to committing to irrevocable technical solutions. The review process should be designed to ensure that the requirements are well defined. That means several things. It means that you confirm that the requirements are complete, that no major gaps exist and no critical functionality is missing. It also means that the requirements are understood; that they are clear, concise, and testable; that they do not conflict with one another; and that they are viable. This review will accomplish two things. First, it creates a commonality among teams. This is a common understanding between the client and the members of your technical and management teams as to the scope, purpose, and use of the requirements. The "daunting" element alluded to earlier will then have been somewhat reduced. Second, it should uncover any problems with the requirements set and give you the focus you need to resolve requirements issues. Out of this review activity, the requirements should emerge in strong shape. The organization should then be able to confirm that the defined requirements have the ability to meet the client's needs. 5.8.2.3. 7.2.3. Customer communicationFocus on the customer does not end once you understand what the customer wants. It should continue throughout the life of the project. Staying in touch with your customer is important, because when you boil it down, all projects are partnerships. The customer has partnered with you to create something. And so it is important to maintain communication with the customer over the life of this partnership. The Standard recognizes this through three requirements. The first is that the organization shall plan communication with the customer. For example, the project plan might contain a section on communications management, or you might even devise a separate communications plan to map out how you'll remain in touch with your customer. However you approach it, the avenue for communication should be clearly defined. The second is that the organization shall regularly share information with the customer concerning project progress and activity. This sharing typically includes exchanges concerning budget and schedule updates, functionality and product information, contract issues as they arise (should they arise), and changes or adjustments that need to be made from time to time to the project scope or deliverables. The third requirement is that the organization shall seek regular customer feedback. This implies an open channel of communication between the organization and the customer. This channel should support ongoing discussions, feedback as to how the organization is performing on the project. The organization, in the spirit of process and quality improvement, should also not shy away from any complaints that might come its way through this channel. All information can be used to beneficial purposes. 5.8.3. 7.3. Design and DevelopmentThe ultimate purpose of any project is to create something. The purpose of a Quality Management System is to help you create that something in an ordered manner. There are two recognized steps in this process: defining the solution and then realizing that solutiondesign and development. The ISO 9001 Standard composes the requirements for design and development in greater detail than the information in any other section. Requirements are presented for planning the design and development activities, establishing proper design inputs (such as functional requirements and regulatory requirements), generating appropriate outputs so that products can be adequately verified, reviewing designs and work products, verifying that designs and work products comply with the requirements, validating that the design and work products will function as intended, and ensuring that any changes introduced during design and development activities are properly controlled, tracked, and managed. These subsections are described in brief. 5.8.3.1. 7.3.1. Design and development planningDesign and development can (and almost always do) involve a variety of activities. To coordinate these activities effectively, they should be carefully planned. Usually this is reflected in a Project Plan, although it may exist as its own Design and Development Plan. The plan then becomes a management tool used to control design and development activities, to monitor their progress, and to provide mileposts for course confirmation and correction as needed. Proper planning should allow for management along several lines. For example, the plan should break down design and development into a series of manageable stages. This degree of decomposition depends upon several factors, including the scope of the project, the size of the project team, and the management view wished by the customer. The key is to understand what work products will be required for both design and development and then form the stages to accommodate them. Also, the stages you define for design and development activities can be used as quality gates during the project life cycle. They can serve as milestone points at which work products can be inspected prior to their moving along in the process. The Standard supports this approach by requiring that you plan for the review, verification, and validation of ensuing work products at defined stages. Effective planning should also require that the organization not only describe what activities will occur and when they will occur, but also who will be responsible for making sure they occur. The plan should reflect this. In it, you should assign responsibility and authority for the design and development activities and ensure that those team members assigned are explicitly made aware of (and prepped for) their duties. 5.8.3.2. 7.3.2. Design and development inputsThis subsection requires that you define and identify in the plan the specific inputs that are going to be related to the design. These are the documents or references that will be needed to produce a design that is complete and viable. These typically include things like the functional and performance requirements you have created through your work with the customer. Also included are the statutory or regulatory requirements that may be mandated by your customer's industry or by government agencies. In addition to the requirements, you might also point to other reference materials. For example, if you have worked on successful projects in the past using similar designs, you might (with the customer's acquiescence) reference the reuse of certain of those components. You might also do the same with existing code modules for developmental work activities or for any other work products that can be applied on the project. The goal here is to thoroughly think through the design and development activities and document what existing materials are relevant to these activities. Then you can plan for their acquisition over the life of the project. This ensures a solid degree of readiness for the team and positions the project to move forward in a focused and managed direction. 5.8.3.3. 7.3.3. Design and development outputsJust as you need to identify the inputs that are going to be used to create the design and guide development, you also need to identify what work products are going to emerge from the design and development activities. The outputs are typically some form of work product. These products add real value because they allow the team to properly verify and approve the work prior to moving it further along the production line. Note: As your program develops, you'll find that many of the outputs you create in the design stage may become appropriate inputs for later design or development stages. The Standard requires that the design and development outputs share certain characteristics. The first is that the outputs can be (and are) traced back to the requirements. This is an essential trait of good design and development, and a hallmark of sound quality control. Traceability is the process of tracking each requirement as it migrates across the production life cycle. When traceability is ignored or poorly implemented, requirements can become lost, convoluted, or their operations compromised. This is true especially in large systems with many requirements, or with systems that experience ongoing change. Traceability is a method to help guard the ultimate goal of the project: that what you build ends up containing everything the customer asked for. Next, the outputs should provide appropriate information for purchasing, production, and service provisioning. This means the outputs should be created with the understanding that they may influence what components, tools, or support materials have to be purchased to support their further development, deployment, or implementation. This information may be embedded as part of the output, or it may be attached to the output as an addendum or reference documentation. The outputs should also provide criteria for quality acceptance. This means that the work products or components produced during design and development should be established against certain standards. These standards serve as acceptance criteria for moving the product further along the life cycle or releasing the product to the customer. These criteria will vary from one work product to another, depending on the product type, the customer requirements, and the scope of the output. The key here is to ensure that these criteria are defined for each type of output. (These criteria will come into play in Section 7.3.4.) Finally, the outputs should specify the characteristics of the product that are essential for its safe and proper use. This requirement reflects ISO's manufacturing origins. Certain products' components can carry with them safety issues. You've no doubt read the caution labels on consumer products, such as "Don't spray next to open flame." Lawnmowers carry caution labels; shaving lotion cans carry caution labels. In assembling components for a guided missile, the same type of safety information would naturally apply. The idea here is that, if you are creating outputs (products or components) that need to be integrated or used in a particular way, you should describe what this particular way is and make it available to the handlers of the product or component so that potential misuse can be avoided. 5.8.3.4. 7.3.4. Design and development reviewThe inputs for design and development help ensure that the technical team knows how to build the right components and products for the customer. The outputs that emerge from design and development help confirm that the appropriate components and products are being produced. Section 7.3.4 deals with this confirmation process. The idea behind design and development review is to inspect the outputs at specified points in the production process. The inspection should be conducted by a team qualified to evaluate the output against two requirements. The first is that the team will evaluate the ability of work in progress to meet requirements. This includes assessing the work to make sure it meets (or contains) the requirements it was designed to fulfill. It's also important here to confirm that product functionality can be traced back to specific customer requirements. The next is corrective. If the team identifies any problems with the work product, it will evaluate, document, and recommend solutions to correct the problem. This process is often called a peer review and is a valuable quality-control tool. It is preventative in nature. Peer reviews are set into place to spot trouble areas as early on in production as possible, where they can be much more effectively corrected than if they show up in the finished product. 5.8.3.5. 7.3.5. Design and development verificationVerification is an extension of the peer-review process. One can think of the peer review as a team check for quality, a check conducted against a set of criteria. Verification is usually a much more organized effort. It often precedes a peer review or it is employed at certain milestone points: when critical components are integrated for the first time or a product is about to be released. In the field of technology development, verification is most often associated with testing. Testing can come in many forms: unit testing, system testing, integration testing, acceptance testing. Or it can be shaped as a very formal peer review. However you approach it, all verification efforts in ISO 9001 need to share two traits. The outputs of design and development activities should be verified to ensure that they can be traced back to the requirements and that they meet the intention of the requirements in full. This is most often accomplished through some form of testing procedure or some manner of in-depth inspection and sign-off. To support the verification process, the team should maintain records of verification results. These recordsobjective measurementscan be used to assess whether or not the component or product has been adequately realized. If it has been, the production process can continue. If not, corrective action may need to be taken. Keeping verification results is also a good tool for measuring the quality of team work. As these results collect over time, the organization should be able to see how its quality trends are shaping up. 5.8.3.6. 7.3.6. Design and development validationPeer reviews and verification activities are all about assessing whether or not the work meets the customer requirements. Validation adds another dimension. Its purpose is to ensure that the product will operate well in its intended environment. This duality can be a stumbling block for technology projects. For example, you might build a product that meets all of the customer requirements. When you test it on your in-house systems, it performs flawlessly. You therefore deem it ready for deployment. But once it's installed, something happens. Back at your office, you tested it with a team of 13 people banging away at it. But your customer sets 300 people on it and, as they do, performance slows to an unacceptable crawl. Another case: think of a computerized toaster. You're the software end of that business. Your staff tests a stream of software that sends an electronic pulse to a spring lever when a sensor detects the release of carbon monoxide (the toast is done). The code runs flawlessly on your development boxes. But when the software is embedded in a chip in the toaster, the up-down heat variation causes the silicon to expand and the software to loose its bearings. Proper component and product validation is set into place to anticipate these kinds of issues. Experienced technology shops will seek out these production requirements early on in the project. They are often defined as performance requirements, environmental requirements, or availability requirements. But whatever types of requirements you get, you should work with the customer to configure and create a validation environment that is as close to a real production environment as is practical. With this environment set up, you should then conduct a series of validation tests or analyses. And, as with verification, you should maintain records of the validation results. 5.8.3.7. 7.3.7. Control of design and development changesAnyone experienced with development projects knows well that change is the norm. Requirements change, environments are upgraded, systems migrate. A shift anywhere here could cause your work products to fall out of sync, operate poorly, malfunction, or become obsolete. Unless you actively manage such change, you risk losing control over the quality of what you produce. This is where the concept of change control becomes essential to project success. The ISO 9001 Standard requires that change management be implemented across all design and development activities. Your change-management program should have the following characteristics. As a part of ongoing quality management, changes should be regularly controlled. That means you should have mechanisms in place to monitor change requests on a set schedule. This may mean establishing a change-control board or change-review committeeor some similar teamand then chartering that group to meet at set points during the project. The chief purpose of this change-control group is to review change requests and assess the impact and effort required to introduce them into project work activities. In order for this to be conducted in a smooth manner, you'll find that a manageable change control program should contain some or all of the following components:
In addition to the above four components, the project team should ensure that change records are maintained across the life of the project. Figure 5-6 illustrates design and development control. Figure 5-6. Under activities for design and development, the program is required to support seven areas of control: planning for design and development, identifying design inputs, identifying design outputs, providing for design reviews, providing for proper verification, providing for proper validation, and managing change in a controlled manner. 5.8.4. 7.4. PurchasingIn technology projects, teams often explore what are called make/buy/reuse decisions. That is, they analyze choices when they have to produce something. Do they build it fresh, buy it new, or reuse existing components? If the team elects to make the component from scratch, they will typically have more control over its ultimate functionality and quality, but heavy costs and efforts may be required. If the team elects to reuse, it can work with something already built, perhaps customizing it to the needs of the project. But the degree of flexibility in such customization may be limited. If the team elects to buy new, it may be able to acquire the component quite cost-effectively, but it may risk introducing a preshaped element into the project, an element over which you may have little control. The decision to purchase a component and integrate it into the overall product scheme can be an effective strategy if it is managed well. In recognizing this, the Standard supports a considered method for purchasing components for a project. It does this by setting forth requirements for establishing a purchasing process, for defining the criteria the purchased element must meet, and for verifying that these criteria are met when the product is delivered. 5.8.4.1. 7.4.1. Purchasing processThe Standard requires that your Quality Management System contain a documented (and maintained) purchasing process. This process should define how to evaluate suppliers and vendors based on their ability to deliver quality goods. It should also define how the organization establishes the purchasing criteria to be used when third-party products are going to be examined. The goal of the purchasing process is to give your organization a consistent method for managing "buy" activities. The first part of the process is intended to help you deal with vendors who have the ability to meet your expectations and have proven this in the marketplace. This is important when purchasing. You are, in a very real way, giving up control of some commitments to your customer, placing them in someone else's hands. And so you want to take this step only with qualified vendors. Next, you want to establish the functional or performance criteria the purchased component must meet. This objectifies the purchasing process. Purchase decisions can often be made based on relationships, or on a perceived "wow factor" in a product. This leads to emotional choices that may not be best for the project in the long term. A better approach is for the organization or the project team to define what the component must do up front in order to meet specific customer requirements and then define some form of comparative checklist that can be applied to product options. This gives the team a sound base for evaluating purchasing choices. 5.8.4.2. 7.4.2. Purchasing informationThe evaluation criteria described in the previous section is fully developed here in purchasing information. The Standard requires that the project team, in working through the purchasing process, describe the product to be purchased in line with customer requirements. This description usually includes the criteria to be used for confirming the product's goodness-of-fit and approving its acquisition. It should also include such considerations as required vendor experience, qualifications, and market stability. To avoid undue outside influence, this information should be prepared by the team in advance of establishing vendor contacts. This step in the purchasing process is key to the success of the process. This is the action that makes the method a "considered" one. By thinking out and documenting what it is exactly you need to purchase, you increase the likelihood that what you end up buying will be something that fits the needs of the project. It helps to remove (or at least lessen) the potential for impulse buying or for making a purchasing decision based on a relationship, not on the needs of your customer. 5.8.4.3. 7.4.3. Verification of purchased productThe purchasing process also requires you to exercise due diligence for all purchases. The purpose here is to ensure that you are going to purchase components that will add value to the resulting product, that will take you closer to meeting customer requirements and performance expectations. And so the process includes steps for defining just what it is you need to purchase, what vendors are qualified to provide you with the goods, and what criteria you will use to make a purchasing decision. With all of this in place, you can proceed with the acquisition. But before the deal is done, you need to take one final step: you need to verify that the purchased product does in fact meet those purchasing criteria. So before you incorporate the componentbefore you integrate it with other componentsyou need to take a look at your criteria and inspect the product (what was actually delivered to you) against that. This verification process (you'll typically see this performed as an inspection or a series of acceptance tests) should be incorporated into the purchasing information (see Section 7.4.2). That way, the vendor will know what functional/performance features need to be met, as well as what acceptance process will be undertaken to bring the deal to a successful close. Once this final step is completed, you can integrate the acquired component with your other elements. 5.8.5. 7.5. Production and Service ProvisionSection 7.3 sets forth requirements for design and development activities. Section 7.5 rounds this out with requirements for production and service provisioning. Section 7.5 complements Section 7.3. It adds to 7.3. Design and development contains a series of discrete activities: inputs, outputs, verification steps, and so on. Product and service provision provides a framework under which you can conduct the design and development activities. This section is organized into five subsections:
Let's take a brief look at each of these. 5.8.5.1. 7.5.1. Control of product and service provisionThe processes you use to manage product (and service) production need to provide for an adequate degree of managerial control. To facilitate this, plans should be set into place for the major development stages: production, installation, and service delivery. These plans should include considerations such as:
By accounting for these planning parameters, the organization sets into place control mechanisms that will ensure work products are generated in an orderly manner, one that is visible for inspection and quality confirmation. As with all quality-control methods, the idea here is to plan, follow the plan, and then evaluate progress for effectiveness. It is through this path that the organization's product and service provision methodology can become refined and improved over time. 5.8.5.2. 7.5.2. Validation of processes for production and service provisionAs you've seen, ISO 9001 contains description of two general inspection activities: verification and validation. Verification is usually linked with activities like testing and product inspections. The goal of these activities is to confirm that the work products you've built satisfy the requirements that were specified by the customer. Verification is all about meeting requirements, and should really be chiefly focused on that. Validation is a little different. In one way, it's an extension of verification. The goal of validation is to ensure that the work products you produce operate in their intended environments. This is usually accomplished through some form of performance, load, or production mock-up testing. Validation helps ensure that the system interfaces work as planned, that the system will be able to stand up in the production environment, and that it will perform as expected during peak production activity. To support this, your Quality Manage System should contain processes for ensuring proper and appropriate validation checks of the product. Because validation is a key to product quality, the organization needs to plan its validation activities carefully. Processes here typically describe several activities, such as:
Finally, the process should contain criteria for product acceptancethat is, what validation results should be reached for the product to be deemed production-worthy. 5.8.5.3. 7.5.3. Identification and traceabilityTake a look at a bottle of Tylenol or a can of Thrifty Maid green peas. Somewhere on each container is the stamp of a batch number. That is about the cleanest example of identification and traceability I know of. If the peas I buy turn out to be moldy, that might indicate more than a bad can of peas. It could point to a larger production problem, one that might require the recall of lots of cans of peas. With that batch number, the manufacturer will know just which cans went through a shared process, when they were produced, and where they were shipped. Because that batch of peas has been identified and is traceable, the manufacturer can move effectively recall the cans, wherever they've ended up. This process of identification and traceability is valuable in the ISO world from two perspectives. First, it strengthens the capability of internal product management. You can keep a tight track on where your components are during each step of production. Second, you can know comfortably later on where your products are in the field, should you need to find or monitor them there. In the field of technology, identification and traceability are tied closely to configuration management (reflected in Section 5.5.5, "Preservation of product"). Good configuration management maintains an audit trail of your work components as they move through the various phases of the production process. And it keeps unique identifiers attached to these components so they can be easily identified, detached, rolled back, or discretely managed. Identification and traceability are also important from the perspective of customer satisfaction. You can see how this requirement is useful for forward management. But it is also useful for backward management, as a tool to trace the functionality in each component back to the requirements that the customer specified. By ensuring that you can trace requirements in such a manner, you add a level of confidence that your end product does indeed meet initial customer specifications. 5.8.5.4. 7.5.4. Customer propertyOften during project work, you'll find that your team is required to work with customer property. This may come about from working at the customer site, using specific customer equipment, or using intellectual property unique to your client. The Standard recognizes this and sets forth the requirement that you shall take good care of customer property. In other words, when placed in your care, you are responsible for making sure that the property is guarded against harm. This includes protecting it from damage, ensuring its safe and proper storage, and granting access to it only from authorized parties. If anything should happen to the property, you are required to record data about the incident and promptly report it to the customer. 5.8.5.5. 7.5.5. Preservation of productAs a technology organization, you may be producing software, circuit boards, system designs, or laptop computers. But whatever it is, you have to handle it at some point. ISO 9001 requires that your QMS contain a method for the proper handling of your products and their individual components. The Standard states that the organization shall take care to preserve the product and components during handling, packing, storage, transport, and delivery. With an otherwise sound QMS, you can create reliable deliverables. But if you drop them on the floor, bang them into a wall, overwrite them with a previous version, or erase them outright, your work can come to naught. That why it's important to "preserve" the products from the time materials come through your door on through each production phase, until they are finally delivered and installed. In the field of technology, this is typically part of your configuration management activities. Configuration management guards the state of your components. It preserves their integrity. Configuration management ensures that your team members have access to the components they need, and that they don't have access to things they don't need. It ensures that your team members are working on the latest version of a component (with the latest specs) as it matures over time. It makes sure that products are migrated from one staging area to another in an orderly and consistent manner. And it enforces guidelines and rules for promoting a product into production or packaging it for release. Good configuration management is an integral part of the ISO 9001 quality program. With it, you can be confident that your materials are handled properly and transported safely. 5.8.6. 7.6. Control of Monitoring and Measuring DevicesThe final section under Product Realization is Control of Monitoring and Measuring Devices. (This subject is extended with additional detail in Section 8 of the Standard.) In ISO 9001, the use of monitoring and measuring devices is essential to effective product realization. The monitoring and measuring devices you employ are the tools that enable you to confirm that what you have realized is satisfactory for release. Because these devices are so important to overall project success, it's important that they are properly controlled at all times on any given project. Therefore the Standard requires that you define what monitoring and measurement devices will be needed across the realization cycle. This can includefor technology projectswhat inspections and tests you'll conduct to ensure that the work meets customer requirements and operates in the intended environment. Additionally, you will want to establish processes to make sure that the monitoring and measurement activities are carried out in a coordinated manner. At heart, the Standard wants you to measure and monitor three things:
To do this effectively, your Quality Management System will need to contain definitions of how to measure these. You will need to define, for example, how to measure customer satisfaction. This might be done through a customer survey, through tracking technical support calls, by tracking the number of complaints, or any combination of these. Process effectiveness might be measured in throughput times, in defect occurrences, or by comments made in process review sessions. Work product quality might be measured in terms of reliability, requirements traceability, or cleanliness from defects. Once you have defined how you will measure these attributes, you will then need to build the processes (procedures and formulas) for monitoring, collecting, and analyzing the measurement data. These processes should then be incorporated into the project plan, with time and resources allocated for the activities around them. This will ensure proper control of the monitoring and measurement activities. 5.8.7. Required RecordsSection 7 of the Standard requires the collection of the most records: 13 in all. These records serve as artifacts that help you manage and control the product realization processes and they also serve as artifacts to show that you are complying with the requirements of this part of the Standard. Required records for Section 7:
|
EAN: 2147483647
Pages: 116