Voices on Project Management

> Back to Voices Home

The Danger of Being Too Productive?

| | Comments (4) | TrackBacks (0)
In the book Peopleware by Tom DeMarco and Timothy Lister, there's a humorous story about a project manager who--seeing the progress her team was making--knew she would deliver her project on time. With confidence, this project manager told management that she could guarantee the project would come in, as scheduled, by 1 March.

Management chewed over this unexpected good news and summoned her the next day. They told her that since she was on target for 1 March, they were moving up the deadline to 15 January.
I had a similar experience when I presented an initial update for a recent software project. I confidently explained to our stakeholders that the software enhancements for the common process tool would be delivered on time.

Sheepishly believing the stakeholders would be impressed, I waited for a compliment. 

Instead, the stakeholders proceeded to hand down a "schedule challenge" for the team to deliver three weeks early. Their rationale was that they wanted to capitalize on the team's productivity and wow the senior leadership team.
So, care to share your productivity war stories? 


Bookmark and Share


The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

0 TrackBacks

Listed below are links to blogs that reference this entry: The Danger of Being Too Productive?.

TrackBack URL for this entry: http://blogs.pmi.org/mt-tb.cgi/313

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.


Management-imposed "impossible" target dates tend to result in Project slippage beyond what would have been a "reasonable" target date due to all the bad practices employed in trying to achieve the impossible. But if management insists on a date, better to give them something by that date, if not the full scope.

Predicting the future is always a bit risky, so saying you are on track and have known risks under control is one thing, predicting you will definitely deliver is another.

That possibly sends a message of such overconfidence that the stakeholders believe you must have have tons of contingency time available and that your targets are in fact too low.

However, I suggest that the reaction you describe is the exception rather than the rule, except where a serious backlog of project work exists and stakeholders will, rightly or wrongly, take every opportunity to press more work into the same time frame. (Of course, this exception may seriously increase the incidence of this kind of stakeholder behaviour).

It is good practice (and part of the PMI code of conduct) to inform the stakeholders of the true status of the project, so that if in fact you can get more done without incurring other risks or penalties then they should be given that opportunity.

At the same time they should be given a new baseline to reflect the fact that being on target does not mean finishing early or even on target necessarily, and stating when the reasonable expected completion date with the new work will be.
They can then make an informed decision, whatever that will be.

Certainly makes me feel the good work ethic my parents instilled in me could get me into the same bind.

Schedule showed 10/1, management asked for 7/15, since "otherwise customer/partner will not move his ... to deliver their obligations". By increasing risk in times, by removing buffers, assuming and buying in promises that all 3 teams should work like a swiss clock, no obstacles or they should be removed in 24hrs, etc., schedule moved in to the desired date. On the next day it started t slip, but management blindly go for 7/15, despite for all warnings, escalations, resource burn. Since development were cut off from customer, no one told him, customer, about slippage...

At 7/15 customer was "disappointed". management - puzzled ("how dare you miss the date!").

At the end, project was released at 10/15. Almost in time by the original schedule.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll