See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/235321177

Implementing statistical process control: An organizational

perspective

Article in International Journal of Quality & Reliability Management · June 2008

DOI: 10.1108/02656710810881872

CITATIONS READS
33 3,246

3 authors, including:

Mattias Hans Elg Jens J. Dahlgaard

Linköping University Linköping University
84 PUBLICATIONS 1,963 CITATIONS 119 PUBLICATIONS 6,656 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Mattias Hans Elg on 29 April 2016.

The user has requested enhancement of the downloaded file.

 The current issue and full text archive of this journal is available at
www.emeraldinsight.com/0265-671X.htm

Implementing
Implementing statistical process statistical
control: an organizational process control
perspective
545
Mattias Elg
Division of Quality Technology and Management, University of Linköping, Received 28 August 2006
Linköping, Sweden Revised 7 January 2008
Accepted 18 February 2008
Jesper Olsson
The Swedish Association of Local Authorities and Regions, Stockholm,
Sweden, and
Jens Jörn Dahlgaard
Division of Quality Technology and Management, University of Linköping,
Linköping, Sweden

Abstract
Purpose – The purpose of this paper is to contribute to the understanding of how statistical process
control (SPC) methodology can be implemented and used in organizational settings.
Design/methodology/approach – An action research model was used. Data were collected
through formal meeting protocols, interviews and participant observation.
Findings – Based on the results of an action research project, the paper emphasizes the need for: top
management support with respect to roles such as infrastructural assistance, mentor, critic, financer;
creating system validity through the involvement of people with experiential knowledge about the
“world” in which SPC should be applied; keeping a small, highly knowledgeable development team
with appropriate expertise together during the whole process from beginning to end; keeping the
various end-users in focus but separate and prioritising between their different needs; and working
with iterative design methodology.
Research limitations/implications – The paper provides the research field with a unique case of
implementing SPC using a computerized administrative data system.
Practical implications – Organizations are given guidelines to use when implementing SPC.
Originality/value – The paper contributes knowledge in an underdeveloped field of research. It may
provide a basis for further research and scholarly analysis.
Keywords Statistical process control, Performance measures, Knowledge management
Paper type Case study

1. Introduction
Statistical process control (SPC) has been found to be a valuable technology for
understanding process behaviour and for making real-time decisions by operators and
managers working in production (Deming, 1986; Juran, 1989; Deming, 1993; Bergman International Journal of Quality &
and Klefsjö, 2003). The systematic use of this technology makes it possible to identify Reliability Management
Vol. 25 No. 6, 2008
the various sources of variation and detect out-of-control situations. An effective pp. 545-560
implementation also includes mechanisms for removing unusual sources of variation q Emerald Group Publishing Limited
0265-671X
by corrective action as a part of the everyday practice of engineers, managers and DOI 10.1108/02656710810881872
IJQRM operators (Montgomery, 2001). Research on SPC has mainly been preoccupied with the
25,6 technical solutions and statistical choices (Mann and Kehoe, 1995; Does et al., 1997;
Rungtusanatham et al., 1999; Antony, 2000; Rungasamy et al., 2002). A database search
in Emerald with keywords SPC and implementation (in all text fields) shows 392 items.
By scanning abstracts and keywords, we identified 17 articles which actually dealt
with SPC implementation from both a technical and organizational point of view.
546 Roughly, three articles used a survey approach (Mann and Kehoe, 1995;
Rungtusanatham et al., 1999; Rungasamy et al., 2002;), six were conceptual (Xie et al.,
1999; Dewhurst et al., 1999; Hassan et al., 2000; Mason and Antony, 2000; Xie and Goh,
1999; Antony, 2000) and eight used a qualitative approach (Lin, 1991; Kumar and
Motwani, 1996; Hewson et al., 1996; Krumwiede and Sheu, 1996; Bunny and Dale, 1997;
Does et al., 1997; Brannstrom-Stenberg and Deleryd, 1999; Bamford and Greatbanks,
2005). The research is quite consistent in terms of the most important aspects to
consider when implementing SPC: management commitment, general and specific
training, identification of processes to work with, choice of parameters and control
chart techniques to be studied, and project team. Some authors propose generic
implementation plans (Krumwiede and Sheu, 1996; Kumar and Motwani, 1996) and
some claim that every organization has to develop its own unique way of
implementation (Dale and Lascelles, 1990; Mann and Kehoe, 1995). The use of IT in
SPC implementation is also stressed as an important aspect for further investigation
(Dewhurst et al., 1999; Does et al., 1997; Lin, 1991).
From an organizational point of view there are several questions that need further
attention. One area concerns the core development team responsible for design and
implementation, its composition and relation to stakeholders of the SPC system (among
them the top managers, operators, engineers and managers who are supposed to work
with SPC). How should the core development team be composed and what kind of
relations should they have with other stakeholders? A second problem area concerns
the priorities, procedures and activities that the core development team enacts as it
proceeds through different development phases. These questions are given further
attention herein. The purpose of the paper is to contribute to the understanding of how
statistical process control methodology can be implemented and used in organizational
settings.
The empirical support for the present study analysis is based on the practical
application of an SPC system at the production unit of a Swedish industry organization
(fictitious name “ALPHA”) which has developed and introduced an information
technology solution for SPC. The idea behind this project was to “develop an easy and
accessible database for operators based on the methodology of EWMA charts”.
EWMA is an exponentially weighted moving average. Each EWMA point in a control
chart includes information from all of the previous subgroups or observations. An
EWMA chart is often used to monitor in-control processes for detecting small shifts
away from the target (Montgomery, 2001). Furthermore, the SPC method:
. . . should be able to continuously give information on the results from the process and inform
the operator when the process is out of control. The method should be implemented in an
administrative data system. Operators should be given education and training in the method.
The article starts with a presentation of the project, which had the aim of designing
and introducing SPC. The next section presents the project in more detail. In particular
we examine the development of the SPC solution and how it has been realized in an Implementing
administrative data system. The subsequent section analyzes the question of how statistical
validity of system design has been accomplished throughout the development process.
Finally, the article gives recommendations and discusses considerations for how an process control
implementation may be carried out.

