Home | Login | Recent Changes | Search | All Pages | Help

NotesSessionFour004

Observer

• First question was, "Who is the PM?"
• Factory team started without talking with the customer
• Factory team organized on what little information they had
• Factory team talked about delivery but it still became an issue later
• Factory used the wrong sort order
• Factory recovered by Tim L. getting detailed information from customer
• Facory owner played a role similar to the one he plays at work
• Factory did capacity planning
• PM did delegate
• First status report did not reveal information that the customer wanted
• Factory workers sorted decks without management asking (self organized)
• Smart move to create a time keeper role and buffer
• Work trailed off and workers became idle, which was okay
• Factory discussed speed versus quality
• PM did some socializing with the customer
• Customer became agitated when asked about requirements (had an agreement with the sales person who left)
• Promises to customer about delivery was not communicated to the factory
• Factory workers asked questions internally about whether a bonus was possible
• PM did not recalibrate ??? on change request
• Smart move to put decks in the hand on the workers so they could see
• Limit on delivery was rediscovered but persistence paid off when customer hired more QA staff
• Factory did create rapport with customer

Owner

• I didn't know all the rules
• Started without complete requirements. But made good assumptions.
• Did not feel empowered

Project Manager (PM)

• Did not status owner
• I was unnerved that I didn't know the customer
• Used advice of the factory workers
• Starting gets you immediate feedback
• Owner let people self nominate, which was good

Factory Workers

• Sorted decks without management knowledge
• Would have been nice to have someone nail down the requirements early
• Time keeper calibrated feedback to the workers by counting down
• We stayed out of each others way
• Time keeper chose role because he liked the quiet
• Consultant chose his role without formality
• Shipped product without QA knowing of shipment
• Workers all evolved to QA. Otherwise it would have been a lot slower.
• Management enabled people to self-direct

Customer

• Had written set of requirements from sales person
• People from factory were dragged in by sales rep
• Liked meeting the owner
• Status was not good
• Eventually became satisfied

Customer Quality Assurance

• Cards always mapped to the requirements
• Got clarity on card order. Tim L. made it very clear.

General feedback

• Status is less important if project is going well
• Measurement were distorted
• Status was reflected by the work environment
• Bandit told the story about how his father did his daily status reports. Before the meeting, he walked around and looked at the workers' notes.
• Customer may or may not be interested in how the company is organized
• Ask the customer what want to know and how frequently
• Frequency of status changes over the project lifecycle
• Did energy chart
• Sorted the jokers just in case
• When there is more anxiety, more frequent status is desirable
• Workers needed feedback early and less later (stay out of their way)
• Status is much different for larger projects
• One measure of status is the number of requirements delivered and accepted by customer
• Jerry's story about the best defense department project. A measure that he used was whether the customer was willing to write a letter about the results of the project
• Agile shops use the number of stories delivered and scored, which is posted where Executives can see it
• All measurements require QA. Without it that measures may be worthless
• Big projects require different status dimensions (Executives, workers, and so on)
• You can't let any one stakeholder win. Balance the needs of the diverse groups.
• Slip charts are an effective status device. They show the difference between schedule and delivery changes). You can tell where how reliable their estimates have been (See QSM volume 2)
• First status problem may be NOT having a customer (to get requirements from)
• Method is to find out what the customer wants
• A consistent problem is getting to "The Contract"
• Schedule for how long it will take to get the requirements
• The measurement is "When will we be ready?"
• "90% complete" may mean 100% complete of what people know what to do
• Test by having people forecast the delivery of their most predictable piece of work
• You want status to be an honest look
• Listen for this key phrase, "We can't tell this customer this." Danger.
• Getting an informed, intelligent customer is a good first step
• Educate your customer
• The hardest thing is emotionally facing up to telling the truth
• It's better to get out early rather than later

SteveSmith 2004.11.14