What is a Brown Paper?

It is a pictorial representation of an entire process, detailing the actual

steps taken and highlights all applicable interfaces, decision points
and information sources.
Brown Paper Overview
When: During sales process to develop and present the solution
During the analytical phase of a project to study the “current situation”
During results delivery as needed and to help develop “future state”

Why: The brown paper shows the entire process and work flow. It is used to:
• Highlight strengths • Build credibility
• Identify • Create understanding of
opportunities key interfaces
• Show the big picture
Who: The brown paper is constructed with client involvement; team
members act as facilitators/drivers.

Additional training: Will occur as you construct brown papers. These

should always be a joint activity. You should
understand how to assemble a brown paper so that
all of them are consistent.
Why do a Brown Paper?
• Show the process’ areas of strength
• Show areas of opportunities
• Show the big picture: “forest and the trees”
• Provoke thought for improvement opportunities
• Promote common understanding - increased cross-
department learning and fewer knowledge gaps
• Tell a story
• Use as a training tool
• Information sharing
• Facilitates non-technical user involvement
Brown Papers can depict several
states
• Can be used in a variety of applications
• AS-IS (actual process in use today)
• SHOULD-BE (process according to procedures)
• COULD-BE (optional methods)
• TO-BE (model for implementation)
Elements of a Good Process Flow
• High client involvement
• Capture process-formal; informal; emotional
• Highlights opportunities for improvement
• Details all critical activities (“As-Is”)
• Simple and self explanatory
• “Live” documentation
• Captures all perspectives
• Icons and humour help communicate
Tips on H2 build a brown paper
BEFORE:
Get supplies:
flipchart, brown
Examine and Determine mix Communicate paper, masking Plan the
agree on of functional with identified tape, long rulers, process
desired results representation resources markers, pencils

DURING:
Capture
Begin dialog
Kick-off: team additional Agree on Agree on
between team
lead intro, doc documents Triggers where to end
lead and
requirements and research START!
content lead
on flipcharts

AFTER:

Validate with Identify

other users opportunities
Guidelines for Building a Brown
Paper
• Don’t create a finished brown paper from scratch
• Disagreement about how the function is completed is acceptable
• Make not knowing the answer to every question an acceptable
situation
• Be sure participants understand that the steady stream of
questions is not an attempt to trick or humiliate them
• Ask for hard copy and completed examples
• No value judgements
• Identify one stream of activity and do it start to finish
• Write explanations directly on the brown papers
• Specify percentages “yes” or “no” for decision points
• Use arrows to show the flow
• Rule of thumb
Use Standard Symbols
Task - Actual task Out of Area / Interface
performed Draw Attention
Comments/Explanation
Example - Type a form,
review a Example - Input from
form Strategy
Development

Major Opportunity
Decision - Requires a 1
Yes or No Example - How to reduce
answer the 73% re-
work at this
Example - Is the form step
complete?
Quantify opportunity
Sample Brown Paper Format
(Client Name) Service Excellence Strengths
Department Name Attach Identify
documents, strengths on
green post-it
(Flow Name Here) reports, etc.
notes

Use ICONS to Diamonds %

show the process Use blue ink to ICONS are Rectangular
when possible identify process used for ICONS are used
decision for activity
points Opportunities
1
Identify % 1.
opportunities on
yellow post-it notes Show detail 2.
with red ink Quantify
when 3.
necessary
opportunities,
loops, lags, etc.
Please Sign In
Show linkages to
1 other process flows
LOOK FOR THESE SPECIFIC
OPPORTUNITIES
• Dead Zones - Places where work sits, gets held up (bottleneck) or gets
lost
• Lost Time
• Obvious - People looking for work
• Hidden - Re-work Loops have double backs for more information or
to correct errors
• Checkers checking the checkers - Too many approval layers
• Duplicate work
• Broken interfaces - Interfaces not effective or non-existent