Managing Product Development

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.