Schedule Game #6: Sweep Under the Rug


A few years ago, I received a call to help out a project in trouble. Unsurprisingly, when I was reviewing what had been done and what still left to do, the PM explained there were many half-implemented features. (The team had not been implementing by feature, but instead by architecture. Each architecture group had prioritized in their own way.) We created a list of things we would finish and a list we would postpone until the next release. The project finished.

I had suggested the team hold a retrospective, to learn what to do differently the next time. The VP didn't think anyone would learn from a retrospective. He said, “But the team did a great job. They did everything we wanted in this release.”

That's sweeping the problems — especially the changes in priority — all under the rug. Now management lacks credibility. And no one believes they did a good job. The project team is frustrated and tired. If they had known at the beginning that those requirements were unnecessary for this release, the developers wouldn't have started working on them.

Some ideas to avoid this game:

  • Rank the features to implement for a specific release. (Ranking means 1,2, 3, 4, 5, 6, …43, 44, 45,…)
  • Implement by feature.
  • Develop release criteria, so you have the conversation at the beginning of the project about what's needed for release.

These strategies for avoidance all require conversations at the beginning of the project with the project stakeholders. And those conversations are difficult. But the payoff is that no one has to pretend the project was successful. Instead, the project can focus on what's required for success and do that.

3 thoughts on “Schedule Game #6: Sweep Under the Rug”

  1. I agree with this strategy completely. The ranking of what’s important is critical, especially if the delivery timeline has narrow boundaries. We’ve just gone through this exercise for a .1 release of a new Sales Force Automation project. It was extremely helpful to focus on implementation of the feature set and let the architecture goals be secondary. I truly believe you can’t consider yourself successful unless the customer considers the product successful.

  2. Not only did they miss the opportunity to avoid sweeping problems under the rug, but they also missed the opportunity to really understand why the manager said the team did a great job. What was it about not delivering all the features that was (or wasn’t) important? In a retrospective, te team gets a change to assess the mis-cues, but also to dig into why things go right, when they do. Teams learn to replicate good stuff, as well as avoid familiar potholes.

  3. “Implement by feature”, in my experience, all too often becomes a game used by unscrupulous PM’s to play ‘kill the engineers’.
    Here’s an example of how to play this particular management mind game.
    Say the project has a large, complex engineering piece, ‘NLP core’.
    PM finds a trivial feature, ‘dialog box to select between British and US English’ that depends on the big one, schedules it, and then traps the poor, unassertive engineer into trying to do the giant piece on the small piece’s budget.
    My example’s exaggerated. If this is done on a smaller scale, it actually works.
    In the long run, of course, you burn out the programmers and they leave for a place without PM’s.
    Tricks like this are why I now always ask how project management is done when interviewing. I do this because I’m looking to see if there’s a ‘project manager’ involved. If so, I run the other way.

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: