(^154) 97 Things Every Project Manager Should Know
Should You Under-Promise, or Over-Deliver?
Joe Zenevitch
New York, New York, U.S.
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 con-
tinue to add features, even as the team’s capacity to deliver them shrinks. The
business people, thinking that the project manager has things under control,
take 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 neces-
sarily the newest additions, grudgingly begins. The formerly happy business
people are now planning the termination, or at least the post-release punish-
ment, 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 substituted for a planned feature.
The experienced PM avoids “High–Medium–Low” categorizations, as cus-
tomers 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
- Release: At the end of a predefined work period, one or more iterations, the goal is to have the
feature(s)—working code—of the software available for demonstration to the customer, or perhaps
for actual use by a limited user group. This delivery of completed features is called a release in agile
programming.