Estimation: The Art of the SWAG

>> CHRIS GREATENS:  Thanks, Andy.  Welcome, everybody.  Glad to have some folks here this morning to talk about estimation.  

A little bit about myself before we get started.  I am a senior director of digital experience platforms at a company called Bounteous.  I've been working in the Drupal space and with Bounteous since 2009, and my team really focuses on Drupal.  

I have a lot of interests.  Astronomy, baseball, reading many books, and doing large jigsaw puzzles.  And this whole thing is a little bit new to me.  So I have a couple of young kids and a cat not usually present when I give presentations, so there may be a special guest appearance.  

A little bit about Bounteous.  We were formed in 2003 in Chicago.  We work with lots of great clients and we have lots of great people that work for us, including an amazing Drupal team.  We do a lot more than Drupal.  We do strategy, experience, design, analytics, insighting, marketing, and more.  If you'd like to talk to me about what we do and how we do it, I'd be happy to talk to you.  

So, the agenda today to talk about estimation is this.  I'm going to break it down into just talking a little bit about some basics about estimation to make sure we're on the same page, so to speak.  I'll talk about the different approaches I use to do estimation and talk about some of the principles that I follow when I'm doing estimation.  

I should have probably ten or so minutes for questions at the end, so, you know, I'll have Andy read them to me at the end.  So please, you know, fire away in the chat as you will.  

So let's talk about estimation.  I pulled this definition from Oxford Online, and it goes that an estimate is an approximate calculation or judgment of the value, number, quantity, or extent of something.  And if you read the definition a little further, it goes on to say that it's also a written statement indicating the likely price that will be charged for a specified work or repairs.  So, this is a lot of what I do on a daily basis.  I'm often evaluating projects, both SSO opportunities and new business, responding to RFPs and things of that nature.  

And this is what I do.  I help create written statements that tell you how much it's going to cost to do something.  I like that definition also has likely in there, because anyone that's done a lot of estimating knows that it's really hard and it's really hard to nail the number exactly.  

So, we'll come back to this point over and over again, I think, during the conversation.  

While I spend a lot of my day doing project estimation, especially at the beginning when there's less information involved, a lot of what I talk about today will apply to you no matter if your something is a task, a feature, or a project.  

So, we estimate every day even though we don't really think about it in these terms.  Certainly, I do it a lot.  If I need to go somewhere, I ask when will I arrive.  Your boss might ask you when a certain task will be done by.  My kids love to ask me when I'm going to have dinner ready.  I often ask myself how far I can go before running out of gas.  So far, fortunately, I only ran out once.  

If I think about the when will I arrive part of this, I spend a lot of time going to Chicago and to our offices.  I live up here in Green Bay.  So I often have to plan out those trips.  And so if you think about it in terms of estimation, it's what I'm doing.  First thing I do is I think about how long it's going to take me to get to Chicago, assuming there's no problems, right?  

So roughly, that's about a three hour and 15 minute trip for me.  And then I start to think, hey, when am I going to leave Green Bay?  Because if I leave Green Bay at the wrong time, I'm going to hit traffic in Milwaukee and Chicago, which is going to lengthen the trip.  I may need to get gas on the way, so I need to incorporate those types of things.  Maybe I want to grab some breakfast if it's really early morning.  

So lots of these things that we kind of incorporate into what we do every day.  And ultimately, I arrive when I need to arrive.  If I need to make sure I arrive by a certain time, I'm going to bias my estimate a bit.  I'm going to make sure I overestimate how long things are going to take as opposed to underestimate them.  These are some of the techniques that I use daily, and we'll go through them as we go.  

Before talking about those techniques and some more questions you should ask yourself, I'd like to think about what an estimate is not.  So an estimate is not a guess.  Anyone familiar with the term swag that's in my title, I put that in there, it stands for silly wild ass guess.  It's not what we do.  We're really smart people.  We've done this for a long time.  We have lots of history to fall back onto.  Our estimates are really educated buyer experience and buyer data, hopefully more data than experience, but definitely we're not just picking out numbers out of thin hair.  

And an estimate is also not a plan.  I talked about my trip a bit.  It's true that it's part of a plan, or a plan can be part of what you do for an estimate, but ultimately the first thing we do when we do an estimate, we're really trying to figure out how long it's going to take us to do this regardless of the other extraneous details.  

So as we talked about it, I'll talk about how you use a plan to help shape my estimate as well.  But they're definitely not one in the same.  

And an estimate should not be static.  And this one, I think oftentimes people kind of fall back to it as a stat tick thing.  If you're in the same position as me and making estimates at the beginning of a project to respond to an RFP, there are many things I don't know when I make that estimate, so if we just blindly follow that estimate without updating it as we go along and as we learn more things, it's going to become wildly inaccurate.  

