Sane project planning pt. II: Against Wishful Thinking

If you want to keep your customers happy, one foundation that your product process needs is a shared understanding across your entire organization around at what stage of development can you commit to a release date.

When sales is involved, this also translates to: at what point can the sales team start selling a feature.

This should be something the entire organization knows and consents to, and should be built in to the process.

It might be okay to be fuzzy with ship dates on aspirational projects, but when people are betting revenue on a delivery date, we need to be really confident we can deliver.

If you pick a release date before you have even understood what you are going to deliver, you are setting yourself up for a high likelihood of failure and disappointed customers.

Classifying Deadlines

Some deadlines are nice-to-have. They represent goals chosen for some more or less arbitrary reason.

Some deadlines are do-or-die for external reasons.

I've seen situations where engineers don't know which are which until rather late in the game, because there was no established way to communicate that information.

That is, the process and tools used did not provide a canonical way to communicate that a task had external deadline pressure, so that knowledge existed only in out-of-band discussions. This leads to the people who know assuming that everybody knows. The problem comes when the people who don't know have no way to see that anything about this task is unusual.

Two bad tastes that taste worse together

Combining the previous two points: We should strive to avoid do-or-die deadlines caused by promises made prematurely or with insufficient information.

This is partly a matter of communication between business and product teams. This is why I get very nervous when quarterly features get announced at all-hands meetings - I'm afraid some sales or support staff members will tell a client or prospect that they can have something that might not even be possible. Ultimately the solution here is a culture that discourages this from the top down. I don't know of any shortcuts to maturity of that sort.

Tools

Tools can make things easier. If your project management tools provide you a good way to distinguish hard deadlines from soft deadlines, use it. If workflow is customizable, it's worth a little thinking about what's different between tasks that have external deadlines and tasks that do not. Perhaps you can configure slightly different workflow for the two.