Yesterday I volunteered at the Seattle/King County clinic, a four-day event at Key Arena where about 750 volunteers provided over a thousand people per day medical services for free. You could have dentures made, get eyeglasses, and receive vaccinations. There are also people to help navigate the health insurance system, which is no easy task.
Everyone who attended was entitled to a free pair of shoes donated by Brooks (thanks to Chris Clark from Brooks for arranging the donation and running the team for 4 days, 12 hours a day). I spent an 8-hour shift helping hand out these shoes.
The “client” is met at the door of a small building by a volunteer, brought to a seat, and asked their shoe size and any color preference. The volunteer then walks to a back room, picks out a couple of pairs to show the client, and returns. Sometimes the client picks one and leaves; sometimes it would take a few trips to get it right. Everyone left with a pair of shoes.
Surprisingly, there were a couple of great project management lessons I picked up that day.
If a person’s judgment is involved, the duration of a task varies greatly and is non-Gaussian
That’s a geeky way of saying that the amount of time a task takes doesn’t follow a nice bell curve if someone has to make a decision. I put the clients into two categories: easy (either just picked a pair and left, or tried on one or two pairs) and hard (required 3 or more trips back to the boxes of shoes). About 80% of the people were easy; most of my time was with hard people.
If you’re estimating how long a task will take and human judgment is involved, then allow for the possibility that you’ll get a hard one. Unless you can filter out the hard ones (which is difficult to do) and eliminate them (which is often not an option) then sometimes these tasks are just going to take much longer than it “should”. Your process improvement effort may be best spent on how to reduce the time spent on the few “hard” cases than improving your performance for the typical cases.
The challenge for most of the hard clients was determining the requirements
Imagine picking out a pair of shoes for someone. Now imagine this will be their only shoes for a year, so they really care. Now imagine that they don’t speak English. Now add that they have a mouth full of cotton, because they just had a tooth pulled. Imagine that you have little experience and no training in picking out shoes. Imagine that you have a line of people out the door looking to get shoes, and the faster you go, the more people will go home with new shoes. How do you quickly figure out the requirements for the right pair of shoes for this client?
In finding shoes, I did a couple of things:
- Ask their shoe size
- Ask what colors they liked
- Look at their current shoes and dress to guess if they’d prefer flashy or subtle styles
Based on my inference, I would pick out three pairs of shoes of varying styles and see which pair they liked best. Hopefully they would like one of the pairs, and if the shoes didn’t fit, then I’d have a better idea of what they’d like for round two. It was common for someone to say they liked blue, but they’d pick the one green pair that I brought back, so you can’t just go by what someone says.
One of the hardest tasks of a PM is to extract requirements from the stakeholders. Often you speak different languages (e.g. marketing vs. mechanical engineering) and the stakeholder doesn’t completely understand what they want, but they’re in a rush to get it (whatever it is). Not having clear requirements creates a great risk that the implementation team will head off in the wrong direction, so it’s worth the time to get it right at the start. If there’s ambiguity make it explicit (e.g. we want the mass to be small since it’s a handheld device, but we’re not exactly sure what that means).
Giving your stakeholders choices is a good way to understand their requirements (e.g. would you prefer having something that weighs 1 kg in a month or 600 grams in two months?). When working with stakeholders it’s fine to infer what people want based on whatever clues you have to get the process started, but it’s important to understand the difference between imply (what people mean without saying) and infer (what you think people mean that they aren’t saying). If you make an inference, it’s important to ask if what you’re inferring is what they’re implying.
It’s a challenge matching vague requirements to a box of shoes
An older woman told me that she likes black and white and she wears size 8 1/2 shoes and I’m faced with this.
My solution is in that box. It’s not going to be exactly what she wants. It might not even be close. It’s going to be the best I can do given my constraints of time and the shoes in that box.
Often stakeholders want something that’s just not going to happen. Maybe they can’t afford it, they’re constrained by schedule, or it’s just not physically possible. You have to separate out what the stakeholder wants from what they need. They need a pair of shoes to protect their feet; they want something that matches their personal style. In my case yesterday, most of my clients had reasonable expectations. That’s not always true with stakeholders.
There are lessons to learn no matter where you are or what you’re doing
Whether you’re helping an indigent person get a pair of shoes or a startup design a medical device, you should always be bringing your A-game. Understanding the needs of another person is always an important part of solving any problem. Any project, no matter how small, is important to your stakeholder and you should treat it as such.