Subscribe via RSS Feed

Tag: "estimation"

The 3 Great Interrupters: Meetings, Management and Drive-Bys

interruptors-300x199Recently, we’ve introduced Commitment Based Estimation  to a couple of our software teams. Typically, this helps a team provide highly-accurate estimates. These teams go on to deliver successfully by meeting these estimates.

Why Your Change Request Estimates May Be Out Of This World!

PenetrationIn my last post, I talked about why it is critical to have different roles involved in the Change Control process. Failure to include a larger team in change assessment is a common oversight that makes it harder to understand the total impact of a change request.

Staying with the Change Control theme, I see one other challenge that occurs across teams. It may not occur “every time”, but when it does, your estimate for a given change request may be off by orders of magnitude.


A typical approach to estimating change requests…


When developers receive change requests to estimate, they start by understanding

  • the current functionality that exists,
  • the desired change to this current functionality,
  • the impact of the change and effort to complete the change.

While I know this is over-simplified and obvious, I want to drive into the 3rd bullet, assessing the impact of the change request. I believe most individuals assessing changes do a fairly complete job in assessing the impact. But there is a hidden monster (or pothole) that can destroy the accuracy of an estimate.

Let me illustrate with a quick (and over-simplified) example. I’ll call it …

The Grid

Let’s say your application includes a search screen that allows a user to search through all of the employees in your company.  The search allows you to search for employees by office, region, tenure, etc.

A change request comes through that says they want to be able to hover the mouse over any employee record in the result and display the details in a pop-up bubble.

With a  mock-up of the bubble and a clear understanding of the data, the request seems simple enough.

You estimate the impact of adding this functionality directly to this search might be one to two  days to complete and have ready for business review.





Enter the hidden Reuse monster

As it happens, the employee search in this system is reused in several different areas.  One of the areas is the ability for any employee or internal contractor to search for an  employee’s name, office and phone extension.  Because it isn’t obvious that this search is reused when first looking at the code,  you may inadvertently add this functionality to all the areas where  a user  can search for employees!

But WAIT! Do you really want just anyone getting personal details of your employees? You probably only wanted the management group to have this access, right?  So when you add this functionality, you now have either created defects in other areas or  have to “break” the reuse and write this code separately.

For all my architect friends out there, yes there are better solutions to solving this problem. But here is my point:

Many times when estimating what implementing a change would take, we don’t verify that the code involved in the request is not reused elsewhere or that other dependencies exist.

We may do this when making the change, but we need to know this when estimating the change too!

It may impact our own estimate as well as the QA estimate for this change request.

So here’s the quick tip

When estimating for a change request, make sure you estimate the impact this change will have on functional or code reuse. It isn’t always obvious!

Can you think of any recent examples when your change request estimates were out of this world?

IT as Great Facilitators Part 4

What Great Facilitators Know About Estimating

IT-Great-Facilitator-4Last post, I shared an exercise that helped teams understand how to develop a plan that is manageable and achievable. I call this “Commitment Based Estimation”.  Now, I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to be effective at facilitating estimation sessions,  I’m going to discuss how to select the best person to facilitate these sessions.

I typically find that the team-lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who can allow the team to own the estimate.

When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to constantly optimize an estimate, then the team won’t feel ownership. This is not how to get a Commitment Based Estimate.

Similarly, when an architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.

Now, you may be thinking: Does this mean I can never challenge a team? It does not. What is does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.

For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now, you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Good Facilitators Can Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic.  I talked about this in a past blog called “Attitude of Estimation”.  As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered.  Project Managers can offer perspective on dependencies and resource availability.  The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects, and the database team also need to weigh in.  Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

Have you ever been in an estimation session where the facilitator was more of a hindrance than a help?

I hope you have enjoyed my 4-part series on facilitation. If you missed them, here are the links:
IT as Great Facilitators Part 1
IT as Great Facilitators Part 2
IT as Great Facilitators Part 3

In my opinion, there are way too many people who take the facilitator role for granted.

I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them.  A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

IT as Great Facilitators Part 3

Commitment Based Estimation

