Should You Under-Promise, or Over-Deliver?

At the end of the project, deliver less than you said you would and you are a bad software project manager. Deliver more than you said you would and you're the hero. Actually, you should strive to deliver exactly what you promised. No more, no less.

New project managers, eager to please, let business people/customers continue to add features, even as the team's capacity to deliver them shrinks. The business people, thinking that the project manger (PM) has things under control, takes advantage of this opening and the onslaught of new features continues.

Afraid to show weakness, the green PMs just sweat it out and hope they can deliver. But as the project end date draws near, it may become obvious that the features list will not be finished. The process of cutting features, not necessarily the newest additions, grudgingly begins. The formerly happy business people are now planning the termination, or at least the post-release punishment, of the project manager.

The experienced PMs know that they are going to have to be firm from Day One. Anything that resembles a new feature, or a change in scope, will be met with pushback from the PM. He/she reminds the business owners that only so many features will fit into each release*. If something new comes up, it must be deferred to a future release or substitute it for a planned feature.

The experienced PM avoids "High-Medium-Low" categorizations, as customers may mark everything a "High". They prefer a prioritized list of features based on business value. A good PM reminds the business owners that features at the bottom of the priority list may not get done this release if delays are encountered. These rules serve as an annoyance to the business owners, especially those who haven't learned that ramming in features won't work. Over time, they get used to the process and come to accept it as a fact of project life.

Of course, the experienced PM expects that changes are going to happen during the course of the project, and has built contingency time into the plan. This contingency is held close to the vest, sometimes not being revealed to the customer, or even the team. It is managed like a precious resource, and only features that survive the pushback battle get to eat into it.

When this does happen, the business owner is usually thankful that the PM finally obliged them. In the final days of development, if contingency remains, the PM might even opt to "open the reserves" and produce a few extra features. Some business owners might question why they couldn't have them earlier, but in most cases they are happy to receive a few extra, unexpected things.

Now the PM stands at the end of the release. The team has delivered on what they said they would. Sometimes they have provided extras. The business owner is happy, the team is happy, and the PM's reputation is intact. Let the end of release festivities begin.

• Release - At the end of a pre-defined work period, one or more iterations, the goal is to have the feature(s) (working code) of the software planned to be finished during that work period available for demonstration to the customer, or perhaps actual use by a limited user-group. This delivery of completed features is called a release in agile programming.