2. Research methodology 547

The present project has used an action research model (see Aagaard Nielsen and
Svensson, 2006; Fishman, 1999). In such models, the researcher takes active part in the
object of her study. Action research aims to contribute both to practical issues, e.g. how
to handle practical problems in relation to the management of change, and to the
creation of scientifically acceptable knowledge. Action research has its roots in social
science (Collier, 1945). The psychologist Kurt Lewin, considered by many to be the
father of action research, argued for a discipline whose main purpose was “to help the
practitioner” (Lewin, 1946). Action research, as practiced in Scandinavian countries, is
defined by Aagaard Nielsen and Svensson (2006):
. . . as a scientific method for making research. It underlines the connection between
understanding and change, between theory and practice, and an active co-operation between
researchers and the participants in the production of new knowledge (www.aktionsforskning.
net, cited in Aagaard Nielsen and Svensson, 2006, p. 14).
This definition has been used in the present research project.
The results from the present study are based on a two-year study in one company.
One of the researchers (M. Elg) took an active part in the development process as the
developer of the statistical solution and participated in various activities throughout
the development project (e.g. educating operators in SPC, participating in project
meetings). The researcher was thus an active part of the development team.
Data were collected through formal meeting protocols, interviews and participant
observation. The analysis of data occurred throughout the development project. The
following empirical material has been used by the researcher during and after the
project:
.
Production data in order to develop a SPC solution.
.
Event data from the progress of the implementation process (e.g. “today
operators in production line three have tested a version of the administrative
software for analyzing SPC data. The result was . . . ”).
.
Development team meeting protocols in order to produce time lines for the
implementation process.
.
Interview material for understanding the attitudes and motives of personnel
(both managers and operators) involved in the implementation process.
The article was written after the project’s closure. Descriptions of the implementation
process have been validated by staff from the development team.

3. Results
3.1 The context
The participatory action research project took place in an organization (“ALPHA”)
located in the south of Sweden. This organization is located in the process industry and
IJQRM produces products for the consumer market. They produce large volumes of a limited
25,6 range of products exported throughout the world. Their brand is considered to have
very high goodwill around the world.
The central problem to be solved by implementing SPC at ALPHA was to identify
out-of-control situations and processes in the production. In the production unit, there
are over 100 different types of defects that can occur, for example that the product is
548 cracked, that there are errors in the design, or that information on the product is not
correct. The code system for these different types of defects has been implemented and
used in the production unit for several years.
The idea, spelled out by management, was to move away from the strategy of
inspecting all products (a highly costly and non-motivating activity) to a sampling
strategy where a certain number of products are taken out from the process. By using
such a strategy, information and control over process behaviour can be maintained.
In the year 2000, management of ALPHA decided that quality control by inspection
of all products in the production process should be abandoned. Two years later,
statistics were introduced through the use of histograms for controlling the variation in
the process. The procedure for doing this was made through manual collection and
registration in a designed MS Excel spreadsheet. Samples from the production process
were taken every half hour and non-conformities were counted. All these quality
procedures were done manually. By the end of the year 2002, management decided to
build a computerized operator control system. The idea of SPC was introduced at that
time.