IT-as-Great-Facilitators-Part-3I want to tie together two concepts I have blogged about in the past few months. Specifically, how proper facilitation can help a team confidently develop a plan that is realistic and manageable.  This is what I call Commitment Based Estimation.  As a quick review, Commitment Based Estimation is an estimation approach that helps a team:

  • Develop estimates they genuinely believe are achievable
  • Feel ownership for their estimates
  • Treat these estimates as commitments and therefore honor them by managing to their plan

You can find my previous posts on this topic here:

Experiencing Why Commitment Based Estimation Works

I’ve used the following facilitation exercise to help teams understand some of the flaws with our typical approach to estimation.  This activity also demonstrates why Commitment Based Estimation can lead to much higher quality results.

I always do this 2-part estimation exercise in person and always with a group of people. Important: If you do this with others, be sure to state the following rules:

  1. You cannot ask any questions. Do your best with the information I give you.
  2. Write down your answer. This is important (especially when doing this in groups).
  3. You cannot collaborate or look at your co-worker’s  answers.

I’d like you to choose a shopping mall or large shopping center that is a typical weekend shopping destination for folks near your office.  The key is that it shouldn’t be across the street from your office, but requires a planned trip to get to.  For example, where I work, there is a shopping center called Oakbrook Mall, which is about four miles from my office.

Now here is the first step.  I’d like you to personally estimate how long it will take to leave your office, go to the shopping center, and find a store that carries designer sunglasses.  Then, purchase a pair of glasses with mirrored lenses for your spouse or other family member.  Then drive back to your office and drop off the glasses.  Oh … and one other thing… On your way  back to the office, please pick up an ink cartridge for your inkjet printer.

Now, I challenge everyone to come up with the estimate above. They each get about 90 seconds to come up with their answers.

The First Readout…

I then go around the room and ask everyone to read exactly what they wrote down as their estimate. It is important they use the exact words they wrote down. 60 minutes is not the same as one hour.

If you do this with a group, you will get all different answers. Typically you will get:

  • Someone who is  optimistic and says a very short time. From my office, they might say 30 minutes.
  • A  few folks who give a pretty precise estimate. For example 53 minutes, or one hour and 12 minutes.
  • Someone who  might be swagging it at one hour or “an hour and a half”.

That Was the Setup. So Now You Change the Game…

After everyone has done their readouts, I then say “great job” and explain that I want them to estimate again. However, this time  they have something to lose. I pretend that I am giving away an iPad or some other prize to the three folks who provide actual estimates.

So, I want them to redo their estimates. Knowing there is a prize at stake, they now have something to lose!

And Then the Fun Begins…

I now give the group another 90 seconds to redo their estimates.

If you actually created an estimate while reading along, I’d like you to take the opportunity to make it “more accurate”.  Pretend you could win a real iPad if you create an estimate that you can deliver on.

I then go around the room and ask everyone to give both estimates.  So again, here are some typical results during the second readout:

  • The person who was optimistic at 30 minutes says: My original estimate was 30 minutes and my new estimate is 42 minutes.
  • The folks with the precise estimates of 53 minutes either stay the same, or they may go up a little to 61 minutes.
  • (This baffles me.) There’s always someone that will take their estimate and actually lower it. They may go from 80 minutes down to 70.
  • And every once in a while someone “pads” their estimate and says “one full day”.

Seriously – the Lessons We Can Learn …

This seems like a hokey exercise. Yes – I am a hokey person 🙂 .  But let’s look at the real takeaways:

  1. When we did our first estimate, we didn’t take it seriously. The goal of the entire activity is to realize that if we have something at stake, we will actually estimate differently, and try to come up with an estimate we can confidently deliver on.So when our project teams are estimating, are they approaching this as the first go around?  Are they saying “You want an estimate? 53 minutes.”  Or do they understand there is something at stake?  They should re-think and verify that they can deliver on their estimate. Do they understand there is much more than an iPad at stake?
  2. We assume that an estimate should be as low an estimate as possible, even if it creates risk to delivery.When we estimate, are we so afraid of estimating for real world contingency and risk that we always estimate optimistically?  We probably shouldn’t pad to a full day, but we aren’t asked to make the estimate the “best case scenario” either.It should be an estimate that we all believe is achievable and can be managed to!
  3. When I do this in group, everyone wants to ask questions.  Is there construction?  What time of day are they going? Do they know what store has the glasses?  But as part of the rules, I say no questions are allowed.When they do this exercise, they can even be frustrated that they are being asked to create an estimate without knowing these answers. They think “How am I supposed to estimate this”?And this is exactly what happens in real life with our project teams!  It is the nature of our world that teams will always have some questions that can be answered and many others that cannot be answered. Yet, we still ask them for estimates that we can plan and execute against.

