There are two extremes about this approach. On the one side is the management’s urge to shorten the project’s duration leading to unrealistically short schedules. Sometimes the developers (usually younger and inexperienced ones) get infected by the flowing optimism and make unrealistic estimates, which you know are impossible to meet. Then, when you make the final schedule you add some percentage of time (usually between 10% and 20%) to make sure that even after the management shortens your schedule you will still have the necessary time to complete the project on time.

On the other side there is a different story. Your team members are experienced enough, “old dogs” who know that whatever estimate they give, the management will cut it. Then they add this padding by themselves and their estimates become unrealistically longer. This way they want to make sure for themselves that after you or the upper management shortens the schedule, they will be able to fulfill their tasks within it.

And here are the questions I ask myself and because I can’t give a straight answer I want to put them to you:

• Do you know how your team members make their time estimates?
• Can you judge if their estimates are accurate?
• Do you know whether they estimate the tasks duration too optimistically or they put reserve time (padding)?
• Do you make any corrections to their estimates?
• Do you add your padding knowing that the management will shorten the schedule and will put you in a “Mission: Impossible” project or you shorten it by yourself knowing that your developers already had added extra time in it?

Thinking deeper a more serious question arises:

• Do you communicate your opinion within your organization honestly (your team members to you and you to your upper management) or you try to outwit each other?

I am waiting for your comments impatiently.

You may also find these posts interesting:

• Project Management and Hiking

He says:

Hiking requires Planning and Scheduling and Execution. Alternative plans are needed, alternative schedules always happen and alternative execution choices are always there. So what’s all the noise about Planning and Scheduling in agile software development?

And more:

Preparation is the key to a successful hike

Why wouldn’t…
Preparation be the key to success for a project?

To argue otherwise – that planning, preparation, sequencing, and execution performance management – is not needed is dangerous in the hiking paradigm. Why do we think these activities are not important in the project management paradigm?

Good questions to ask ourselves and especially those religious fanatics who claim that their extreme approach with no planning is always a better solution than the traditional management methodologies.

Read the whole article here.

You may also find these posts interesting:

• Krishna Kumar Did An Interview With Me On Software Development
• Top-down Planning – Good or Bad?
• Managing Padding in Time Estimates
• The Recommended Weekly Readings (2007-08-18). Project Management
• Project Management 3.0