3.2 The development team and its activities

In January 2003 the first project meeting was held and a project definition was
discussed and presented. The group consisted of a project leader from the Quality
department, an SPC expert and an IT consultant. At later stages, a financial controller
and a person working with information technology infrastructure and installations
were also added to the group.
A few months after the start, the project group had collected initial data from the
process and chose from among three different types of control charts for the
monitoring and control of the production process. These control charts were proportion
of non-conformities (p-chart), geometric EWMA and normal transformed EWMA. The
latter control chart was selected. A major reason for choosing this method was that the
number of non-conforming products was extremely low. The method builds on the idea
to monitor the number of conforming samples prior to the detection of a
nonconforming one. This is called CCC, cumulative count of conforming. Due to the
highly skewness of such data, it is suggested by Montgomery (2001) and Xie et al.
(2002) to transform data to one close to normal distribution. After transformation of
data, the traditional EWMA method can be applied in such a case.
Approximately one month after starting the project, the team met with two different
suppliers of standardized software for SPC (the two most important retailers of SPC
software for online applications in Sweden). Neither of them could present a
satisfactory solution for the problems at hand. Hence, the project team decided to give
the task of building an ALPHA-designed software to a small consulting business. This
made it possible to develop an adapted software solution for the specific problems
encountered by ALPHA. The consultant working for this firm had been employed for Implementing
other similar assignments at ALPHA. statistical
In April 2003, one of the production lines started to use an MS Excel-based
prototype of the methodology. During May to October, programming and refinements process control
of the SPC method took place. In September, education and training in SPC
methodology started (with the first production line). At this time several validations of
the software were done with the help of production managers and quality managers. A 549
full-scale test at one production line started in October 2003. Feedback from operators
was encouraged and several errors and improvement suggestions were taken care of
by the project team. By the end of 2003 much of the programming was finalized. User
manuals and various reports were created. More and more production lines were
introduced to the computerized SPC. By February 2004 much of the production was
using the SPC for monitoring and control of the production unit. At this time the
project team was working with minor changes to the system: updates of statistical
parameters such as m and s, the administration of the system, computers and
keyboards.

3.3 The statistical solution

The statistical solution was based on the EWMA-normal transformation. This choice
was based on the idea presented by Xie et al. (2002). One of the final results of the
development project, the graphical user interface viewed and run by the operator at
ALPHA, is shown in Figure 1.

Figure 1.
The graphical user
interface as viewed by the
operator
IJQRM 3.4 End-user focus during all implementation steps
25,6 One of the more important factors for the implementation of the SPC concept was the
focus on the end-user. That is to say: the development team must have the end-users’
point of view in mind during all steps of the development process. The strategy of
involving end-users is not simply a plan for getting acceptance for the SPC
implementation – even though this aspect is important – but also to get input into the
550 development process. Operators can, for example, through their experience bring up
many concrete, valid suggestions for improving the solution. So, the involvement of
end-users works in two directions: partly as an input for the development team and
partly for the motivation and education of operators. There are at least five reasons
why this is important:
(1) creating acceptance for the solution that is under development;
(2) creating validity of the SPC solution as the operators have the ability to reflect
and comment upon early stage SPC solution;
(3) creating operator knowledge about SPC in advance as the early phase
involvement of operators requires that they at least have some idea of what it is
all about;
(4) identifying errors and limitations of the new solution because early phase
solutions are tested in real environments; and
(5) help with active problem solving.

In order to involve operators in the development process, several strategies were used
(see, for example, Kotter and Schlesinger, 1979). Education and training in SPC and the
administrative data system have been important activities. Two different, formal
educational settings were arranged. The first included a general presentation of the
statistical foundations of SPC with cases familiar to the operators and examples related
to the new SPC solution. The second occasion was carried out according to the idea of
“training just-in-time” (Bunny and Dale, 1997) as the operators were educated and
trained to use the new graphical user interface. This included both input data
registering and output data analysis and forms of corrective action.
From the development team’s point of view, other transactional relations with
operators were also important. As various versions of the SPC solution had been tested
in the production units, feedback of various kinds came from the operators. Four
versions of design were used:
(1) Paper-based data collection with subsequent data analysis in statistical
software by the researcher and the quality manager (mainly through MS Excel,
MINITAB).
(2) Data collection, computation, analysis in MS Excel. MINITAB supports
analysis.
(3) Data collection, computations and graphical presentation in test version of
administrative software. MS Excel and MINITAB supports analysis.
(4) Full-scale administrative software in production unit.