Commitment Based Estimating

Commitment Based Estimating is about helping a team deal with all three of these challenges. In my next post, I will talk about how proper facilitation can help a team deal with these challenges and deliver a Commitment Based Estimate that everyone believes in and the team can manage to.

Can you think of any situations where it would have been worthwhile to try this exercise before delivering an estimate?

The Attitude of Estimation

The-Attitude-of-EstimationOver the past three or four blog posts, I tried to challenge our thinking on estimation by sharing some specific ideas on why padding an estimate is evil or how a SWAG can actually be fairly accurate.

Now I want to take a step back and share the biggest obstacle any organization has to getting consistent estimates. By that I mean estimates that drive confidence for the team and it’s stakeholders. That obstacle is our attitude towards estimates.

To clearly share what I mean by our attitude, let me share a typical estimation experience:

Experiencing the Attitudes of Estimation…

I am working with a new team and walking them through some standard use cases or agile stories. I present the first feature, the team evaluates it, and give me their initial estimates.

One person on our team, let’s call her Ann, quickly throws out “This should be about two days”.  Another senior member of the team, let’s call him Jerry, says: “I can’t imagine that taking more than a couple of hours”.

I ask Ann, “Why do you think this is two days”? She responds: “Well if I say a day and there are defects etc, it’s going to take longer. The truth is I don’t know whether this is one day or three days – but this is only an estimate. No matter what I say it’s going to be off, and you’ll be unhappy”.

After defending myself and saying “That’s not true, yada yada yada”, I then turn to Jerry asking why he thinks this is only a couple of hours. He responds, “How hard can this one be? It’s a straight forward screen. I just have to get a new table built with the reference codes and we are good to go. I don’t see any challenges”.

One of Jerry’s teammates asks: “Isn’t it going to take some time to download the reference codes, clean them up and get them in the table? And shouldn’t we create some quick automated tests to make sure this works?” Jerry pauses and says: “Well I guess. If you want to include all that then I need a full half day”.

Finally Ann jumps in and shares: “If you ask me, I think you should estimate a full day. We’re going to need the QA team to sign off and by the time you do any adjustments, it might take you all day”.

Jerry doesn’t necessarily agree, but the team agrees it’s better to be safe then be sorry.

Why These Attitudes Make Sense…

I regularly find both attitudes on the same team across companies, sectors and experience levels. I understand both approaches. I can defend them!

Ann is right. No matter what we estimate, it’s going to be wrong. That is why we are estimating and not “predicting”. In fact, I’d even argue “weather forecasting” should be called “weather estimating”. Forecasting suggests we are truly predicting. Estimation suggests based on what we know and the models we are using, here is our best guess.

And Jerry also isn’t wrong in saying he knows that it will take two hours. He genuinely believes for the feature at hand, he can get this out quickly. However, the team quickly reminds him that there are other “tasks” and “team members” that need to be included in his estimate.

Commitment Based Estimates

Having different attitudes and approaches to estimation is a clear obstacle to getting consistent estimates that can be managed and adjusted. To remove this obstacle, I suggest having a standard approach or attitude to estimation. I call this approach: Commitment Based Estimates.

When asking for estimates, I want the team to understand, I am not asking for the smallest, leanest, quickest estimate for each task. If I did, this optimistic plan would simply be impossible to deliver on. It won’t take one small thing into account: LIFE.

I also don’t want them to pad estimates and not be realistic.

So I ask them to think about it from the point of view of “commitments”. When can you commit that this feature will be “done/done/done”? When do you believe it will be ready for deployment to our integration test environment?

