BPI-6 Sigma: Defining the Project
| |
Morris Williamson
Mr. Williamson has a bachelors degree in Mathematics,
a masters in Statistics, and a masters in Management Science.
He has 30+ years experience in quantitative methods, is
Adjunct Faculty in Mathematics with Austin Community College,
and has been a trainer in BPI with Dell Inc.
You may contact Mr. Williamson at MWillia900@aol.com. |
|
| |
|
Note: The opinions and views expressed in this BPI series are strictly
those of the author.
In the first article, the typical BPI model was presented: Define,
Measure, Analyze, Improve, Control, and Document.
All BPI projects will flow through each of these phases, some projects
spending more time in some phases than others. It is not uncommon
that as a project moves through the Measure or Analyze phase, it
may recycle back to the Define phase to "reset" the scope
of the project or underlying issue or to expand the process map
to a different level of detail. The first article also discussed
some of the responsibilities of the Corporation and Employee.
This article will focus on Phase 1: Define. The Define phase establishes
the foundation from which the project analysis is based. Any weakness
during this phase can result in questionable analysis and improvements.
Sometimes the improvement is cosmetic and doesn't attack the root
cause of the issue, thus allowing the problem to pop up again in
the future.
In the Define phase, the project is correctly scoped in size by
the BPI Champion (Black Belt) and the Executive staff. A contract
is established. The contract is an agreement between "vertical"
management and the project team that management recognizes the issue(s)
and approves and supports the resources (project team) in their
endeavors leading to issue resolution. A fixed contract structure
should be established for all projects. This provides a common format
for input into the project database, leveraging lessons learned
and best practice solutions. The contract structure outlines the
project objective and issue, estimated savings (this should be determined
by someone other than the project team), estimated start/end time,
team members, management approval for resources, etc.
When writing the contract, it is useful to use the SMART goals:
- Specific — Be specific in the objective writing, i.e. improve
through put by 20%, decrease scrap by $20/unit.
- Measurable — This allows comparison to a baseline to determine
project improvement and success.
- Achievable — The goals need to be realistic with high probability
of success.
- Relevant — The goals should reflect the department or organization's
mission statement and that of the company relative to the customer's
wants/expectation (productivity, cycle time, quality, cost). Here
the customer is anyone that receives the output of the process
that is going to be analyzed.
- Timely — The BPI project should be of the appropriate estimated
duration reflective of the scope and complexity.
The primary team comprises members familiar with the process and
with skills to drive the BPI process. Other team members may include
the financial analyst who will be measuring the final results and
metrics used to make that determination, individuals from other
parts of the company who have knowledge about the process and interaction
with their organization, and outside specialists with skills that
can facilitate movement of the team through situations uncovered
by the team for which they lack the skills to move forward.
A process map is developed: a detailed block diagram/flow chart
reflecting the tasks and sub-processes in which the issue emanates.
A process map is enhanced with identified queues/bottlenecks, where
decision points take place within the process, electronic or hardcopy
inputs/outputs reports, where metrics are generated, and which part
of the process these metrics reflect. Metrics are measurements of
the process behavior or data that will be obtained from the process.
This will be discussed further in a future article, Measurement
and Analysis Phase of the BPI Model.
Process maps can take on many forms: linear map (steps or tasks
that are done in a sequential flow); cross-functional map (which
function within the company is performing the task[s]); organizational
map (where in the corporation's organization the task[s] are being
performed); geographical map (where physically the task[s] are being
performed), etc. There are no right/wrong process maps. A project
process map may reflect a variety of these forms at various levels
of task detail. As a project moves through the BPI model, it may
return to the Define phase to enhance the details of the process
map previously developed.
This first process map should reflect the "as is" process
that is currently in place. Frequently individuals providing input
to the map development will want to talk about future tasks or tasks
that they think will fix the problem. Without a well defined "as
is" process map, wasted time and resources may occur and possible
premature cosmetic solutions obtained.
Many basic process maps can be developed using sheets of butcher-block
paper as the background and with Post-its representing frequently
used symbols: rectangle Post-its for tasks or steps, rectangle Post-its
with double vertical lines for sub-processes or other defined processes,
square Post-its rotated for decision blocks, ellipses for start/finish
of processes or sub-processes, circles for multiple task connection
points including standard representations for electronic/hardcopy
documents, queues and small ellipses for page continuation points.
Books and software packages (I use Visio) are available to facilitate
process map development and documentation.
| Symbol |
Represents |
|
Symbol |
Represents |
 |
 |
|
 |
Task or activity |
|
 |
Electronic/hardcopy report or documentation |
 |
Decision point |
|
 |
On page continuation point |
 |
Direction of flow |
|
 |
Task connector point |
 |
Sub-process or predefined process |
|
 |
Queue |
|