 |
Home > Detail: Done and DONE-done
| A StickyMinds.com Original |
|  | |
Done and DONE-done
The Magic of Completion Criteria
By Payson Hall
   
Summary: As a professional project manager and amateur magician, Payson Hall assures us that effective project management isn't magic. A magician should never reveal how a magical effect is accomplished, but good managers do share the rationale behind their actions to help others become more self-sufficient. Demystifying effective management actions improves our ability to get results, allowing us to move on to new and different challenges. In this column, Payson explains the strongest management "trick" in his repertoire--the pursuit of unambiguous completion criteria. He also tells us that perfecting this trick takes a lot of practice, but it can serve us immediately and throughout our careers. | | |
|
|
 |
Barbara was a programmer on my team responsible for building a utility for our project. This utility displayed a scanned image on a screen, allowed users to define regions on the image, captured the corresponding coordinates, manipulated the regions, and stored the new image in a special format. An adjacent project needed an early version of the utility and we agreed to provide them with a "prototype", which was expected to be functional, ugly, Spartan, and have minimal error checking.
On a Monday, I asked Barbara when the prototype would be finished, and she told me it would be done on Friday. At the end of the week, I went to Barbara and asked, "Are you done with the prototype?"
“I'm done,” she replied.
“Great!” I said, extending my hand. “Give it to me.”
“Well…” demurred Barbara sheepishly, “I'm not DONE-done.”
“DONE-done?” I inquired. I'd never heard that one before.
“I built the prototype and tested it using simple test data,” she said, “but I haven't yet integrated the more complex transforms. Integrating those and testing will take another two days.”
“I'll see you Tuesday then,” I said. DONE-done. Ha! What a kidder.
On Tuesday, I stopped by Barbara’s cube. With an almost straight face, I inquired, “Hey Barb, are you … DONE-done?” I couldn't help but chuckle.
“I'm DONE-done,” she beamed. “It works great.”
“Wonderful!” I said, extending my hand. “Give me the disk.”
“Well,” Barbara hesitated, “I'm not DONE-done-done.”
The humor drained from the situation. In my mind, I began hearing Beethoven’s “Fifth Symphony”: DONE-DONE-DONE, DONE. DONE-DONE-DONE, DONE.
I got grumpy. “What do you mean you're not DONE-done-done?”
“Well,” she replied earnestly, “I built the prototype and tested it successfully with the transforms. But I haven't built the readme file that explains the subdirectory structure, or copied the pieces and parts to a diskette. I won't be DONE-done-done until tomorrow.”
I was angry and disappointed. “What time tomorrow?” I grumbled. We agreed that I would stop by at 4:00 p.m. to pick up the diskette.
I went to complain to the senior project manager, Pat, about what an unreliable and equivocating person Barbara was--to whine about Done, DONE-done, and DONE-done-done and explain why I was surprised by the delay. I expected sympathy and strategies for disciplining Barbara, but Pat gently interrupted me and said, “Why are you frustrated with Barbara? You screwed up.”
“Me?” I said. “What did I do?”
“Unclear completion criteria,” Pat said. “If you had been clearer about what ‘done’ meant, you likely would have gotten a clearer answer to your original request for an estimate and probably even a straight answer when you asked about progress.”
“What do you mean?” I asked. “Isn't ‘Done with the prototype’ clear enough?”
“Apparently not,” smiled Pat. “You say she wasn't done Friday--how could you tell?”
“Because if she had been done, she would have been able to provide me with a diskette of the code and information that I needed for the other project to run the utility,” I said, still not getting it.
“Then that’s what you should have asked for when you defined the task,” Pat said. “You might have said, ‘Barbara, I need to send a diskette to the other team so that they can use the prototype. What will it take for you to build and test the utility and put it and any necessary files and instructions on a diskette for me so that I can pass it to them?’ It might not have gotten you what you wanted, but it would have clarified your goals earlier and improved communication.”
Pat had made her point.
Since then, with practice, I've gotten better at defining completion criteria and recognizing when “done” is not clearly specified. I've also discovered that poor communication about completion criteria is often the root cause of disagreements related to task definition, project definition, and whether or not requirements have been satisfied. Take a moment and think about a current task you are doing or someone is doing for you. Now answer these questions:
- How will you know the task is done?
- What work products will the task create?
- What standards apply to the work products to assure they meet requirements?
- Where will those work products be when the task is complete?
If you and someone else familiar with the task answered those questions independently, would you come up with similar answers? If not, prepare to discuss DONE-done.
Getting good at defining completion criteria isn't magic, though it sometimes seems that way. Pulling a rabbit from a hat is applause-worthy, but asking, “How will we know this is complete?” can save a project.
About the Author
Payson Hall is a consulting systems engineer and project manager from Catalysis Group, Inc. in Sacramento. Formally trained as a software engineer, Payson has performed and consulted on a variety of hardware and software systems integration projects in both the public and private sectors throughout North America and Europe during his twenty-year professional career. He is a regular columnist on StickyMinds.com.
Back to Top
StickyMinds.com Weekly Column From 03/13/2006
|
