I perform project and process assessments as part of my consulting work. During one assessment, a senior manager took me aside, and said, “I want you to tell me what you think of our testers.”
“All of them?”
“Well, the developers meet all their milestones, but the testers don't meet any.”
Hmm. It's hard for me to believe that an entire group isn't delivering what they need to deliver, but stranger things have happened. Here's what I discovered during the assessment. Yes, the developers met every milestone. Every single milestone. They were never late — not once.
Now, you don't have to review too many projects before you realize that's an incredible event. I've never met a project where the developers weren't at least a day late on something. But these developers met every deadline.
I dug a little deeper. I asked one of the developers if his code was complete. “Sure it is.” “So, you've unit-tested it, run it all on all the platforms, and made a build that you ran on your machine?” “No, I didn't do that. But the structure is all there.”
I asked what the developer meant by structure, and discovered that not only wasn't the code tested, it didn't exist. The project schedule was so optimistic that the developers could never meet any of the deadlines if they'd worked in a reasonable way. So they sketched out what each module was supposed to do, checked it in without any testing or review, and never checked to see if the product could build. Of course, the developers met every milestone; the milestones were meaningless. This is an example of schedule chicken.
You may have also seen schedule chicken in project team meetings where the project manager reviews the major milestones with the project team. Then the project manager asks the magic question, “We're on target to make the release date, right?” Everyone seems to be nodding, or somehow agreeing with the project manager, but every single person in that meeting knows he won't meet this schedule. All you have to do is be ready before the last person who claims to be on time actually finishes.
Many projects have suffered from schedule chicken. It's very hard to speak up in a room of your peers, or worse, your managers, and say “Um, my part's not going to make it on time.” You look like the only one who can't keep a schedule.
Even if your management doesn't blame you for being late, you might feel as if you've let the group or the project down.
And if you're a developer with an impossible schedule, what hope do you have of injecting reason into the schedule? Most of the time you don't. So, you implement as much as you can, and claim you meet your deadlines. Or, you can do what another of my clients is noticing: in the last few days or the last week before the last time you can add new code to the system, all the developers check in twice or up to five times as much code as they've checked in during any other week. Even if you've been building every night, by now the build is broken, the testers are finding problems faster than before and the developers can't keep up with the fixes.
Schedule chicken starts when everyone is afraid to be honest and hopes someone else will blink first. Astute project managers recognize they need to gather more data than “Yes, I met my deadline.”
For quantitative data, I gather information about the date (planned and actual major and interim milestones), what's been created (feature set completed) and what's left to do (feature set remaining to implement), how fast we're developing and testing (velocity levels), and defect levels (open, closed, and remaining open problems. If you only measure the schedule data, you'll get schedule chicken every time.
I also measure qualitative information about the project. Anonymously, I ask people how they feel about their date commitments. The two measures I gather are percent confidence each person will make his dates, and each person's confidence in the overall schedule. The lower the confidence people have in their individual dates, the less likely the project will meet the schedule. The less confidence people have in the project schedule, the more problems there are in the interactions among people. As a project manager, you'll know where you have work to do.
When I manage projects, I want to know the reality of the project, whether I like it or not. I don't want to play schedule games with the project team, nor do I want them to play schedule games with me. And if you're in senior management, or are a project sponsor, don't make people “commit” to a project date they don't think they can make, because you're setting yourself up for schedule chicken.
© 2005 Johanna Rothman.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.