Project Management Stack Exchange is a question and answer site for project managers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When scheduling, I tend to add a lot of reality into the guestimates I am provided with.

I always add in generous amounts of probable sick days for manpower and extra time for integration and bug fixing. (All this based on decades of experience.)

As a result, my projects tend to deliver on schedule. But they never finish earlier than expected.

Now I'm wondering if the projects would deliver earlier if I didn't pad the schedule as much.

Would everything move a little faster if the teams had the incentive to meet deadlines based on the data they provided, as opposed to the padded ones I provide?

Or put another way: Does work expand to fill up available time?

share|improve this question
10  
I suppose it would be pouring salt in a wound to point out that cancelled projects end early. – Carl Witthoft Mar 15 at 11:39
8  
Hofstadter's law. :) – Iain Mar 15 at 23:14
1  
What do your reports think? Do they feel rushed? Do they feel like they have time to spare? Personally, I prefer not to be rushed, as I tend to burn myself out when in 'rush mode' for an extended period of time, but everyone is different. – Tyzoid Mar 16 at 15:02
3  
Perhaps instead of arbitrarily shorter deadlines, it could incentivize your reports to finish early and under-budget if you offer a fraction of the remaining budget as a bonus? – Tyzoid Mar 16 at 15:04
4  
I've had projects end before they even start!! Does that count? :-) – corsiKa Mar 16 at 15:18

14 Answers 14

While in most projects, the work can expand to fill up some or most of the 'extraneous' time, for many products things are simply done when they're done. In software development, when the product is feature-complete and all (sufficiently important) bugs have been dealt with, you're ready to release. The problem with software development is that there are a lot more variables and there is a lot more opportunity for external factors to affect the timeline.

In addition, if the padding on the estimate is done based on experience, that time is generally actually going to be needed unless there's nothing that goes wrong or takes longer than expected. That's why you've padded the estimate: in your experience, time X is usually needed in addition to the 'optimistic estimate' of completing the work in time Y.

So what would happen if you don't pad the estimate?

Most likely, the types of unexpected issues that you normally reserve extra time for will take place. Then the deadline approaches and, depending on how important it is to make that deadline, generally the quality of the product will suffer. In my personal experience, testing, bug-fixing and dealing with tech-debt are the first things to go if it looks like the deadline is in trouble. This view is supported by pretty much everyone I've ever come into contact with, but this may be a case of observer's bias or the like.

There's a reason why 'picking two' from the product management triangle is such a widely accepted concept. The basic premises: To produce a product of sufficient quality, three factors are involved: Cost, Schedule and Scope. Altering any of the three 'pillars' will have an adverse effect on either one or both of the other two pillars, or will it affect the quality of the product. Therefore, to produce a product of sufficient quality, at most two of the three pillars can be fixed but at least one must remain flexible.

This extends to the question at hand: by tightening the schedule you're increasing the stress that's placed on that pillar. This means that either it will affect one or both other pillars, or the overall product will be affected.

share|improve this answer
9  
I like that last part. Put another way: the variables are meant to be time, cost and scope, and the invariant is meant to be quality. Of course, as project management practitioners generally try to make the variables invariant, quality becomes the variable. – Robert Grant Mar 15 at 15:04

Parkinson's Law and Student Syndrome. These two concepts I believe truly impacts our work. There's validity in "challenging" the team by constraining the planning values that the team thinks they need to do the job. But it takes sophisticated analysis to understand that coming in late and over budget on an optimistic planning value could be indeed more favorable than coming in on time or even ahead of time on a pessimistic planning value. The on time and on budget metric rules us as project managers and feels better for customers, despite whether they paid the price for that metric.

Bragging being on time and on budget on all of your projects is an indicator that your projects are budgeted fat and happy, which to me, if true, is not a great achievement.

share|improve this answer
    
The suspicion that your projects are budgeted fat and happy is what prompted me to ask the question. – Danny Schoemann Mar 15 at 11:29
7  
Whether it is a great achievement or not depends largely on how we, as PMs, are measured... If my sole criterion is "Must deliver on time and budget" (as it often is) then I also plan F&H to meet that goal. It is the path of true PM happiness if you can get signoff for a F&H budget :) – Marv Mills Mar 15 at 12:12
    
