PM Articles > Geof Lory > Shopping for Requirements

Shopping for Requirements

by Geof Lory

When it comes to domestic duties, my wife and I have pretty clear lines of division of labor. I can't say that we have talked about it all that much, but there are some household things I do and other things that Beth does. We don't have defined or documented job descriptions (although it might have saved more than a few "misunderstandings" if we did) but we do have a pretty well understood TOA (Team Operating Agreement). Co-location and an intimate understanding of each other's strengths and weaknesses, interests and dislikes over 15 years will do that.

Like most couples, we can read each other's moods, finish each other's sentences, and know when a single look speaks volumes. But, there is one area where we are challenged to communicate well, and that is in the kitchen; specifically, grocery shopping and cooking.

I don't typically shop for groceries. That's Beth's job. Beth doesn't cook. That's my job. With rare exceptions, this division of responsibilities has held true since we have been married. And I know we are each grateful that we don't have to do the other person's job.

When I do find myself wandering around the grocery store looking for olive oil or basmati rice, I might as well be lost in the deepest rain forest. Stumbling up and down the same aisle, l finally ask a clerk where the item is. Then with a sigh of frustration, I move to the second item on the list and repeat the exercise. Grocery stores just don't seem to be laid out the way my brain works. Beth on the other hand has her list organized by aisle and zips down each aisle just once, stuffing her cart in record time with minimal hesitation, every Saturday morning (while I am golfing).

As foreign as the grocery store is to me, the kitchen is to Beth. I enjoy cooking and am reasonably good at it, but if it were up to Beth, we would eat whole wheat pasta with microwaved pasta sauce from a jar and a salad every night. That's not going to cut it for me. It's not that I live to eat, but I feel meals should be shared and enjoyed, not mundanely endured for the sake of sustenance. Beth understands and appreciates that, but not enough to make the effort to cook.

I'm willing to bet that for most couples there is some area of their relationship that has this yin and yang to it. But, what does this have to do with requirements?

On occasion, I decide to prepare something different and intricate that requires some spices or ingredients that I don't regularly have on hand in the pantry or refrigerator. So I dutifully put those items on the grocery list, conveniently stuck on the Team Refrigerator with a magnetic pen so it is readily available, expecting that by Saturday afternoon they will magically appear for me.

Invariably, about the 8th hole, my phone starts to ring. "Did you want fat-free sour cream or regular? The red potatoes are all large, is that OK? They don't have cilantro, will Chinese parsley do? How do I tell if these are jalapeno or serrano peppers? They don't have any swordfish but the butcher says the sea bass is fresh. And what the heck is pro-sci-oo-toh? Your handwriting is terrible."

I don't need this. I'm trying to sink a 4-footer to save bogie and my cell phone is vibrating like crazy. Why doesn't she understand my cooking requirements? I wrote them down pretty clearly, at least to me.

I help a lot of teams adopt best practices in project execution, and by far the most challenging area is the translation of the business needs into sufficient detail that the team (usually developers writing code) can create the expected result, or maybe something even better. Commonly referred to as requirements definition, business analysis, or functional specifications, this activity usually emulates the processes used in the construction and engineering worlds. Most organizations employ methodologies that continually elaborate the requirements into greater and greater detail, from a Business Requirements Document to a Functional Requirements Specification to a System Requirements Specification to a Technical Design Document (with signatures at each hand-off). This usually results in more documentation than even the most diligent developer will ever read, let alone deliver on. More time is spent reviewing and approving the documentation than actually writing code or delivering business value.

I tried to do this once with Beth's grocery list. At the top of the list I wrote:

2 - regular cans of diced tomatoes with cumin spice. Del Monte is the best brand but if you can't find that, Hunts or the local brand will do. If you can find any that also have jalapenos diced in them that would be better but not if they are too spicy because your Aunt Katharine gets heartburn easily. They have to be diced, not stewed or whole, because I hate having to cut them up. I'd rather just pour them in already cut. Some have celery and onion in them. That will leave an off-taste when I reduce the sauce, so don't get those. If you can't find the regular size cans, get three of the smaller cans or one of the large cans…

By this time, there was no more space on the grocery list for the next ingredient, so I got another sheet of paper.

Why couldn't I just write "2 cans of tomatoes for Chicken Stew with White Wine?" Because Beth doesn't cook. She lacks the context to make the same decisions I might make when faced with the challenge of uncertainty or discovery at the grocery store. So, instead, she attempts to clarify my requirements with questions like, "How many ounces in a regular can?" Of course, I have no idea. In my job, I just open the can and pour it in.

At this point, I am left with two other options: A) Be willing to cook with whatever she buys and brings home, or B) go grocery shopping with her. When it isn't that important, I choose option A. When it really matters, I go shopping with her. I do occasionally shop by myself, but I've already described why that is not a preferred option.

I have never really understood why we put so much time and effort into attempting to refine an inherently weak communication medium rather than leveraging a naturally strong one. You would think we were all lawyers drafting contracts to protect our parochial interests rather than trying to deliver a valuable business outcome. The minute documentation even feels like a CYA, you are dead.

Collaboration through dialogue is clearly a more effective method of conveying requirements, especially when the two sides don't share a common context or experience. Not only will the dialogue bring greater clarity, but in the process each party will gain some insight into the other's perspective, making the next dialogue that much more effective. And after all, we're not trying to create the perfect shopping list. We're just trying to make a good meal.

Increasing shared context through dialogue creates a more flexible environment. Before we decide on the groceries, Beth and I talk about the dinner we are going to have so she understands my general vision, even though she lacks the context to decompose it into ingredients. But, when I do go shopping with her, it is not uncommon for me to see something that looks really good and totally change everything I was planning to make. I scratch off half the things on her list and fill the cart with what I know I'll need, trying to remember what I already have in the pantry. This used to frustrate Beth because we had already agreed to what would get done. But now, she just listens and helps me find what I need. We're a good team that way: agile.

BTW, we do the dishes together. Bon appetite.




Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

What a perfect way to describe it!


Great thought. I'll give it a try as I advocate for my peanut/nut-allergic kids' safety in school.


I love this analogy. As a business analyst in a government environment, I can totally relate.


Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.