The development team started the process of developing an SPC solution by testing
various SPC solutions with sampled data from the production process. This first phase
of collection of data was made through a paper-based version in which operators filled Implementing
in the total number of defects from samples of the production process. The purpose statistical
was to use production data for finding an appropriate statistical model (e.g. statistical
distribution, estimations of statistical parameters, choice of control charts) (Bergman process control
and Klefsjö, 2003; Montgomery, 2001; Xie and Goh, 1999).
Each possible SPC method identified was compared with the others and the final
selection was based on multiple criteria referring to statistical effectiveness, ease of 551
understanding and interpretation of the control chart, and, finally, ease of
implementation. The project leader and the statistical expert conducted this
evaluation together. See Figure 2.
In the second phase of data collection the development team constructed an MS
Excel spreadsheet for the operators to use. The purpose of this data collection phase
was to find out and test the appropriate input variables for the computerized data
system. The MS Excel spreadsheet was viewed as a rough design of the final solution.
In this test, data were collected for estimating parameter values for the statistical
solution. In the third phase, a test version of the final administrative software was
used. The reason for this test was to “try out” the method in a real environment.
Another reason was that more input was needed for the initial statistical parameters
used. The fourth phase implied a full-scale implementation of the SPC solution in
practice. At that time, most of the production unit used SPC in order to monitor and
control their processes.

3.5 Strategies for building the SPC solution into an administrative data system
In building the administrative data system, various methods and approaches were
used and together they constitute a strategy for building an administrative data
system. The following section will identify and comment on some of those strategies,
with the focus on:

Figure 2.
The matrix for evaluation
and selection of SPC
solution
IJQRM .
a third-party vs a custom-built system;
25,6 .
a user-centred and iterative development process; and
.
a mature requirements specification.

3.5.1 A third-party vs a custom-built system. Early on in the project it was decided that a
custom-built solution was needed to comply with the requirements. There are systems
552 that can be bought off the shelf which are compelling since they already are there and
there are risks in building a system of one’s own from the ground up.
The motivation for this choice was that ALPHA wanted a system that met its exact
requirements, not more or less. It also became clear that the third-party products would
need a considerable amount of customization.
3.5.2 A user-centred and iterative development process. For the project to be
successful it is important to use a user-centred development process. This is a way of
thinking that takes the position that the user is the expert. The user may not be an
expert on SPC, statistics or system development, but she has invaluable experience and
knowledge in her working field. The aspects of user-centred design that are mentioned
in this article are the importance of knowing the users and the working environment,
users taking active part of the development team, and iterative development using
prototypes.
Knowing who the users are and the environment where the system is to be used is
important and has consequences for the design of the user interface. Consequently, the
system needs to be “user-friendly”. The particular users will use this system
continuously as a part of their job, and the occurrence of beginner users is rare. So
“user-friendliness” in this application does not mean “simple”, but rather a powerful
system that is quick and convenient to use after an appropriate introduction. A great
help to the project was the inherent striving for perfection and quality that exists
within ALPHA. The operators want to do tests and enter the data, which is a means to
their goal of a perfect product.
The end-users also participated as early as possible in the development process of
the system. The first prototype of the actual system was created in conjunction with
the end-users using a whiteboard; the second was created using pencil and paper. This
is in contrast to development when users’ first contact with the system is an almost
complete, relatively good-looking computer program which inhibits the creativity of
the end-users. They do not know what can be changed and even if they would want to
change something, it might be too late, considering the time and effort required. The
users worked together with the developer which resulted in a system that was both
simple to use and possible to build.
Iterative development means that the system is being built in cycles, each cycle
resulting in a refined prototype that is evaluated and improved in the next cycle. An
example of a feature that was introduced at the users’ request is depicted in Figure 3.
The users had found out that it is hard to type on the computer keyboard due to a
rubber coating that is needed in the factory. They instead suggested the introduction of
“value-buttons” that when clicked meant that the value on the button was entered in
the next free text box.
The prototypes, ranging from spreadsheet documents on paper to computer
applications, and the end-user participation increased the acceptance of the system
even before it was introduced, improved the quality of the product, and the collected
 Implementing
statistical
process control

553

Figure 3.
At the users’ request,
“value buttons” were
introduced to reduce the
need for pressing buttons
on the keyboard

