Estimates, Schedules, Assumptions and Risks

"Though life is made up of mere bubbles, 'Tis better than many aver, For while we've a whole lot of troubles, The most of them never occur.”
                                                                                                - Nixon Waterman

With this post I conclude the series on scheduling and estimating that started with the basics of scheduling.  I hope that this series has successfully drilled into you that offering an informal estimate, without including all of the elements for success and properly qualifying the estimate with assumptions or risks, is an eventual path to damaging your credibility and the credibility of the PM profession.  Estimates should almost universally be presented as ranges with statistical probabilities.  (It’s a real disgrace that our tools generally don’t provide this capability.)

Estimates should always include estimating assumptions.  This is not a CYA point, but rather the estimating assumptions further clarify the scope and scope boundaries, establishing basis for (project) change control.  Change Management is a topic that I haven’t developed yet and is a good one for a future series.  Stay tuned for that one.

A well-formed schedule takes work to produce.   When done well it has a rational basis and a foundation in science.  And despite all that, it is still subject to failure.  That is no excuse, though, for us not to do the work that our profession calls for.  In fact, it is the reason that we should be as rigorous as possible in our duties.

Starting with my next post, I’m going to cover a few miscellaneous topics for a few posts before starting a new series.

What estimating and scheduling issues do you experience that I have not addressed in this series?

© 2013 Chuck Morton.  All Rights Reserved.

Estimate Confidence Buffers, Risk Buffers and Management Reserve

"If confusion is the first step to knowledge, I must be a genius.”
                                                                                                - Larry Leissner

We’re nearing the conclusion of this series that started with the basics of scheduling.  I want to tie up a few loose ends, maybe clarify some inaccuracies and address some confusion I may have introduced.

As I developed this series on scheduling, leading up to the previous post on estimate buffers, I hopefully offered convincing arguments for including appropriate buffers.  In this post, I want to compare and contrast various types of buffers that are common.

I think the discussion I offered on risk buffers is consistent with other authors and industry practices, so I won’t belabor that discussion.  I will point out that risk buffers are included in the project (time and cost) budget and are managed by the Project Manager.

Literature and practices for improving estimate confidence are much rarer.  Therefore, there may be some stakeholder pushback for including these buffers in the schedule.  However, you can demonstrate through logic, reason, science and ethics that, in order to have a realistic schedule, these buffers, like the risk buffers, must be included in the schedule.  Like risk buffers, these confidence buffers are included in the project budget and are managed by the Project Manager.

However, you don’t want to “double count” your risks.  Let’s say you do a lot of similar projects.  For these, there will probably be a common pool of risks that are included.  However, if your estimates are based on historical results and sometimes these risks occur, then there is the potential that your Pessimistic estimates will already account for those risks.  You will need to adjust either the estimates or the risk buffers so they are in the schedule only once.

In contrast to the confidence and risk buffers, some PMs Pad their estimates.  Some project managers, after over-running the project schedule a few times, learn that their estimates are never sufficient and start adding arbitrary amounts.  “We go over by 20% every time, so I’ll just start adding 20% to the schedule.”  This may sound logical on the surface, but is actually bad for their credibility and for the PM profession.  (Look for more discussion on this topic in a future discussion of The Toyota Way.)  Stakeholders learn that the PM is padding and, in response, start cutting the budget or otherwise compensating.  Pad is Bad.

In contrast, neither confidence buffers nor risk buffers are arbitrary.  Hopefully, if you’ve followed the discussion this far, the reasonable, logical and scientific justification for including these in the project are thoroughly explained and documented.

One last buffer that is sometimes seen in large, third-party project contracts is Management Reserve.  Management Reserve is separate from and distinctly different than estimate confidence buffers, risk buffers or pad.  Management Reserve is contingency funds allocated for use by the contract owner (sponsor).  These funds are not part of the project budget and are not available to the Project Manager except after approved project change control to authorize allocation to the project.

I hope this series has been interesting and informative for you.  One last remaining post and then we can move on to new topics.

Was this discussion scheduling and estimating clear and thorough?  Is there anything I missed that you would like me to address or anything that is still not clear that I should expand on?

© 2013 Chuck Morton.  All Rights Reserved.

Estimates & Buffers

“A clever person turns great troubles into little ones and little ones into none at all.”

- Chinese Proverb