I then clarify: That means you have to take into consideration any “clarification” of requirements, obtaining resources such as a tables, test data, web services, tools, conversion scripts, documentation and so forth. It also means you have done your testing and are comfortable that this actually works. You are proud of the result.

In our previous example, the team compromised and said this would take a full day to finish our feature. I might test this by asking the team: “Would you bet your paycheck on this? In other words, are you truly committing to that one day estimate”?

In the real word, if we are working on something that we said takes a day, and it ends up taking an extra 45 minutes, we would typically do what it takes to get it done on schedule. That is the nature of development teams. We truly want to deliver on expectations if “we own them”.

I could write another page or two on Commitment Based Estimation, but I won’t (yay)! I will leave you with these other thoughts:

  • Never force an estimate on the team. If you are doing Commitment Based Estimation, the team needs to feel full ownership for the creation and development of their commitment.
  • I highly recommend all estimates be in ½ day increments. More specifically, NOT in hours. If I say I am going to be done in 6.5 hours, am I actually going to get another .5 or 1.5 hours worth of work on my next task done? Stick with ½ day, full day,  three days or five days etc…
  • If your estimate is longer than a week or so, I’d challenge the team to split the work into two tasks and estimate them separately. (There may be some exceptions to this one.)

The Goal: Consistency

Regardless of whether you agree with Commitment Based Estimates, it’s important to get the team to have a common attitude to estimating as much as a common approach. I hope you give Commitment Based Estimating a try. I have found a great deal of success with it.

I’d be very interested in hearing your experiences with “attitudes” towards estimation and why you believe this approach will or will not work with your team. Please leave your comments below!

As always, please feel free to share this post with anyone you think might benefit.

How to Turn a WAG (Wild-Ass-Guess) Into a SWAG (Scientific-Wild-Ass-Guess)

Next in our Providing Meaningful Estimates series we talk about turning WAGs into SWAGs.

SWAG-Bar-Chart1S-W-A-G stands for a Scientific Wild Ass Guess.  It’s sometimes used more as a tongue-in-cheek way of saying: “This estimate isn’t really reliable. I pulled it out of the air.”

I’m going to  show you how to put the S — the science — back in a WAG so even an off-the-cuff estimate can be meaningful and useful to your audience.  The easiest way for me to demonstrate how to improve your SWAGs is to use a simple example.

Consider providing a SWAG, an order of magnitude estimate, on how long it would take you to read to The Fountainhead (752 pages) by Ann Rynd. In fact, stop reading this  article right now  and come up with your estimate.   Please don’t do any research.  Just take a moment and give me your “best” wild-ass-guess (WAG) right now.  I’ll pause for a sec.

No seriously, take a moment, and come up with how many days it would take you? 1, 7, 14,…… 365?  Just take a moment.

Now, I’m going to l give you a technique that to  add some  S to your WAG and make it a more  a scientific answer.

Actually, It’s All In the “Words” We Use When We Present  to Provide Our Estimates.

Whenever someone asks you for high-level-estimate and you can’t really do proper research, you will need to make assumptions.  The key is to expose  these assumptions with your estimate and to demonstrate how changes in assumptions might impact your estimate.

Here’s a framework that demonstrates how this  works:

  • When providing an estimate, always provide a range. And for each number in the range, provide assumptions. It sounds simple, but the difference is pretty significant.Always start out by thinking: What is the lowest reasonable number your estimate might be. More importantly, explain provide why do you think it is unreasonable to assume that the estimate might be lower.So for The Fountainhead, you might start the estimate with:“I can’t imagine it taking me less than 7 or 8 days. Assuming I find the book interesting, I can probably read 100 pages a day and a little more on the weekend. But with my workload at work, and errands in the evening, it’s not realistic to expect me to read more than 100 pages or so each day during the week.”
  • Next,  think about what is realistically the longest this task should take you. When you give this estimate, you also share what assumptions need to be true for you stay within this estimate (not exceed your high number).Returning to our example with The Fountainhead, you might continue your estimate with:“I can’t imagine it taking me more than 40 days.  If it does take longer, then the book must have been written in a 3-point font or in French (I don’t speak French) or a crisis at work came up.  I have to believe that I could force myself to read 20 pages a day, and even if I find it boring, I’ll get through the book in 35 to 40 days.”