So when you prepare to do your estimates, when I prepare to do my estimates, I often ask myself, you know, a number of questions.  One of the first things I want to know when I'm doing an estimate is, you know, what precision do I have in order for this thing to be considered accurate.  

If you think about what accuracy means, you know, that's whether or not it actually hits the target.  And precision is the range around that number that I get to hit and still be considered accurate.  If you think about it, in these terms, if they gave you a project and you estimated it to take a year, and actually took 13 months, you know, would we consider that to be accurate.  

If we had a project and we estimated it to be a million dollars, and it came in at $1.2 million, you know, is that accurate?  And the answer is it kind of depends, right?  It depends on what the precision is.  Although, I'd say for both of those estimates, especially if they were really early on in the project, I'd consider those smashing successes.  

I also want to know how confident do I need to be in the estimate.  What's kind of at stake if we get this wrong and we get it wildly wrong.  

And what happens if we go over the budget or, you know, past the timeline or those types of things.  

Depending on how confident we all need to be in the estimate, that might kind of inform the next question, which is what direction should the error be made in.  We think about my example of driving to Chicago, and wanting to be there at a certain time, I make sure all of the errors are overestimates.  And so I think it's going to take me three hours and 15 minutes, but I assume I'm going to run into, like 30 minutes of traffic.  And I assume I'm going to take a pit stop and it's going to take me 30 minutes.  So I leave my house four hours and 15 minutes early.  If I end up being early, that's great, I just don't want to be late.  That's the type of thing that we want to know here.  

It's also important to know what question the estimate is helping to answer.  When somebody asks you to do an estimate, they have an idea in mind what they want to know.  Oftentimes the question is how long will this take, and we're all used to doing those types of questions.  

Sometimes it can be, you know, can or should we do this project, right?  So if I come up with this estimate and I hand it off to the person, they might be just using that to evaluate whether it's, you know, valuable to the project.  You know, if it's going to cost me $500,000 and we expect to, you know, generate $500 of revenue every quarter from that, it's probably not a worthwhile project.  

And so, you know, those are some of the things that we can do.  Some of the questions we might want to answer.  

We also recently had an example where a client came to us and wanted a number of things fixed, and they had a pretty tight deadline.  

So the question wasn't how much is this going to cost or how long did this take, it was how much can you fit in this timeframe.  Which is a different level of estimate as well.  

Kind of thinking beyond the estimate and maybe more of the solutioning part, there's a few more questions we can ask ourselves.  What kind of Mac and cheese are we really making here?  Is it store brand?  Is it Kraft?  Is it gourmet?  All this to say if I'm working on a solution for a high end fashion agency and this is going to be a really public website, I'm probably going to make this thing gourmet.  But if I'm working with maybe a start up or someone that has a really, really tight budget, we're going to lean towards the store brand and make this really practical and get it working as quickly as we can.  

So those are some questions you want to ask yourself.  In my case I often ask myself whether or not this is new business.  And if it is new business, is this fixed bid or T&M?  If it's fixed bid, it will go back to the question of how am I going to bias the errors.  Going to bias them to be overestimates because we're taking 100% of the risk if it goes over.  

I also think about whether or not this is an existing client or new client.  If it's an exist client, what do I know about the client?  You know, what do I know about, you know, their desire for how fancy the solution should be, or are they really tight on timeline and budget, what kind of client am I dealing with?  All these things help shape the solution, which then impacts the estimate that I do.  

So when and how often [indiscernible] that you're thinking about?  What you're looking at on this page is called the cone of uncertainty, and I got familiar with it from a book by Steve McConnell, which I'll reference a little bit later.  

But the idea here is that on the left side of the screen is the very beginning of the project.  We've come up with an idea for a project, we've thought through it a little bit, and we've come up with an estimate.  And as we go right, we're going through stages of the project to define it better and whatnot, and then we get to the build, and then we continue right until finally the upper and lower ranges meet on the timeline, and that's when the project is done.  So as you think about this, it makes a lot of sense.  The more we do in the project, the more we learn about the project.  The more we understand the requirements, and maybe the what the unsaid requirements were, the more we understand how the client is going to work, all these types of things bring more clarity to what we're doing.  You know, we understand the team better, we understand how it works and how efficient it is, you know, all those types of things are going to let us narrow the range that we think that this project is going to hit.  

And ultimately, when we're done, we know how long it will take.  

On the left side, to give some perspective, though, when we really initially think about the project, McConnell suggests that the range is 2.5x to 4x.  If I think the project is going to take a thousand hours and somebody asks me at that point how long I think it's going to take, if I want to be right 90% of the time, I'm going to tell them 250 to 4,000 hours.  It's a crazy big spread, but ultimately, if we want 90% accuracy at that early stage, that's what we're really talking about.  

So a fun fact before we go into estimation approaches.  We only know a project's cost or length with 100% certainty when it is complete.  Often we express, you know, confidence in our estimates and we're surprised when they go over, but ultimately, really the only thing we know is 100% certain, how much it's going to cost, when it's going to be done is when we're done with it.  

