I don’t normally drink coffee from Starbucks but someone gave me a gift card. I like black coffee, with no cream or sugar. I like my coffee fresh so I order a small size. So, why on Earth did the person behind the counter not listen to me?
I ordered a small Caffè Americano. For those who do not drink coffee, that’s nothing more than a small espresso and water. My expectation was I would get a small cup of coffee. When I looked at my receipt it said Tall. I brought this to their attention and I was dismissed. “Oh, it’s the same thing.”
Well, no, it’s not. Line up the cups and this is what you will see. Extra-Small, Small, Medium, Large, and Extra-Large. What does Starbucks call them? Tiny, Small, Tall, Grande, Venti. So, what I got was a medium. I’m not going to split hairs here. I’m trying to make a point. There needs to be a common understanding between the vendor and the customer when you both define the same thing differently. This is a financial transaction. I want what I paid for.
How does this apply to Project Management? From the customer’s perspective, what is the definition of done. From the vendor’s perspective, what is the definition? From every stakeholder perspective, do you all have the same definition of done? You should!
It’s important to note, it doesn’t matter which approach you use. Waterfall, RUP, Agile, or Kanban. Everyone needs to understand and agree to what done means.
Things seemed to get a little heated in the meeting yesterday. Upon reviewing the vendor-supplied PowerPoint deck, we noticed graphs illustrating the quantity of issues found and when the vendor planned to fix them. So, we flipped back a few slides and noticed a table detailing the quantity of requirements that passed or failed, during the last build. What we didn’t get was something that illustrated the relationship between the two. Since it wasn’t included in the packet, we wanted an explanation.
Never ask a question in an accusatory manner. Don’t be condescending. Make sure the other party hears what you say and understands. I started with something like this
So help me understand what I’m seeing here.
I see…. …Is that what you see?
I’m looking for the relationship between the issues found and the work you were authorized to complete. Can you help me with this?
What was missing here was a Requirements Traceability Matrix. It would have answered everything. During this build, only work pertaining to agreed upon requirements should have been done. Only work pertaining to agreed upon requirements should have been tested. Therefore, we should have known immediately which requirements had passed and which failed. That didn’t happen.
It doesn’t matter if you’re using user stories or requirements. There are documented expectations that need to be met. User acceptance criteria should be known.
In celebration of my wife’s birthday, I figured I would make her a homemade birthday cake. I haven’t done that since before we got married 5+ years ago. This time, however, I actually asked her what she wanted. That’s right. The first birthday cake that I made for her, I didn’t even ask what she would like. If you were the customer, wouldn’t that kind of tick you off? Thanks for the cake but… I don’t like that kind.
Getting input (and listening) to your customer goes a long way.
Sure, I could have ordered a cake from the local (and now famous) Charm City Cakes but she didn’t ask for that. She wanted a chocolate cake with butter cream frosting. So, last night, our 4-year-old son and I made her a chocolate cake with butter cream frosting. We even cleaned up the mess after! But, it wasn’t completely uneventful. All I can say is I’m glad there were well documented instructions.
Me: Are we a pair of knuckleheads or what?
My son: I think we’re a pair of clowns, Daddy.
Here is my Project Management Spin
- Find out what your customer wants.
- Deliver what your customer wants, not what you want.
- You’ll spend more money if you want a chef to bake and decorate your cake.
- You’ll save more time if you want a chef to bake and decorate your cake.
- Even a pair of clowns can bake and decorate a cake (if instructions are good).
- You should expect lower quality from a pair of clowns.
- Both cake and frosting passed unit testing. (Mmmmmm)
- We did a little beta testing last night before the final build.
- The final build was successful.
- We delivered on time.
- We delivered below budget.
- The good news is, I’m pretty sure we’ll pass user acceptance testing.
Happy Birthday to my beautiful and wonderful wife!
What’s a weekend without grilling steak? I would say a weekend without a good blog post idea. Some things in life are an art and some a science. It doesn’t matter if it’s project management/leadership or grilling a steak.
So, what is a geeky way to write about grilling the perfect steak? I would say compare it to the Deming cycle, or PDCA (Plan-Do-Check-Act) cycle to illustrate the point. PDCA is a continuous quality improvement model consisting of a logical sequence of four repetitive steps for continuous improvement.
- Plan what you intend to do. In this step assess where you are, where you need to be, why it is important, and plan how to close the gap. Identify some potential solutions.
- Do try out or test the solutions.
- Check to see if the changes you tried had the effect you hoped for, and make sure that there are no negative consequences associated with them. Assess if you have accomplished your objective.
- Act on what you have learned. If you have accomplished your objective, put controls into place so the issue never happens again. If you have not accomplished your objective, go through the cycle again, starting with the Plan step.
PDCA applies to entrepreneurial ideas, application development, and anything that happens to do with my grill. Realistically, you can apply it to anything where unknowns exist. There are just so many variables, you need to be prepared to act and pivot. I have grilled countless steaks and have refined my process to the point that it finally meets my quality standards. On occasion, I do check to see if my process holds true and all I do is mess up a good steak. I won’t go into specifics as to what my perfect grilled steak process is. (Unless someone asks) Rather, I’ll say I documented it and saved it in Evernote.
Now if only I could do the same with a hamburger.
When I was young man, others told me my parents were pretty strict. I didn’t think my parents were strict at all. It’s just the way we were raised. There were some pretty basic rules I remember following when it came to courtesy. Some call them common courtesy. But, I’m starting to think it’s not as common as you might think. So, today I’m going to give you a few rules of common courtesy. They will not be in any specific order. Please apply to your work and home life. Hope you enjoy.
Derek’s Rules of Common Courtesy
- Hold the door for people
- Say thank you when someone holds the door for you
- If someone says hello, say hello back
- Listen, don’t wait to talk
- If you must interrupt someone, say excuse me
- If someone sneezes, say bless you, gesundheit, or something similar
- Say goodbye to your boss and colleagues before you leave for the day
- If someone sends you an invitation, either confirm it or deny it. Don’t not respond
- Don’t take credit for work others have done
- Look people in the eye when they are talking to you
- Say please
- Say thank you (hand written thank you’s are a big bonus when appropriate)
- Don’t talk on you mobile phone while in a checkout line
- Turn off your mobile phone while at the theater or restaurant
- When in traffic and you come to a yield sign…yield
- When in traffic and you come to a N-way stop…stop
- Arrive at appointments or meetings on time
- If you say you’re going to do something, do it
- If you drink the last of the coffee, please make another pot
- If you use the last of the toilet paper, please replace the roll (at least tell someone)
I would love to hear if you have a rule to add to the list.
The other day I met Scott Simko, who I “knew” through This Week In Startups and Thomas Kiblin, CEO and Founder of Virtacore. I met them as the founder of HueCubed, a web startup company offering a flashcard engine that we plan to scale like Weblogs, Inc. or Stackoverflow. (Create a niche product and then scale it in other vertical markets) Our flagship product, PMPrep Flashcards, was released in March and I wanted to meet the people who are hosting our product(s).
Up to this point, I have introduced myself as Derek Huether, Project Management Professional® and adviser. But these people don’t know me as that. They were meeting me as Derek Huether, entrepreneur and founder of a web startup. As a result, I stumbled when it was time to introduce myself. Don’t make this mistake!
If you wear multiple hats in your organization, you may need to know who you are to different stakeholders. Is your specialty in Waterfall, Agile, or Kanban? Take a moment and imagine you are being introduced to someone. What are you going to say? This is part personal branding and part stakeholder management. What I needed was a solid 30 second elevator pitch. What’s the takeaway from this post? Know who you are and what you represent. It may be different, based on the company you keep.