Wild Ass Guess Vs. Scientific Wild Ass Guess

Now, let’s  contrast these approaches in terms of reading The Fountainhead- a. All 752 pages.

WAG: It  might take me anywhere from 7 days (a week) to 30 days (a month).

Using our new framework, you would answer:

SWAG: “I can’t imagine it will take me less than 7 days, assuming life doesn’t throw me any unexpected curveballs and I can  read 100 pages a day.  I can see it taking  me as long as 38 or 40 days if I can only get through 20 pages a day due to boring content or unexpected crises at work. If it takes me longer than 40 days, then it not only was painfully boring, it probably is written in some ridiculous font or written in French (I don’t know French).”

I hope you agree, that the second  example provides a level of confidence that we thought through our WAG and have some reasoning behind our estimate.

Check Assumptions. Manage Expectations.

The correct wrap up for a SWAG is an opportunity to further manage expectations by saying:

“If The Fountainhead  is as  good a book as you say it is,  , then let’s assume I’ll get it done in about 14 days. Within the first 2 or 3 days, I can update you on whether this was a reasonable swag or not.”

This means within the first 2 or 3 days, you determine if the SWAG assumptions are correct. You  can even restate your  SWAG now that you have started reading it and verified your assumptions (one way or another).

If you still aren’t convinced, let me show you how effective this approach can be might be by by using a  one more example real life example.

A Real SWAG in Every Day Life.

You own a home and want to build a deck on the back of your house. You ask two contractors to come out to your house and give you bids on the work. With each of the contractors, you walk through the backyard and show them where you want the deck.  They show you different styles of decks and after reviewing the pictures, you choose your preference.

Each contractor tells you they will give you an exact estimate for cost and a proposal by the end of the week. But you have a key question:  Your son is graduating college in two weeks and you want to know if the deck will be completed in time for the graduation.

Contractor #1 answers:

WAG: “The deck could take anywhere from 2 to 5 days. So if we start Monday we should have it done by the weekend. Let’s just hope we don’t get any bad weather.”

Are you at all nervous that the deck will not be done in time?

Contractor #2 answers:

SWAG: “I can’t imagine it taking less than 2½ days. If we can get the deck primarily built the first day, we’ll need the 2nd day to stain, make final adjustments etc. So by the time it’s dry and tweaked we are at the 2 or 3 day mark. It’s important that we don’t get any rain on Tuesday when we stain the deck.

Sometimes when we put the “supports” in the ground, we find obstructions we need to move. That could make the job take up to 5 days.  If it takes longer than 5 days, then you have a surprise waiting under the ground.  I don’t think you do, but until we start the job, I can’t be 100% sure.  Of course, this assumes the weather doesn’t blindside both of us.

So barring any golden surprises, we should be able to complete the job between 2 to 5 days. I would hope to have it wrapped up by day 3 but I’ll know more on Monday.”

Which contractor gives you more confidence in their ability to deliver on what they said?

More importantly, if the estimates are off, they can talk with meaning. They can discuss what assumptions were wrong, or what had they not considered. In other words, it doesn’t feel like they just pulled a number out of the air without any thought or real consideration.

In summary: The Framework

So, in order to turn your WAG into a SWAG, start your estimate with:

  • The  shortest or lowest estimate that is reasonable
  • Why it isn’t reasonable to be shorter/lower
  • Explain how large it is possible to go
  • What are the assumptions that would make it go that large
  • What are your assumptions that could cause it to larger
  • Finish your estimate with a viable, in between reasonable “target” in between that you believe is reasonable to start with. Explain how and when you will be able to validate assumptions and firm up your estimate.

Estimating Without Fear: How To Do Away With Padding and Still Come Out Looking Like a Hero

Estimate-Without-FearWhen your team puts together an estimate, does it command a sense of confidence, trust  and respect from those reviewing the estimate? Or, is it assumed that  your estimate typically  is padded and may be off-by-an-order-of-magnitude?