So let's talk about some of these different estimation approaches that I use anyway.  My go to method really for doing these estimations is something I'll call comparison basest pacing, and the idea is we take whatever project that we're thinking about and we try to compare it to something we've already done.  

And hopefully, we've done a lot of different projects so we have lots of things to compare to, because ultimately what we want to do is find out how is this project alike, how does it differ, and I'm thinking in terms of, you know, size and complexity really.  

And, you know, do we have anything that's really comparable.  If we don't have something that's, you know, comparable per se, we can often stack projects together.  So, the project I'm looking at is like two of those projects, or like three of those projects to get our comparison based estimate.  

The more experience you have, and the more data you have, the better this is going to work.  You know, I think pretty obvious.  But if your entire world has been building one brochure, and then something like Amazon.com, and I give you a third project, it's going to be really hard to compare this project to those two things.  Likely, it's going to be more towards the brochure than Amazon.com.  And we want data.  The more data we have, the better off we're going to be.  

One of the things that's really important, though, is that we really need to know the actual data from the projects that we're comparing to.  And this is important because if we don't, we're going to introduce air into our estimates.  So if you think about an example where you compare this project to another project, and that other project, you estimated to take 1,500 hours, and you say, yep, this is exactly like that one, and you go with the 1,500 hours, what happens if the other project actually took 2,000 hours to complete?  You've just introduced 33% error into your estimate.  

And you also need to make sure that that data is accurate.  As a consultant, we're constantly logging our time.  Constantly logging my time, it's really important.  But if you work for a company and you're building your own Drupal website, do you have time tracking?  And if you have time tracking, you work for salary, do you bother to put in more than 40 hours?  So somebody's actually working 50 hours a week, but the they only put in 40, that's a 25% error that goes in there.  

I find that this is a pretty good method for doing quick estimates.  Accuracy can be lacking, because it's comparing big projects to big projects.  But I often use this early on in our process when we're evaluating whether we want to respond to an RFP or, you know, like what we think the likely outcomes are for us.  

But if I want to be more accurate with this, I'm going to use this with decomposition.  And so, you know, the larger the project is, the harder it is to compare it to other projects, because there's so many differences between the two projects.  

And so often what we can do is break down those projects into smaller chunks.  And then start to compare the chunks, and that will give us a better idea of what we think about how this will work.  

Now, there's a number of different ways you can break down and decompose a project.  You can do it by Project Phase, so you can do it with, you know    you can break it down into different activities like requirements gathering, things like that.  I tend not to do this, because it's kind of hard for me to understand when one phase ends and another begins.  You know, if you have a requirements gathering phase that we've estimated, or comparing, and we typically find the misrequirements.  We're running up against the build, so where do I allocate that time to.  A lot of times, our clients want us to hit certain timeline deadlines with our projects, and so often, we'll overlap, conceive, and build.  And so it's hard to maybe pull those numbers apart.  

We also do it by components, and when I say components, I'm really not talking about like a hero banner or a quote.  What I'm really talking about is like the sync part of the system, an order entry system, or an inventory system.  And, again, this isn't one I tend to do a lot, because oftentimes when we do this, and we compare this, we miss the glue or the interconnectivity that make these systems work.  

So if I'm thinking about the order entry system that needs to tie into the inventory system, which one of those buckets gets the time to make the interconnectivity work.  I typically do this by user functionality.  You can typically think about these as user stories or epics.  What I like to do with those things is I like to make sure that they cross big swaths of the system.  So I make sure I incorporate all that glue that I need to do in there.  

I think the big stories are really good for us with entire projects, but if the we're working in a sprint per se, we can start breaking those things down, and oftentimes we do, things of that nature.  

To take decomposition a bit further, there's a technique called bottoms up.  It just goes much, much deeper.  And, again, this project or this method works by breaking the project down, into features and tasks.  And it gives a much better idea of what it will take to do this project.  We talked about the big project being harder to estimate.  

But one of the things that also brings into focus is the fact that if I make an error when I'm doing the estimation, it's going to be either higher or low.  And there's like no in between really.  

Whereas if I decompose the project into all of its features and tasks, I am essentially estimating many, many smaller features, and typically, there are going to be errors on both sides.  There's going to be some overestimation, some underestimation.  And these will tend to balance each other out.  

And what this does is it gives us a more accurate estimate.  The one thing I would caution you is that you don't want to get fixated on any of these individual parts.  And what I mean by that is, when I go    and I've done my estimation, and I give the number often tames, I'm told, oh, yeah, it's a bit high, right?  And then somebody very helpfully goes through my estimate line by line, and they pick up the things that they think are overestimated.  And what this does is if you just change those numbers, presuming we drop them lower, what it does is it gives you    you're left with anything that is accurately estimated or underestimated, because when someone seems to think the project is overestimated, they don't care about the things that are underestimated.  Now we're left with a more inaccurate estimate and it's also underestimated.  

