« Are You Treating Good Customers Like Bad Ones? | Main | An employee benefits mishap »

Bustin' My Buttons

Button_brokenI like to have my shirts professionally laundered.  For a couple of bucks, my dress shirts are washed, ironed, starched, and placed in neat little plastic wrapping (which is recycled as packing cushion when I need to mail my books someplace). 

There's nothing like the feeling of contentment when I put on a crisp clean shirt in the morning...


My one big pet peeve about dry cleaners and professional launderers is when they break a button and don't stop to replace it. 

My last dry cleaner, Reeds, did that religiously.  In the four years I used them as a laundry service, I maybe had one or two button issues.  The prior cleaner, whom I unceremoniously fired, was notorious for breaking or losing buttons from my shirts.  Worse, they were unapologetic about it.  So I switched to Reeds.  But now Reeds has closed their doors, and I'm forced to find a new dry cleaner. 

And with my first trip to the new cleaner, what am I finding on my shirts?  Broken buttons.  I think I'd rank "button condition" above starch level on my satisfaction scale for professionally laundered shirts.  You could say it's a "hot button" of mine (OK, bad pun, sorry).  I'll give the new cleaner a shot at fixing the issue by communicating to them how important this one criterion is to me.  If they don't fix it, I'll be shopping for another dry cleaner.

But let's tie this issue back to our projects.  What are the success criteria that define the quality of project completion?  We use terms like "user friendly" without giving specific criteria for meaning.  We talk about wanting things "as soon as possible" but don't tell people how we're defining the "possible" part. 

On some of my projects, the team will do a short exercise before we begin defining requirements.  I ask everyone on the team to define two terms:  "Cold weather" and "Small town."  The definitions come back all over the board, both in quantitative (below 32 degrees, under 5000 people) and qualitative (hat and glove weather, only has a Casey's) terms.  We then use this exercise to talk about being specific on defining our project solutions.

The blog, Neeru's Corner, agrees with the approach.  Guest blogger Jim Swanson nails the ambiguous language problem very well

The truth is, one of the surest ways to fail in requirements is to say to your users, "Give me your requirements," then stand back and "catch" them. Why doesn't this work? The stakeholders are experts in their domains. While the analyst probably has more expertise in the IT domain, the two speak different languages. The stakeholders truly do not understand exactly what IT needs to be able to develop an effective system for them.So the only way for a project to obtain comprehensive, correct, and complete requirements from all stakeholders is to truly elicit them. Elicit means to probe and understand the requirements, not just capture or gather them.The reality is that the quality of the requirements depends on the quality of the solicitation of them by the analysts.

So as you are defining your next project, take some time to work with all of the key stakeholders to better communicate and document your expectations.  And if you can recommend a great dry cleaner in the Urbandale vicinity, please let me know.

Carpe Factum!


TrackBack URL for this entry:

Listed below are links to weblogs that reference Bustin' My Buttons:


The comments to this entry are closed.

« Are You Treating Good Customers Like Bad Ones? | Main | An employee benefits mishap »

Technorati Bookmark: Bustin' My Buttons

This site is intended for informational and conversational purposes, not to provide specific legal, investment, or tax advice.  Articles and opinions posted here are those of the author(s). Links to and from other sites are for informational purposes and are not an endorsement by this site’s sponsor.