Do projects ever end early?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.