And we as developers are happy path people, and so our estimates tend to be underestimates anyway.  So we definitely don't want that help, if you will.  

Another method that is often overlooked is just account stuff.  So, there are a lot of things that we do on a project, lots of things that we can count that correlate with time and effort.  

And so if there's user stories and requirements and defects, the story points, and lots of things that we do on a daily basis.  We also in Drupal projects have a lot of other things that we can count.  We can count content types and components and taxonomies.  We can count, you know, your contrib modules that we're using.  Those types of things.  All of these things at some level will correlate to how long the project takes.  

If you're going to use count stuff, it does better if you use more than just a few things, and more is better, up to a point.  

Again, I've said it before and I'll keep saying it, we want historical data for previous projects that we can use.  So when we count a bunch of things, we want to be able to look at it and say, hey, in the past, a content type takes us 20 hours to build, or, you know, a small component takes us four hours to build.  Whatever it is.  

Because what we'll ultimately want to do is take those things that we've counted and we want to multiply them out.  And give us our estimate.  

You know, whatever we're counting should be consistent from project to project.  You know, so, if you think a small component on one project is a cool component and on the other is an insane Google map with a bunch of integrations, there's going to be a problem there.  So we just want to make sure that we're consistent from project to project.  And I find that this is a pretty good method to use on any stage of the project.  And it's not as, you know, detailed as, say, like a bottom's up, so it might not have the same accuracy.  So it can give me a pretty rough idea of what's going on.  

Even to the point where I know some project teams have, instead of using story points and planning poker, just the user stories after a while, because what they found is that they're consistently delivering the same number of stories every sprint.  

Another way we can break things down is T shirt size by feature.  So, again, there's a common theme here, right?  Taking a hard problem and breaking it down and slicing and dicing in many different ways.  In this case, we're slicing it into the features, and we're distributing them around T shirt sizes.  Small, medium, large, extra large.  And again, we're going to go to historical data, hopefully visit, and we're going to multiply it out, and it's going to tell us roughly how long this thing is going to take.  Get pretty good at getting a rough estimate, so if you don't want to spend a lot of time on the estimate, this is a good way to give you some good feedback right away.  

Another method that I use, but this is not really estimation, but it helps me inform my estimate or my pricing, is staff planning.  So, I have the plan, or I have the estimate.  I've taken the time to look at all the requirements and I've mapped it out and I've broken it down and I've compared the projects and I've got, you know, 1,500 hours let's say on a project.  What I'm going to do is I'm going to take that and see how it's broken down by back end and front end developers and I'm going to develop a plan.  Based on this, I think it will take X number of sprints to get this thing down.  

What that really lets us do is it really helps us tease out things that are going to happen on the project that affect pricing, maybe not the estimate, but they affect pricing, and we have to figure out how we're going to accommodate this stuff.  

You know, is everybody going to ramp up on the project right away?  Let's say you have a project that you think is going to use seven developers.  Are they really all going to start day one and all be, you know, fully allocated and usable at that point?  You know, do you have certain things that you need to work on that you don't know when you're going to get them?  Thinking in our case, sometimes overlap, conceive, and build.  

I just have to make sure that for the build portion of it, that we're going to get the wire frames and the comps and the requirements and things of that nature that we need.  

This also helps you account for the    I'll call it nonwork.  It's important, but it's not geared towards doing actual tasks.  You think about your standups, you think about the sprint planning and sprint retrospectives and things of that nature.  These are all important things and we have to make sure we accommodate them.  Ultimately, it helps me understand whether the plan is feasible or not.  

So if I have a deadline that I have to hit, the staff plan will take that into consideration and is I reasonable.  

The classic example would be if I have a project, it's a 20 week project and I have 20 developers at my disposal, I don't think there's anyone here that thinks we can get that project done in a week.  So we need to look at that plan and we need to make sure that it's feasible.  

So, we know what an estimate is.  And we've seen different ways that we can estimate.  

So, the last section is dedicated to, you know, the principles that I like to follow, things I like to think about when I'm going through this process.  I said it before, but it bears repeating.  We only know a project's cost or length with 100% certainty when it's complete.  And this is important for a variety of reasons.  For one, we need to somehow be able to convey our confidence level and the estimate.  And, you know, there are a couple different ways that people typically do this.  One of the ways that people do this is that they will say, I am 75% confident in this estimate.  Or I'm 50% confident in this estimate.  

The percentage, like, confidence level to me, it doesn't work, like I'm not really good at it, because frankly, I don't know what the difference between 85% confidence to 90% confidence are.  