Do people believe, that even though some changes will occur due to dependencies out of your control, your estimate is still reasonable and something the organization can  manage to?

Or, do they say that it would be great to hit that date, but still  challenge your assumptions and believe you’re really going to miss it?

I am sure that most of us will answer that “it depends”. It depends on the size of the project, the complexity, the individual asked (Harry never trusts our estimates), and so on.

So let me ask you to think of this from a different perspective.

  • Does your immediate management, your boss, typically have confidence in your team’s estimate?
  • Do your business sponsors and senior executives typically have confidence in your team’s estimates?
  • And for the most telling question of all: Do all of the members of your team who participated in creating the estimate, typically have confidence in the estimate and the ability to manage to it?

I am always surprised at how inconsistent these questions are answered, especially the last question.

In this post, I want to discuss the estimating activity that does the most damage in terms of  building  credibility and confidence, as well as  our  ability to predictably meet expectations.

Padding Your Estimate!

Padding an estimate is as common place as speeding over the posted speed limit. Sure, there are a few folks who typically follow the posted speed limit, but most of us realize that when they posted the 55 mph limit, that really is “highway speak” for 65 mph.  We pad that speed limit too!  But NOT for the same reason.

From my experience, padding an estimate is done out of fear.

We pad an estimate for fear of the unknown.

“I have worked with Jerry often enough to know that there is a chance he will want to tweak the report layout.  Also, even though he says keep it simple, he’s going to change his mind and will want to add features like exporting to Excel and PDF. If I pad this estimate, I’ll have enough time to give him what he really wants and be a hero by coming in on schedule and on budget. Hmmmm should I pad it by 25%, 100% or more? Hmmm?”

We also pad an estimate for fear of the known.

“I am going to need some new tables from the DBA team. I’m also going to need the backend services team to add some features to two web services.  This should only take a day or two, but I know that the process and wait time will take at least a week or two.  I should pad my estimate to allow for that, so I am not blamed if they take longer to deliver their changes.  I don’t want to be blamed. “

Remove the Fear Factor With Contingency Estimating

Your  fear is real. In fact, the truth is that many times, the fears become reality and we need the extra time. This is where  Contingency Estimating comes in.

The one consistent theme that padding an estimate has is a base and a pad. I think it will take two days (the base estimate), but because they always change their minds, this will take a full week to deliver (the pad).

With Contingency Estimating, you actually want to “advertise” and “magnify” your pad!  This is counter-intuitive, but you want to describe your estimate in the following way:

We believe this will take two  days.  We also believe, from experience, that we will take time during the review and find changes and enhancements. This happens every time and since Joe will want these changes, we believe we should plan on additional three  days of contingency time to let Joe volleyball back and forth so we can deliver this. So my estimate is two days to get it initially done, and three  days to let Joe modify,  enhance and get this done/done/done.

Now management can understand that if they want to reduce your five day estimate, they need to work with Joe – not you – on how to eliminate the rework or agree that the extra  three  days is  needed estimate to “get this right”.  The key is Joe owns the contingency time! And you have been transparent about what is driving your estimate.

Just as important, Joe knows that we have planned to allow for three days of review and enhancements and that he needs to have some ownership in time-boxing his review in that time-frame and schedule.

Here is another example:

We believe building this functionality will take about  one week. We can manage our part to the one week. However, we have to wait on the ERP team to modify their web services to handle the changes.  This typically should take three  days, however, they are so backed up, they typically take up to two weeks to complete the work and remove any defects. So my estimate is one  week and three days to do the core work.  However, I am adding seven business days as contingency time for integration, testing and making sure the ERP team and us are talking the same language.

Again, management can now understand the cost of the team-to-team communication and integration.  It doesn’t necessarily mean there is an ERP team problem! In fact, the challenge may be with your team and their ability to pro-actively manage in an integrated and distributed environment.

The truth is, it’s irrelevant “why” this happens when you build the estimate. It’s important to share the contingency time and then to tackle how to optimize later. This will build more confidence than “Padding” your estimate.

In Summary…

