PROJECT QUALITY case studies in project program and organizational project management
162 CASE STUDIES
CHAPTER SUMMARY
Name of Case Area Supported
by Case
Case Type Author of Case
Robots Fail Too Quality Control
Techniques Issue - based Case
Ferra Weyhuni The Peaceful
Black Belt Quality Management
Approach — Six Sigma Issue - based Case
Marie Anne Lamb Workshop: Project
Quality Program Quality Management
Critical Incident Dragan Z. Milosevic,
Peerasit Patanakul, and Sabin
Srivannaboon
163
Robots Fail Too
Ferra Weyhuni
Within the recent month, there have been two sudden robot failures on two differ- ent tools during a build cycle. Lisa, the manufacturing engineer, has notifi ed Nick,
supplier quality engineer, about the failures, assuming that the two robots have some bad parts. She has requested that the two robots be sent back to the supplier
for rework, even though no root cause has been identifi ed. But, it seems that such a move has caused some to question where the blame should be placed. The focus
of this case is related to project quality management.
OUR BUSINESS
The IEM Company is a high -
tech company producing customized Ion and Electron Microscopes. The applications of their products can be used in a variety
of fi elds, from academia to high - tech industries. Their customers are given the options of customizing the product to meet specifi c process needs. The company ’ s
fi nancial profi le shows that their sales revenue last year exceeds 400 million. The company is currently upgrading their tools for the improvement in the imaging
and wafer transfer system. This is required to help expand the market size and to meet customers ’ satisfaction. This upgrading project was executed and is now in
its operational stage.
WE HAVE A PROBLEM AND IT IS NOT OUR FAULT Nick: How do you know it was the supplier ’ s fault? Is there a chance that we
damaged them during handling or installation? Lisa: According to the Reject report, the technician said that the two robots
were working fi ne for two weeks after installation. But then there were a few error lines such that the wafer transfer was stopped.
Nick: We don ’ t really know if it ’ s the supplier ’ s fault or not. If it is their fault, those robots wouldn ’ t have worked for two weeks, would they?
Lisa:
True. However, anything is possible. I think we should send these machines back for them to check it out.
164 CASE STUDIES
Nick: We can ’ t just send them back without a well - documented “ potential causes ” report.
Lisa: We don ’ t have time to do any tests or troubleshooting. They have the experts in their company who can test the robots to fi nd out what ’ s
wrong with the machines. I suggest we send them back and save ourselves some time.
Nick agreed with Lisa ’ s suggestion. The two robots were sent back to the sup- plier for investigation. One week later, similar problems occurred on several other
machines. The problem became so big that the issue was elevated to Donnie, a manufacturing engineering manager. Donnie asked Lisa to form a team to identify
the root cause of the problem. Lisa agreed to put together the team to brainstorm the root cause and the next course of action. She promised to follow the follow-
ing steps: goal defi nition, root cause analysis, countermeasures identifi cation, and standardization.
Lisa called a meeting with Nick and the other two manufacturing techni- cians, Joseph and Ryan. The team was working to get a list of possible causes for
the problem. As a normal procedure in the team ’ s analysis, the first thing to do was to create a fishbone diagram.
Joseph: As a starting point, can we capture what actually happened before the error message showed up on the screen?
Ryan: I don ’ t really know what happened. I was just starting to teach the robot, following our procedure, but then the error message showed up.
Joseph: That doesn ’ t make any sense. If nothing changed on the system itself, we shouldn ’ t have gotten the error. There ’ s got to be something changed on
the system. Lisa: Let ’ s create a fi shbone diagram for potential root causes of this
problem.
The team brainstormed using the affi nity diagram method. The purpose of this exercise was to ensure everyone ’ s input was captured during the process. They
determined the amount of time to be spent on brainstorming, and then went through each idea that each member came up with. When going through each
idea, they also decided whether those ideas were candidates for root causes. If any of the ideas didn ’ t make sense, they put them aside and noted them as “ possible
but not likely ” causes. Some of the ideas are shown in Table 8.1 .
Once the ideas of potential root causes were laid out, they started their fishbone diagram by grouping the potential causes into larger categories such as
Software, Mechanical, etc. The fishbone diagram would be used as a tool to com- municate with upper management as well as field personnel showing all possible
items that needed to be checked if and when the errors occurred again. Figure 8.1 is an example of a fishbone diagram.
Project Quality Management 165
Table 8.1 Results from Brainstorming Session Potential Causes
Possibility To Be Tested YN
Robot ’ s Firmware High
Y Robot ’ s Controller
High Y
Communication to Robot ’ s Controller
Medium Y
System ’ s PC Low
Y Overall System ’ s
Communication Low
Y System ’ s Software
Low N if overall system ’ s communication
passes the test Robot ’ s Manual Controller
Medium Y
Robot ’ s Cables Low
Y Motion Controller
Low Y
Motion Cables Low
N if motion controller passes the test
Lisa: Here ’ s the fi shbone diagram you requested. We came up with a few things that need to be checked using our tools on the manufacturing fl oor.
Donnie: How much time do you need? Do you have a test plan for each item? Lisa: I have not created the test plan yet but it should be straightforward.
Donnie: I think you should create a test plan to show us all what you ’ re going to do and what the results would be. The customer does not know that we have
this issue on the manufacturing fl oor and they don ’ t know how severe it is. We should get to the root cause before it gets out of hand.
Lisa: I understand. However, I don ’ t have the bandwidth to do all of this correctly.
Donnie: This is of the highest priority now. Lisa: Okay. I will work on it.
Robot Failure Robot Controller
Motion Controller
System PC System Communication
Setup Software Bugs from Upgrade
Software Version Setup
Software Version Unknown Change from Suppliers
Software Version Setup during Build
Cables Connection Cables Revision from Supplier
Figure 8.1 Draft of the Fishbone Diagram for the Failures
166 CASE STUDIES
Date:
Results Activities
Follow “Check Robots Firmware” work instruction
1 Check revision number for the controller
2 Match the controller version number with the
Bills of Materials System used for testing:
Technician name:
Potential Cause
Robot’s firmware
Robot’s controller
Communication to Robot’s controller
System’s PC Overall system’s
communication System’s software
Robot’s manual controller Robot’s cables
Motion controller Motion cables
Figure 8.2 Quality Testing for the Robot to Be Used by Technicians
Lisa created a spreadsheet that could be used by technicians to test the tool for all possible causes see Figure 8.2 . This spreadsheet shows all activities to be per-
formed to ensure there are no assumptions made by technicians. The results are recorded and anything worth noting during the test must be written down.
Discussion items
1. List the process that Lisa used to create the quality testing of the robot. 2. What can be done to improve the process that she ’ s using?
167
The Peaceful Black Belt
Marie Ann Lamb
For the fi rst time Milla Gold had to admit, at least to herself, that this might be beyond her capabilities; but within the fi eld of program effi ciency expertise, she
felt she had little choice, unless she wanted to switch career paths. She felt lost in all the equations and multiple terms with the same statistical meaning. Milla
could no longer rely on her tried, tested, and proven leadership and program man- agement skills for her success. To her it seemed only years before that she was
conquering the Pareto chart analysis with some confi dence; now, if she was to become a six sigma black belt she also had to prove her other statistical skills.
A THREE - YEAR BUMPY ROAD TO TECHNICAL PROWESS
Milla works for a Fortune 500 consumer goods company with more than 50,000 employees. She was chosen from thousands of potential candidates to receive the
expensive training because of her infl uencing abilities, leadership, and program management results within the company.
There were several issues, out of her control, that delayed Milla from gaining her six sigma black belt certification for another two and a half years. She had
gone into the training thinking one was certified just by taking the training, as did 85 percent of her 30 fellow trainees representing seven different companies.
In reality, this was just an initial training. Additional requirements for certification were: two six sigma black belt projects with at least 500,000 net savings each,
proven six sigma leadership, and proven advanced statistical skills using less commonly known struggles encountered by six sigma black belt trainees.
In effect, the black belt ’ s performance and path to certification could be frustrated and even curtailed by one of these struggles. One of these struggles is
encountered at the onset in the training phase: Advanced statistical skills required for black belt work can be extremely difficult for nontechnical people.
As this lesser - known struggle indicates, becoming a certified six sigma black belt is not for those who want to take the easy path. Looking back, Milla started
her black belt journey in 2004 with the misunderstanding that certification was achieved by simply sitting through a three - week black belt training requirement.
168 CASE STUDIES
Two and a half years later, Milla finally achieved the much - sought - after six sigma black belt certification.
GUTS FROM THE START — OR IGNORANCE?
How na ï ve she was at the end of 2003, when Milla had created her development plan for the upcoming year; including a desire to receive six sigma black belt cer-
tifi cation based on the belief that the process was simply a revised set of program management steps called DMAIC; but with increased proven results from other
program management philosophies. Also, Milla did not think it would be a nega- tive to show her drive for self - improvement to upper - management levels. In April
2004, faced with an allotment of training dollars for six sigma black belt training for a handful of people, Milla ’ s upper management immediately tapped her for
the opportunity. Upper management had put a high priority on candidates with proven leadership and project results. What they did not know was that Milla had
some inkling that it would be necessary to bone up on simple statistics and even suspected there might be more to the statistics than that; but thought she would
have one or two years to do so before the opportunity arose. Milla uses one simple word to describe the scenario in which she found herself: “ . . . Gulp. ”
The training program was to be provided by another Fortune 500 company, known to be one of the best, and most visible, black belt programs in the world.
Milla decided she would improve her chances at doing well on the statistics by buddying with another program manager to work on the simple statistics pre -
homework assignments. With some diligence they conquered the control and Pareto chart analysis sections with aplomb. She headed into the three - week train-
ing with renewed confidence.
ADVANCED STATISTICAL TRAINING NEARLY SANK HER
By the third day of training, Milla ’ s brain felt shaken, and never righted itself throughout the remaining three weeks. She had taken on legions of challenges
before this, but now found herself faced with what seemed an insurmountable number of new skills and approaches to becoming more technically savvy. For
the fi rst time, she could not rely only on her leadership and program management skills for her success. She spent those three weeks in a daze relying heavily on
one set of skills she had honed over time: how to smile and nod even in the worst of circumstances. She refl ects, “ The one small moment of understanding I had in
any of the statistical training was when we broke up into small teams, built paper planes, and conducted timed drop tests; which resulted in showing us the impor-
tance of various types of operator errors that can occur during a measurement. ” Milla further explained that she was lost in all the mathematical equations and
numerous statistical terms. For her to succeed as a six sigma black belt, she had to prove her skills in:
Project Quality Management 169
1. Setting up a statistically valid data collection plan. 2.
Setting up a measurement plan to ensure statistically valid repeatability, reproducibility, and part - to - part variation.
3. Determining minimum sample size. 4. Understanding variation, stability, and capability analysis.
5. Conducting hypothesis testing techniques. 6. Determining confidence intervals.
7. Doing 1 - and 2 - sample t - tests. 8. Conducting simple and multiple linear regressions.
9. Conducting 1 - way and 2 - way ANOVA.
10. Setting up and conducting a design for experiment.
AN UNEXPECTED REASON FOR HER PERSEVERANCE
The class moved fast, with each skill building onto the next. In the middle of this, Milla was able to glean enough high - level understanding to be able to say
to all her relatives and co - workers that this training was important enough that “ everyone should learn these skills. ” For several years Milla had been trying to
improve her skills and program management methods to gain effi ciencies; but she felt she had hit a wall as to the next level of effi ciency gain. Within the sec-
ond day of training, a lightbulb went off and Milla realized what was missing in her program management methods: a more technical and data - driven approach.
From what she could glean at this high level, the six sigma black belt process and skills would close this gap for her. However, at the end of the training period, she
estimates that she learned less than 10 percent of the knowledge and skills that could be realized from the training. She discovered that she ’ d been ill - prepared
to the extent that she also could not comprehend what approach to take to correct the large gaps of understanding needed to learn from one day of training to the
next. So, she continued to smile, nod, and sink further into a pool of what could only be called “ statistical confusion. ”
She closed out her three - week training realizing the six sigma process and statistical skills would be paramount for her next level of development; but to do
so would require re - training in approach and diligence to gaining technical skills. Prior to this, improvements in leadership and program management had built
upon one another; whereas, the technical skills needed to be a black belt would require getting off one track she was already running on and getting onto another
track at which she would be starting at a crawl. Then, if she could learn how to at least walk within this new track, she would have to quickly meld the two tracks
together as this was expected in her leadership role at the company.
The path to technical skills was not an easy one for Milla. She returned from her initial training and rather than conquering this obstacle head - on, she fell back
on comfortable leadership skills while using, as she is ashamed to admit, “ big, technical words like ‘ measurement capability’ ” to keep the ill - informed from
170 CASE STUDIES
realizing she could not perform the technical black belt skills. This resulted in projects using some of the six sigma tools, but not all; therefore, not qualifying
as full six sigma black belt projects. Milla continued to compensate by stepping up to be a voiceleader for six sigma and this later aided her in satisfying, in fact
surpassing, the six sigma leadership requirements for certification. However, this experience left Milla feeling, for the first time, that she was a “ talk - the - talk, not a
walk - the - talk ” type of person — unable to perform to what was promised. She was also perceptive enough to know statisticians, as well as the few six sigma black
belts in the company, had a much higher standard of expectations.
After about a year and a half of being in the limelight for six sigma leadership, Milla, as part of her next development plan, took a basic to mid - level statistics
course given within her company. The class was to be taught by statisticians over a four - month timeframe, consuming both company and personal time. As this
class progressed at a relatively slow pace, Milla was not only able to put the big picture around how the statistical pieces fit together, but was also able
to significantly increase her technical skills. The course, though, was taught by statisticians from her work group, so she felt hesitant about asking more ques-
tions to increase understanding — recall that she had already claimed to have been trained in this skill set
Milla might have continued to progress at this pace, except that something happened to finally hone her concentration on the required statistical skills for
certification. Up until this time, approximately mid - 2006, training alone carried a relatively higher weight within her company than certification. Currently, how-
ever, Milla ’ s company was planning a large layoff, and although not in a high - risk category, she realized that it would be next to impossible to receive black
belt certification elsewhere as most of her previous work would be moot at other companies. The next six months progresses at a startlingly fast pace with focus-
ing on six sigma project requirements; including “ training while doing ” statistical tasks and results for the project. Milla managed to swallow much of her pride and
sign up for the internally taught advanced statistical course. She began to notice that as she conquered one statistical skill, it was easier to move onto the next. A
doable list of technical skills to be checked off began to form in her mind. In this advanced class, although extremely difficult for her, Milla raised her hand and
asked questions if she did not understand something — Gone were the days of the the empty nod to indicate understanding where there was none.
With her increased ability to say, “ I don ’ t understand and I need help ” came respect and invaluable assistance from statisticians and black belts alike. This
group became mentors who helped Milla to finally gain her six sigma black belt certification two and a half years after she had started down this road. For
many reasons, two and a half years is not uncommon for gaining six sigma black belt certification; however, Milla often reflects on her experience. The 87 - page
document that was needed for certification, showcasing all her six sigma project accomplishments, leadership, and technical skills, remains as a great source of
Project Quality Management 171
pride for Milla. What she often reflects on, though, is how did she manage to go so wrong from the start through to the middle of this certification process? “ I ’ d
rather take on a leadership challenge and speak in front of thousands of people; I had to do battle with myself and face many of my technical fears and this was
one of the hardest tasks I have ever had to take on. ”
Discussion items
1. Where do you believe Milla Gold made some miscalculations in her approach to the technical aspects of six sigma black belt training?
2. What are some ideas for easing the path to understanding the advanced statis- tics necessary to become a six sigma black belt — particularly for nontechnical
people? Include short - term and long - term actions. 3. Should six sigma black belt certification require advanced statistical skills?
4. Do you think the three criteria — influencing ability, leadership, and program management skills — used by Milla ’ s management in choosing who to send to
six sigma black belt training were the right ones?
172
Workshop: Project Quality Program
Dragan Z. Milosevic, Peerasit Patanakul, and Sabin Srivannaboon
Ball, Inc. is a management consulting fi rm with the objectives to locally provide its clients the best services in various fi elds such as organizational change man-
agement assistance; development of coaching skills; and technology, project, and operations management improvements. The company motto is: “ Your one - stop
management consulting for all your business. ” Konrad Cerni is one of not so many employees who have been working there since day one. He loves the company
environment and enjoys working with his peers and clients. More importantly, he loves his job — project management training. Konrad is well known inside and
outside the company. His current position is a senior consultant, and his speciali- zation is in the areas of project management tools and metrics.
Recently, his local client requested Konrad conduct a workshop specifically designed for project management tools. Particularly, the workshop must be done
within a very strict timeframe to accommodate the participants ’ schedules. With more than 50 tools that are available in the practice and literature of project man-
agement, Konrad knew he had no time to cover all of them. Thus, he had to pick only the important ones, and cover them in as many areas as possible. One of the
tools he included is called the “ project quality program. ”
WHAT IS A PROJECT QUALITY PROGRAM?
A project quality program is an action plan striving to ensure that the actual quality of a project will meet the planned one. Using WBS as a skeleton for integration, the
program sets a quality level based entirely on customers ’ expectations and require- ments. With such a strong customer focus, the project quality program translates the
requirements into tangible quality standards, for whose accomplishment a set of tasks is defi ned. Explicitly defi ned responsibilities and timelines for the performance of the
tasks add necessary elements to use the program as a project quality roadmap. In a nutshell, the project quality program states that this is what this project has to do to
ensure that the quality of its deliverables is meeting our customers ’ requirements.
Project Quality Management 173
A PICTURE IS WORTH A THOUSAND WORDS
Konrad said, “ The quality of the project quality program is heavily dependent on the quality of its inputs. In particular, the following inputs are known for their
impact on the program:
Quality policy and procedures, Voice of the customer, and
Scope statement and WBS. ”
He continued, “ The foundations of how quality is managed in an organization are described in its quality policy. Defined, documented, and supported by
management, the policy is a statement of quality principles, beliefs, and key objectives for projects that set a general framework to carry out quality manage-
ment actions in the organization. This framework is further detailed in quality procedures. Together, the policy and procedures set a direction for the program.
For example, if the procedures mandate compliance with ISO 9000 standards, the program will have to comply.
● ●
●
PROJECT QUALITY PROGRAM
Project Name: SMP-1 Prepared By: Bob Maxwell
Rev: 1 Sheet: 2 of 3
Date: May 10, 01
Project Mgml
Manual Flesh reading
ease ISO 9000
PMBOK Review
Review Check and
correct Brevity
guidelines
Organization policy for writing manuals
D Review
D D
D 5 7 5 14 5 21 5 28 6 4 6 14 6 21
D A
Run test and rewrite
Pete Alan
Perry Kim
DZM Ian
D
D
Quality Standard
Quality Assurance
Task Responsibility Matrix
Schedule MayJune 2001 Week of
WBS Code
WBS Element
1 2
3 4
5 6
2.03
Key: D-Do A-Approve
Figure 8.3 An Example of the Project Quality Program
174 CASE STUDIES
Listening to the voice of the customer will not only help discover custom- ers ’ needs; it will also help decipher customers ’ needs and translate them into the
recognizable language of the project scope, establish units to measure customers ’ needs, and express them as quality standards, a crucial piece of the program. For
this reason, the project quality program needs to be closely coordinated with the voice of the customer.
Finally, when you are setting project goals, the scope statement also sets a quality goal for the project. Along with this input goes the WBS which defines
the project work for which a project quality program is developed. Therefore, both the scope statement and WBS are significant inputs to the quality program
preparation. ”
Figure 8.3 is an example of the project quality program which also shows the responsible parties and the timelines of the WBS elements.
Discussion items
1. What are the pros and cons of the project quality program? 2. When should the project quality program be used?
175