I typically like to use a range.  You know, if we think back to that cone of uncertainty that we saw earlier, I think this is a really good way to address the uncertainty that we run into.  I can say I think this project will cost between 150,000 to $200,000, or between 100,000 and 1 million.  The first indicates that I'm a lot more confident in the estimate than the last.  And so this is the type of information that we really want to convey to the person that's consuming the estimate.  

The assumptions you made to get to the estimate are as or not as the estimate.  So what this is saying is we all assume some things when we're building out an estimate.  And if we're doing that, we need to document them.  The person consuming the estimate needs to understand what those things are.  

I think about when we build, you know, our estimates for Drupal project.  You know, the assumptions I'm putting in there are like, is this going to be self hosted or is it going to be past hosted platform.  How many websites are we dealing with?  Are we dealing with this as multi lingual or not?  Is the personalization involved?  How many content types?  You know, how many taxonomies?  How many components?  How many page layouts?  All these types of things.  Because they all impact the estimate.  

So, if you think about something like components.  A lot of us are building component based sites now.  If I have as part of my estimate and assumption that we'll use 24 components, and we get into the built phase, and ultimately the client decides that they want 70 components, my estimate is no longer valid, right?  We need to reestimate there.  We need to talk about it.  Lots of things that we need to do.  

But ultimately, if the estimate assumes 24 components and you build 70, and you go over budget, like don't blame the guy that made the estimate, right?  Because you've invalidated it.  But it's really important that everybody understands what those assumptions are.  

When you estimate a project, don't assume the most qualified person on your team will do the work, right?  A lot of times people that are doing the estimates are also like our A team players.  So, you know, don't think about it in terms of how long it will take you to do the project.  Think about how long it will take, you know, somebody else on your team that's maybe a little bit more junior or maybe a little less experienced with Drupal.  

A long time ago, I worked with a fellow whose name was Troy.  Whenever Troy was asked how long it would take to do something, his first question was, do you want that in Troy hours or do you want that in regular developer hours?  

Now, conceited it is, I agree, but it really hit on a key point, because Troy actually was a really good developer and he actually was    you know, was able to develop things a lot quicker than other people.  And so really what it's saying is, look, if someone else is going to do this, it's going to take longer. That's really important for us to capture in our estimates.  

You know, this is easy for me to avoid, because I live in Green Bay and I work all the time, but don't give off the cuff estimates.  If you're walking in the hallway and you meet at the watercooler, you know, your boss says, hey, how long will it take you to do this feature?  The best answer you can give is, hey, let me get back to my desk and I'll get back to you.  

The reason I say this is oftentimes, when we're put into a spot like that, whether it's in the meeting or in the hallway, whether it is.  We really quickly go through the estimation process.  An estimation is hard.  And we don't think about things.  We don't think about the assumptions.  We don't think about what it all takes to do the solution.  We're asked a question that we've been trained to respond quickly.  

One, those estimates are going to be just bad.  Not very accurate.  

But two, and I'd say most importantly, is that the person that asks you that question is going to    they think that's a commitment, right?  They don't just think of it as an estimate.  Hey, Andy, how long is it going to take you to do that?  Tomorrow.  They'll say, okay, by 5:00 tomorrow, I'm going to have this thing, right?  In the meantime, Andy's gone back to his desk and he's like, ah, crap, this CSS is a mess.  And my local environment is not spun up.  And all these different things that I assumed were good when I made that estimate and now they're not.  And now it's hard to walk that back.  So just be really careful when you're making these types of estimates.  

Don't imply a preciseness that your estimate is not providing.  What I mean by this is, let's say your boss runs into you in the hallway, and asks you how long it's going to take to do a feature.  And you've taken my advice, and you say, you know what?  Let me get back to my desk, get back to you.  And you go back to your desk and you think about it and you break it down and you're like, all right, there's these seven things that we have to do, and yada yada yada, blah blah blah, and you come up with the answer of 28.75 days.  Don't send that email, right?  Don't say it's going to take 28.75 days.  Because the person on the other side is going to say, wow, like, two decimal places.  He is super confident in that thing.  And that's not really what you mean.  You just mean, I did this thing and this is what I came up with.  

A better answer there is a month.  I'll accept four weeks, but a month is better.  If somebody asks you how long something is going to take and you calculated it as 335 days, it's a year.  One significant digit is really good, because by giving a number as opposed to a range, is really going to, you know, imply some preciseness that you're really not meaning.  

So for a project to be accurate, the project leadership needs to exert project control.  So what I mean by this is, you know, especially if you are someone that works in the RFP space and you provide estimates for projects really early on.  What we need for that estimate to come true is for the project leadership, whether it's technical leadership or the project management to really drive to that budget.  They really need to stay on top of the developers to make sure we're not spending lots of time for things that we don't need to, that we're focused on the right things.  We need to make sure that the client doesn't add requirements as we go along.  They need to be diligent about that.  Those things need to be added to the estimate or addendums to the SOW, whatever it is.  