If you’ve been following the series on the well-formed schedule and the subsequent series of posts, you are aware that from the WBS you create estimates and iteratively refine those estimates by, for example, improving the probability of success and compensating for risk.  One of the PM challenges is how to balance motivating task owners, setting appropriate stakeholder expectations, reporting honestly and doing all of this in a forthright and ethical manner.

To demonstrate, let’s use our example task from Risk Buffers – An Example.  You might estimate that your Most Likely time for the commute is 30 minutes and the Optimistic time is 20 minutes.  However, the Expected (Mean) time might be calculated as 35 minutes (this is the 50% probability of success, where you’re as likely be early as late).  If you toss in one standard deviation to get to a 65% probability of success or two standard deviations to get to a 95% probability of success, the estimate could balloon to 45 or 55 minutes.  On top of this, then, you add those risk buffers, which might add 10-15 more minutes to the estimate.

Let’s take a look at this from your perspective with several of the stakeholders to examine the conflicts.  First, with the task owner:  Physics and Theory X management say that if you put that high estimate on the task, the task owner will take all of it.  In order to motivate the task owner, it is necessary to use, for example, either Most Likely or Expected.  In fact, I’ve managed projects in organizations that insisted that I use the Optimistic estimate and “stay on those team members” or they would just slack off.

Now looking at this from the perspective of your relationship with the project owner or sponsor, if you fill the schedule with fully bloated tasks (“What do you mean it’ll take 65 minutes to drive to the office!  I know full well it only takes 30 minutes.), you’ll lose all credibility.  However, if you use only Optimistic (!) or even Most Likely or Expected estimates, the end (date or cost) is not realistic and you’ve set yourself up for failure (as documented in The Schedule – Probability of Success). 

Some stakeholders want to know when it will really be done and how much it will really cost.  And they want to have realistic progress updates on these realistic completion values.  If you are not using fully weighted estimates, your reporting to these stakeholders will not be accurate.

Finally, another stakeholder that you have to true to is yourself (and the PM community).  How you address these conflicts must be ethical.

The conflict then is how to have individual task estimates that are under-weighted, but have the overall project estimate include the probability of success and risk adjustments.  The solution, of course, is to have “tasks” in the schedule that represent these estimating and risk buffers.  So let’s say you create these buffers and put them all at the end of the schedule.  This also creates reporting problems because there will be the appearance, at the start of the project, of a large gap between the end of the last deliverable and the end of the project.  It will appear as you progress and report completion of deliverables that you are (most likely) late on all of the deliverables.

At a minimum then, you need to distribute these buffers into each deliverable, spreading them over the life of the project.  You, as project manager, own these buffers and you have to deplete them as you go, continually reassessing much has been consumed by actual task overage and underage.

Since these buffers are included in the project (cost and time) budget, they cannot be arbitrarily reduced, eliminated, increased or created except through formal project change control.  They can (depending on the rigor of project change control) be moved between deliverables, but this should be documented.

Before closing I want to mention that the book Critical Chain by Elihayu M. Goldratt describes a formulaic approach to determine the appropriate amount and placement of the buffers.  This approach has been successfully used in many organizations and should be considered as an alternative to the custom and complex approach to buffers I’ve presented.  Further, he goes in to much more detail on the operational practices.

In my next post I’ll conclude this series on buffers and then we can move on to some new topics.

What challenges have you had convincing stakeholders to use realistic schedules?  Do you get pushback that you are just padding your estimates?  How do you handle it?

© 2013 Chuck Morton.  All Rights Reserved.

The Schedule – Improving Estimate Confidence

“My own idea is that these things are as piffle before the wind.

                                                                                                - Daisy Ashford

My previous post on the probability of schedule success, as pessimistic as it was, still left something hanging.  I talked about estimating an individual task to a 50% or 90% confidence level.  Is that just bunkum or is there a way to really get that kind of confidence?

Well, there really is, but a stated confidence level is just a piffle unless the techniques described in this post are used.  My post today is how to really get that level of confidence and how to recognize when it’s real.

