Quality management system
A quality management system (QMS)
is a collection of business processes focused on achieving your quality policy and
quality objectives — i.e. what your customer wants and needs.[1] It
is expressed as the organizational structure, policies, procedures, processes
and resources needed to implement quality
management. Early systems emphasized
predictable outcomes of an industrial product production line, using simple
statistics and random sampling. By the 20th century, labour inputs were
typically the most costly inputs in most industrialized societies, so focus
shifted to team cooperation and dynamics, especially the early signalling of
problems via a continuous
improvement cycle. In the 21st century, QMS has tended
to converge with sustainability and transparency initiatives,
as both investor and customer satisfaction and perceived quality is
increasingly tied to these factors. Of all QMS regimes, the ISO 9000 family
of standards is probably the most widely implemented worldwide - the ISO 19011 audit regime
applies to both, and deals with quality and sustainability and their
integration.
A QMS can be defined as:
“A set of co-ordinated activities to direct and
control an organisation in order to
continually improve the effectiveness and efficiency
of its performance.”
These activities interact and are affected by being
in the system, so the isolation and study of each one in
detail will not necessarily lead to an understanding
of the system as a whole. The main thrust of a QMS is
in defining the processes, which will result in the
production of quality products and services, rather than in
detecting defective products or services after they
have been produced.
A
fully documented QMS will ensure that two important requirements are met:
• The
customers’ requirements – confidence in the ability of the organisation to
deliver the desired
product and service consistently meeting their needs
and expectations.
• The
organisation’s requirements – both internally and externally, and at an
optimum cost with efficient
use of the available resources – materials, human,
technology and information.
These requirements can only be truly met if
objective evidence is provided, in the form of information and
data, to support the system activities, from the
ultimate supplier to the ultimate customer.
A QMS enables an organisation to achieve the goals
and objectives set out in its policy and strategy. It
provides consistency and satisfaction in terms of
methods, materials, equipment, etc, and interacts with all
activities of the organisation, beginning with the
identification of customer requirements and ending with
their satisfaction, at every transaction interface.
Methodology
Once the processes needed for the QMS and their sequences and
interactions have been identified (see Figure 1),
it is necessary to establish management responsibilities and accountabilities
for the performance of these processes. Many methodologies are available for
managing and improving processes, but all share some simple basic elements. A
simple process management and improvement methodology organized in a series of
steps is described in the following:
Step one: Establish the
responsibilities for managing the process. It is critical to have an
overall process manager or process owner with end to end responsibility and
accountability for all aspects of process performance. The process manager
needs to understand the entire process and have the authority to effect changes
in any part of it.
The process manager is
responsible for the following:
·
Forming
the process management team, which includes representatives from each major
part of the process.
·
Ensuring
the process operates in a controlled state of predictable performance.
·
Establishing
process performance measures that adequately characterize the efficiency and
effectiveness of the process in meeting the needs of all customers and other
interested parties.
·
Ensuring
all aspects of process management and improvement are performed. This includes
creating documentation, tracking performance, and securing and allocating
resources.
Step two: Define the
process. The
process manager and process management team need to carefully define the
process so everyone working within the process has a shared understanding of
how it operates. How much documentation is required depends on such attributes
as the stability and education of the workforce and the complexity and
criticality of the process.
All process inputs and
outputs are identified, along with the suppliers and customers, who may be
internal or external. The team also identifies process steps and flows. Many
quality tools, such as block diagrams and flowcharts, are available to support
these activities.
Step three: Identify
customer requirements. Carefully gather, analyze and document customer needs,
including how customers use the outputs of the process. Communicate frequently
with customers to understand needs from their viewpoint.
To the extent possible,
define measurable customer needs and rank them in order of importance. Directly
validate needs and requirements with customers.
Step four: Establish
measures of process performance. Translate customer needs and requirements into measures of
process performance. This is one of the most important and difficult steps in
process management.
Include customer
satisfaction, in-process measures and measures of supplier performance in
process measures. Relate all important customer needs, such as on time
performance, defect or error rates, tolerance intervals, product reusability,
and worker health and safety, to performance measures.
The process approach is
therefore one of the strongest approaches for integrating management system
standards because each process must be managed and improved simultaneously for
all process performance measures. Directly linking process performance measures
with customer needs is one of the most powerful aspects of process management.
Step five: Compare
process performance with customer requirements. Use the process
performance measures to ensure your process is operating in a stable and
predictable manner.
Compare the process
performance measures with the needs and requirements of the customers. Use a
variety of statistical tools for analyzing process measurement data to help
quantify process performance. Identify critical process improvement
opportunities through gaps in process performance.
These first five steps
provide a basic methodology for process management. But the responsibilities of
the process manager and process management team do not end there. A significant
benefit of process management is its natural fit with process improvement. Once
process performance has been compared with customer requirements, process
improvement is the natural next step.
Step six: Identify
process improvement opportunities. Use gaps in process performance vs. customer needs to
determine critical process improvement opportunities. Analyze process
performance measures for improvement opportunities related to sources of such
attributes as errors and defects, process simplification opportunities, process
bottlenecks and lack of adequate process controls.
Both process effectiveness
and efficiency can improve as a result of process improvement activities. Many
tools exist to identify process improvement opportunities.
Once process improvement
opportunities are identified, any of the many quality improvement methods can
be used to improve process performance. These quality improvement methods fit
naturally into step seven of the process management and improvement
methodology.
One quality improvement
method that can be used at this step is the plan, do, check, act (PDCA) cycle.
Step seven: Improve
process performance. Select
the process improvement opportunity to pursue. This selection should take into
account such attributes as the criticality of certain improvement needs,
difficulty of improvement opportunities, and resources and expertise available.
Establish quality
improvement teams to pursue specific improvement opportunities. These teams are
established by the process manager and process management team. The quality
improvement teams report to the process manager or the process management team
and are typically disbanded once their improvement project is completed.
The quality improvement
teams complete the following activities:
·
Clarify
the improvement opportunity problem statement, schedule and budget.
·
Determine
the root causes of problems.
·
Develop
and implement countermeasures to reduce or eliminate the occurrence of root
causes.
·
Stabilize
the process at the new level of performance.
·
Return
to step six or seven.
Support for the system
approach
The process approach is
an important part of the system approach to management. The process approach
assumes understanding and managing interrelated processes as a system can
contribute to an organization's effectiveness and efficiency in achieving
objectives.
Using the process approach,
a QMS is comprised of the following four categories of interrelated
Quality Planning
A quality plan describes how an organisation will
achieve its quality objectives. It describes the quality objectives and
specifies the quality assurance and control activities to be performed in
day-to-day company operations. In the case of a software development
organisation individual quality plans may be prepared for each software or
systems engineering project.
ISO 90011 requires top management to "...
ensure that the planning of the quality management system is carried out
..." (refer clause: 5.4.2 Quality management system planning).
Planning for Quality at the Organisation and Project
Levels
At the company level quality planning addresses
development, maintenance and improvement of the overall quality management
system. At the project level quality planning applies the quality management
system to individual projects.
Organisational Quality Plan
Content
An organizational quality plan is typically prepared
by the Quality Manager and covers the following issues:
Quality
objectives and goals
The overall objectives of the quality management
programmer together with measurable goals to be achieved
Quality
management system scope
Who and what will be impacted by the quality
management system. For example: process scope, product scope, organisational
scope
Organisation
& responsibilities
Organisational structure, reporting relationships
and roles and responsibilities for quality
Resource
requirements
Identification of the people and resources required
to develop, use, maintain and improve the quality management system
Cost
benefit analysis
A quality program cost benefit analysis addressing
issues such as: the cost of poor quality, the cost to improve quality and the
cost benefits to be achieved
Activities
and deliverables
The quality management system elements will be
produced/improved The quality management system development activities required
Schedule
The timeframes in which the work will be achieved
together with major milestones for quality management system element delivery,
review and deployment.
Risk
analysis
An analysis of what could go wrong together with
strategies for risk reduction.
Project
Quality Plan Content
A project quality plan describes the tailoring of an
organisation's quality management system for a particular project. The
Institute of Electrical and Electronics Engineers (IEEE) Std 730 Standard for
Software Quality Assurance Plans2 provides a well tested framework to work
from.
IEEE Std 730 Standard for
Software Quality Assurance Plans
1. Purpose
2. Reference
documents
3. Management
4. Documentation
5. Standards,
practices, conventions, and metrics
6. Software
reviews
7. Test
8. Problem
reporting and corrective action
9. Tools,
techniques, and methodologies
10.
Records collection, maintenance, and retention
11.
Training
12.
Risk management
Building a culture that values quality
Many of us in the testing profession have shared the
same sensation that Mike Talks described to me:
Sometimes in IT I feel we're right back at school,
the desperate kid trying to rush homework and get "something" in on
time, even though the teacher will get annoyed and make us do it again.
An organization’s culture starts at the top. How can
upper management nurture an environment that fosters collaboration, where
everyone, regardless of role, takes responsibility for building quality in to
the product?
Placing more value on the quality of the product
rather than just whether a particular feature was delivered on time could help
development teams integrate testing more tightly with coding. Mike Talks
suggests that “we need to challenge what we mean by ‘delivery.’ ‘Delivery of
code’ should mean something suitable for production, not the latest untested build.”
A culture of blame works against a culture of
quality. Ruhland noted that “at some companies, there is a reliance on the test
team to be the gatekeepers of quality, rather than have it everyone’s
responsibility.” How can we change this? Ruhland provided these ideas:
We should encourage reviewing problems and solutions
from a holistic perspective. For example, when an important bug is missed, do
not immediately blame the testing team. Instead spend time to understand what
in the process contributed to the bug being missed and implement necessary
changes.
As Ruhland pointed out to me, each team must agree
on areas for improvement, and define common goals. She recommends an
incremental approach, trying small pilot programs, continuously applying what
is learned to make small improvements.
A focus on learning leads to a focus on quality.
Many programmers have no experience with testing. They need time to learn
practices that “bake quality in,” such as test-driven
development and specification
by example. People in different roles need time to learn good ways to
collaborate with each other. When executives assure the development
organization that they themselves value quality over speed, and budget the time
to enable that to happen, teams can try experiments and pilot projects to
improve their process and manage their technical debt. Programmers and testers
can learn how to integrate testing with coding, and deliver the code their
customers want.
It takes courage to be a change agent. As Bob
Martin explains in his book The
Clean Coder,
telling management that your team will “try” to meet an impossible deadline
does NOT equal being a “team player.” A team player does what is right to make
the business succeed, and that includes being honest about the team’s
capabilities, and the risks associated with poor software quality. O’Gorman
shared his opinion with me:
My view is that upper management in our organization
needs to continue adopting ‘Agile’ development approaches, to see a wider
responsibility for quality.
ISO, the International Organization for Standardization, is a
nonprofit organization that develops and publishes standards of virtually every
possible sort, ranging from standards for information technology to fluid
dynamics and nuclear energy. Headquartered in Geneva, Switzerland, ISO is
composed of 162 members, each one the sole representative for their home
country. As the largest developer and publisher of standards in the world, ISO
fills the vital role of a medium for agreement between individual standards
developers, spreading progress made by one country's local developers across
the world to further the goal of standardization.
ISO 9000 - Quality management
The ISO 9000 family addresses various aspects of quality
management and contains some of ISO’s best known standards. The standards
provide guidance and tools for companies and organizations who want to ensure
that their products and services consistently meet customer’s requirements, and
that quality is consistently improved.
There are many standards in the ISO 9000 family, including:
·
ISO 9001:2008 - sets out the requirements of a quality
management system
·
ISO 9000:2005 - covers the basic concepts and language
·
ISO 9004:2009 - focuses on how to make a quality
management system more efficient and effective
·
ISO 19011:2011 - sets out guidance on internal and
external audits of quality management systems.
The Capability Maturity Model (CMM)[1] is a development model created after study of data collected
from organizations that contracted with the U.S. Department of
Defense, who funded the research. The term "maturity"
relates to the degree of formality and optimization of processes, from ad hoc practices, to formally defined steps, to managed result metrics,
to active optimization of the processes.
The model's aim is to
improve existing software-development processes, but it can also be applied to other processes.
A maturity level is a
well-defined evolutionary plateau toward achieving a mature software process.
Each maturity level provides a layer in the foundation for continuous process
improvement.
In CMMI models with a
staged representation, there are five maturity levels designated by the numbers
1 through 5
1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing
CMMI Staged Represenation- Maturity Levels
Now we will give more
detail about each maturity level. Next section will list down all the process
areas related to these maturity levels.
Maturity Level
Details:
Maturity levels consist of a predefined set of process areas.
The maturity levels are measured by the achievement of the specific and generic goals that apply to each predefined set of process areas. The
following sections describe the characteristics of each maturity level in
detail.
Maturity Level
1 - Initial
At maturity level 1,
processes are usually ad hoc and chaotic. The organization usually does not
provide a stable environment. Success in these organizations depends on the
competence and heroics of the people in the organization and not on the use of
proven processes.
Maturity level 1
organizations often produce products and services that work; however, they
frequently exceed the budget and schedule of their projects.
Maturity level 1
organizations are characterized by a tendency to over commit, abandon processes
in the time of crisis, and not be able to repeat their past successes.
Maturity Level
2 - Managed
At maturity level 2, an organization has achieved all the specific and generic goals of the maturity level 2 process areas. In other words, the
projects of the organization have ensured that requirements are managed and
that processes are planned, performed, measured, and controlled.
The process
discipline reflected by maturity level 2 helps to ensure that existing
practices are retained during times of stress. When these practices are in
place, projects are performed and managed according to their documented plans.
At maturity level 2,
requirements, processes, work products, and services are managed. The status of
the work products and the delivery of services are visible to management at
defined points.
Commitments are
established among relevant stakeholders and are revised as needed. Work
products are reviewed with stakeholders and are controlled.
The work products and
services satisfy their specified requirements, standards, and objectives.
Maturity Level
3 - Defined
At maturity level 3, an organization has achieved all the specific and generic goals of the process areas assigned to maturity levels 2 and 3.
At maturity level 3,
processes are well characterized and understood, and are described in
standards, procedures, tools, and methods.
A critical
distinction between maturity level 2 and maturity level 3 is the scope of
standards, process descriptions, and procedures. At maturity level 2, the
standards, process descriptions, and procedures may be quite different in each
specific instance of the process (for example, on a particular project). At
maturity level 3, the standards, process descriptions, and procedures for a
project are tailored from the organization's set of standard processes to suit
a particular project or organizational unit. The organization's set of standard
processes includes the processes addressed at maturity level 2 and maturity
level 3. As a result, the processes that are performed across the organization
are consistent except for the differences allowed by the tailoring guidelines.
Another critical
distinction is that at maturity level 3, processes are typically described in
more detail and more rigorously than at maturity level 2. At maturity level 3,
processes are managed more proactively using an understanding of the
interrelationships of the process activities and detailed measures of the
process, its work products, and its services.
Maturity Level
4 - Quantitatively Managed
At maturity level 4, an organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, and 4 and
the generic goals assigned to maturity levels 2 and 3.
At maturity level 4
Subprocesses are selected that significantly contribute to overall process
performance. These selected subprocesses are controlled using statistical and
other quantitative techniques.
Quantitative
objectives for quality and process performance are established and used as
criteria in managing processes. Quantitative objectives are based on the needs
of the customer, end users, organization, and process implementers. Quality and
process performance are understood in statistical terms and are managed
throughout the life of the processes.
For these processes,
detailed measures of process performance are collected and statistically
analyzed. Special causes of process variation are identified and, where
appropriate, the sources of special causes are corrected to prevent future
occurrences.
Quality and process
performance measures are incorporated into the organization.s measurement
repository to support fact-based decision making in the future.
A critical
distinction between maturity level 3 and maturity level 4 is the predictability
of process performance. At maturity level 4, the performance of processes is
controlled using statistical and other quantitative techniques, and is
quantitatively predictable. At maturity level 3, processes are only qualitatively
predictable.
Maturity Level
5 - Optimizing
At maturity level 5, an organization has achieved all the specific goals of the process areas assigned to maturity levels 2, 3, 4, and 5
and the generic goals assigned to maturity levels 2 and 3.
Processes are
continually improved based on a quantitative understanding of the common causes
of variation inherent in processes.
Maturity level 5
focuses on continually improving process performance through both incremental
and innovative technological improvements.
Quantitative
process-improvement objectives for the organization are established,
continually revised to reflect changing business objectives, and used as
criteria in managing process improvement.
The effects of
deployed process improvements are measured and evaluated against the
quantitative process-improvement objectives. Both the defined processes and the
organization's set of standard processes are targets of measurable improvement
activities.
Optimizing processes
that are agile and innovative depends on the participation of an empowered
workforce aligned with the business values and objectives of the organization.
The organization's ability to rapidly respond to changes and opportunities is
enhanced by finding ways to accelerate and share learning. Improvement of the
processes is inherently part of everybody's role, resulting in a cycle of
continual improvement.
A critical
distinction between maturity level 4 and maturity level 5 is the type of
process variation addressed. At maturity level 4, processes are concerned with
addressing special causes of process variation and providing statistical
predictability of the results. Though processes may produce predictable
results, the results may be insufficient to achieve the established objectives.
At maturity level 5, processes are concerned with addressing common causes of
process variation and changing the process (that is, shifting the mean of the
process performance) to improve process performance (while maintaining
statistical predictability) to achieve the established quantitative
process-improvement objectives.
Maturity
Levels Should Not be Skipped:
Each maturity level
provides a necessary foundation for effective implementation of processes at
the next level.
·
Higher level processes have less chance of success
without the discipline provided by lower levels.
·
The effect of innovation can be obscured in a noisy
process.
Higher maturity level
processes may be performed by organizations at lower maturity levels, with the
risk of not being consistently applied in a crisis.
Maturity
Levels and Process Areas:
Here is a list of all
the corresponding process areas defined for a S/W organization. These process
areas may be different for different organization.
This section is just giving names of the related process areas,
for more detail about these Process Areas go through CMMI Process Areas Chapter.
|
Level
|
Focus
|
Key
Process Area
|
Result
|
|
5
Optimizing
|
Continuous Process
Improvement
|
·
Organizational
Innovation and Deployment
·
Causal Analysis and
Resolution
|
Highest Quality /
Lowest Risk
|
|
4
Quantitatively Managed
|
Quantitatively
Managed
|
·
Organizational
Process Performance
·
Quantitative
Project Management
|
Higher Quality /
Lower Risk
|
|
3
Defined
|
Process
Standardization
|
·
Requirements
Development
·
Technical Solution
·
Product Integration
·
Verification
·
Validation
·
Organizational
Process Focus
·
Organizational
Process Definition
·
Organizational
Training
·
Integrated Project
Mgmt (with IPPD extras)
·
Risk Management
·
Decision Analysis
and Resolution
·
Integrated Teaming
(IPPD only)
·
Org. Environment
for Integration (IPPD only)
·
Integrated Supplier
Management (SS only)
|
Medium Quality /
Medium Risk
|
|
2
Managed
|
Basic Project
Management
|
·
Requirements
Management
·
Project Planning
·
Project Monitoring
and Control
·
Supplier Agreement
Management
·
Measurement and
Analysis
·
Process and Product
Quality Assurance
·
Configuration
Management
|
Low Quality /
High Risk
|
|
1
Initial
|
Process is informal
and Adhoc
|
|
Lowest Quality /
Highest Risk
|
What is Next:
What is Risk Management?
Risk management is a structured methodology of handling uncertainty associated
with a threat. Risk management includes development of strategies to handle the
risk either by
a. Transfer of the risk to
some other party
b. Taking actions so as to
completely avoid the risk
c. Taking measures aimed at
reducing the damaging effects of the inevitable risk
d. Taking decision to accept
some or all of the consequences of a particular risk.
Few of the Risks associated
with software product are described as under:
1) Risks related to the Size of the Product:
The size of the software product also can pose threat when it gets subjected to
unexpectedly high deviation compared to the expectations. As a best practice, the
expectations from the product are compared with similar situations encountered
in the past & learning from the past happenings.
Some of the risks
associated with the size of the software product can be:
a. Judgement on the size of
the product can be a threat
b. Judgement on the number
of users using the product can be a threat
c. Judgement on the size of
the associated database can be a threat
d. Uncontrolled changes in
the product requirements can be a threat to the product size
2) Risks having Impact on the Business:
There are certain types of threats or risks, which can have effect on the
performance of the business. Such risks are like:
a. Quality of the software
product having an impact on revenue of the company.
b. Product delivery dates
having impact on the company business, including costs of delayed delivery.
c. Inconsistent customer
needs having impact on the company business.
d. Drastic change in number
of users expected to use the product having impact on the company business.
e. Inadequacy of help /
documentation as expected by the customer.
3) Risks related to Customers:
Every customer has a different personality, so are their needs. We can
categorize customers in the following way according to their behavior &
reaction to the product delivered to them.
a. Type of customers who
happily accept a product as it is when delivered
b. Type of customers who are
of complaining nature & usually tend to grumble on the quality of the
product delivered to them. Such customers pose a reasonable amount of threat to
the project manager handling the project
c. Type of customers who
happen to have past association with the product developing company
d. Type of customers who
have good technical knowledge of the product
e. Type of customers who
have fairly good understanding of the usage of the product
f. Type of customers who
have a good understanding of process of software engineering
g. Type of customers who are
ready to participate in the process of reviews during the SDLC
h. Type of customers who are
not much aware of the product & start using it as & when it comes
i.
Type
of customers who are technically clear about their requirements / expectations
from the product & are able to define the scope of the project clearly
4) Risks related to Software Engineering Process:
Clear cut definition of the entire process of software engineering is of
paramount importance for the success of the product. A badly planned process
will result into a software product posing great threats to itself as well as
to the organization.
Following guidelines /
checklist can be helpful in identifying the software engineering related
threats & planning their counter measures.
a. Ensure the availability
of a documented process planned for the development of the software product.
b. Ensure that all the
participants of the product development team (whether in-house or third party
peoples) is religiously following the documented process
c. Ensure the availability
of a mechanism for monitoring the activities & performance of third party
developers & testers, if any.
d. Ensure the active
participation of someone who can regularly monitor the technical reviews
conducted by the development teams as well as the testing teams.
e. Ensure the proper
documentation of outcome of the technical reviews detailing the resources
deployed to unearth what type of software bugs.
f. Ensure the availability
of a configuration management mechanism for ensuring adequate consistency in
design, development and testing of the product in line with the basic
requirements already defined.
g. Ensure the availability
of a mechanism to handle the changes in product requirements raised by the
customer from time to time. Such system should be able to analyze the impact of
such changes on the software product
5) Risks related to the Technology of Development:
Many times technological factors also pose great threat to the success of the
software product. Following guidelines / checklist can be helpful in
identifying the technology related threats & planning their counter
measures.
a. An absolutely new
technology being used for building the software application can be a threat to
the organization.
b. Unless proper interface
is developed between the software & hardware of some new configurations,
there can be a cause of threat.
c. Unless function,
performance and interface of the database system has been proven across the
application area in question, there can be a cause of threat.
d. Requirement of some
absolutely new or highly specialized interface as expected by the product can
also pose a threat
e. Demand of some
specialized requirements of particular type of design and testing tools and
techniques can be a cause of concern or risk.
f. Too much of structured
requirements imposed by the customer can a lot of pressure on the performance
of the product
g. Inadequacy of
productivity-related metrics and quality related metrics available to the
product development teams can pose risk of emergence of poor quality product
6) Risks associated with development & Testing Tools:
Different types of development and testing tools can also be a cause of concern
many a times during the SDLC.
a. Use of some typical
methods for analysis can be a cause of concern.
b. Use of some typical
methodologies for documentation can be a cause of concern.
c. Use of some typical
methods to design the test cases can be a cause of concern.
d. Use of typical tools for managing
the project activities can be a cause of concern.
e. Use of particular tools
for configuration management during the SDLC can be a cause of concern
f. Use of particular tools
for prototyping purposes can be a cause of concern
g. Use of particular tools
for providing support to the software testing process can be a cause of concern
h. Use of particular tools
for managing the documentation can be a cause of concern
7) Risks related to the developmental Environment:
Environment provided for development of the product also plays a key role in
the success of the product. Some of the factors or situations described below
can pose certain amount of risk.
a. Availability of an
adequate tool for the management of the software product & its development
processes.
b. Availability of an
adequate tool for performing design and analysis activities.
c. Adequacy of performance
of tools deployed for design and analysis of the product being created
d. Availability of a
suitable code generators or compiler compatible with the product being created
e. Availability of a
suitable testing tools compatible with the product being created.
f. Availability of a
suitable configuration management tools compatible with the product being
created.
g. Compatibility of the
databases with the environment under which they are deployed.
h. Compatibility or proper
integration of all software tools with each other
i.
Adequacy
of skills / training to all concerned team members as regards application of
the tools.
8) Risks related to the quality of development personnel:
A product coming out of the hands of personnel of lower skill levels shall be
certainly a cause of risk to the organization. Following checklist shall be
helpful in bridging the gaps in this area.
a. Deployment of personnel
having best possible skills appropriate to the project
b. When in a team, proper
combination of various personnel with different temperament & skill levels
is important.
c. Availability of the
nominated personnel during the complete duration of the project is of key
importance. The project will get seriously affected If