Ultimately, if no one is paying attention and no one is really steering, if we're just going through the day to day motions of let's have our standups, let's do the tasks, let's move the board, if no one is really keeping their eye on the big picture and making sure we're staying true to what the estimate was and the assumptions that were there, you're going to go over budget.  You're going to go over time and budget.  It's just going to happen.  

Steve McConnell, in the book that I'll mention later on, had a great quote, which is a good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.  

Again, I think about a project like Transatlantic navigation.  If you leave England and you're trying to go New York and you don't constantly keep apprised of where you are in the ocean and, you know, you're making these tiny corrections, if you're not doing that, you're never going to get to New York City.  So these are the kind of things we're talking about.  You have to make the corrections to make sure you get to where you want to be.  

If something is hard to do, do it more often.  Estimation is hard.  So thinking about to that kind of uncertainty.  We're constantly getting information, and we're constantly getting more knowledge and these things will help us, like focus our estimate.  And tighten up the ranges as we go along.  When we do work at Bounteous, there's the estimate at the RFP range.  But then as we go along, if we do discovery and conceive, we write into our SOWs that we get to reestimate.  Especially if we've had to recommit to the build.  And even when we get into that build work, you want to start estimating.  You're going to use the T shirt size, by feature, there's lots of different ways that you can give yourself information as you go along to make sure you're staying on track.  

Underestimating a project by a significant margin will cause it to be even later or more overbudget than you'd expect.  Prefer overestimates to underestimates.  The first part is really true, and I'm sure we've all been on these projects where the estimate is for, like, 200 hours and it's really going to take you 400 hours, but you tray to manage to the 200 hours, and it blows things up.  We don't do things well, we're under pressure.  The code that we write is shoddy which makes maintaining even harder.  You know, the client is wondering, you know, after 175 hours and things are half done, what's going on.  So now we're in more meetings and we're writing more reports and we're writing more analysis, doing all these different things that certainly, you know, weren't considered in the estimate.  

And so it just taxes the team more and more and more.  It's just going to make you more and more and more later.  

Now, a lot of times we significantly underestimate a project, not because we want to, but because this pressure to get to a certain price.  

So the thing to keep in mind is that estimation and pricing are two distinct things, so we don't really want to confuse them.  

So when I do an estimate for a project, I will say, hey, it's going to take 2,000 hours, let's say, and it's going to cost so much money.  If we as a team don't like that idea, we want to win the work, there's some strategy behind that, you know, whatever the deal is, those are two distinct conversations.  We can price it differently.  We can make an investment.  There's lots of things that we can do on the pricing side.  But ultimately, what we don't want to do is lower the estimate and the amount of time that we're going to take to do it, because again, going back to the last slide, it's just going to make things harder and harder and harder.  

So if you think it's 2,000 hours and you pricing as though it's an 1,800 hour project, you really need to keep managing it as though it's a 2,000 hour project, otherwise bad things will happen.  

My last little principle is when you're doing estimation, we want to use multiple methods.  I use two, typically.  I compare the results.  So whenever I estimate a project, I go through and I use comparison based and oftentimes, I'll take that a step further and do comparison based with decomposition, and I'll get    you know, I'll see that that's out.  And then I might do something, you know, like counting or I might use the teacher size feature thing.  

But ultimately, I want another point to mach sure that I'm in a good place.  That I think this is a good estimate.  Sometimes I'll also just pull in a colleague, and just see where we are.  But ultimately, you don't want to count under the one estimate, because you want to spot that if you can.  

In summary, I pulled up four things from this talk.  One is it's really important to understand the question that's being asked.  A lot of times that's cost or length of time.  But whatever the question is being asked, you want to make sure that we understand when we do the estimate to make sure that we give the proper perspective to whoever is asking that question.  

Remember the cone of uncertainty early on in the project.  Things are very uncertain.  Ranges should be pretty wide, as we get further and further along in the project, we can tighten up our ranges.  

You have multiple estimation approaches at your disposal.  I've shown you the things that I like to use.  There are more, and you probably have more or different ones as well.  Just know which ones you're comfortable with, and when you're comfortable with them.  

And then lastly, prefer data to expert opinion.  You know, there are things that we're going to have to do our expert opinion on, because we just haven't done it before and that's fine.  But as much as we can we want to prefer data because it takes the bias out of things.  

In preparation for this talk, along with many years of experience, I read a couple of books that are really good.  Software Estimation Without Guessing, that came out in September and I really love their brooks.  So I recommend that one.  

And Software Estimation:  Demystifying the black art by Steve McConnell is a really amazing book.  And I really like all of McConnell's books that I read.  I recommend that one as well.  

Please provide feedback.  Here is a link to my session, and also on the session, you can find these slides.  And thanks to the partners for captioning the sessions.  It's great to have that.  