The first step is to produce three estimates for each task.  This is not the same as Delphi estimating method, getting estimates from three experts.  Instead we’ll use the PERT three-point estimate, as mentioned in The Schedule – Estimate Task Effort.  For this exercise, the task estimator produces three independent estimates:  an optimistic estimate (O), a pessimistic estimate (P), and a most likely estimate (L).  The expected time is then calculated as E = (O + 4L +P) / 6.  So, if the optimistic estimate is 3 days, the likely estimate is 5 days, and the pessimistic estimate is 13 days, the expected time is (3 + (4 * 5) + 13) / 6, or 36/6, or 6 days.

Next, calculate the standard deviation using the formula SD = (P – O) / 6, or 1.67.  From these two values, we can now produce an estimate to the desired confidence level.

So, the 50% confidence level is determined using the expected time calculation above, or 6 days in this example.

The 84% confidence level is one standard deviation (4.33 – 7.67 days, or, rounding up, 5-8 days).  A confidence level of 98% is achieved by going out two standard deviations, or 3-10 days.  You can even get to a better than 99% confidence level by going out three standard deviations (1 – 11 days).

However, this only gets the individual tasks up to the target probability of success.  As noted in my previous post, the project’s probability of success is determined by multiplying the probabilities of the critical path tasks.  If you have ten critical-path tasks in your project and you estimate each task to a 95% confidence level (two standard deviations), your project still only has about a 62% probability of success.

To get the project to a 90% probability of success, you have to get each task up to a 99.7% probability of success (three standard deviations).  (This will actually get this example project up to a 97% probability of success.)

In my next post, I’ll provide some example numbers to demonstrate just how significant this is.  Which will also show why we as PMs woefully underestimate our projects, why we have such a dismally Chaotic success record, and why attempting to fix it will receive push back from our stakeholders.

CAVEAT:  This math works for standard distributions (you know, those bell curves).  Task estimating is not a standard distribution; the curve is compressed on the left and stretched on the right.  There is a formula/ process for converting a non-standard distribution to a standard distribution, but, even without that, what I’ve described above is still a vast improvement over the typical schedule twaddle.

How often do your projects complete on schedule.

The Schedule – Probability of Success

"Try not to become a man of success, but rather try to become a man of value.”

                                                                                                                - Albert Einstein

I completed the series on the well-formed schedule, but the final post, on adding risk buffers, was pretty light.  I want to take a couple of posts and expand on the topic of risk-based or risk-adjusted scheduling, which also will start some interesting metrics discussion.

How tough is the job of project management?  Planning a new project, the PM prepares a schedule that documents months in advance a completion date.  What is that PM’s probability of success?

It turns out that this is a fairly easy mathematical calculation.  If you have all of the tasks estimated and know the probability of success for each individual task, then you can calculate the project’s probability of success – the probability of completing the project on schedule.  You merely multiply the probabilities of success for each task (in the critical path) together.

For a simple example, if you have a 10-task project (each task in the critical path) and you’ve estimated each task with a 50% likelihood of success (i.e., equally likely to finish early or late), then the likelihood of completing the project on time is 0.50 x 0.50 x 0.50 x … or 0.50¹⁰ or 0.09.8%.  With a very simple project, you have less than 1 in 1,000 likelihood of completing your project on schedule.

Even if you upgrade the individual tasks to a 90% probability estimate, you only have a 35% chance of success (1in 3) in this example.  And with each task you add, the probability of success drops proportionately.  To emphasize the point:  even when you use aggressively conservative scheduling, you will miss the date more often than you hit it.

In other words, we’re screwed before we start.

This sounds very pessimistic.  What are the best practices that can improve this performance?  I explore that in my next post.  Stay tuned…

How do you generate estimates on individual tasks?  What is your expectation for the task success?

The Schedule – Risk Buffers

“The first step in the risk management process is to acknowledge the reality of risk.  Denial is a common tactic that substitutes deliberate ignorance for thoughtful planning.”

                                                                                                                - Charles Tremper

With this post, we conclude the series on developing the well-formed schedule.  We have taken the WBS, which defines the project scope, added the task dependencies, estimated the effort for each task, assigned resources to each task, and resource-leveled the task assignments.  The final step to complete the well-formed schedule is to add risk buffers so that the schedule has the intended probability of success.

A schedule without risk buffers has virtually no probability of success.  Since you probably want to present a schedule with some probability of success, it obviously follows that you must add some risk buffers.  So now you probably want me to tell you how many and where.