I hope you find this a reasonable approach to clarifying  for your management and team members what drives  your estimates and what part of your estimate is contingency planning for the “real world” challenges you deal with day to day.

Taking it a step further, I also hope this approach allows everyone to come to the table and begin the process of identifying areas that the teams can start managing better and  improve the actual time it takes to complete work. This would be done by first identifying contingency estimates and then addressing potential waste in the organization.

If you have a different opinion, I’d love to hear it. Please leave a comment and let us know!

The Biggest Management Lie You’ll Ever Hear: “I Won’t Hold You To It”

Wont-Hold-You-To-ItI have to be honest on this one.  Not only have I been on the receiving end of this, but I am guilty of saying these words as well:

“I need a high-level estimate.  I won’t hold you to it. I know you typically need more time to create an estimate, but I am looking for an order-of-magnitude estimate. Can you get me something by tomorrow? Again, I won’t hold you to it. I know you need to do a full estimation process to give me the real number. I’m just looking for a swag.”

And then, at some point  in the future, management gets the  real estimate. It is almost always higher (sometimes double) and management (myself included) can’t understand how it got that way.   How can you go from $100k to $125 or $150k?   Or from two months to almost four months?

And, inevitably,  the creator of the swag estimate is asked,  “So what would it take to get down to the original estimate?”

So What is Management Really Thinking?

When you are the recipient of the line: “I won’t hold you to it”, the  first question you have to ask yourself is:  What was management thinking?  When management asks us to provide a high-level estimate, what do they really need that number for? It seems they were saying, don’t worry about being inaccurate or way off … I won’t hold it against you! But this isn’t rational.

Management is Trying to Make a Business Decision!

They are going to use that number for decisions. Decisions at their level! Decisions that may determine:

  • Go/no-go on a project, or
  • Do I need to plan for more budget and if so, what kind of dollars are we thinking of, or
  • Do I need to request more staffing or can I give away resources, etc.

These are typically higher-level decisions.  That means the estimates they are asking for are actually as important as any other combination of estimates we provide.

The next question: Does Management really mean it when they say “We won’t hold you to it”?

The truth is, they will hold you accountable for the number they receive.  No one in leadership is going to say: Pull a number out of the air, and wink-wink, we know it’s way off. But no worries, I know you threw a dart at a board of numbers and just gave me the result squared.

What they are really saying is that they need an estimate without going through the typical rigor of process that may take days or weeks.  I am not looking for a plan with milestones and staffing requirements.  I am looking for an overall high-level plan without that detail information. So don’t try and cover yourself on this. I won’t create pain for you.  Just give me the high-level estimate.

They may not understand, that getting them the high-level estimate requires us to build the details.  Only then will the high-level numbers have enough validity so they can make business decisions based on them.

A Best Practice: Communicate Your Concerns! Call Them Out on It

The next time management says I need an estimate but I won’t hold you to it, call them out on it! Ask them what they need the estimate for and what decisions will it be used for.  Are they looking to free up resources?  Are they putting in a budget request? Ask how painful it will be if the estimate is off by x%?   Odds are they may pad the estimate (their budgets) for planning purposes.

Start having a conversation so you can truly help management as best you can, and as a partner.

One thing is for sure, if they are asking you for an estimate, they are using it for business reasons. And, bottom line, you will be the owner of that estimate!

Estimating is a Minefield!

Estimating can be a minefield. Everyone asks for estimates. We ask a child how long a chore will take, or when they’ll be home from a party. We ask a boss when our review will be done.  Marketing has been asking me when will I have this blog article complete? (By the way, they clearly tell me they will hold me to it!)

We need a consistent language around estimating and more importantly, we need consistent expectations around how we estimate and what we “can” and what we “can’t” estimate, repeatedly and predictably.

So the next few articles are going to focus on common obstacles that cause a team estimate to either be order-of-magnitudes incorrect or simply an estimate that does not command everyone’s confidence.

We’ll start next post with about padding estimates and why we should NEVER do it.  I will present you a better alternative.

So, how many times has management asked you for an estimate that you won’t be held to?

Photo Credit: Denise Chan