data could be used when finding out the initial values for the parameters used in the
statistical analysis.
3.5.3 Requirements specification. A mature requirements specification is critical to
the success of the system for several reasons. All involved parties – the project owner
and the developer – need to know exactly what is to be built, or it will not be possible
to determine whether the system really does what it is supposed to do, let alone try to
determine whether development is finished or not. Not having a good requirements
specification can result in a project that never ends, since the target is moving
constantly. It is also important that the statistical concept work is done when starting
to implement, since in this step of the project, a lot of potentially expensive time is
spent realizing all concepts, and changing the chosen statistical methods can lead to
radical and expensive changes to the system.
To clearly define the system in a requirements specification, an adapted version of
the Rational Unified Process (RUP, a software engineering process) “Use Cases” were
used. A Use Case is a document that contains a detailed textual description of a
function in the system that an “actor” performs. The actor, e.g. “an operator” or “the
system”, starts the function by doing something, and the Use Case describes what
happens, although not how or why.
As mentioned above, the first sessions with the end-users resulted in an extremely
simple, pencil-on-paper prototype. Although this prototype is simple, it is sufficient to
form the base when constructing the Use Cases, and the completed Use Cases together
form an essential part of the requirements specification. Other parts of it include the
non-functional requirements, i.e. requirements that do not really have anything to do
with specific functions in the system. Rather, they describe constraints, e.g. constraints
on system response time, etc. All parties should agree on the validity of the
requirements specification before work can begin.
IJQRM 3.5.4 Top management support. Top management support is one of the most
25,6 frequently mentioned aspects for a successful SPC implementation. In what sense is
top management support important? How can they support the SPC implementation
team? There are at least four aspects that we have seen from this project that are
meaningful to discuss: top management support with respect to roles such as
infrastructural assistance, mentor, critic, and financer. The role of giving
554 infrastructural assistance is that of providing access to various arenas and
technology. For instance, it was important for the SPC implementation team to have
access to all parts of the computer system and the intranet. Top management also
opens up the way for the SPC team to work with other management teams in
production. The role as mentor means that one or a few members of the top
management team work as wise and trusted guides and advisors. This support is
valuable as the team encounters various problems throughout the implementation
process. The role as a critic means that members of the management team express
reasoned judgments about the progress. Finally, top management also provides
financial support for the development project.
It is important to note that we emphasize roles and not specific persons. The four
different roles may be distributed in time and among several different persons. The
role of mentor might not be held by the same person who has the role of critic.
Furthermore, the mentor role might be shifted between different persons at different
stages of the development project. In all, we think that these four roles are essential to
ensure continuity and realization of the ideas that are being developed in a SPC
implementation effort.
3.5.5 Ensuring validity of design throughout the development process: how do we do
that?. The implementation of the system and its SPC solution at ALPHA is presently in
its final stages of realization. Although there is more to do, the formalized development
project has completed its work. Other considerations related to the maintenance of the
system will now come into focus. Despite the fact that the project has only recently
been finalized, one project evaluation has assessed the effort. The purpose of this study
was to examine the pros and cons of the SPC application within the production unit.
The survey and interview-based study concluded that:
.
There is good potential that the data system will work very well and become a
useful system. The implemented system has good quality and the
implementation has been conducted in an appropriate manner.
.
Operators’ understanding of the functioning of the system varies between those
that have been engaged and operators which have not been involved in
implementation.
.
The physical placement of computers creates problems for the operators.
.
Administrative work for operators is reduced.
. The operators’ work has not changed too much.
.
Users of the system think that the design of the system is of good quality and
that it has led to an increased motivation for work (Bengtsson et al., 2004, p. 2).