I’ll briefly identify two common practices for identifying risk buffers.  The first is built from the standard risk management process.  The PMI PMBoK risk management process includes the step “Quantify risks.”  You’ve probably wondered what this means.  For risks that should be mitigated, determine the probability of occurrence (a percentage) and the time and cost that must be added to the project if the risk event occurs.  Let’s say for a specific risk you determine there’s a 25% probability that it will occur and that if it occurs it will add 12 weeks (I’m just going to deal with time in this example, but you can extrapolate for costs) to the schedule.  The 25% probability times the 12 weeks is 3 weeks, meaning that you should add a risk buffer of three weeks to your schedule.

Depending on a variety of factors, you can either add all three weeks to the end of the schedule or spread it in appropriate points over the life of the project.

You repeat this for all significant project risks.

A very common alternative to this approach is to use the Critical Chain approach developed and promoted by Elihayu M. Goldratt.  It uses a formulaic approach to determine the appropriate amount and placement of the risk buffers.

This overview is obviously too high a level for practical application.  But with this post I’ve finally presented enough of the PM foundation so that I can introduce some of the more interesting and complex concepts.  I’ll do this starting with a couple of posts on advanced quantification of the schedules, then maybe transition to more fully explaining the development of risk buffers.

It’s taken me two years of posts to get to “the fun stuff.”  What area of project management best practice would you like me to tackle?

The Schedule – Resource Leveling

“Happy people plan actions, they don’t plan results.”

                                                                                                                - Dennis Wholey

We are nearing the end of the series on scheduling basics.  We have taken the WBS, added the dependency chain, estimated the effort and assigned resources.  The next step to completing the well-formed schedule is to level the resource assignments.  This is done to:

• Prevent over allocation of a resource within the project
• Prevent over allocation of a resource across enterprise assignments
• Accommodate non-productive time and absences

First, let’s assume the project is in an organization following best practices.  In that case, all team members record all of their time each cycle to specific project tasks and to operations, administrative, absence, and other non-project activities.  Your project management software integrates with these time records (or time is entered directly into the software, such as Sharepoint wih MS Project EPM, Clarity or Primavera).  In this case, you already have all of the elements in place to just “push the button” on your project management software to resource level the schedule.  You will then want to review and fine tune the results.

On the other hand, if you do not have the luxury of these conditions, you have more work.  For example, you will have to tune and adjust using heuristics to get the right productivity factor so that you don’t over allocate resources within the project;  and it will be much harder to track other assignments and activities to prevent over-allocation across enterprise activities.

In either case, this step will be repeated regularly over the life of the project.  Rescheduling and replanning are regular activities in the Project Manager’s Cycle.

In my next post, we’ll conclude this series of posts on the basics of creating the well-formed schedule by discussing risk buffers.

If you are not in a “best practice” environment, what steps do you follow to produce a resource-leveled schedule?

The Schedule – Resource Assignments

“Time is the scarcest resource and unless it is managed nothing else can be managed.”

                                                                                                                - Peter Drucker

We are now half way through the steps for creating a well-formed schedule.  In my previous post in this series, we added task effort estimates, but we have not yet added resource assignments, which we will now do.

Why add task estimates without considering the resource assignments and then immediately follow that step with the step that adds the resource assignments and then re-estimate each task specifically for the resource?  Let’s consider three scenarios:

For a small, routine project in a fully staffed environment, assigning resources may be a mechanical exercise (you’ve probably done this same type of project so often, the WBS was built practically from a template and you know exactly who is doing each task).  I’ll come back to this first scenario later.

A second scenario is more common:  It is a large project, but some of the resources are known (or the resource skill is known and easily acquired).  However, for some tasks, there may be choices or the resource may not be known until late in the planning cycle.

A third scenario could be a large project, but it is one where the resources are definitely not known and there could still be many negotiations about staffing options.  In fact, the budget, schedule and scope could still be under negotiation.  But a time and cost schedule is needed to get approval to acquire the resources.

For a best practice recommendation, it must be general to all possible cases.  Since it isn’t always possible to know the resources and sometimes it is necessary to have estimates without resources, the general case is to first build the schedule with estimates but not resources.  Then when appropriate, add the resources and re-estimate.

For the first scenario, you certainly can combine these two steps.  Just understand that you are taking a short cut and that in other circumstances or a different environment you will want to follow the best practice.