Contribution Day is still going on from 10:00 to 4:00.  So please give back to the community, and with that, I'll say thank you and ask if there are any questions.  

>> ANDREW OLSON:  Thanks, Chris.  I don't see any questions quite yet, but please throw those in the Zoom chat.  A lot of clapping going on, which is great.  

>> CHRIS GREATENS:  Appreciate that.  

>> ANDREW OLSON:  The last slide again about Contribution Day?  I'm not sure about that.  

Let's go to the next one.  Thanks, I like to use ranges as well, but clients just ten to assume that higher range is real estimate.  Any suggestions, Chris?  This is from Luke.  

>> CHRIS GREATENS:  It's a good question, Luke.  You know, I think    I mean, yeah, it's tough, right?  Because frankly, I think it tends to be more higher than the lower as well.  But I think what you can do is use some of your real data.  I mean, if you've been tracking this stuff, you can even talk to them about he's done most of these projects and we fall right in the middle of the range or we fall closer to the top end.  

I think we can even guide them with your words when it comes to that.  For given ranges, especially if they're not super wide, and I certainly can't get away with that range.  

So I'm okay with    I'm okay with that range and I'm assuming it's at the top end.  Also could make sure that it goes to the lower end of the range as well.  

>> ANDREW OLSON:  Another question is I'm not sure I understand the difference between bottom up and decomposition.  Can you clarify?  This is from Andy Blum.  

>> CHRIS GREATENS:  Okay, Andy, I will try.  I think the big difference to me is the size of the chunks that I'm breaking them down into.  So comparison based estimation and when I'm doing decomposition.  A lot of times it's pretty early in the process, and so I might say there are like 12 content types and I'll generalize between the content types.  

Or I might say there are 40 components and I'll generalize to the 40 components about how long I think it's going to take.  

When it comes to testing composition, I'm saying there's a hero banner component, there's a code component, there's a location component, there's a slider component, a three up component.  Like, I will break them down to very specific things and I will estimate those very specific things.  Or compare it to things that I've done before.  

So it's just a matter of the amount of detail and the amount of time I'm spending on it, because, you know, the more time we spend on an estimate to a certain degree you'll give more accurate numbers.  A lot of times, depending on how close I need to be is    I'll decide whether or not I'll deep dive or not.  Hopefully that helps out.  

>> ANDREW OLSON:  Great question here.  Can you speak a bit to value based pricing estimating versus hourly?  

>> CHRIS GREATENS:  Value based pricing versus estimating    or estimating versus hourly.  I'm not    maybe Steve you can clarify that for me.  I think, you know, if we're talking about, you know    value based estimating versus hourly.  I mean, typically I always do the hourly    you know, I start with hourly, especially if I'm doing, you know, new business work.  To come up with the targets or whatever.  

Now, after I have an idea what it's going to take  

>> ANDREW OLSON:  It's clarified here.  Basically, there's a value around let's say a logo design... not hourly.  What's it worth to a company, because a logo might just take an hour to do.  

>> CHRIS GREATENS:  Yeah.  I think this gets to the heart of estimation is not quite the same as pricing.  So I think, you know, what I'm trying to do, especially in my position is tell us how long I think it will take.  But I think to your point there, ultimately, you know, if there is value    you know, if there is more value to your client, than the hour or so it takes you, you should be charging for that.  

You talk to a plumber and they take the screwdriver and they make a couple of turns and they fix the problem, and it didn't take very long.  It's like, take an hour about what to do and 30 seconds to do it.  Part of that will be estimating how long it takes to do the actual work and what goes into it.  

But just because you make an estimate and it says this is how long it will take doesn't mean that your pricing has to, you know, to reflect just the hourly wage.  It can certainly require representative value.  

>> ANDREW OLSON:  Another question, from Beatrice.  Sometimes devs can start to feel a lot of pressure and feel longer estimates somehow signify incompetence, which is so, so wrong.  How do you maintain an encouraging environment for proper estimation if those feelings have crept in?  

>> CHRIS GREATENS:  That's a great question.  I think part of this is having the understanding, having done this for a long time, that, you know, typically developers are happy people and they typically underestimate everything anyway.  

So for me personally, if I talk to one of my devs and they tell me how long they think it's going to take, like, I just multiply it by a factor, because I just assume that it's    they're like me and they're going to underestimate it.  

I think the best thing you can do as a developer is just have transparency.  Because, you know, I think when we have these types of challenges or conflicts or whatnot, it's because we just are misaligned on what the problem is and how to solve it.  I think it's like, these are the estimations I've made.  

You know, a good example is the thing early on where you talk about, you know, with the developer giving the example or giving the estimate at the watercooler.  They get back to desk and they realize all these things that are wrong.  You know, it's hard    you know, like, those impact your estimate and those impact how long it takes you to do it.  

And so it's    you know, I think to me as the developer, it's just important to articulate what's taking you, you know, longer and longer to do.  