The SPC solution provided by the development team seems to have fulfilled its initial
aims. The conclusions presented above show that there are some further steps to be
taken but much of the work is done. This is in line with Bunny and Dale’s (1997)
empirical observation that techniques are learned as they are practiced and Implementing
consequently errors should be corrected along the way. statistical
What, then, are the important aspects to consider when implementing such a system
within an organization? In order to give an answer to that question we must first process control
describe the delimitations and the domain (Alvesson and Sköldberg, 2000) in which the
results may be valid. We concur with Dale and Lascelles (1990) who say that “because
of the variety of starting points and motivations for quality improvement it is not 555
possible to identify an implementation plan detailing the order in which techniques
should be used”. A first condition of the present case is that the design and
implementation of the SPC system concerns a statistical application for one production
unit with a number of production lines located in the same geographical area. The
statistical application is designed into user specific software built by a software
consultant. Much of the organizational solution: “what do we need and why do we need
it” was at the initial stage of the studied project already set up by management. Thus,
there were no major problems with definitions and terms of what defines a
non-conforming item and there was little consideration about when and by whom
samples should be taken from the production unit. Much of this work was already
defined when the project started. From this perspective, the development process
started several years earlier than the formal start of the development project which is
the focus of this article.
There are several aspects to consider when implementing a performance
measurement system such as the case of ALPHA. In the previous sections we
presented strategies and ways to proceed with the innovations that were available to
the project team. The following considerations have been important in the development
process.
.
The organizational solution – what do we need and why do we need it?
.
The statistical solution – how do we develop a statistical solution which
provides us with effective decision support?
. The graphical user interface – how should we design the user interface so that
purposeful, effective problem-solving can take place?
.
The application in the administrative data system solution – how do we create a
robust data system solution for our purpose?
.
The physical implementation of the system into the production line – how do we
build the solution into the operator’s everyday work?

We propose that the success of any implementation of a SPC system – where

production units systematically, in real time, are being monitored and controlled by the
operators – rests on these questions. In the subsequent section, we further analyse
these different propositions.
The composition of the development team is essential. The completion of the
various tasks in the development project requires that these tasks be partitioned to
several different persons (task performers). Not only is it important to include task
performers with proper knowledge but it is also important to keep them in the project
team from the beginning until the solution has been realized. Thus, “finding the
appropriate core project team and keeping them together” should be done carefully.
IJQRM Van de Ven and Poole (1990, p. 315) express a similar thought as they discuss the
25,6 composition of a research team:
. . . systematic and creative data analysis often involves a sequential set of tasks best
performed by one or two individuals who can increase their probabilities of learning and
generating significant insights by performing all these tasks from beginning to end.

556 Many people can come and go from a project but it is important that the core project
team is stable. Why is that so? The central point is that each person has different
important roles during various phases of the development project. Roles such as
“solution finder”, “error detector”, “educator” and “project legitimizer” have been
identified.
For example, the role of the researcher was in the beginning of the project to develop
a suitable SPC solution. Soon after that, the role of the statistician changed from being
the “solution finder” to an “error detector”. The ability to detect errors in subsequent
steps is very much dependent upon the availability of and access for the “solution
finder”. For example, during the phases of building the SPC solution into the software,
the “solution finder” was the IT consultant and the statistician was used in order to
find errors made in the graphical user interface and to detect programming errors
when data were being obtained from the database and computed. Several such errors
were detected.
Another example: although the project leader primarily had knowledge about
project management, the “operator world” and the settings in which managers use
information, she was also updated about both statistics and databases. She had among
other things worked with Six Sigma projects in the organization and therefore built up
knowledge about statistics, and she had also earlier participated in several other
database projects. This implied that she could validate the statistician’s and the
programmer’s solutions from the perspective of the company (the operator in
particular).
While single project members primarily deal with certain types of knowledge, the
whole team and its success is dependent on the team organization. As a great many of
the team activities are dependent upon a wide range of issues, the team relies on
various sources of knowledge in order to make fair judgments. Hutchins (1995) has
pointed out and shown how the robustness of information flow is dependent on the
team organization: “the way a task is partitioned across a set of task performers has
consequences for both the efficiency of task performance and the efficiency of
knowledge acquisition” (Hutchins, 1995, p. 267). The “main” actor during a particular
development phase needs other team members to make his solution valid in relation to
the system in which the solution is applied, i.e. external consistency. For example, the
IT consultant’s design of the user interface could not have been accomplished without
support from the statistician and the project leader. Many different corrections of
statistical design and operator-friendly user design were done in this phase by the
project team members. This is an interpretation of Hutchins’ point. In the ALPHA case,
the efficiency of task performance and the efficiency of knowledge acquisition are
dependent upon the presence of other team members in that phase. Thus, it would be
devastating if a core project team person only participated in one of the developmental
phases.
 People with experiential knowledge, in this case the project leader managers, are Implementing
