Skip to content

About the author of Daydream Drift

Tomasz Niezgoda (LinkedIn/tomaszniezgoda & GitHub/tniezg) is the author of this blog. It contains original content written with care.

Please link back to this website when referencing any of the materials.

Author:

Managing Expectation Management

Cover image for "Managing Expectation Management".
Published

"Underpromise and overdeliver" describes a project management strategy, whereby the official delivery schedule is reserved in scope and any extra deliveries are non-binding and "gifted" to the client. It's a rule of thumb approach that is generally good to follow.

Failing to keep up with delivery often leads to some intense and even hostile scope renegotiations between the client and the deliverer. Oftentimes, the client still wants the missing features without paying more than initially agreed and the deliverer wants to be paid for spending more time finishing them. Such situations quickly and permanently tarnish a professional relationship.

But "underpromise and overdeliver" can be a risky rule in business-to-business deals when considered alone. In B2B, they key is to be predictable. The client needs to feel safe and comfortable working together. They don't want surprises one way or the other.

Once we’ve received a promise, we strongly expect it to be met but do not in any way anticipate more than has been promised. For this reason, doing what you say you will is clearly essential for maintaining your reputation but doing more is unlikely to win you additional points.

-- Why 'Underpromise and Overdeliver' Is Terrible Advice

The bigger the client, the more sensitive to unplanned changes they are. They do a lot internally that relies on trust and keeping to the mutually confirmed schedule. When the project is not delivered as planned (i.e. under- or overdelivered), it starts a waterfall of negative events at their company.

For instance, they may have a marketing campaign already planned or be preparing their DevOps team to join the project at a specific moment. It's rarely a fully transparent and obvious relationship between two entities.

It seems morally okay to overdeliver and show more progress. This choice is not always appreciated or rewarded in practice.

"Invest efforts into keeping promises, not in exceeding them," Epley concludes. "Behaving fairly toward others is the critical point. Beyond being fair, generosity does not seem to be valued as much as one would expect."

-- Why 'Underpromise and Overdeliver' Is Terrible Advice

An improvement to "underpromise and overdeliver" is having two pipelines or what's called a frontroom and backroom.

As a deliverer, try to manage the project like a restaurant. The client places orders at a table at the front and the kitchen at the back prepares food. The chef decides when to release ready meals to the client. Some are given right away while others are delayed ensuring a steady stream of food.

The client doesn't need to know everything going on in the kitchen and how things are prepared and organized.

The aim is to maintain a constant stream of high-value deliverables from the earliest step. The backroom shows the development and production cycles, which might well take longer than the duration of a step to produce. Ideally, the project manager will have step options in reserve so that any delays are not visible to the customer and the project team is given some flexibility to cater for any unexpected problems.

-- Principles Of Software Engineering Management

The approach also does a good job at completing large features, because they can be worked on for a longer time while others are delivered. And minimizes downtime caused by activities outside of the deliverer's control. Things, like waiting for a third party payments provider to validate the account for the project or for a design firm to complete mockups.