Ask for a general question, get a general commitment.

I don’t know if this has ever happened to you, but when you are in the middle of a project (not even a business project, but say coordinating some volunteers for an event) and you ask around for help in general terms.  You know the conversation it sounds something like “Hey Jan. I’m heading up the refreshments for next weeks Scout meeting.  Would you like to help by bringing some cookies or maybe help setting up?”  Usually the people you talk to agree to these general commitments.  After two or three conversations like this you start feeling good about the project and have a sense that you’re going somewhere.  Then it hits you, all you’ve done at this point is ask two or three people if they are interested enough in what you are doing, to possibly take part in it.  At this rate, you could have ten people ready to help and waiting for further instructions in no time.

What really needs to happen is you have to have a plan, even a rough one, at the outset. With some sort of a plan, you can ask for a specific commitment like “Jan we need refreshments for next week’s Scout meeting. Would you be able to bring two dozen cookies on Tuesday night?”  After asking this, you wait for an answer (a specific commitment.) Then if you need to you can follow up with “Great! Thanks.  Also we will be setting up for the meeting at 6:45, can you be there to help?”  This benefits both you as the coordinator since you have a better idea of what to expect, and the person you are asking as they have a clear idea of what is expected from them.  It’s a simple concept that sometimes gets lost. The problem is that when it’s lost, you eventually have to go back and ask everyone that gave a general commitment for a specific commitment.  

I was reminded of this earlier this week when talking to one of Visionpace’s .Net development teams.  The conversation was concerning code coverage for our unit testing and my initial question to the team was “Are our coverage and testing scenarios sufficient for these user stories?”  Just as I asked the question, I realized it was too general.  Before I could rephrase the question, another teammate spoke up for me and said, “I think what Martin is asking is two questions. A) What is the percentage of coverage we have for the different modules on the project? B) Are we testing the ‘happy path’, boundary conditions and ‘unhappy paths’ for all unit tests?” He was right. His questions got to the specific meaning of what I wanted to know and he asked questions that the developers could give specific answers to.  Had the questions not be rephrased, I’m sure I would have gotten the equally general answer of ‘Sure’.  The answer is valid, but because of the question, I’d most likely have to ask the more specific questions later.  Instead we were able to talk about specific areas of the project that needed further testing for boundary conditions and testing the unhappy path.

One exercise that I do occasionally is to go 24 hours and consciously make sure I don’t ask any general questions.   After I do this, I find that I continue to ask more specific questions without thinking about it.  Of course this leads to other issues when it comes to my kids. Rather than ask “Have you done all of your chores?” I’ll ask “Has the laundry been put away? Have the dishes been put away and the dishwasher loaded? Have you cleaned your room?”  One of my kids might answer yes to all the questions and bound off to their room.  When I follow up with “Why is the living room dirty?” the answer is usually “You didn’t ask me if the living room was clean…..”  Se la vie.