present which may lead to valid decisions about the implementation. She has direct statistical
face-to-face experience with both managers and operators working in the production
unit. She also has direct experience of working in the production unit so she has direct process control
knowledge from the world in which SPC is about to be applied. Thus, the group relies
not only on “indirect” knowledge but also on the direct knowledge that the project
leader possesses about the organization. In some cases the project leader lacked such 557
valid knowledge so the team invited other members of the organization to discuss
solutions. This is the point of “Understanding the needs of the end-user”. As presented
earlier in the article, the project team used several different strategies to involve the
end-user. The purposes of this involvement strategy varied according to the needs of
the team. It should also be noted that there have been different end-users: both
operators working directly with feedback from the process, managers who are more
concerned with daily or weekly updates of the production results, and quality
managers working with long-term development. These different end-users have
different needs that sometimes are in conflict with each other. Therefore, in a
development project, it is important to distinguish between the various interested
stakeholders and to prioritise between them. In the present work, the development
project had the operator as the main stakeholder.
Hutchins (1993; 1995) discusses this phenomenon in terms of bandwidth of
information. At one end we have discussions, interpretations and analyses of
organizational activity conducted by people with no knowledge whatsoever of the
organizational context other than the statistics and administrative data system. This is
a case of low bandwidth of information. At the other side we have evaluations of
organizational activity by people who are well acquainted with the local circumstances
under which the solution should be applied. Of course, there is not a clear-cut
distinction between people with knowledge about things being evaluated and those
who do not. The strategy of involving people with experiential knowledge is important
because it gives validity to the ideas in the project team.
To sum up, the importance of knowledge from each area varies in different phases
of the innovation process but have to be considered throughout the whole journey.

4. Discussion and conclusion

The present article presents and discusses the results of the implementation of a
performance measurement system for monitoring and controlling non-conformities in
a production unit. A statistical process control solution has been developed and
realized in an administrative data system at the company. In order to succeed with
such an effort, the development project team used various strategies throughout the
development project. Questions asked were: What can be learned from this case when
implementing such a performance measurement system – including both hard and
soft issues – in other organizations? We conclude that the success of such an
implementation of performance measurement systems depends upon:
.
Clarity of purpose expressed by top management.
.
System validity through the involvement of people with experiential knowledge
about the “world” in which the system should be applied.
IJQRM .
Keeping a small, highly knowledgeable development team with appropriate
25,6 expertise together during the whole process from beginning to end. Such
expertise involves: statistics, information technology (database knowledge,
programming and knowledge about information technology systems within the
company, interface design), project management, knowledge about the “operator
world” and the settings in which managers use information.
558 .
Keeping the various end-users in focus but separate and prioritizing between
their different needs.
.
Using an iterative design methodology with various versions of the system from
paper-based version via MS Excel to a full-scale administrative data system. Real
data and the end-user should play an important role in all steps.

All these questions that a developmental team must face are discussed in the article.
We focus much of the attention upon the various types of knowledge that are required
in order to develop the initial idea and to realize it into the physical world of the
operator. For example, we see that important knowledge areas are: statistics,
information technology (database knowledge, programming and knowledge about
information technology systems within the company, interface design), project
management, knowledge about the “operator world” and the settings in which
managers use information. The importance of knowledge from each area varies in
different phases of the innovation process but has to be considered throughout the
whole journey of implementation.

