I don’t really bother with new year resolutions, but it is a good time to take stock and make a new start for the new year. Most of us are feeling the effects of the recession, so rather than moaning about our finances this is a good time to take action.
Take Control of Your Food Shopping:
By planning your shopping in advance and buying the supermarket own brand products where possible you can avoid waste and cut your grocery bills significantly.
Take Control of Your Car Costs:
The cost of running your car makes a significant dent in your weekly budget, but a few simple adjustments will help you to reduce the cost of fuel for your car. Good planning and sensible driving can help you to reduce unnecessary journeys and avoid wasting fuel.
Give Your Time To Your Family:
In the long term your children will not remember the expensive gifts that you worked so hard to provide. They will remember time spent with you doing simple things like cooking, playing in the park or going to the library. Your family need your time and attention, family time doesn’t have to be expensive there are lots of things that you can do as a family that cost very little.
Be Content With What You Have:
In recent years we have got used to spending more than we have and always being able to have what we wanted when we wanted it. Our grandparents and great grandparents lived their lives very differently and there is a lot we can learn from their example. Like them we must learn to live within our means, to take care of the things we have and not waste anything. It will help us, but it will also help the planet if we learn to live more sustainably.
Don’t Be Too Proud to Accept Advice:
Don’t overlook the wisdom of those who have lived a little longer than you, you may have heard it all before but take a little time to consider their advice. Your Grandmother’s sayings may have taken their place in family folk law, but remember that her generation lived through the hardest of times, so there may be a lot that you can learn from her example of independence and determination.
Finally, Wish You A Happy & Prosperous New Year 2010 to all of you!!!
With Love,
~SA
Thursday, December 31, 2009
Monday, November 9, 2009
Zero Defects - Get it right first time
How much do quality failures cost your company?
Quality defects have significant costs associated with them - some of the most obvious being money, time, resources, and lost reputation. And programs to eliminate quality defects can be expensive and time consuming. Do you insist on eliminating defects entirely no matter the cost? Or, do you accept that a certain, albeit very small, percentage of defects is acceptable, and just accept the costs and learn to live with them?
One of the most influential ideas about this was the notion of "zero defects." This phrase was coined by Philip Crosby in his 1979 book titled, "Quality is Free."
His position was that where there are zero defects, there are no costs associated with issues of poor quality; and hence, quality becomes free.
Explaining the Idea
Zero defects is a way of thinking and doing that reinforces the notion that defects are not acceptable, and that everyone should "do things right the first time". The idea here is that with a philosophy of zero defects, you can increase profits both by eliminating the cost of failure and increasing revenues through increased customer satisfaction.
***"While this will probably be true, it may not be true in every case!"
"Zero defects" is referred to as a philosophy, a mentality or a movement. It's not a program, nor does it have distinct steps to follow or rules to abide by. This is perhaps why zero defects can be so effective, because it means it's adaptable to any situation, business, profession or industry.
The question that often comes up when zero defects is discussed, is whether or not zero defects is ever attainable. Essentially, does adopting a zero defect environment only set users up for failure?
Zero defects is NOT about being perfect. Zero defects is about changing your perspective. It does this by demanding that you:
* Recognize the high cost of quality issues;
* Continuously think of the places where flaws may be introduced; and
* Work proactively to address the flaws in your systems and processes, which allow defects to occur.
Zero defects is a standard. It is a measure against which any system, process, action, or outcome can be analyzed. When zero defects is the goal, every aspect of the business is subject to scrutiny in terms of whether it measures up.
***"The quality manager must be clear, right from the start, that zero defects is not a motivation program. Its purpose is to communicate to all employees the literal meaning of the words 'zero defects' and the thought that everyone should do things right the first time."
When you think about it, we expect zero defects when we are talking about items or services that we use. If you buy a fancy new plasma TV and your pixels start burning by the thousands, you demand satisfaction. When you take the car in for brake service, you expect that the mechanic will install the parts exactly as the manufacturer prescribes. No defect is an acceptable defect when it affects you personally.
So why then, is it so easy to accept that "defects happen" when you are the one producing the product or providing the service? This is the interesting dichotomy that presents itself. Zero defects is one of the best ways to resolve the discord between what we expect for ourselves and what we can accept for others.
***"Be very careful about where you apply zero defects. If what you're doing contributes towards a mission critical or complex goal, you'd better adopt a zero defects approach, or things could quickly unravel."
However, if you fanatically follow a zero defects approach in areas which don't need it, you'll most likely be wasting resources. One of the most important of these resources is time, and this is where people are accused of time-destroying "perfectionism."
Adopting Zero Defects
There are no step-by-step instructions for achieving zero defects, and there is no magic combination of elements that will result in them. There are, however, some guidelines and techniques to use when you decide you are ready to embrace the zero defects concept.
Management must commit to zero defects. Zero defects requires a top down approach: The best-intentioned employees cannot provide zero defects if they are not given the tools to do so.
* When you decide that zero defects is the approach you want to take, recognize that it likely represents a significant change to the way people do things. Manage the introduction using the principles of change management.
* Understand what your customers expect in terms of quality. Design systems that support zero defects where it matters, but don't over-design if the end-user just doesn't care.
* Zero defects requires a proactive approach. If you wait for flaws to emerge you are too late.
* Create quality improvement teams. Zero defects must be integrated with the corporate culture. Zero defects needs to be accepted as "the ways things are done around here".
* Learn poka - yoke (POH-kay YOH-kay.) Invented in the 1960s by Shigeo Shingo of Japan, it translates to "prevent inadvertent mistakes". It's an approach that emphasizes designing systems that make defects almost impossible or, if they can't be avoided, easy to detect and address. To implement zero defects, you have to have strong systems in place.
* Monitor your progress. Build mechanisms into your systems and methods of operating that provide continuous feedback. This allows you act quickly when flaws do occur.
* Measure your quality efforts. It is important to express your progress in terms of the bottom line. Take baseline measurements so you understand the cost of defects in your organization, and can measure the benefits your achieveing in eliminating them.
* Build quality into your performance expectations. Encourage members of your team to think about how they can achieve zero defects, and reward them when they're successful.
* Recognize that although zero defects is a destination, circumstances keep changing. Monitor, evaluate, and adapt in a continuous, never-ending cycle.
***"Things have moved on since 1979. Since then, there have been several waves of quality improvement which have taken things further, most recently resulting in "Six Sigma".
While zero defects is a useful idea, be aware that you may have to go much further nowadays if you want to lead your market in terms of quality of delivery."
Quality defects have significant costs associated with them - some of the most obvious being money, time, resources, and lost reputation. And programs to eliminate quality defects can be expensive and time consuming. Do you insist on eliminating defects entirely no matter the cost? Or, do you accept that a certain, albeit very small, percentage of defects is acceptable, and just accept the costs and learn to live with them?
One of the most influential ideas about this was the notion of "zero defects." This phrase was coined by Philip Crosby in his 1979 book titled, "Quality is Free."
His position was that where there are zero defects, there are no costs associated with issues of poor quality; and hence, quality becomes free.
Explaining the Idea
Zero defects is a way of thinking and doing that reinforces the notion that defects are not acceptable, and that everyone should "do things right the first time". The idea here is that with a philosophy of zero defects, you can increase profits both by eliminating the cost of failure and increasing revenues through increased customer satisfaction.
***"While this will probably be true, it may not be true in every case!"
"Zero defects" is referred to as a philosophy, a mentality or a movement. It's not a program, nor does it have distinct steps to follow or rules to abide by. This is perhaps why zero defects can be so effective, because it means it's adaptable to any situation, business, profession or industry.
The question that often comes up when zero defects is discussed, is whether or not zero defects is ever attainable. Essentially, does adopting a zero defect environment only set users up for failure?
Zero defects is NOT about being perfect. Zero defects is about changing your perspective. It does this by demanding that you:
* Recognize the high cost of quality issues;
* Continuously think of the places where flaws may be introduced; and
* Work proactively to address the flaws in your systems and processes, which allow defects to occur.
Zero defects is a standard. It is a measure against which any system, process, action, or outcome can be analyzed. When zero defects is the goal, every aspect of the business is subject to scrutiny in terms of whether it measures up.
***"The quality manager must be clear, right from the start, that zero defects is not a motivation program. Its purpose is to communicate to all employees the literal meaning of the words 'zero defects' and the thought that everyone should do things right the first time."
When you think about it, we expect zero defects when we are talking about items or services that we use. If you buy a fancy new plasma TV and your pixels start burning by the thousands, you demand satisfaction. When you take the car in for brake service, you expect that the mechanic will install the parts exactly as the manufacturer prescribes. No defect is an acceptable defect when it affects you personally.
So why then, is it so easy to accept that "defects happen" when you are the one producing the product or providing the service? This is the interesting dichotomy that presents itself. Zero defects is one of the best ways to resolve the discord between what we expect for ourselves and what we can accept for others.
***"Be very careful about where you apply zero defects. If what you're doing contributes towards a mission critical or complex goal, you'd better adopt a zero defects approach, or things could quickly unravel."
However, if you fanatically follow a zero defects approach in areas which don't need it, you'll most likely be wasting resources. One of the most important of these resources is time, and this is where people are accused of time-destroying "perfectionism."
Adopting Zero Defects
There are no step-by-step instructions for achieving zero defects, and there is no magic combination of elements that will result in them. There are, however, some guidelines and techniques to use when you decide you are ready to embrace the zero defects concept.
Management must commit to zero defects. Zero defects requires a top down approach: The best-intentioned employees cannot provide zero defects if they are not given the tools to do so.
* When you decide that zero defects is the approach you want to take, recognize that it likely represents a significant change to the way people do things. Manage the introduction using the principles of change management.
* Understand what your customers expect in terms of quality. Design systems that support zero defects where it matters, but don't over-design if the end-user just doesn't care.
* Zero defects requires a proactive approach. If you wait for flaws to emerge you are too late.
* Create quality improvement teams. Zero defects must be integrated with the corporate culture. Zero defects needs to be accepted as "the ways things are done around here".
* Learn poka - yoke (POH-kay YOH-kay.) Invented in the 1960s by Shigeo Shingo of Japan, it translates to "prevent inadvertent mistakes". It's an approach that emphasizes designing systems that make defects almost impossible or, if they can't be avoided, easy to detect and address. To implement zero defects, you have to have strong systems in place.
* Monitor your progress. Build mechanisms into your systems and methods of operating that provide continuous feedback. This allows you act quickly when flaws do occur.
* Measure your quality efforts. It is important to express your progress in terms of the bottom line. Take baseline measurements so you understand the cost of defects in your organization, and can measure the benefits your achieveing in eliminating them.
* Build quality into your performance expectations. Encourage members of your team to think about how they can achieve zero defects, and reward them when they're successful.
* Recognize that although zero defects is a destination, circumstances keep changing. Monitor, evaluate, and adapt in a continuous, never-ending cycle.
***"Things have moved on since 1979. Since then, there have been several waves of quality improvement which have taken things further, most recently resulting in "Six Sigma".
While zero defects is a useful idea, be aware that you may have to go much further nowadays if you want to lead your market in terms of quality of delivery."
Monday, October 12, 2009
Software Engineering Process Group (SEPG)
A Software Engineering Process Group (SEPG) is an organization's focal point for software process improvement activities. These individuals perform assessments of organizational capability, develop plans to implement needed improvements, coordinate the implementation of those plans, and measure the effectiveness of these efforts. Successful SEPGs require specialized skills and knowledge of many areas outside traditional software engineering.
Most organizations have many different projects or contracts underway simultaneously, and perhaps several different software development and maintenance divisions. Thus, many instances of the process improvement cycle may be operating concurrently. For example, one part of the organization may be following up on assessment findings by examining current cost-estimation practice, and another may be training software engineers in code inspections. The process improvement cycle works both globally across the organization, through policy changes and process assessments, and locally, with the implementation of particular changes. Assessments lead to strategy and policy updates; these updates lead to plans for the incorporation of new approaches to management and new software technology; the results meanwhile must be tracked and reported.
The software engineering process group is a central force for process improvement. The group maintains the overall view of current efforts and facilitates these efforts on a continuing basis. Its members foster collaboration among everyone in the organization who is involved with software process improvement.
Following are ongoing activities of the process group:
* Obtains and maintains the support of all levels of management.
* Facilitates software process assessments.
* Works with line managers whose projects are affected by changes in software engineering practice, providing a broad perspective of the improvement effort and helping them set expectations.
* Maintains collaborative working relationships with software engineers, especially to obtain, plan for, and install new practices and technologies.
* Arranges for any training or continuing education related to process improvements.
* Tracks, monitors, and reports on the status of particular improvement efforts.
* Facilitates the creation and maintenance of process definitions, in collaboration with managers and engineering staff.
* Maintains a process database.
* Provides process consultation to development projects and management.
The process group is not part of product development but is staffed by practitioners. As a result, it has expertise in software engineering. It may also have, and at any rate should develop, expertise in process definition, organizational change, and technology related to improving or measuring quality.
Costs & Benefits:
Process groups had to present a persuasive business case to become chartered and operational. Software
engineer process improvement was a concept with inherent merit in their organizations; competitive pressures required a steady increase in quality, which in turn required a commitment to improve. Nonetheless, it should be helpful to look briefly at specific costs and benefits of process groups and related efforts.
Costs:
The costs of estabilishing the software engineering process group and related functions- the process improvement infrastructure- are primarily labor costs. These are consumed in staff for the software engineering process group, and in the time spent in planning and implementing improvement actions. Often these are costs that would be expended on similar activities in any case, but in a less organized and therefore less visible way.
Benefits:
The primary benefit of an improved- that is, more disciplined -software process is improved visibility of the process. The visibilty makes the process more manageable during software development and maintenance, thus reducing risk. Schedules become more predictable, as do costs. Software is of higher quality at delivery and is easier to maintain. The cost of investment in process improvement work is amortized and ultimately more than rapid.
Another benefit is the improved prospect of winning and keeping contracts when the government includes software process maturity in its source selection and contract management criteria. Moreover, if certain contracts incentives are inaugurated, developers would be paid an award fee of up to 15% based on software quality as assessed during the early post -deployment phase. A mature development process would make it more likely that the award would be earned.
With Love,
~SA
Most organizations have many different projects or contracts underway simultaneously, and perhaps several different software development and maintenance divisions. Thus, many instances of the process improvement cycle may be operating concurrently. For example, one part of the organization may be following up on assessment findings by examining current cost-estimation practice, and another may be training software engineers in code inspections. The process improvement cycle works both globally across the organization, through policy changes and process assessments, and locally, with the implementation of particular changes. Assessments lead to strategy and policy updates; these updates lead to plans for the incorporation of new approaches to management and new software technology; the results meanwhile must be tracked and reported.
The software engineering process group is a central force for process improvement. The group maintains the overall view of current efforts and facilitates these efforts on a continuing basis. Its members foster collaboration among everyone in the organization who is involved with software process improvement.
Following are ongoing activities of the process group:
* Obtains and maintains the support of all levels of management.
* Facilitates software process assessments.
* Works with line managers whose projects are affected by changes in software engineering practice, providing a broad perspective of the improvement effort and helping them set expectations.
* Maintains collaborative working relationships with software engineers, especially to obtain, plan for, and install new practices and technologies.
* Arranges for any training or continuing education related to process improvements.
* Tracks, monitors, and reports on the status of particular improvement efforts.
* Facilitates the creation and maintenance of process definitions, in collaboration with managers and engineering staff.
* Maintains a process database.
* Provides process consultation to development projects and management.
The process group is not part of product development but is staffed by practitioners. As a result, it has expertise in software engineering. It may also have, and at any rate should develop, expertise in process definition, organizational change, and technology related to improving or measuring quality.
Costs & Benefits:
Process groups had to present a persuasive business case to become chartered and operational. Software
engineer process improvement was a concept with inherent merit in their organizations; competitive pressures required a steady increase in quality, which in turn required a commitment to improve. Nonetheless, it should be helpful to look briefly at specific costs and benefits of process groups and related efforts.
Costs:
The costs of estabilishing the software engineering process group and related functions- the process improvement infrastructure- are primarily labor costs. These are consumed in staff for the software engineering process group, and in the time spent in planning and implementing improvement actions. Often these are costs that would be expended on similar activities in any case, but in a less organized and therefore less visible way.
Benefits:
The primary benefit of an improved- that is, more disciplined -software process is improved visibility of the process. The visibilty makes the process more manageable during software development and maintenance, thus reducing risk. Schedules become more predictable, as do costs. Software is of higher quality at delivery and is easier to maintain. The cost of investment in process improvement work is amortized and ultimately more than rapid.
Another benefit is the improved prospect of winning and keeping contracts when the government includes software process maturity in its source selection and contract management criteria. Moreover, if certain contracts incentives are inaugurated, developers would be paid an award fee of up to 15% based on software quality as assessed during the early post -deployment phase. A mature development process would make it more likely that the award would be earned.
With Love,
~SA
Wednesday, September 16, 2009
Quality Assurance Process Tasks
PROCESS TASKS:
1. Establish QA organization or function
The PM appoints an individual or group responsible for QA. QA must have organizational freedom, authority, and independence to objectively evaluate and report on project activities. The QA Group maintains a reporting channel to senior management that is independent of the project.
2. Select QA tasks and assign responsibilities
The QA Group defines and assigns the tasks, work products and processes that will be performed, such as those listed below:a. Review products, tools, services, and facilities against requirements, standards and guidelines.
b. Audit project processes for compliance with standards, and established best practices.
c. Participate in peer reviews and project reviews (technical and management reviews) by providing status on compliance, problem areas, and risks.
d. Suggest methods, standards, guidelines, and tools to be defined for the project and verify they are documented in the project management plan or separate QA plan.
e. Report results of product and/or service evaluations and process audits to the PM, senior management, relevant stakeholders, and the project’s engineering process group (e.g. SEPG) as appropriate.
f. Collect and report metrics on the status of cost and schedule, product evaluations, project quality, and audits.
g. Collect improvement information on the QA processes and establish and maintain a description of the defined process.
The QA Group develops and documents QA plans in the project plan or equivalently in a QA Plan. Depending on the size and type of QA activities required, planning topics can include those listed below:
| · Quality objectives, in measurable terms · Types of test and verification and validation (V&V) activities · Entry and exit criteria for project lifecycle phases · Responsibilities of the QA group · Resource and training requirements for the QA group or function · Scheduling, budgeting and funding of QA activities · QA participation in development of project plans, standards, and procedures | · Process evaluations and audits to be performed by QA · Product and service audits and reviews to be conducted by QA · Standards and procedures used for QA · Documenting and tracking noncompliance issues, and the escalation procedure · Documentation that QA establishes, maintains, and controls over the life of the project through delivery · Method, audience, and frequency of providing feedback on QA activities |
4. Create and maintain QA procedures and checklists
The QA Group establishes and maintains the procedures, checklists, and work aids that describe how QA is to be performed.
The QA Group ensures that resources (tools, databases, work stations, etc.,) for performing the QA Process, developing the work products and providing QA services are adequate. Tools required to perform the QA tasks are identified based on project requirements.
The QA Group performs the tasks as defined in the project or QA Plan. Problems or non-conformances with requirements and standards are documented and reported to the PM or appropriate authority. The QA Group communicates the results of QA activities to relevant stakeholders for resolution. Senior management addresses non-compliance issues that cannot be resolved within the project.
6. Identify and select QA training
The QA Group identifies training required to perform the tasks identified in the QA Plan. Training includes training of the QA Group and QA orientation for the project team members.
7. Monitor and control the QA Process
The QA Group monitors and controls the day-to-day QA activities against the QA Plan, schedule and budget. Identify and evaluate the effects of risks on, and significant deviations from, the QA plan, schedule and budget. Take corrective action when requirements and objectives are not being satisfied or when progress differs significantly from the plan.
8. Place QA work products under CM
The QA Group places completed QA work products under configuration management (CM) in accordance with the project CM Plan.
9. Objectively evaluate the QA Process
The Objective Verifier evaluates the QA Group to provide credible assurance that the QA Process is implemented as planned, and adheres to its process description, standards and procedures.
QA activities, status and results are reviewed with the stakeholders, PM and senior management on a periodic and event-driven basis as designated in the QA Plan. The QA Group escalates unresolved or non-compliance issues and resolves them as necessary.
11. Collect improvement information
The QA Group initially reviews project QA processes and identifies improvements and efficiencies for future use. Suggestions for improvement of project QA processes are submitted to the project’s engineering project office for evaluation. Nominations for organizational standard best practices should be handled per the SSC San Diego SPA document, (submitted to SEPO, using Document Change Requests).
SEPO collects work products, measures, measurement results and improvement information derived from planning and performing the project QA Process to support future use and improvement as process assets.
SEPO establishes, collects and analyzes qualitative and quantitative measures of process variability to determine whether the processes are adequate for the intended function, satisfy project and organizational goals, and whether learning has been effectively shared.
12. Create and maintain a defined QA Process description
Working from SPI Agent and project nominations, SEPO and SPI Agents select and further refine QA best practice nominations into defined organizational QA standard process descriptions, templates and checklists for reuse as organizational process assets.
The QA Group then selects and tailors the QA Process assets from the process asset library according to the tailoring/scalability guidelines and the projects needs.
~SA
Friday, August 7, 2009
Agile Methodology
What Is Agile?
Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. But before discussing agile methodologies further, it’s best to first turn to the methodology that inspired it: waterfall, or traditional sequential development.
Where Did Agile Come From?
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.
It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?
Why Agile?
Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.
Agile Methods
Some of the well-known agile software development methods:
* Agile Modeling
* Agile Unified Process (AUP)
* Agile Data Method
* DSDM
* Essential Unified Process (EssUP)
* Extreme programming (XP)
* Feature Driven Development (FDD)
* Getting Real
* Open Unified Process (OpenUP)
* Scrum
* Lean software development
Agile Practices
* Test Driven Development (TDD)
* Behavior Driven Development (BDD)
* Continuous Integration
* Pair Programming
* Planning poker
Regards,
~SA
Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences, known as sprints. But before discussing agile methodologies further, it’s best to first turn to the methodology that inspired it: waterfall, or traditional sequential development.
Where Did Agile Come From?
In 1970, Dr. Winston Royce presented a paper entitled “Managing the Development of Large Software Systems,” which outlined his ideas on sequential development. In essence, his presentation asserted that a project could be developed much like an automobile on an assembly line, in which each piece is added in sequential phases. This means that every phase of the project must be completed before the next phase can begin. Thus, developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. There is little, if any, communication between the specialized groups that complete each phase of work.
It’s easy to see how this development agile methodology is far from optimized. First of all, it assumes that every requirement of the project can be identified before any design or coding occurs. Put another way, do you think you could tell a team of developers everything that needed to be in a piece of software before it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant. In that scenario, a company has spent time and money to create software that no one wants. Couldn’t it have been possible to ensure the end product would still be relevant before it was actually finished?
Why Agile?
Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle. This is achieved through regular cadences of work, known as sprints or iterations, at the end of which teams must present a shippable increment of work. Thus by focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology could be described as “iterative” and “incremental.” In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks, there’s always time to steer it in another direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world. In essence, it could be said that the agile development methodology helps companies build the right product. Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.
Agile Methods
Some of the well-known agile software development methods:
* Agile Modeling
* Agile Unified Process (AUP)
* Agile Data Method
* DSDM
* Essential Unified Process (EssUP)
* Extreme programming (XP)
* Feature Driven Development (FDD)
* Getting Real
* Open Unified Process (OpenUP)
* Scrum
* Lean software development
Agile Practices
* Test Driven Development (TDD)
* Behavior Driven Development (BDD)
* Continuous Integration
* Pair Programming
* Planning poker
Regards,
~SA
Thursday, July 16, 2009
ISO (International Organization for Standardization)
About ISO
ISO (International Organization for Standardization) is the world's largest developer and publisher of International Standards.
ISO is a network of the national standards institutes of 161 countries, one member per country, with a Central Secretariat in Geneva, Switzerland, that coordinates the system.
ISO is a non-governmental organization that forms a bridge between the public and private sectors. On the one hand, many of its member institutes are part of the governmental structure of their countries, or are mandated by their government. On the other hand, other members have their roots uniquely in the private sector, having been set up by national partnerships of industry associations.
Therefore, ISO enables a consensus to be reached on solutions that meet both the requirements of business and the broader needs of society.
Discover ISO:
ISO's Name:
Because "International Organization for Standardization" would have different acronyms in different languages ("IOS" in English, "OIN" in French for Organisation internationale de normalisation), its founders decided to give it also a short, all-purpose name. They chose "ISO", derived from the Greek isos, meaning "equal". Whatever the country, whatever the language, the short form of the organization's name is always ISO.
Why standards matter:
Standards make an enormous and positive contribution to most aspects of our lives.
Standards ensure desirable characteristics of products and services such as quality, environmental friendliness, safety, reliability, efficiency and interchangeability - and at an economical cost.
When products and services meet our expectations, we tend to take this for granted and be unaware of the role of standards. However, when standards are absent, we soon notice. We soon care when products turn out to be of poor quality, do not fit, are incompatible with equipment that we already have, are unreliable or dangerous.
When products, systems, machinery and devices work well and safely, it is often because they meet standards. And the organization responsible for many thousands of the standards which benefit the world is ISO.
When standards are absent, we soon notice.
What standards do:
ISO standards:
- make the development, manufacturing and supply of products and services more efficient, safer and cleaner
- facilitate trade between countries and make it fairer
- provide governments with a technical base for health, safety and environmental legislation, and conformity assessment
- share technological advances and good management practice
- disseminate innovation
- safeguard consumers, and users in general, of products and services
- make life simpler by providing solutions to common problems
ISO standards provide technological, economic and societal benefits.
For businesses, the widespread adoption of International Standards means that suppliers can develop and offer products and services meeting specifications that have wide international acceptance in their sectors. Therefore, businesses using International Standards can compete on many more markets around the world.
For innovators of new technologies, International Standards on aspects like terminology, compatibility and safety speed up the dissemination of innovations and their development into manufacturable and marketable products.
For customers, the worldwide compatibility of technology which is achieved when products and services are based on International Standards gives them a broad choice of offers. They also benefit from the effects of competition among suppliers.
For governments, International Standards provide the technological and scientific bases underpinning health, safety and environmental legislation.
For trade officials, International Standards create "a level playing field" for all competitors on those markets. The existence of divergent national or regional standards can create technical barriers to trade. International Standards are the technical means by which political trade agreements can be put into practice.
For developing countries, International Standards that represent an international consensus on the state of the art are an important source of technological know-how. By defining the characteristics that products and services will be expected to meet on export markets, International Standards give developing countries a basis for making the right decisions when investing their scarce resources and thus avoid squandering them.
For consumers, conformity of products and services to International Standards provides assurance about their quality, safety and reliability.
For everyone, International Standards contribute to the quality of life in general by ensuring that the transport, machinery and tools we use are safe.
For the planet we inhabit, International Standards on air, water and soil quality, on emissions of gases and radiation and environmental aspects of products can contribute to efforts to preserve the environment.
The ISO brand:
- Democratic
Every full member of ISO has the right to take part in the development of any standard which it judges to be important to its country's economy. No matter what the size or strength of that economy, each participating member in ISO has one vote. Each country is on an equal footing to influence the direction of ISO's work at the strategic level, as well as the technical content of its individual standards.
- Voluntary
ISO standards are voluntary. As a non-governmental organization, ISO has no legal authority to enforce the implementation of its standards. ISO does not regulate or legislate. However, countries may decide to adopt ISO standards - mainly those concerned with health, safety or the environment - as regulations or refer to them in legislation, for which they provide the technical basis. In addition, although ISO standards are voluntary, they may become a market requirement, as has happened in the case of ISO 9001 quality management systems, or of dimensions of freight containers and bank cards.
ISO itself does not regulate or legislate.
- Market-driven
ISO only develops standards for which there is a market requirement. The work is mainly carried out by experts from the industrial, technical and business sectors which have asked for the standards, and which subsequently put them to use.
- Consensus
ISO standards are based on international consensus among the experts in the field. Consensus, like technology, evolves and ISO takes account both of evolving technology and of evolving interests by requiring a periodic review of its standards at least every five years to decide whether they should be maintained, updated or withdrawn. In this way, ISO standards retain their position as the state of the art.
- Globally relevant
ISO standards are technical agreements which provide the framework for compatible technology worldwide. They are designed to be globally relevant - useful everywhere in the world.
ISO standards are useful everywhere in the world.
How to recognize an ISO standard:
In paper form, an ISO standard is published in A4 format - which is itself one of the ISO standard paper sizes. It may be anywhere between a four-page document and one several hundred pages' long. ISO standards are also available as electronic downloads and many are available as part of a collection on CD or in handbook. An ISO standard carries the ISO logo and the designation, "International Standard".
The scope of ISO's work:
ISO has more than 17500 International Standards and other types of normative documents in its current portfolio. ISO's work programme ranges from standards for traditional activities, such as agriculture and construction, through mechanical engineering, manufacturing and distribution, to transport, medical devices, information and communication technologies, and to standards for good management practice and for services.
Examples of the benefits standards provide:Standardization of screw threads helps to keep chairs, children's bicycles and aircraft together and solves the repair and maintenance problems caused by a lack of standardization that were once a major headache for manufacturers and product users.
Standards establishing an international consensus on terminology make technology transfer easier and safer. They are an important stage in the advancement of new technologies and dissemination of innovation.
Without the standardized dimensions of freight containers, international trade would be slower and more expensive.
Without the standardization of telephone and banking cards, life would be more complicated.
A lack of standardization may even affect the quality of life itself: for the disabled, for example, when they are barred access to consumer products, public transport and buildings because the dimensions of wheel-chairs and entrances are not standardized.
Standardized symbols provide danger warnings and information across linguistic frontiers.
Consensus on grades of various materials gives a common reference for suppliers and clients in business dealings.
Agreement on a sufficient number of variations of a product to meet most current applications allows economies of scale with cost benefits for both producers and consumers. An example is the standardization of paper sizes.
Standardization of performance or safety requirements of diverse equipment makes sure that users' needs are met while allowing individual manufacturers the freedom to design their own solution on how to meet those needs.
Standardized computer protocols allow products from different vendors to "talk" to each other.
Standardized documents speed up the transit of goods, or identify sensitive or dangerous cargoes that may be handled by people speaking different languages.
Standardization of connections and interfaces of all types ensures the compatibility of equipment of diverse origins and the interoperability of different technologies.
Agreement on test methods allows meaningful comparisons of products, or plays an important part in controlling pollution - whether by noise, vibration or emissions.
Safety standards for machinery protect people at work, at play, at sea... and at the dentist's.
Without the international agreement contained in ISO standards on metric quantities and units, shopping and trade would be haphazard, science would be unscientific and technological development would be handicapped.
~SA
Tuesday, June 30, 2009
CMM & CMMI
Capability Maturity Model (CMM):
The Capability Maturity Model (CMM) in software engineering is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization's processes. The CMM has been superseded by the Capability Maturity Model Integration (CMMI).
Capability Maturity Model structure
The Capability Maturity Model involves the following aspects:
* Maturity Levels: A 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.
* Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
* Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
* Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
* Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.
Levels of the Capability Maturity Model:
There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."
Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, shifting the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.
CMMI (Capacity Maturity Model Integration):
CMMI (Capacity Maturity Model Integration) is a model for evaluating a company's level of maturity in terms of IT developments.
CMMI is a broader version of CMM, on which it is based and from which it borrows most of its concepts, and offers best practices benchmarks for software development. The goal is to encourage companies to monitor and continually improve their processes and evaluate the maturity level of these processes on a five-level maturity scale set by the CMMI.
CMMI is a collection of best practices that meet the needs of organizations in different areas of interest. A collection of best practices that cover a particular area of interest is called a CMMI model.
CMMI currently addresses three areas of interest:
(1) Product and service development — CMMI for Development (CMMI-DEV),
(2) Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and
(3) Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).
CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.
CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM.
Achieving CMMI compliance:
The traditional approach that organizations often adopt to achieve compliance with the CMMI involves the establishment of an Engineering Process Group (EPG) and Process Action Teams (PATs). This approach requires that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM and primarily using the traditional approach. These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the CMMI.
The Software Engineering Institute’s (SEI) Team Software Process methodology and the Capability Maturity Modeling® framework have been successfully employed to accelerate progress from Maturity Level 1 to Maturity Level 4. They’ve demonstrated progressing form Level 1 to Level 4 in 30 months, which is less than half of the average time it has taken traditionally.
CMMI Can Benefit You:
CMMI provides
For More Information About CMMI:
Go to CMMI Web site:
http://www.sei.cmu.edu/cmmi
http://seir.sei.cmu.edu
Contact SEI Customer Relations:
Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
FAX: (412) 268-5800
customer-relations@sei.cmu.edu
With Love,
~SA
The Capability Maturity Model (CMM) in software engineering is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization's processes. The CMM has been superseded by the Capability Maturity Model Integration (CMMI).
Capability Maturity Model structure
The Capability Maturity Model involves the following aspects:
* Maturity Levels: A 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.
* Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
* Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
* Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
* Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.
Levels of the Capability Maturity Model:
There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."
Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the process (for example, shifting the mean of the process performance) to improve process performance. This would be done at the same time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.
CMMI (Capacity Maturity Model Integration):
CMMI (Capacity Maturity Model Integration) is a model for evaluating a company's level of maturity in terms of IT developments.
CMMI is a broader version of CMM, on which it is based and from which it borrows most of its concepts, and offers best practices benchmarks for software development. The goal is to encourage companies to monitor and continually improve their processes and evaluate the maturity level of these processes on a five-level maturity scale set by the CMMI.
CMMI is a collection of best practices that meet the needs of organizations in different areas of interest. A collection of best practices that cover a particular area of interest is called a CMMI model.
CMMI currently addresses three areas of interest:
(1) Product and service development — CMMI for Development (CMMI-DEV),
(2) Service establishment, management, and delivery — CMMI for Services (CMMI-SVC), and
(3) Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).
CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.
CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM.
Achieving CMMI compliance:
The traditional approach that organizations often adopt to achieve compliance with the CMMI involves the establishment of an Engineering Process Group (EPG) and Process Action Teams (PATs). This approach requires that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM and primarily using the traditional approach. These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the CMMI.
The Software Engineering Institute’s (SEI) Team Software Process methodology and the Capability Maturity Modeling® framework have been successfully employed to accelerate progress from Maturity Level 1 to Maturity Level 4. They’ve demonstrated progressing form Level 1 to Level 4 in 30 months, which is less than half of the average time it has taken traditionally.
CMMI Can Benefit You:
CMMI provides
- Efficient, effective assessment and improvement across multiple process disciplines in an organization
- Improvements to best practices incorporated from the Software CMM
- A common, integrated vision of improvement for all elements of an organization
- A means of representing new discipline-specific information in a standard, proven process-improvement context
For More Information About CMMI:
Go to CMMI Web site:
http://www.sei.cmu.edu/cmmi
http://seir.sei.cmu.edu
Contact SEI Customer Relations:
Customer Relations
Software Engineering Institute
Carnegie Mellon University
Pittsburgh, PA 15213-3890
FAX: (412) 268-5800
customer-relations@sei.cmu.edu
With Love,
~SA
Wednesday, June 17, 2009
Six Sigma – A Strategy for Achieving World Class Performance
What is Sigma (σ)?
Sigma Level:
Short-term sigma levels correspond to the following long-term DPMO values (one-sided):
Why Six Sigma:
Some Success Stories:
Cost of Poor Quality:
Elements of a process that significantly affect the output of that process. Identifying these elements is figuring out how to make improvements that can dramatically reduce costs and enhance quality.
Six Sigma Phases:
DEFINE: Define the project goals and customer (internal and external) deliverables
Fully trained team is formed, supported, and committed to work on improvement project.
Team charter developed, customers identified and high impact characteristics (CTQs) defined, business process mapped.
Checkpoints for Readiness
Team Readiness :
Team is sponsored by a champion or business leader.
Team formed and team leaders assigned.
Improvement team members fully trained on Six Sigma and DMAIC.
Team Charter :
Completed project management charter, including business case, problem and goal statements, project scope, milestones, roles and responsibilities, communication plan.
Customers
Customer(s) identified and segmented according to their different needs and requirements.
Data collected and displayed to better understand customer(s) critical needs and requirements.
Business Process Mapping
Completed, verified, and validated high-level 'as is' (not 'should be' or 'could be') business process map.
Completed SIPOC representation, describing the Suppliers, Inputs, Process, Outputs, and Customers.
MEASURE: Measure the process to determine current performance
Key measures identified, data collection planned and executed, process variation displayed and communicated, performance baselined, sigma level calculated.
Checkpoints for Readiness
Key Measures Identified
Key measures identified and agreed upon.
High impact defects defined and identified in the business process.
Data Collection Planned and Executed
Solid data collection plan established that includes measurement systems analysis.
Data collected on key measures that were identified.
Process Variation Displayed/Communicated
Process variation components displayed/communicated using suitable charts, graphs, plots.
Long term and short term variability accounted for.
Performance Baseline/Sigma Calculation
Measure baseline process performance (capability, yield, sigma level).
ANALYZE: Analyze and determine the root cause(s) of the defects
Data and process analysis, root cause analysis, quantifying the gap/opportunity.
Checkpoints for Readiness
Data and Process Analysis
Identify gaps between current performance and the goal performance.
Root Cause Analysis
Generate list of possible causes (sources of variation).
Segment and stratify possible causes (sources of variation).
Prioritize list of 'vital few' causes (key sources of variation).
Verify and quantify the root causes of variation.
Quantifying the Gap/Opportunity
Determine the performance gap.
Display and communicate the gap/opportunity in financial terms.
IMPROVE: Improve the process by eliminating defects
Generate (and test) possible solutions, select the best solutions, design implementation plan.
Checkpoints for Readiness
Generating (and Testing) Possible Solutions
Possible solutions generated and tested.
Selecting The Best Solution(s)
Optimal solution selected based on testing and analysis.
New and improved process ('should be') maps developed.
Cost/benefit analysis of optimal solution(s).
Small-scale pilot for proposed improvement(s).
Pilot data collected and analyzed.
Improved process ('should be') maps modified based on pilot data and analysis.
Project impact on utilizing the best solution(s).
Designing Implementation Plan
Solution implementation plan established, including schedule/work breakdown structure, resources, risk management plan, cost/budget, and control plan.
Contingency plan established.
CONTROL: Control future process performance
Documented and implemented monitoring plan, standardized process, documented procedures, response plan established and deployed, transfer of ownership (project closure).
Checkpoints for Readiness
Monitoring Plan
Control plan in place for sustaining improvements (short and long-term).
Process Standardization
New process steps, standards, and documentation are ingrained into normal operations.
Documented Procedures
Operating procedures are consistent.
Knowledge gained on process is shared and institutionalized.
Response Plan
Response plans established, understood, and deployed.
Transfer of Ownership (Project Closure)
Transfer ownership and knowledge to process owner and process team tasked with the responsibilities.
The basic method consists of the following five steps:
* Define design goals that are consistent with customer demands and the enterprise strategy.
* Measure and identify CTQs (characteristics that are Critical To Quality), product capabilities, production process capability, and risks.
* Analyze to develop and design alternatives, create a high-level design and evaluate design capability to select the best design.
* Design details, optimize the design, and plan for design verification. This phase may require simulations.
* Verify the design, set up pilot runs, implement the production process and hand it over to the process owners.
Tools and Roles for Six Sigma:
Process Maping:
Design of Experiments (DOE):
Executive Leadership: Includes CEO and other key top management team members. They are responsible for setting up a vision for Six Sigma implementation.
Champions: Are responsible for the Six Sigma implementation across the organization in an integrated manner. Champions also act as mentor to Black Belts.
Master Black Belts: dentified by champions, act as in-house expert coach for the organization on Six Sigma. They devote 100% of their time to Six Sigma.
Black Belts: Operate under Master Black Belts to apply Six Sigma methodology to specific projects. They primarily focus on Six Sigma project execution.
Green Belts: Are the employees who take up Six Sigma implementation along with their other job responsibilities. They operate under the guidance of Black Belts and support them in achieving the overall results.
Six Sigma Do's:
Six Sigma has made a huge impact on industry and is widely employed as a business strategy for achieving and sustaining operational and service excellence. However, there have also been various criticisms of Six Sigma.
Lack of originality:
Noted quality expert Joseph M. Juran has described Six Sigma as "a basic version of quality improvement," stating that "[t]here is nothing new there. It includes what we used to call facilitators. They've adopted more flamboyant terms, like belts with different colors. I think that concept has merit to set apart, to create specialists who can be very helpful. Again, that's not a new idea. The American Society for Quality long ago established certificates, such as for reliability engineers."
Role of consultants:
The use of "Black Belts" as itinerant change agents is controversial as it has created a cottage industry of training and certification. Critics argue there is overselling of Six Sigma by too great a number of consulting firms, many of which claim expertise in Six Sigma when they only have a rudimentary understanding of the tools and techniques involved.
The expansion of the various "Belts" to include "Green Belts," "Master Black Belts" and "Gold Belts" is commonly seen as a parallel to the various "belt factories" that exist in martial arts.
Potential negative effects:
A Fortune article stated that "of 58 large companies that have announced Six Sigma programs, 91 percent have trailed the S&P 500 since." The statement is attributed to "an analysis by Charles Holland of consulting firm Qualpro (which espouses a competing quality-improvement process)." The gist of the article is that Six Sigma is effective at what it is intended to do, but that it is "narrowly designed to fix an existing process" and does not help in "coming up with new products or disruptive technologies." Many of these claims have been argued as being in error or ill-informed.
A Business Week article says that James McNerney's introduction of Six Sigma at 3M may have had the effect of stifling creativity. It cites two Wharton School professors who say that Six Sigma leads to incremental innovation at the expense of blue-sky work. This phenomenon is further explored in the book, Going Lean, which provides data to show that Ford's "6 Sigma" program did little to change its fortunes.
Based on arbitrary standards:
While 3.4 defects per million opportunities might work well for certain products/processes, it might not be ideal or cost-effective for others. A pacemaker process might need higher standards, for example, whereas a direct mail advertising campaign might need lower ones. The basis and justification for choosing 6 as the number of standard deviations is not clearly explained. In addition, the Six Sigma model assumes that the process data always conform to the normal distribution. The calculation of defect rates for situations where the normal distribution model does not apply is not properly addressed in the current Six Sigma literature.
Criticism of the 1.5 sigma shift:
Because of its arbitrary nature, the 1.5 sigma shift has been dismissed as "goofy" by the statistician Donald J. Wheeler. Its universal applicability is seen as doubtful.
The 1.5 sigma shift has also been contentious because it results in stated "sigma levels" that reflect short-term rather than long-term performance: a process that has long-term defect levels corresponding to 4.5 sigma performance is, by Six Sigma convention, described as a "6 sigma process." The accepted Six Sigma scoring system thus cannot be equated to actual normal distribution probabilities for the stated number of standard deviations, and this has been a key bone of contention about how Six Sigma measures are defined. The fact that it is rarely explained that a "6 sigma" process will have long-term defect rates corresponding to 4.5 sigma performance rather than actual 6 sigma performance has led several commentators to express the opinion that Six Sigma is a confidence trick.
~SA
- A term used in statistics to represent standard deviation, an indicator of the degree of variation in a set of a process
- A statistical concept that measures a process in terms of defects – at the six sigma level, there 3.4 defects per million opportunities.
- A philosophy and a goal : as perfect as practically possible
- A methodology and a symbol of quality
Sigma Level:
Short-term sigma levels correspond to the following long-term DPMO values (one-sided):
- 1 sigma = 690,000 DPMO = 31% efficiency
- 2 sigma = 308,000 DPMO = 69.2% efficiency
- 3 sigma = 66,800 DPMO = 93.32% efficiency
- 4 sigma = 6,210 DPMO = 99.379% efficiency
- 5 sigma = 230 DPMO = 99.977% efficiency
- 6 sigma = 3.4 DPMO = 99.9997% efficiency
These figures assume that the process mean will shift by 1.5 sigma towards the side with the critical specification limit some time after the initial study determining the short-term sigma level. The figure given for 1 sigma, for example, assumes that the long-term process mean will be 0.5 sigma beyond the specification limit, rather than 1 sigma within it, as it was in the short-term study.
Why not Four Sigma or 99.379 % ?
- Every hour the postal service would lose 20,000 pieces of mail
- Every day our drinking water would be unsafe for almost 15 minutes
- Every week there would be 5,000 surgical operations that go wrong in some way
- Every month we would be without electricity for almost seven hours
Why Six Sigma:
- Money
- Quality
- Customer Satisfaction
- Competitive Advantage
- Growth
- Employee Pride
Some Success Stories:
- At GE, Six Sigma added more than $ 2 billion to the bottom line in 1999 alone
- Motorola saved more than $ 15 billion in the first 10 years of its Six Sigma effort
- AlliedSignal reports saving $ 1,5 billion through Six Sigma.
"Six Sigma is about practices that help you eliminate defects and always deliver products and services that meet customer specifications"
Cost of Poor Quality:
- What is cost of scrap?
- What is cost of rework?
- What is cost of excessive cycle times and delays?
- What is cost of business lost because customers are dissatisfied with your products or services?
- What is cost of opportunities lost because you didn’t have time or the resources to take advantage of them?
Elements of a process that significantly affect the output of that process. Identifying these elements is figuring out how to make improvements that can dramatically reduce costs and enhance quality.
Six Sigma Phases:
D M A I C : Define -> Measure -> Analyze -> Improve -> Control
- Define Customers and Requirements (CTQs)
- Develop Problem Statement, Goals and Benefits
- Identify Champion, Process Owner and Team
- Define Resources
- Evaluate Key Organizational Support
- Develop Project Plan and Milestones
- Develop High Level Process Map
Fully trained team is formed, supported, and committed to work on improvement project.
Team charter developed, customers identified and high impact characteristics (CTQs) defined, business process mapped.
Checkpoints for Readiness
Team Readiness :
Team is sponsored by a champion or business leader.
Team formed and team leaders assigned.
Improvement team members fully trained on Six Sigma and DMAIC.
Team Charter :
Completed project management charter, including business case, problem and goal statements, project scope, milestones, roles and responsibilities, communication plan.
Customers
Customer(s) identified and segmented according to their different needs and requirements.
Data collected and displayed to better understand customer(s) critical needs and requirements.
Business Process Mapping
Completed, verified, and validated high-level 'as is' (not 'should be' or 'could be') business process map.
Completed SIPOC representation, describing the Suppliers, Inputs, Process, Outputs, and Customers.
MEASURE: Measure the process to determine current performance
- Define Defect, Opportunity, Unit and Metrics
- Detailed Process Map of Appropriate Areas
- Develop Data Collection Plan
- Validate the Measurement System
- Collect the Data
- Begin Developing Y=f(x) Relationship
- Determine Process Capability and Sigma Baseline
Key measures identified, data collection planned and executed, process variation displayed and communicated, performance baselined, sigma level calculated.
Checkpoints for Readiness
Key Measures Identified
Key measures identified and agreed upon.
High impact defects defined and identified in the business process.
Data Collection Planned and Executed
Solid data collection plan established that includes measurement systems analysis.
Data collected on key measures that were identified.
Process Variation Displayed/Communicated
Process variation components displayed/communicated using suitable charts, graphs, plots.
Long term and short term variability accounted for.
Performance Baseline/Sigma Calculation
Measure baseline process performance (capability, yield, sigma level).
ANALYZE: Analyze and determine the root cause(s) of the defects
- Define Performance Objectives
- Identify Value/Non-Value Added Process Steps
- Identify Sources of Variation
- Determine Root Cause(s)
- Determine Vital Few x's, Y=f(x) Relationship
Data and process analysis, root cause analysis, quantifying the gap/opportunity.
Checkpoints for Readiness
Data and Process Analysis
Identify gaps between current performance and the goal performance.
Root Cause Analysis
Generate list of possible causes (sources of variation).
Segment and stratify possible causes (sources of variation).
Prioritize list of 'vital few' causes (key sources of variation).
Verify and quantify the root causes of variation.
Quantifying the Gap/Opportunity
Determine the performance gap.
Display and communicate the gap/opportunity in financial terms.
IMPROVE: Improve the process by eliminating defects
- Perform Design of Experiments
- Develop Potential Solutions
- Define Operating Tolerances of Potential System
- Assess Failure Modes of Potential Solutions
- Validate Potential Improvement by Pilot Studies
- Correct/Re-Evaluate Potential Solution
Generate (and test) possible solutions, select the best solutions, design implementation plan.
Checkpoints for Readiness
Generating (and Testing) Possible Solutions
Possible solutions generated and tested.
Selecting The Best Solution(s)
Optimal solution selected based on testing and analysis.
New and improved process ('should be') maps developed.
Cost/benefit analysis of optimal solution(s).
Small-scale pilot for proposed improvement(s).
Pilot data collected and analyzed.
Improved process ('should be') maps modified based on pilot data and analysis.
Project impact on utilizing the best solution(s).
Designing Implementation Plan
Solution implementation plan established, including schedule/work breakdown structure, resources, risk management plan, cost/budget, and control plan.
Contingency plan established.
CONTROL: Control future process performance
- Define and Validate Monitoring and Control System
- Develop Standards and Procedures
- Implement Statistical Process Control
- Determine Process Capability
- Develop Transfer Plan, Handoff to Process Owner
- Verify Benefits, Cost Savings/Avoidance, Profit Growth
- Close Project, Finalize Documentation
- Communicate to Business, Celebrate
Documented and implemented monitoring plan, standardized process, documented procedures, response plan established and deployed, transfer of ownership (project closure).
Checkpoints for Readiness
Monitoring Plan
Control plan in place for sustaining improvements (short and long-term).
Process Standardization
New process steps, standards, and documentation are ingrained into normal operations.
Documented Procedures
Operating procedures are consistent.
Knowledge gained on process is shared and institutionalized.
Response Plan
Response plans established, understood, and deployed.
Transfer of Ownership (Project Closure)
Transfer ownership and knowledge to process owner and process team tasked with the responsibilities.
DMADV: Define -> Measure -> Analyze -> Design -> Verify
The basic method consists of the following five steps:
* Define design goals that are consistent with customer demands and the enterprise strategy.
* Measure and identify CTQs (characteristics that are Critical To Quality), product capabilities, production process capability, and risks.
* Analyze to develop and design alternatives, create a high-level design and evaluate design capability to select the best design.
* Design details, optimize the design, and plan for design verification. This phase may require simulations.
* Verify the design, set up pilot runs, implement the production process and hand it over to the process owners.
DMADV is also known as DFSS, an abbreviation of "Design For Six Sigma"
Tools and Roles for Six Sigma:
Process Maping:
- Creating flowcharts of the step in a process – operations, decision points, delays, movements, handoffs, rework, loops, and controls or inspections.
- process map is illustrated description of how a process work.
Design of Experiments (DOE):
- DOE is a structured, organized method for determining the relationship between factors (Xs) affecting a process and the output of that process (Y).
- A group of rows and columns, with one set of increments marked along the X (horizontal) axis and another set of increments marked along the Y (vertical) axis.
- The purpose of using XY matrix is to study and understand the relationship between what you are putting into a process and what your customer is getting out of it.
- The XY matrix allows the team to identify gaps, areas for improvement.
- The goal of this tool is to ensure that your measurement system is statically confident – that it’s both accurate and precise each and every time it is used.
- Undertaken during Measure phase, your MSA determines whether or not you can take a certain measurement and repeat or reproduce it among different people who take the same measurement.
- Process capability tool is the measure of a process being able to meet specification requirements and fulfill customer CTQ needs on a long term basis.
- Investigating a theory about the suspected cause (s) of a particular effect in a process to determine if it is correct.
- It’s a compass that points you directly to the vital few factors that are most affecting your process.
- The manner in which a part or process can fail to meet a specification, creating a defect or non-conformance, and the impact on the customer if that failure mode is not prevented or corrected.
- A detailed assessment and guide for maintaining all the positive changes you, your black belt, and the project team have made.
- It ensures that all your analysis and efforts stay in effect and that you have information at your disposal to prevent backsliding or a return to less than optimal performance standard.
Executive Leadership: Includes CEO and other key top management team members. They are responsible for setting up a vision for Six Sigma implementation.
Champions: Are responsible for the Six Sigma implementation across the organization in an integrated manner. Champions also act as mentor to Black Belts.
Master Black Belts: dentified by champions, act as in-house expert coach for the organization on Six Sigma. They devote 100% of their time to Six Sigma.
Black Belts: Operate under Master Black Belts to apply Six Sigma methodology to specific projects. They primarily focus on Six Sigma project execution.
Green Belts: Are the employees who take up Six Sigma implementation along with their other job responsibilities. They operate under the guidance of Black Belts and support them in achieving the overall results.
Six Sigma Do's:
- Do communicate the commitment company-wide
- Do demonstrate the commitment of company leaders
- Do empower your key human resources
- Do provide on-site mentoring for black belts
- Do be patient at the inception of you six Sigma initiative
- Do claim and advertise early “wins”
- Do benchmark
- Do establish project baseline and
Six Sigma has made a huge impact on industry and is widely employed as a business strategy for achieving and sustaining operational and service excellence. However, there have also been various criticisms of Six Sigma.
Lack of originality:
Noted quality expert Joseph M. Juran has described Six Sigma as "a basic version of quality improvement," stating that "[t]here is nothing new there. It includes what we used to call facilitators. They've adopted more flamboyant terms, like belts with different colors. I think that concept has merit to set apart, to create specialists who can be very helpful. Again, that's not a new idea. The American Society for Quality long ago established certificates, such as for reliability engineers."
Role of consultants:
The use of "Black Belts" as itinerant change agents is controversial as it has created a cottage industry of training and certification. Critics argue there is overselling of Six Sigma by too great a number of consulting firms, many of which claim expertise in Six Sigma when they only have a rudimentary understanding of the tools and techniques involved.
The expansion of the various "Belts" to include "Green Belts," "Master Black Belts" and "Gold Belts" is commonly seen as a parallel to the various "belt factories" that exist in martial arts.
Potential negative effects:
A Fortune article stated that "of 58 large companies that have announced Six Sigma programs, 91 percent have trailed the S&P 500 since." The statement is attributed to "an analysis by Charles Holland of consulting firm Qualpro (which espouses a competing quality-improvement process)." The gist of the article is that Six Sigma is effective at what it is intended to do, but that it is "narrowly designed to fix an existing process" and does not help in "coming up with new products or disruptive technologies." Many of these claims have been argued as being in error or ill-informed.
A Business Week article says that James McNerney's introduction of Six Sigma at 3M may have had the effect of stifling creativity. It cites two Wharton School professors who say that Six Sigma leads to incremental innovation at the expense of blue-sky work. This phenomenon is further explored in the book, Going Lean, which provides data to show that Ford's "6 Sigma" program did little to change its fortunes.
Based on arbitrary standards:
While 3.4 defects per million opportunities might work well for certain products/processes, it might not be ideal or cost-effective for others. A pacemaker process might need higher standards, for example, whereas a direct mail advertising campaign might need lower ones. The basis and justification for choosing 6 as the number of standard deviations is not clearly explained. In addition, the Six Sigma model assumes that the process data always conform to the normal distribution. The calculation of defect rates for situations where the normal distribution model does not apply is not properly addressed in the current Six Sigma literature.
Criticism of the 1.5 sigma shift:
Because of its arbitrary nature, the 1.5 sigma shift has been dismissed as "goofy" by the statistician Donald J. Wheeler. Its universal applicability is seen as doubtful.
The 1.5 sigma shift has also been contentious because it results in stated "sigma levels" that reflect short-term rather than long-term performance: a process that has long-term defect levels corresponding to 4.5 sigma performance is, by Six Sigma convention, described as a "6 sigma process." The accepted Six Sigma scoring system thus cannot be equated to actual normal distribution probabilities for the stated number of standard deviations, and this has been a key bone of contention about how Six Sigma measures are defined. The fact that it is rarely explained that a "6 sigma" process will have long-term defect rates corresponding to 4.5 sigma performance rather than actual 6 sigma performance has led several commentators to express the opinion that Six Sigma is a confidence trick.
~SA
Tuesday, June 9, 2009
KAIZEN - A STRATEGY FOR PERFORMANCE EXCELLENCE
KAIZEN (INTRODUCTION):
Kaizen (改善, Japanese for "improvement") is a Japanese philosophy that focuses on continuous improvement throughout all aspects of life. When applied to the workplace, Kaizen activities continually improve all functions of a business, from manufacturing to management and from the CEO to the assembly line workers. By improving standardized activities and processes, Kaizen aims to eliminate waste.
Kaizen was first implemented in several Japanese businesses during the country's recovery after World War II, including Toyota, and has since spread to businesses throughout the world.
Masaaki Imai is known as developer of Kaizen.
What Does Kaizen Mean?
The original kanji characters for this word are: 改 善
In Japanese this is pronounced "kaizen".
改 ("kai") means "change" or "the action to correct".
善 ("zen") means "good".
Make it easier by studying it, and making the improvement through elimination of waste.
How It works:
Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work ("muri"), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes. The philosophy can be defined as bringing back the thought process into the automated production environment dominated by repetitive tasks that traditionally required little mental participation from the employees.
People at all levels of an organization can participate in kaizen, from the CEO down, as well as external stakeholders when applicable. The format for kaizen can be individual, suggestion system, small group, or large group. At Toyota, it is usually a local improvement within a workstation or local area and involves a small group in improving their own work environment and productivity. This group is often guided through the kaizen process by a line supervisor; sometimes this is the line supervisor's key role.
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. Hence the English usage of "kaizen" can be: "continuous improvement" or "continual improvement."
This philosophy differs from the "command-and-control" improvement programs of the mid-twentieth century. Kaizen methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested.
In modern usage, a focused kaizen that is designed to address a particular issue over the course of a week is referred to as a "kaizen blitz" or "kaizen event". These are limited in scope, and issues that arise from them are typically used in later blitzes.
Why Kaizen:
Kaizen (改善, Japanese for "improvement") is a Japanese philosophy that focuses on continuous improvement throughout all aspects of life. When applied to the workplace, Kaizen activities continually improve all functions of a business, from manufacturing to management and from the CEO to the assembly line workers. By improving standardized activities and processes, Kaizen aims to eliminate waste.
Kaizen was first implemented in several Japanese businesses during the country's recovery after World War II, including Toyota, and has since spread to businesses throughout the world.
Masaaki Imai is known as developer of Kaizen.
What Does Kaizen Mean?
The original kanji characters for this word are: 改 善
In Japanese this is pronounced "kaizen".
改 ("kai") means "change" or "the action to correct".
善 ("zen") means "good".
Make it easier by studying it, and making the improvement through elimination of waste.
How It works:
Kaizen is a daily activity, the purpose of which goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work ("muri"), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes. The philosophy can be defined as bringing back the thought process into the automated production environment dominated by repetitive tasks that traditionally required little mental participation from the employees.
People at all levels of an organization can participate in kaizen, from the CEO down, as well as external stakeholders when applicable. The format for kaizen can be individual, suggestion system, small group, or large group. At Toyota, it is usually a local improvement within a workstation or local area and involves a small group in improving their own work environment and productivity. This group is often guided through the kaizen process by a line supervisor; sometimes this is the line supervisor's key role.
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. Hence the English usage of "kaizen" can be: "continuous improvement" or "continual improvement."
This philosophy differs from the "command-and-control" improvement programs of the mid-twentieth century. Kaizen methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested.
In modern usage, a focused kaizen that is designed to address a particular issue over the course of a week is referred to as a "kaizen blitz" or "kaizen event". These are limited in scope, and issues that arise from them are typically used in later blitzes.
Why Kaizen:
CPI (Continual Performance Improvement)
- Data Driven Methodology to Magnify Impact of Process Improvement
- Apply Control Techniques to Eliminate Erosion of Improvements
- Proceduralize/Standardize Improvements for Improved Maintenance of Critical Process Parameters
Kaizen
- Use Small Teams to Optimize Process Performance by Implementing Incremental Change
- Apply Intellectual Capital of Team Members Intimate with Process
The Nine types of waste:
- Overproduction
- Delays (waiting time)
- Transportation
- Process
- Inventories
- Motions
- Defective products
- Untapped resources
- Misused resources
3 Main Principal of KAIZEN:
- Consider the process & the Results.
- The need to look at the entire process of the job at hand and to evaluate the job as to the best way to get the job done.
- Kaizen must be approached in such a way that no one is blamed and that the best process is put into place.
Key Features of KAIZEN:
- Widely Applicable - Can be used in both manufacturing and non-manufacturing enviornments.
- Highly Effective & Results Oriented - Kaizen event will generate Quick results, Measurable results, Estabilish the baseline, and Measure the change.
- A Learning Experience - Every member of Kaizen team will walk away from the event learning something new.
- Team Based & Cross Functional - Team members can be form various function of the business. Top managment participation is encouraged.
PHASES IN KAIZEN
- Step#0 - Event Prepration - Select event area, team, and create team package.
- Step#1 - Define the Scope & Goals of the event
- Step#2 - Train the team, Review the World Class Tool(s)and Techniques that Support the Team's Goal
- Step#3 - Walk the Event Area, Observe Physical Layout, Review Videos if Available. This Steps start the idea creation process
- Step#4 - Collect Data on Event Area (Scrap, Production, Time Studies, Videos, Etc) - Develop/Obtain the baseline performance measurements
- Step#5 - Brainstrom Ideas - Thinking "outside the box" and piggybacking important here.
- Step#6 - Use Multi-Voting to Prioritize Top 8-10 ideas that will be Worked on immediately
- Step#7 - Form Sub-Teams to Go Out and Try/Implement ideas
These steps are Shorten into:
- Select an Event
- Plan an Event
- Implement an Event
- Follow-up to an Event
BENEFITS OF KAIZEN
- KAIZEN reduces waste like Inventory waste, Time waste, Workers motion
- KAIZEN improves Space utilization, Product quality
- Results in Higher employee moral and job satisfaction, and lower turn over
~SA
Tuesday, June 2, 2009
Importance of "Work" in our life
Our life is an odd mixture of different moments of action and inaction, work and rest. Work provides us with an inner creative joy. It saves us from the dullness and boredom of life. It puts our energies to a proper use. Unused energies create disorders in us. They make us physically unhealthy and mentally unhappy. Time hangs heavy on our shoulders when there is no work. It provides us with money for our life hood. It makes our life meaningful and peaceful. Idleness is more tiresome and painful than work. Even the most unpaid, unimportant and unpleasant work is better than no work. For a really useful and happy work, two things are necessary. They are skill and constructiveness. Constructive work is rather unpleasant in the beginning, but very pleasant at the end. For deriving maximum pleasure from life, we must consider life as a whole, a unity and a system. Good Work pays and evil work destroys at the end. Every man who learns some useful skill enjoys it till he improves himself completely. The element of constructiveness is an important source of happiness. When a worker builds up something new. He feels encouraged and elevated and thus gets pleasure from his creative work. Where there is no need, there would be no work. Where there is no work, there would be no joy in life.
~SA
~SA
Sunday, May 31, 2009
Quality
Today i'm going to share my thought about term "quality". As most of my friends know that it is related to my job, so i thought i should share something with you guys.
Lets start with the term Quality...
What is quality:
The term 'quality' is often used in a vague, blurred way. If someone talks about 'working on quality', they may simply mean activities designed to improve the organisation and its services.
Quality is essentially about learning what you are doing well and doing it better. It also means finding out what you may need to change to make sure you meet the needs of your service users.
Quality is about:
@ knowing what you want to do and how you want to do it
@ learning from what you do
@ using what you learn to develop your organisation and its services
@ seeking to achieve continuous improvement
@ satisfying your stakeholders - those different people and groups with an interest in your organisation.
The domain of the quality professional has changed. From its humble beginnings in manufacturing, it is now expected, along with other infrastructure professions, such as IT, HR and finance, to contribute at the organisational level. Unlike those other professions, quality expertise can be hard to define, perhaps because there are many views of what business-level quality means.
At its simplest level, quality answers two questions: ‘What is wanted?’ and ‘How do we do it?’ Accordingly, quality’s stomping ground has always been the area of processes. From the bread and butter of ISO 9000, to the heady heights of TQM, quality professionals specify, measure, improve and re-engineer processes to ensure that people get what they want.
So what is wrong?
If requirements are wrong, then failure is guaranteed. Focus is the domain of QA where, without a specification, quality cannot be measured and thus controlled. You cannot have zero defects if you do not have a standard against which to measure defectiveness.
This reflects the early days, where quality was clearly about product. Quality Control, and later Quality Assurance, was our domain - we didn’t care about customers; the research and design department was responsible for designing the job and sales and marketing for selling it. But those halcyon days of definitive specifications and jobs for life are long gone.
I takes a step further down the value chain, to the use of the product or service (at which point customers had forced their way into the frame), i still presupposes that we can fully understand how the product will be used, which is a great challenge (and not always possible). You know, Some things are ‘unknown and unknowable’.
ISO 8402 recognises this uncertainty with its ‘implied need’. It uses the word ‘entity’ as opposed to the ‘product or service’ definition of its earlier (1986) version, indicating a broadening uncertainty. Nonetheless, it suffers again from a simplistic, single-minded focus - all we need to do is to figure out what is wanted and then deliver it.
The quality models are a step further into broader business. Here, although processes are important, quality is much more about people: customers are there, but so too are stakeholders - employees, partners, suppliers, shareholders and society. Perhaps wisely, the models avoid nailing down a specific definition of quality, leaving us without a definition that encompasses a broader business view.
ISO9000:2000 steps in this direction also, talking about ‘customer and other interested parties’, but leaves the definition of quality at a rather generalised ‘degree to which a set of inherent characteristics fulfils requirements’.
I hope that these words will help you to understand the term "Quality"
Luv,
~SA
Lets start with the term Quality...
What is quality:
The term 'quality' is often used in a vague, blurred way. If someone talks about 'working on quality', they may simply mean activities designed to improve the organisation and its services.
Quality is essentially about learning what you are doing well and doing it better. It also means finding out what you may need to change to make sure you meet the needs of your service users.
Quality is about:
@ knowing what you want to do and how you want to do it
@ learning from what you do
@ using what you learn to develop your organisation and its services
@ seeking to achieve continuous improvement
@ satisfying your stakeholders - those different people and groups with an interest in your organisation.
The domain of the quality professional has changed. From its humble beginnings in manufacturing, it is now expected, along with other infrastructure professions, such as IT, HR and finance, to contribute at the organisational level. Unlike those other professions, quality expertise can be hard to define, perhaps because there are many views of what business-level quality means.
At its simplest level, quality answers two questions: ‘What is wanted?’ and ‘How do we do it?’ Accordingly, quality’s stomping ground has always been the area of processes. From the bread and butter of ISO 9000, to the heady heights of TQM, quality professionals specify, measure, improve and re-engineer processes to ensure that people get what they want.
So what is wrong?
If requirements are wrong, then failure is guaranteed. Focus is the domain of QA where, without a specification, quality cannot be measured and thus controlled. You cannot have zero defects if you do not have a standard against which to measure defectiveness.
This reflects the early days, where quality was clearly about product. Quality Control, and later Quality Assurance, was our domain - we didn’t care about customers; the research and design department was responsible for designing the job and sales and marketing for selling it. But those halcyon days of definitive specifications and jobs for life are long gone.
I takes a step further down the value chain, to the use of the product or service (at which point customers had forced their way into the frame), i still presupposes that we can fully understand how the product will be used, which is a great challenge (and not always possible). You know, Some things are ‘unknown and unknowable’.
ISO 8402 recognises this uncertainty with its ‘implied need’. It uses the word ‘entity’ as opposed to the ‘product or service’ definition of its earlier (1986) version, indicating a broadening uncertainty. Nonetheless, it suffers again from a simplistic, single-minded focus - all we need to do is to figure out what is wanted and then deliver it.
The quality models are a step further into broader business. Here, although processes are important, quality is much more about people: customers are there, but so too are stakeholders - employees, partners, suppliers, shareholders and society. Perhaps wisely, the models avoid nailing down a specific definition of quality, leaving us without a definition that encompasses a broader business view.
ISO9000:2000 steps in this direction also, talking about ‘customer and other interested parties’, but leaves the definition of quality at a rather generalised ‘degree to which a set of inherent characteristics fulfils requirements’.
I hope that these words will help you to understand the term "Quality"
Luv,
~SA
Subscribe to:
Posts (Atom)
