What happens when a Project Manager asks one of his team members "Are you done yet"?
If you're a seasoned project manager, then the following scenario will sound very familiar. If you're new at this game, take my word for it: This will happen to you!
------------------------------------------------------
Starring in this article: R.U. Dunyet (a.k.a. Red)
------------------------------------------------------
(Monday)
Red: Are you going to be done for this Friday?
Developer: Oh yeah. I'm actually ahead of schedule.
(Wednesday)
Red: Are we still on track for Friday?
Developer: Yep, no problem.
(Friday morning)
Red: Are you done?
Developer: No, but I should be done today. If might have to stay late, but I don't see why I couldn't finish this evening.
(Friday evening)
Red: Are you done?
Developer: No, but like I said this morning, I will work late tonight to complete it.
(Monday)
Red: Are you done?
Developer: Um, no. But I'm very close.
(Wednesday)
Red: Are you done yet?
Developer: I ran into some integration problems because so and so didn't explain his interface properly. But no worries, he's going to help me this afternoon integrate it. I'll let you know when we're done.
(Friday)
Red: Are you done yet?
Developer: I'm working as fast as I can! Didn't I say I'd let you know when I'm done!
What Do They Mean by "Almost Done"?
The most popular answer to the "How's your feature going?" question is "I'm almost done". But what do developers mean by "almost"? And what about "done"?
I've had developers tell me that they were done when they had in fact not even committed their code to the source repository. When I asked them what they meant by done, they replied their code worked on their machine. Sure, they had not committed their code, integrated their feature, installed it on the daily build or developed unit tests yet, but that's something you do after you're done, right? Wrong!
Lesson Learned
Don't ask vague questions like "Are you done yet" and then walk away. Drill the developer for more details. Ask for specific deliverables like software requirements specifications (SRS), a feature demo, results from unit tests, or even better, have one of your testers write a test case build on the SRS and have him execute it against the daily build. If the test case does not pass, the feature is not done!
Don't be a pest. There are developers that have proven time and time again they will develop features on time and according to specs, and there's no need to annoy them. But let everyone know that you want an accurate report on everyone's status, and do what's necessary to get it.
Luc Richard is professional speaker and author with over 10 years of experience managing the development of software applications. He can be reached via The Project Mangler (http://www.projectmangler.com).