References
Aagaard Nielsen, K.A. and Svensson, L. (Eds) (2006), Action and Interactive Research – Beyond
Practice and Research, Shaker Publishing, Maastricht and Aachen.
Alvesson, M. and Sköldberg, K. (2000), Reflexive Methodology: New Vistas for Qualitative
Research, Sage, London.
Antony, J. (2000), “Ten key ingredients for making SPC successful in organisations”, Measuring
Business Excellence, Vol. 4 No. 4, pp. 7-10.
Bamford, D. and Greatbanks, R.W. (2005), “The use of quality management tools and techniques:
a study of application in everyday situations”, International Journal of Quality & Reliability
Management, Vol. 22 No. 4, pp. 376-92.
Bengtsson, B., Karlsson, J., Eriksson, J. and Gustavsson, T. (2004), Att förändra – En
undersökning kring implementering av SPS i en produktionsverksamhet, Division of
Quality Technology and Management, Linköpings universitet, Linköping.
Bergman, B. and Klefsjö, B. (2003), Quality – From Customer Needs to Customer Satisfaction,
Studentlitteratur, Lund.
Brannstrom-Stenberg, A. and Deleryd, M. (1999), “Implementation of statistical process control
and process capability studies: requirements or free will?”, Total Quality Management,
Vol. 10 Nos 4-5, pp. 439-46.
Bunny, H.S. and Dale, B. (1997), “The implementation of quality management tools and
techniques: a study”, The TQM Magazine, Vol. 9 No. 3, pp. 183-9.
Collier, J. (1945), “United States Indian administration as a laboratory of ethnic relations”, Social
Research, Vol. 12, pp. 275-6.
Dale, B. and Lascelles, D.M. (1990), “The use of quality management techniques”, Quality Forum Implementing
Journal, Vol. 16 No. 14, pp. 188-92.
statistical
Deming, W.E. (1986), Out of the Crisis, MIT Press, Cambridge, MA.
process control
Deming, W.E. (1993), The New Economics – For Industry, Government, Education, MIT Press,
Cambridge, MA.
Dewhurst, F., Lorente, A.R.M. and Dale, B. (1999), “Total quality management and information
technologies: an exploration of the issues”, International Journal of Quality & Reliability
559
Management, Vol. 16 No. 4, pp. 392-405.
Does, R.J.M.M., Schippers, W.A.J. and Trip, A. (1997), “A framework for implementation of
statistical process control”, International Journal of Quality Science, Vol. 2 No. 3, pp. 181-98.
Fishman, D.B. (1999), The Case for Pragmatic Psychology, New York University Press, New York,
NY.
Hassan, A., Baksh, M.S.N. and Shaharoun, A.M. (2000), “Issues in quality engineering research”,
International Journal of Quality & Reliability Management, Vol. 17 No. 8, pp. 858-75.
Hewson, C., O’Sullivan, P. and Stenning, K. (1996), “Training needs associated with statistical
process control”, Training for Quality, Vol. 4 No. 4, pp. 32-6.
Hutchins, E. (1993), “Learning to navigate”, in Chaiklin, S. and Lave, J. (Eds), Understanding
Practice – Perspectives on Activity and Context, Cambridge University Press, Cambridge.
Hutchins, E. (1995), Cognition in the Wild, MIT Press, Cambridge, MA.
Juran, J.M. (1989), Juran on Leadership for Quality, McGraw-Hill, New York, NY.
Kotter, J.P. and Schlesinger, L.A. (1979), “Choosing strategies for change”, Harvard Business
Review, Vol. 57 No. 2, pp. 106-14.
Krumwiede, D. and Sheu, C. (1996), “Implementing SPC in small organizations: a TQM
approach”, Integrated Manufacturing Systems, Vol. 7 No. 1, pp. 45-51.
Kumar, A. and Motwani, J. (1996), “Doing it right the second time”, Industrial Management &
Data Systems, Vol. 96 No. 6, pp. 14-19.
Lewin, K. (1946), “Action research and minority problems”, Journal of Social Issues, Vol. 2 No. 4,
pp. 34-46.
Lin, B.-S. (1991), “Building quality control systems for hospital food-service operations”,
International Journal of Quality & Reliability Management, Vol. 8 No. 2, pp. 35-44.
Mann, R. and Kehoe, D. (1995), “Factors affecting the implementation and success of TQM”,
International Journal of Quality & Reliability Management, Vol. 12 No. 1, pp. 11-23.
Mason, B. and Antony, J. (2000), “Statistical process control: an essential ingredient for
improving service and manufacturing quality”, Managing Service Quality, Vol. 10 No. 4,
pp. 233-8.
Montgomery, D. (2001), Introduction to Statistical Process Control, John Wiley & Sons, New York,
NY.
Rungasamy, S., Antony, J. and Ghosh, S. (2002), “Critical success factors for SPC implementation
in UK small and medium enterprises: some key findings from a survey”, The TQM
Magazine, Vol. 14 No. 4, pp. 217-24.
Rungtusanatham, M., Anderson, J.C. and Dooley, K.J. (1999), “Towards measuring the ‘SPC
implementation/practice’ construct”, International Journal of Quality & Reliability
Management, Vol. 16 No. 4, pp. 301-29.
IJQRM Van de Ven, A. and Poole, M.S. (1990), “Methods for studying innovation development in the
Minnesota Innovation Research Program”, Organization Science, Vol. 1 No. 2, pp. 313-35.
25,6
Xie, M. and Goh, T.N. (1999), “Statistical techniques for quality”, The TQM Magazine, Vol. 11
No. 4, pp. 238-41.
Xie, M., Goh, T.N. and Cai, D.Q. (1999), “An integrated SPC approach for manufacturing
processes”, Integrated Manufacturing Systems, Vol. 12 No. 2, pp. 134-8.
560 Xie, M., Goh, T.N. and Kuralmani, V. (2002), Statistical Models and Control Charts for High
Quality Processes, Kluwer Academic Publishers, Dordrecht.

Corresponding author
Mattias Elg can be contacted at: [email protected]

To purchase reprints of this article please e-mail: [email protected]

Or visit our web site for further details: www.emeraldinsight.com/reprints

View publication stats