You're right, Marv. People are way more comfortable with being on time and on budget despite that they may have paid more for it. In fact, the US government is moving toward fixed price contracts because of this very illusion, despite that they are loaded with contingency. Overall, those contracts will cost more money in the end. Very interesting human factors phenomenon. – David Espina Mar 15 at 12:15
1  
From a consumer point of view, fat and happy is expensive. And if you keep achieving your fat and happy values, that becomes your modal. It'll keep climbing from there because work expands. And, fat and happy is not necessarily tied to quality, as evidenced by monopolies. You have to win the work. – David Espina Mar 15 at 15:23
2  
Sometimes the customer is right to pay for a high probability of getting something by a specified deadline, in which case you want a PM who achieves that, even if they way they achieve it is fat and happy. On the other hand, if you're not really contingent on the delivery date then all else being equal you can take the PM who doesn't pad the schedule and gives you a median estimated date with a 50/50 chance of delivery before or after. Should nothing go wrong, that team will deliver cheaper and sooner because they won't spend contingency time on polishing that isn't strictly needed. – Steve Jessop Mar 15 at 21:52

Is it a good idea to try and use Parkinson's Law to increase productivity. No. (Disclaimer: I'm going to assume you're talking about software projects, not rock breaking or something)

Read an extract from the relevent chapter in the book Peopleware (actually, read the whole book, it's great).

To summarise, you shoudn't treat your staff as if they were lazy disengaged 'Parkinsonian workers'. If you do, you will probably end up with demotated, disengaged workers.

Moreover, the way you'd need to estimate work to motivate the Parkinsonian worker, is empirically ineffective compared to self-estimation:

Productivity by Estimation Approach Effort:

Estimate Prepared by    | Average Productivity | Number of Projects
Programmer alone        |8.0                   |19
Supervisor alone        |6.6                   |23
Programmer & Supervisor |7.8                   |16
Systems Analyst         |9.5                   |21
No estimate             |12.0                  |24 

Bigger numbers being better.
So it turns out *"Just wake me up when you're done."* works best.

It is however, a problem of long projects that people can lose track of deadlines. Perhaps a more iterative approach like Scrum would help here. Also the issue of "padding" goes away, as commitments are made by the team based on iteratively improving evidence of what has quantity of work has been completed before. This would also allow to realise the proven advantages of your team planning and estimating their own work.

Additionally, an iterative (continuously releasable) approach offers the only real chance of "finishing early". If you find out from your users that you have met their needs before finishing all the planned features (everything you thought we necessary at the start), you just stop.

share|improve this answer
1  
For completeness: that table is the result of Data from the University of New South Wales - Michael Lawrence and Ross Jeffery of the University of NSW conducted a survey of 127 projects in 1985. – Danny Schoemann Mar 16 at 11:34

Why do you think an artificial deadline will act as an incentive? In my experience (and Dilbert's), the worker bees can sniff out a fake deadline in minutes, and pretty much ignore it unless there's a threat of layoffs. On the other hand, as is often done in major infrastructure contracts (USA), if you provide a cost-bonus incentive for beating a deadline, you may find success.

share|improve this answer
    
It's interesting that you call it an artificial deadline when it's based on their own data (without my padding). +1 for the cost-bonus incentive idea. – Danny Schoemann Mar 15 at 11:56
2  
Teams will use the word "fake" if it is a planning value they don't like, despite it being perfectly reasonable. Work is not deterministic; it is probabilistic. As long as the PV is somewhere in the distribution, it is not fake. Moving left and right along that distribution is only about taking on more risk or avoiding risk. – David Espina Mar 15 at 12:07
2  
@DavidEspina In theory, yes. In practice, many managers set a deadline based entirely on "making the sale," without regard for risk. – Carl Witthoft Mar 15 at 14:07
    
Price to win! Very true, Carl. – David Espina Mar 15 at 15:06

If you don't pad the estimate, you'll be forced to manage risks.

Padding the estimate is merely a coarse strategic reserve of time. Not sure how you do the pad, but I understand it is common to inflate by some margin (e.g. 20%)

The alternative is to estimate each work package and explicitly discuss the worst, best, and probable case. Then sum those up for a projected delivery date, and use the worst & best cases to perform a monte carlo analysis and build a confidence estimate. ( There is an 80% chance we will be done within 3 weeks of Date X). As time goes by and you complete work packages, your confidence estimate will narrow.

As risks arise and issues manifest, they'll influence your schedule, but you'll always be able to express the impact of any event in terms of the delivery date and the confidence estimate.

share|improve this answer
    
You could use a P30, 40, or 50 planning value and keep additional time off of the PMB. That way, the team marches to the optimistic value but you have the reserve in place in the event they cannot make it. If held off the PMB, then maybe Parkinson's and Student could be minimized. Maybe. All theoretical, though. +1 for the strategic reserve. – David Espina Mar 15 at 15:19

YES, PROJECTS DO END EARLY when they avoid "classic mistakes", do all the fundamentals of development, and also correctly apply "best practices".

I remember reading Steve McConnell's "Rapid Development" and I remember reading in it about some project "Orbit" at IBM that FINISHED EARLY and with 1% of the defect count normally associated with a 500K line project.

How did they do it?

They had 12 levels of code inspections, and code inspections are notorious for:

  1. finding bugs
  2. increasing learning

So indeed, some projects -- namely those that are managed exceedingly well by including numerous "Best Practices" like code inspections, while studiously avoiding Classic Mistakes of software development -- do end ... early.

share|improve this answer

Based on my experience as a developer for over 15 years, if there seems to be ample time in the planning to deliver, then it is quite common that developers lose focus a bit. They might be tempted to add a bit of gold-plating here and there and postpone the unpleasant tasks a bit more. This has the overall effect that (nearly) the full estimated time gets used up, even if the task could have been finished much earlier.

One mechanism that seems effective in countering the slacking off of the developers is to reduce the "available time" for the various tasks.
After making the estimations as usual and adding the overhead that experience has told you is needed, you take about 20% off from every task and you use that 20% for an "emergency buffer" that the project can eat into if certain tasks happen to be severely underestimated. This whole process also gets communicated to the developers, so they know that an overrun of a task doesn't immediately jeopardize the deadline, but it turns out that most tasks can actually be completed within the 80% time, because people instinctively try to stay under the scheduled time.

The 20% buffer appears to be around the figure where slacking off/gold-plating is significantly reduced, but high quality can also be maintained while working at a sustainable pace.

share|improve this answer
    
+1 for the fascination view from the other side! – Danny Schoemann Mar 15 at 15:04

Given no scope creep and in an ideal world, a project will end when all work on that project, foreseen and unexpected, has completed. Therefore a project will end early if the delivery timescales forecast by the Project Manager were greater than that actually needed. The trick is always, of course, knowing in advance how much time to allocate for all the tasks on a project and take into account unforeseen tasks.

This is a practical impossibility.

All a PM can do is use experience and judgement to plan a delivery according to best or most-likely estimates and risks. Personally I don’t pad resource estimates in my plan- I use the effort estimates given to me by the people who are best placed to estimate the work. That way you can learn from variances on a task by task basis. I do, however, include schedule contingency wherever I think there is likely to be material variance in forecast versus actual effort or timescales. In other words I add “buffer” durations into the overall plan, at judicious points, for absorbing additional work caused by estimate uncertainty. How much buffer to add, and at what points in the schedule, is part of the art of the PM planner and the more experience I get with more diverse deliveries the better I get at it.

The other side of that coin is the budget contingency- if you extend work into “buffer” zone because things take longer, then you are going to use more effort, and burn more resource than forecast. There is no point allowing schedule contingency without also allowing budget contingency so I tend to make an allowance in the budget for additional workload into the schedule contingency zones, even though I don’t know at the beginning what the effort will be spent on.

So my version of “Fat and Happy” planning is to allow time in the schedule for unforeseen things to happen (they always do), or some tasks to overrun (there are always some), and allocate budget to cover these things (it’s always needed). Accordingly, the work in my plan always expands to fill the time I have allowed. As I have said, the art is in knowing how much contingency time to allow and at what points in the schedule. Not enough and you are into compressed timescales, pressure, stress, cutting scope or quality. Too much and you are over-charging your client for the job.

That’s in an ideal world with no scope creep. In the real world, with changing requirements and scope, you need to foresee the amount of change likely to arrive in the project and also plan for that, however you can take a risk-based approach to that and add schedule and budget contingency accordingly to cover a certain level of change. Then if there is more change you manage accordingly- use more of your contingency or take it back to the Project Board for more budget or timescale as appropriate and as driven by the change process, not by any knee-jerk reactions or difficulties.

share|improve this answer
    
Nice approach! Pad the schedule, but not the individual task, thus keeping the pressure on the original estimates. (Did I get that right?) – Danny Schoemann Mar 16 at 11:36
    
Yes. I find it to be the best of all worlds planning-wise, but it does take some experience of the projects in-hand to become effective. – Marv Mills Mar 16 at 11:37
    
Marv, I am a bit confused on this. I think contingency lives outside the PMB in all cases. But if you look at an estimate distribution of any given task, what percentile is considered "padding"? – David Espina Mar 16 at 11:46
    
PMB=Project Management Board? Not sure what your question means. I am talking about contingency I allow in the planning and scheduling, notably as part of the initial project delivery estimates (timescales and effort). On your second point, there is no fixed percentage in my planning method, I add schedule contingency into the plan based on contextual need. I never use a percentage, I find that meaningless. YMMV. – Marv Mills Mar 16 at 11:55
    
Performance measurement baseline. On the percentile, I mean this: let's say you estimate a task to take between 6 to 15 days, with a modal of 9. Let's say I want to be at a 50th percentile, or P50, my planning value would be around 10 days or so. If P80 I might be around 12. If I choose P80, am I padding? – David Espina Mar 16 at 14:21

If you have not read Steve McConnell's Software Estimation, I highly recommend it. While there are a number of excellent insights on how to do better estimates, the most value to me was the demonstration of how hard it is. As is well known, developer estimates are typically "best case" scenarios. Unfortunately, life isn't.

share|improve this answer
    
+1 for the recommendation. IMHO developer estimates are more optimistic than best case as they forget integration and the fact that they don't work on the project 24/7 or even 8/5. :-) – Danny Schoemann Mar 15 at 15:01
    
@DannySchoemann That is why all my estimates are in terms of "number of hours working on project" – shelvacu Mar 15 at 19:00

Let's define "early" as not using up contingency time.

The degree to which an activity expands is largely a reflection of how well its process is defined. In my career I have played the roles of both software developer and project manager. As a software dev, I usually have a great deal of latitude as to how I do my job and the process I follow can range anywhere from economical to "gold-plated", and with no other constraints, I'll go with gold-plated if I have time.

As a project manager, I work with my software developers to nail down their process. I don't want to blindly squeeze by setting deadlines, but instead experiment and innovate to find a process that delivers acceptible quality. Over time, you can refine the development process to make it more predictable - the team (both pm and devs) begin to understand where in that range of quality their work needs to be. With that predictability comes the ability to end without needing contingency.

share|improve this answer

One of two things is true: either you'd deliver on time even if the schedule was one day shorter, or you are always so accurate in your predictions that you set the schedule to be precisely the minimum needed and not a day less. Decide for yourself whether you think all your planning and your contingencies are really that accurate.

Often there's an intrinsic unpredictability in the amount of time the work will take (you mention sick leave for example: the smaller the team the less predictable this is, and that's even before you consider the actual work to be done). You allow "enough" contingency to have a very high confidence of delivering on time, and then even on projects with lower-than-average sick time, you still don't deliver early. This should tell you that some form of Parkinson's Law is in effect: no matter how good you are at estimating time you are not subconsciously predicting how much sick leave your staff will actually take and adjusting your estimate elsewhere without realising it. Rather, the team is working to the deadline.

In practice if you set a shorter schedule then you and your team would probably find a way to hit it. But eventually you'd also probably see a slightly higher rate of missed deadlines, shipped defects, silly amounts of overtime and/or negotiations for reduced scope, because you're taking more risk by leaving less contingency.

The reason projects rarely finish early is that there's rarely nothing that could be done, at the moment of completion, either to improve the project or to increase your confidence in its correctness. So time budgeted is generally spent even at a point of somewhat diminishing returns, and the last-minute details usually aren't put on until close to the last minute. You can address this with a more rigorous definition of done, that doesn't allow people to do "better than done" just because there happens to be time available, and doesn't allow people to do "worse than done" just because there happens not to be.

Furthermore, if you plan for people to put in a little bit of overtime at the end of the project, or to delay non-project tasks as the deadline approaches, then again your project will inherently show a certain amount of "rubber-banding". If it's looking like you'll come in early you won't ask for the overtime and you won't put off that stack of filing until next week. This is why Parkinson's Law applies to some extent even in a well-functioning environment.

share|improve this answer
    
Interesting approach, though I'm opposed to working overtime in general, and wouldn't consider it as part of any project planning. – Danny Schoemann Mar 16 at 11:51
    
Yes, I'm not recommending this, just observing that it's a thing that some people do and that it contributes towards deadlines being self-fulfilling prophecies. I've pretty much given up claiming that any need for overtime represents a failure, because approximately nobody believes me on either side of the management line ;-) – Steve Jessop Mar 16 at 12:29

A question is: How do your developers use the "extra time" ? Which corners would they cut, if this extra time was not there?

In my experience, "cutting corners" often means poor test coverage, poor architectural quality, edge cases not properly covered, possibly security vulnerabilities. This was already mentioned as "technical dept" by @Cronax above.

Another problem is that developers have no time to learn, if they are constantly on a deadline. They will not have time to try new things, and instead stick to known, possibly outdated, solutions. This could be called "experience dept", or "edcucational dept".

On the other hand, there is a risk that developers might "slack off", and do things that are nothing but a waste of time.

Imo, a good idea is to allow the time for decent code quality and learning, but avoid feature creep. Architectural quality and simplicity should be present throughout the project development. But optional features, and anything which adds complexity and increases maintenance cost, should be added as late as possible.

share|improve this answer

People will under-promise and over-deliver, but PMs can coach them through providing accurate estimates.

Padding the tasks leads to student syndrome. Instead, use a buffer task at the end of the team's workstream and another one at the end of the deliverable critical paths (right before the milestone). You can base buffer hours on known risks and unknown risks (complexity * percentage of summary task with no risks or padding).

Decrease the team workstream buffers if the take longer than planned, keeping the summary task at equilibrium. Decrease the deliverable buffers to keep the milestones at the same date.

Starting to use a buffer should trigger corrective action. Using up a buffer completely should trigger a change request.

share|improve this answer
    
+1 for student syndrome. Question: Using up a buffer completely should trigger a change request. Change request? From who about what? I'd appreciate if you could elaborate why it's a change request. (As opposed to a red flag that project is slipping over schedule.) – Danny Schoemann Mar 20 at 9:32
1  
@DannySchoemann Good question and I overlooked this in my answer. It depends on the nature of the project and how critical it is. You'll want to agree on the science behind color indicators and change request triggers before you start executing. As an example, when starting to use a buffer, mark it as yellow. When you've used up a buffer, mark it as red. The change request could be reserved for changed dates in final deliverables. Introduce pain for resources who are late to keep them accountable. Being on time for Danny's project is not optional! – Hey Romey Mar 21 at 16:15
    
@DannySchoemann To my company, yellow means slip in progress. Red means slip complete (which is a bad thing). – Hey Romey Mar 21 at 16:26

This is a quite interesting question, since I was reading some articles regarding the same topic a few days ago. My answer, from my humble personal experience and what I have read, is that human psychology tends to always take into account deadlines.

There are always deadlines. We go from one deadline to another, on everything we do. The big problem is that most people have the inheritance to speed-up on dates close to such deadline. The extra stamina you get in that moment makes you two or three times more efficient.

Of course, there are people that are really good at managing their time, following the simple mentality of "what can I do today that saves me time tomorrow?", but unfortunately these are rare cases, even more in the IT world.

Furthermore, in a business, delaying deadlines does not make any sense. Companies that cannot accomplish the deadlines simply reduce the features being provided to the client. This always tends to happen.

What refers to planning, I would avoid using time measurements such as hours, weeks, etc. As you mentioned, the problem with such measurement is that you have to take into account activities that are inherent from software development (e.g. bug fixing), and the condition of the workers. Instead, I would use a fuzzy measurement done by myself, with my own time units, that just rely on comparing tasks. A task of size 2 should have the simple explanation of "it takes double the time that it takes to do a task of size 1". That way, you can get a more specific view of the amount of time necessary for each task.

Therefore, to conclude this answer, you should be able to set your deadlines efficiently, in order to balance working-time and the quality of your product. At the end, the way you set your deadlines will determine the time it takes to achieve them, and not less.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.