Again, I would encourage people to range things, even if it's a task.  If you say something is going to take four hours and it takes five hours, to me, that's like totally accurate.  Like, I'm totally comfortable with that.  

But I think using some of these techniques can help convey the challenge you're facing, and it can be    if I ask you to do    you know, like build a content type, like, you've done that a number of times, assuming there's nothing weird about it, like, we're pretty good about that.  But asking you, you know, to build a custom module to do some integration with a custom system, like, you know, that's going to be a lot rangier.  So just make sure that you essentially place an uncertainty into the estimate.  

I like Dan's comment, too, which is that he usually views the estimate as being a time that people can check in to see what the group wants to do.  

Yeah.  If something is taking longer than you expect, maybe it's time to regroup on the solution.  Maybe we're making it harder than it should be, or maybe Drupal just doesn't do this well.  There's lots of reasons that they have nothing to do with capabilities, and so we should talk about those things.  

>> ANDREW OLSON:  Any other questions?  Feel free to use the Zoom chat to send them through.  We have about five minutes left.  

Also, just to let everybody know, I put a link to the session to get the slides and to rate the session, so that would be great.  

Another question.  Do you ever insert language in statements of work to unlock additional hours when a client might push a project stage beyond the estimate?  I've been squeamish to do this since it presents uncertainty at the stage level.  

>> CHRIS GREATENS:  I mean, so we do typically try to cover ourselves with statements of work.  One of the ways we do is it we like to work by timing materials, and like we get which    we take this much time, you're going to pay this much price.  

But we can't always do that.  The other thing that we can do, you know, especially in our types of projects, you know, where we're going to go through like a couple different phases, we reserve the right    like, if we have to commit to the bill before we know all this stuff, then we write into the SOW, like, we get to reestimate.  

So if the client comes to us and says, you know, we want you to    the statement of work to cover the conceived in the bill, we get to come back and have a chance to deep dive into the requirements and build out the architecture and go through all the    you know, the XD exercises.  We get to come back to this estimate and make sure we do it.  

We also just suggest, like, that they have some kind of contingency, and our contingencies typically vary based on essentially how confident we are in the project and what we've done.  So the answer is yes, we do this, but ultimately we    you need to protect yourself, but you also need to protect the client, too, right?  Which is why I prefer, like, time projects as opposed to fixed bid, because if it's fixed bid, I'm going to jack myself up.  Time and material, it's    you know, to me it's more of a joint, you know, assumption of risk based on what's going to happen in the project.  

>> ANDREW OLSON:  Another question from Luke.  I was going to ask about general suggestions on updating clients on estimates.  Besides being proactive rather than reactive, any other suggestions?  

>> CHRIS GREATENS:  I think it's that.  I think it's, you know, being proactive.  I think it's being transparent.  You know, like as you do this.  I don't    you know, I don't and we don't do estimates, you know, and reestimates like every week.  But you've got a good sense as to where things are and if we've had a couple of bad sprints in a row, I probably want to re evaluate it.  We use weekly communications with our clients, and we talk about budget and timeline and, you know, red, yellow, green, like where they sit.  

But I think, you know, that's the best thing that you can do is just be open and honest and transparent with the communications, because the last thing you want to do if you're in the build and you run into some problems is surprise the client.  You don't want everything to be green for four months and all of a sudden be red.  That's our problem.  And Dan's got a nice suggestion where he does weekly check ins and they use Gantt charts.  I think it's a similar message.  Like, have data, show it to people, even if you're not constantly doing reestimation, you have an idea of how you're burning down compared to what you've projected.  Make sure that you're commune indicating that.  

>> ANDREW OLSON:  Another suggestion I'll give is demos to the client as you go to demonstrate progress.  That really helps give them an idea of where it is.  

And one big red flag that I've had on projects is when you start canceling demos because it's not demonstratable progress, is when things start taking a turn around a corner that you might not come back.  

So, when you have those scheduled demos and people say don't    let's cancel this week's demo because we don't have much to show, and then you do it two weeks in a row, you have to start asking some hard questions.  

>> CHRIS GREATENS:  Take your lumps.  Yep.  Take your lumps.  You know, I mean, because that's what's going to tell them, hey, the project isn't where    you know, it's not going as well as we want.  Absolutely.  It also is, the you know, the team has to, like, internalize it, like, hey, we miss this commitment.  Like, what do we need to do to make sure that we don't miss it again?  Absolutely.  

>> ANDREW OLSON:  Thanks so much.  We can take this talk to the hallway.  I'm going to put in the channel the Zoom for the hallway room.  I'm going to go ahead and stop the recording, and thanks, Chris, for a great talk.  And hopefully everybody can stick around for some more sessions in the afternoon.  Thanks.  

>> CHRIS GREATENS:  Looking forward to it.  Thanks, everyone.  Take care.