I enjoyed Rol's contribution about when to team and when not to team.
>From a 6-page "booklet" about using a Team Charter which I created for my
company, I excerpt another piece, with input from work done at Teradyne,
about when and when not. Because the original is in Word 5.1 and contains
a table, some of the visual impact is lost.
There are key questions you must consider before and during the team
FORMING stage when the charter is being drafted. These are listed in the
table which follows. Not every problem requires a team. Answers to these
questions may help determine your course of action.
Key Question and Points to consider
What is the overall purpose of our team? What products or services do we
provide? What problems are we trying to fix?
Why is this team necessary? The relationship to our Hoshin goals
Who are the key players? Sponsor, leader, facilitator, members
Who are the key customers/suppliers? Project impact on them; how are they
represented?
What method will the team use? 7-Step Process; Voice of the Customer; Project
Engineering; etc.
What is the scope of the project? boundaries and constraints, like budget,
available personnel and time
What resources, including training, will the team need? Will everybody be
speaking the same "quality language"
What results are expected from our team? Goals, outcomes
What is the estimated time frame for completion? Milestones? Project Plan;
Gantt chart; milestone reviews
Hope there's something of interst in this mish mash.
Still, I send best regards if nothing else.
-- Barry Mallis bmallis@markem.com