online
with online menus for
confirmatio
front end
all coded
n of
fields
changes
Custom Import Effect
Impact Effect Impact Effect Impact Total er/Req ance
on Req.
on Req.
on Req. Impact
uireme Ranking
nt
VP Marketing
Input
1
10
10
7
7
1
1
18
requires
no more
than one
minute
No
4
1
4
10
40
1
4
48
system
codes
required
Updates 7
10
70
1
7
1
7
84
applied
the day
form is
complet
ed
Updates 10
10
100
7
70
1
10
180
are
correct
the first
time
Confirm 7
1
7
1
7
10
70
84
ation of
updates
within
eight
hours of
the
system
update
Degree
191
131
92
414
of
satisfacti
on from
impleme
nting
improve
ment
Assistant to VP Marketing
Input
10
10
100
7
70
1
10
180
requires
no more
than one
minute
No
7
1
7
10
70
1
7
84
system
codes
required
Updates 4
10
40
1
4
1
4
48
applied
the day
form is
complet
ed
Updates 7
10
70
7
49
1
7
126
are
correct
the first
time
Confirm 4
1
4
1
4
10
40
48
ation of
updates
within
eight
hours of
the
system
update
Degree
221
197
68
486
of
satisfacti
on from
impleme
nting
improve
ment
Average Ranking
Input
5.5
10
55
7
38.5
1
5.5
99
requires
no more
than one
minute
No
5.5
10
5.5
10
55
1
5.5
66
system
codes
required
Updates 5.5
10
55
1
5.5
1
5.5
66
applied
the day
form is
complet
ed
Updates 8.5
10
85
7
59.5
1
8.5
153
are
correct
the first
time
Confirm 5.5
1
5.5
1
5.5
10
55
66
ation of
updates
within
eight
hours of
the
system
update
Degree
206
164
80
450
of
satisfacti
on from
impleme
nting
improve
ment
Although the ultimate goal of the process improvement ranking is to consider both the customers’
ranking of each requirement’
s importance from Exhibit 3 and the
degree to which each revised process step will satisfy that requirement (its effect) to determine the total impact that implementing a specific step will have on customer satisfaction, the team realized that to be as objective as possible it should not see customer importance rankings when it developed its own effect ratings. It was only when those were completed that the team retrieved the customer rankings and entered them into the chart.
The spreadsheet multiplies the importance ranking by the effect weighting to calculate which steps will have the greatest impact on each individual re quirement.
The column totals show the overall effect that each process step will have on customer requirements and provide an objective method of prioritizing the steps.
Although the XYZ team had funding to implement all three recommendations, if it had been necessary to reduce functionality, this ranking would have shown them the impact on customer requirements of eliminating individual steps.
A separate ranking was prepared for each customer and the results were compared.
As would be expected, because the customers had assigned different importance rankings to each requirement, the results of the improvement ranking varied. To determine an overall ranking, the team averaged the results of all the customer rankings. This average was used to determine the priority of process improvements.
Once the team had developed its proposed solution, validated it with customers, and received the champion’
s approval to proceed, it was ready to begin implementing the solution. This step did not vary significantly from normal IT system development.
THE FINAL PHASE: CONTROL
When the new system was implemented, although the majority of its work was completed, the team knew that the final phase — control — was the one that would ensure that its work achieved the desired benefits. As part of the control phase, the team implemented a formal customer survey process to capture customer
satisfaction metrics. It produced a monthly scorecard showing the number of transactions processed using the new system, the rework rate, and the c ustomer satisfaction statistics. When it was clear that the project goals were being met, the team renamed the final phase of DMAIC “celebrate.”
CONCLUSION
Even companies that do not plan to use all the concepts of Six Sigma can benefit from the structure and methodology that many Six Sigma tools bring to the systems analysis and development process. A high degree of focus on customers, combined with careful measurement of requirements, and the effects that proposed changes will have on those requirements can reduce rework and improve customer satisfaction.
Chapter 16: Solving the Software Quality
Management Problem
James L. Mater
OVERVIEW
In its capacity as an independent software testing lab, QualityLogic, Inc. has worked with the information systems groups of both small and large companies, and with software and systems companies. This work provides a unique opportunity to observe the struggles that organizations go through in attempting to solve their software product quality and quality management problems. This article presents resulting observations and thinking about the basic quality management problem, as well as a new solution for the industry.
Profit and loss (P&L) managers,[1] referred to here as business managers, do not clearly understand or value software quality management. Software companies and projects fail to deliver quality products because they do not treat quality management as a strategic, critical aspect of the product development process that is equal to requirements, design, and code development.
The basic problem is that software quality management is not properly “owned”
within organizations. Instead, because it has historically been relegated to a software quality assurance function, it is considered technical, thus, few business managers would ever consider directly “owning” it.
In traditional industrial businesses, product quality management, quality assurance, and quality control are treated as major corporate functions, reporting to the business manager. However, few software organizations have yet adopted this approach. Indeed, the software business is such a recent “discipline” that the issue of product quality management[2] remains a mystery, especially to business managers without software training or experience.
The software quality issue — which ensures the quality of software products delivered to customers — is not a technical one. It is achieved through a combination of good customer understanding (developed into requirements) and good product development processes.
There are many excellent software development processes and techniques that are both proven and available. The software industry knows how to build high-quality, reliable products that meet the feature, cost, and schedule needs of customers; and that are easily maintained and upgraded. It is a myth that the industry needs better processes or tools to solve the quality problem, whic h skirts the real issue of business manager responsibility.
Unfortunately, the industry typically does not have that combination of discipline and organizational structure required for consistently delivering successful products; that is, a well-defined, well-executed quality management function. Responsibility for this must start at the business management level. The quality problem will remain unsolved until these managers think long and hard about the quality requirements for their products, until they have clearly communicated their conclusions, until they
actively monitor product quality, and until they are willing to act on that information to enforce their policies.
[1 ]The term P&L manager refers to the executive ultimately responsible for both the revenue and expenses for the product organization. In larger companies, this is likely to be a division general manager or president. In smaller companies, it is likely to be the CEO or president. In this article “business manager” will be substituted for “P&L
manager” in most cases, as the former term is more commonly used.
[2 ]Product quality management consists of the quality management function (ensuring that good quality policies are in place and enforced), the quality assurance function (developing and implementing practices and processes that ensure that quality products are produced), and the quality control function (actual testing of products to ensure conformance to customer requirements).
SOFTWARE QUALITY POLICY
Business managers have two critical responsibilities relative to software quality. First, they must set and communicate clear policy, empowering their people to carry out that polic y. Second, they must ensure that these policies are implemented. This entails monitoring quality on an ongoing basis and taking action as needed to keep the organization on track.
Business managers must give serious thought to software quality policy, answering the following questions:
§ Is the organization’
s policy to be first to market with the right features at the right price — and fix reliability issues later?
§ Is it to have the most reliable product available in its class?
§ Is it to aim at the low end of the market, which will accept poorer quality at a lower price?
§ Are there critical safety or customer issues that demand perfection, in terms of 100 percent reliability? (This is the case, for example, for medical instruments, defense systems, and avionics components.)
§ Is the company committed to a zero-defect policy?
The task of determining policy cannot be delegated. Only the business manager can set this policy, because all others in the organization will let the policy be influenced by their (individual) quality goals and the design/implementation of the software.