I've been meaning to write a series of posts on schedule games, and a story I heard over the weekend has jolted me into writing about schedule chicken.
I'm most familiar with schedule chicken that happens in meetings. Usually in a project status meeting, with the project manager and the project team, especially where the meeting is a form of serial status, everyone claims they're on time. But the reality is that each person is waiting for another person to explain why he or she is not ready. In that case, each person graciously says, “Oh, that's fine with me if you take an extra week or two or three. No problem.” Of course it's no problem, if everyone else needs more time.
But I just learned of another schedule chicken. In this case, everyone claims to be on time. And, the developers are checking in code every night and building every night. But imagine there's a milestone, named something like “code freeze.” After code freeze, you can't add any more code, all you can do is fix the code that already exists. The day before code freeze, developers check in two to four times as much code as they had any of the previous days before. The results? Sure, you “met” the code freeze milestone, but the build doesn't work, or even worse, you can no longer build. You spend the next week or two (at one of my clients, it was up to three weeks) fixing the code just so you have a successful build. Now that you have a working build (some time later than the testers expected), the testers find all kinds of problems.
Schedule chicken occurs when PMs only measure the milestones (the date), and not the stuff that's created (the feature set) and the progress towards creating that stuff (velocity) and how good that stuff is (the defect levels) all throughout the project. If you know how much progress people are making, you can use your sense of smell to see if all those checkins were really to make code freeze, or were developers covering their tushes to meet the milestone.
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.
Great note. A version of this game, “Range Poker”, was played – and may still be – at missile test facilities during the run up to launch
Johanna,
Avoiding confusing dates with progress (maturing project) is the primary role of Integrated Master Plan / Integrated Master Schedule (IMP/IMS). Here’s my resource link (a bit out of date) http://www.niwotridge.com/Resources/PM-SWEResources/IMPIMS.htm
The primary outcome of IMP/IMS is the definition of “done” as described by the Significant Accomplishments and their Accomplishment Criteria. Tasks implement the criteria, but a secondary for assessing the maturing results of executing the project.
That way “tell me whate done looks like” is the starting point of the meeting. Play Chicken with the dates and durations is then more difficult.
Just remember – “You can con people into accepting a suicide schedule, but you can’t con them into meeting it.”
Measure progress or don’t measure progress, if you have a deadline people will (try to) game it. We might call this the ‘yacht race start’ game. Everyone tacks back and forth across the line waiting for the gun.
The damage here is not merely one of lack-of-knowledge of the state of the project. The bigger damage is that these dueling giant checkins generally result in far more broken code than an orderly process. So, not only are people less done than you think, the starting line process creates negative progress.