Getting back to this step, then, you have a partially built schedule with dependencies and estimates, but no resources (or possibly generic resources).  So start assigning resources to tasks (or substituting resources for generic resources), ignoring, for now, resource conflicts and over-allocations.  For each resource assignment, review the task (inputs, outputs, work products, completion conditions, etc.) with the resource and have them re-estimate the task based on their understanding.  Review with the resource any task where there is a significant difference between the original estimate and this new estimate to understand why.  Update the task estimates with these revised values.

Don’t be surprised to find that the new estimate from this step is significantly different from the previous estimate and that you may need to renegotiate budget and scope expectations.  You may even find that as you complete some resource assignments, it forces changes to other previous or planned assignments.  And be prepared for even more variance in the next steps.  That’s why this is a recursive process – it seems like you just keep starting over from the beginning.

But actually, we’re up to Resource Leveling, the next to last step in building the well-formed schedule.  This is the subject of my next post.

Do you have resources estimate their own tasks?

The Schedule – Estimate Task Effort

"If you are distressed by anything external, the pain is not due to the thing itself but to your own estimate of it;  and this you have the power to revoke at any moment.”

                                                                                                                                - Marcus Aurelius

As we progress through this series on the well-formed schedule, we have taken the WBS and added the task dependency chain, leading to the next step:  estimate the effort for each task.  Whole books have been written just on estimating, and I’m not about to attempt to tackle the depth and breadth of the subject in this post.  Today I’ll focus on pointers and essentials.  I expect a number of future posts on estimating.

This post – in fact, this series of posts – is about developing the well-formed schedule.  It therefore describes best practices and assumes you are using best practices.  Specifically, that you are using task effort estimates.  I have dabbled around the topic of effort versus duration estimating in several previous posts, but have not focused on it specifically.  And it is too broad a topic for me to address it satisfactorily today.  For now, if you are using duration estimates instead, it severely limits the benefits of your scheduling tools.  I’ll come back to the topic of effort versus duration estimating in a future (series of) post(s).

Stating the blatantly obvious, since we’re developing task estimates from a WBS, we’re well beyond the stage of Rough Order of Magnitude (ROM) and top-down estimating.  However, we’re not yet at a defined estimate (say, -5% to +10% expected accuracy), but which is where we expect to be when we complete this series of scheduling steps.  We are at the first of an iterative series of steps of successive refinement.  In addition, as I’ve stated in the past, an estimate isn’t meaningful without the related risk factors.  These will be incorporated into the schedule at a later step in this schedule building process, but that means you should be noting the sources of risk as you develop these estimates.  You should also document all assumptions that factor into the development of the estimates.

Ideally the task owner should provide the task estimate, but assigning resources to tasks is another step that will come later.  So at this point you will have to do the best you can.  If you are a domain expert, you might come up with this first set of estimates (though there are many risks with this).  Alternately, another project team member who is a domain expert could develop the estimates.  Another approach is to use several expert team members and the Delphi estimating method, which I’ll discuss in a future post.  The Delphi Method is particularly effective for a variety of reasons (in fosters team camaraderie, consensus and consistency of expectations, it is a successive refinement method, it exposes “gotchas,” etc.).  (See also Wideband Delphi Process.)

Delphi may be too onerous, so a good alternative is the three-point estimate, which I’ll also discuss in a future post.  This has many (but not all) of the benefits of Delphi, and it flows right into the advanced “scientific” scheduling discussion that will follow this series on the well-formed schedule.

One thing about the estimates at this point is that they should be “resource independent,” or at least resource agnostic.  That is, for this exercise don’t assume a specific resource will be performing the task;  instead, assume a generic resource skill.  Later, the individual task estimates will be refined based on specific task assignments, the next step in the process and the subject of the next post.

In fact, there are a number of biases that should be avoided at this point.  For example, do not bias for resource availability or skill;  and do not bias for (your expectation of ) task duration.  Next steps will adjust for the former and the scheduling tool will adjust for the latter.

However, it is appropriate to bias for “productive” hours (again, assuming you are estimating effort hours).  Productive hours are those hours that the project team member is working on project tasks and contrasts with (non-productive hours) administrative activities, vacation, holiday, sick time and other absences, etc.  If the team resources have to account for all their time when recording their daily/ weekly activity, then this may already be appropriately factored.  If not, you may have to make adjustments within the tool.  For example, assume a task is estimated at 40 hours of effort.  One’s first expectation is that this is a one week (five day) activity.  However, a person working on this task will also check email, spend time talking on the phone to their insurance agent, landscape supplier, or home repair technician.  They may take a training class.  They make take an afternoon off to attend a school conference.

Over a long project, you may not know specifically when resources will take vacations, but you need to factor in that they will take some vacation sometime.  Such small amounts accumulate over the duration of the project.  Therefore, it is advisable to adjust the scheduling tool so that a workday is only, say, 6.5 hours, rather than the usual eight hours in order to accommodate these variances over the full project duration.

Next we’ll add resources to the project schedule.

This is a lot of material to pack into one post.  Where have I confused you, what do you agree with and disagree with?  What would you like me expand on in a future post?

The Schedule – Dependency Chain

"Things derive their being and nature by mutual dependence and are nothing in themselves.”

                                                                                                              - Nagarjuna

In my previous post on scheduling basics, I listed the essential requirements to have a well-formed schedule, which is also the sequence for developing them:

• WBS
• Dependency chain
• Task effort estimates
• Resource assignments
• Resource leveling
• Risk buffers

This post will discuss the Dependency Chain.  The dependency chain obviously sequences the tasks in the order that you plan to perform them.  A well-formed schedule, though, adds some best practices to the typical attributes. 

A true dependency relationship between two tasks is when a work product output of one task is necessary to start or complete a second task.  When that condition is true, there is a dependency from the second task on the first task.  What this excludes are artificial or convenience “dependencies” to accommodate resource availability, resource leveling, or the PM’s view of “reality.”

Assuming you are using a decent scheduling tool, the tool has features to effectively address resource availability (calendars) and resource leveling.  Thus, if you use dependency chains instead of the appropriate features, you are diminishing the effectiveness of the tool to support your scheduling efforts and you are introducing complexities when conditions change (as they always change) and you have to reschedule.  To restate that:  if you follow the best practice, then you maximize the effectiveness of the scheduling tool and enhance your flexibility to respond to changing conditions.

As you will see over the next few posts, we will continue to build on the foundation of the WBS, now with the dependency chain, to develop the well-formed schedule.

Do you agree that task dependencies should be based on work products (including deliverables)?  Is there ever an occasion to base a dependency on anything else?

The Schedule - Basics

Success is neither magical nor mysterious. Success is the natural consequence of consistently applying the basic fundamentals.

                                                                                                - Jim Rohn

On completing my recent series on the Work Breakdown Structure (WBS), I promised to continue the series on project management fundamentals with The Schedule.   In this post, I’ll discuss the basics of a well-formed schedule, to be followed in future posts with advanced scheduling techniques and best practices.

A schedule is more than just a timeline.  Most “schedules” that I see are actually timelines.  That is, they are a graphic representation of what the PM wants the schedule to look like, how the PM wants the project to flow.  A well-formed schedule, in contrast, is how the PM plans for the project to flow based on a given level of certainty (probability).  It is for this reason that a (time) schedule (and equally a cost schedule) can only be done integrally with appropriate risk management.

A well-formed schedule is built in these steps and, if any steps are omitted, it is not a well-formed schedule and therefore is not reliable:

• WBS
• Dependency chain
• Task effort estimates
• Resource assignments
• Resource leveling
• Risk buffers

We’ve already talked about the WBS.  Over the next few posts, I will expand on these other necessary elements of the schedule.  In addition, there is an optional step to quantify the reliability of the schedule.  This topic is challenging to explain and probably requires a full book to do it justice, but I will at least address the high-points.

One final thing before I close this post:  If you follow these steps and develop a well-formed schedule, will that guarantee a good schedule?  The short answer is: No.  Ignoring the obvious path that “good” is subjective and the pitfalls that leads to, my point is that following the “process” or steps of producing a schedule does not compensate for experience or fate.  That is, if an experienced PM produces a timeline without resource leveling, they will not have a reliable schedule.  On the other hand, if an inexperienced PM follows all of these steps, they still may not have a reliable schedule.   There are lots of ways to produce an unreliable schedule.  And sometimes God just laughs.

Other references on scheduling:
                PMBoK v4, chapter 6 (Project Time Management)
                The Practice Standard for Scheduling v2