Tech & Work

The politics of IT project estimations

Charles Seybold says there is a simple cure for much of the politics that can wreak havoc on projects: stop using single-point estimates and start estimating in realistic ranges.

At most companies, we have to deliver or lose our paychecks. Yet, we are so focused on results that we sometimes fool ourselves into thinking that, if we just wish hard enough, it will become a reality. This wishful thinking (plus the bad habit of single-point estimation) creates major political stress between project teams, their stakeholders, and those people that orbit around them (a.k.a. customers). Even worse, old school project management tools do us no favors in this regard.

The politics part is something I'm sure most readers will recognize. At the heart of it is a process often led by the same people week in and week out debating if something will take four weeks or five weeks and what change is needed to get people somehow working harder and hitting more of their milestones. It feels like continuous real-estate negotiation where nobody seems to win.

To be fair, the dynamic tension is real. On the one hand, you don't want your people sandbagging and slacking off; on the other hand, you want realistic estimates that you can make commitments against. The good news is that there is a simple cure for much of the politics: stop using single-point estimates. These evil little half-truths cause plans to go sideways all the time. Nothing illustrates this more than the estimation game.

The single-point estimation game with Steve and Bob

Steve is a grizzled hardball stakeholder. Bob, who is not grizzled, is a hard worker and eager to please. They use single-point estimation, which leads to a negotiation cycle that invokes the politics of self-preservation if you play it long enough.

Steve: I need you to add an API to the accounts receivable module. Bob: Huh? Steve: Look, the business depends on this. How long will it take? Bob: Ummm, 8 weeks. Steve: That's insane. What's the best case? Bob: Well, if the stars align, maybe 4 weeks. Steve: Great, let's assume 4 weeks in the plan. Bob: No! I can't promise it any earlier than 6 weeks. Steve: Ok, 6 weeks. Bob: #&$^%!

Bob has done stuff like this before, and he's 80% confident he can get it done somewhere between four and eight weeks. Foolishly, he's settled for the midpoint of six weeks as a promise since he wants to please Steve.

Mathematically, there is a 50% chance he'll run late and then take heat for that from Steve. If this game gets played multiple times, he'll quickly start quoting eight weeks to protect his own paycheck. The game itself forces Bob to start sandbagging. How does Bob get Steve to agree to eight weeks? You guessed it --he starts his next negotiation at 12 weeks. Where Bob comes from, that's called a lie, and he feels bad about it, but what's a worker bee to do?

Sandbagging is toxic to plans, especially when you can't see the buffering. Bob's project manager will probably pad things as well by goosing his number by 40% because "developers always underestimate," but I digress.

Fortunately, you don't have to settle for this.

The ranged estimation game with Steve and Liz

Liz is savvier than Bob. She knows single number estimates are a lie. She estimates everything in ranges to capture the realistic uncertainty that exists in predictions.

Steve: I need you to add an API to the accounts receivable module. Liz: That's pretty vague, but I feel 80% confident it can be done in 4 to 8 weeks. Steve: Look, the business depends on this. What are the odds of 4 weeks? Liz: 10%, best case. Let's spend this afternoon talking about requirements, and I can narrow that range for you for sure. Steve: Ok. When can I promise the customer? Liz: Right now, 8 weeks if you want a 90% chance of keeping that promise. If you want higher confidence, add a week. Even odds, we'll get it done in 6 weeks. I'm sure our customers appreciate predictability, so you probably should promise 8 or 9 weeks. Steve: Good point. I'll come back after lunch with more info. Liz: Great, I'll look through our past plans to see how long similar projects took.

This game is completely different because it's not a negotiation -- it's a dialogue. Liz can stand her ground because she is an expert on the issues that are driving the uncertainty. It's also clear she can't resolve the uncertainty until Steve does his part.

Does Liz worry about her paycheck? No, she has a strong track record of delivering inside the estimate range and managing away the uncertainly via collaboration.

Conclusion

Forcing people to ignore undeniable uncertainty injects mistrust into the social network and invokes the politics of self-preservation, which create a lot of bad mojo for today's organizations. Moving the social dynamic away from negotiation towards collaborative dialogue can have a profound impact on delivering results in a predictable and productive way.

Estimation and negotiation have nothing in common so keep them separate. You can easily achieve this by estimating in realistic ranges instead of using a single number.

Charles Seybold is the CEO and co-founder of LiquidPlanner, a maker of online collaboration software that provides teams the ability to easily capture and manage uncertainty in their project plans.

18 comments
jtheires
jtheires

This article poses scenarios that rely only on expert opinion to estimate duration. A bottom-up approach (using a size range) will better prepare you for defense, when the time comes. For example, Liz: "That???s pretty vague, but the last three times we did an API like this, it was between 1200 and 2000 SLOC, and took between 4 and 8 weeks to complete." Steve: "Look, the business depends on this. What are the odds of 4 weeks?" Liz: "10%, best case. If you need it for sure in 4 weeks, you need to remove 600 to 1000 SLOC of functionality. What part do you want me to leave out?" So, approaching this from a more factual basis leaves less room for Steve to twist Liz' arm. This kind of approach will always result in a better business decision, in the end. James Heires EZ-Metrix code counting utility www.ez-metrix.com

Tony Hopkinson
Tony Hopkinson

Cost. If a realistic estimate means something costs too much to start, what happens when the 'business is depending on this'. The estimates get cut so you don't look like the budget is blown from the get go. I don't know whether you are taking us for the sort of naive fools that buy bridges, but if you believe range estimation will solve the problem, I have this rather nice one for sale. I'll give you a vague clue, estimates are not actuals. Taking the high end even if the goal posts don't move for an off the cuff estimate still doesn't make it an actual. If you want an accurate estimate then you have to spend time and money to get it. Most companies on the basis that this effort could be 'wasted' don't bother and then sit around finger pointing when the estimate turns out to be a guesstimate. That's the actual politics of estimation.

patclem
patclem

Going for the high end with an estimate is considered "padding". The excess money takes away from other projects when other projects are cut during portfolio management because of the over-estimation. I see it all the time. Opportunity lost. Also - Parkinson's Law comes in to effect. If you say 6 weeks, it will take 6 weeks. If you say 8 weeks, it will take 8 weeks. Work will always expand to fill the allotted time. Look at real business deadlines (contractual, regulatory, customer satisfaction, lost opportunity, etc.) and work the schedule to meet the business need. Maybe it's worth putting the entire team on the project to get it done in 2 weeks. It's all about the business need.

dlovep
dlovep

Dont even think about estimate, when you get a project in Developing Asia Country, you're going to fix the DEADLINE, seldom have negotiation, what estimation ? you want to get your job done or yourself done ? After being work in western country, its totally different story, I start to realize its where I can apply estimation, planning and thinking about project.

Tony Hopkinson
Tony Hopkinson

no battle plan survives contact with the enemy easily maps to no project plan survives contact with implementation. Goals are flexible, resources are flexible, budgets are fixed...... Think away, I'm not saying it's not worthwhile, but always have contingencies in place. I want to make it clear padding estimates even if you can keep the extra is not real contingency planning. The estimate is based on what you think is required based on what you belive you have available now. Either of those two change you might as well have rolled a dice. It's the assumption that the plan is a concrete entity, that is the problem. In IT change is a given. Cope with it, or fail without a healthy dose of unearned luck.

uFunctional
uFunctional

Call out the difference between estimates and commitments. Estimates are ranges with probabilities, and that's just a non-negotiable fact. Know why you're being asked for a commitment. Is it a motivational tool? Does the project outcome have a real value-loss date (eCom site launched the day after Christmas). Is there some other business event driving it? Ask. Help them figure out another way to meet the objective, even if you can't commit to the original request. Stand your ground. This can take some verbal judo. Sometimes I throw out an original estimate that's ridiculously low. If I hear laughter, then I say, "We've just agreed on something. There's a shortest-possible schedule for this project. We just don't know what it is." The risk here is they don't have a sense of humor, or reality. "OK, I'll expect it in a week." Ugh. Prioritize, and use a short-cycle delivery method if you can. That can deflect scope creeps. "Yes, I'll put it on the list. Do I do it before 'end world hunger' or after?" It's a lot better place to be out of time with 75% of the features completely done than out of time with all of the features 75% done. Stand your ground. Just say no to absurd demands. Really. Every now and then you have to pull out all the stops, but if your customers are always operating that way, you're just enabling their risky behavior at your (and your family's) expense. Stand your ground. Consider switching to metrics-based (or as Steve McConnell calls it, count-and-compute) estimates. If there's something about the requirements you can count (I use function points) and you have historical data, that holds up a lot better in a negotiation. Back at the height of the dot-com hysteria, I convinced a personal friend of my company's founder and owner that he was going to have to go back and tell his investors that the launch date he promised them wasn't going to happen. This was possible because our project data showed that we were going to have to beat our own team productivity record by a factor of two in order to hit his date. Recognize that the person pressuring you is often being pressured by their boss. Proactively help them with that negotiation if you can.

mcarr
mcarr

It's all well and good to say that a task will take between 4 and 8 weeks, but what happens when a developer has two such tasks? The difference between the best and worst case scenarios is two months. Repeat that across a couple of developers and all of a sudden the PM doesn't know if he has a year of full time work for a new developer, or no need to hire anyone. On top of that, there is no possibility of providing a fixed price quote - no customer is going to accept an overrun of 100%, so you quote the full 8 weeks anyway, or quote 6 if you feel the gamble is worth it. Then there's the issue of buying the work if the customer has promise or you owe them... A fixed date is a line in the sand for everyone. It doesn't mean that anyone has to lose their job over missing it, but it provides an appropriate point of reference. Fuzzy durations don't do it for me.

uFunctional
uFunctional

First, one comment about something you said. "It's all well and good to say that a task will take between 4 and 8 weeks, but what happens when a developer has two such tasks? The difference between the best and worst case scenarios is two months." Ranges aren't additive, because of the way probability works. The 90th percentile for A+B isn't the 90th percentile for A plus the 90th percentile for B. Critical Chain project planning accounts for this. But my main point is that uncertainty is very real and unavoidable. Look at the "military maxim" post. If your project plan requires accurate estimation in order to succeed, you're just throwing the dice. If you have to fix a date or a cost (and you usually do), then the uncertainty has to land somewhere else--scope. And the only way to make variable scope work is to use a short-cycle planning framework (call it iterative, agile, whatever).

mcarr
mcarr

"Ranges aren't additive, because of the way probability works. The 90th percentile for A+B isn't the 90th percentile for A plus the 90th percentile for B. Critical Chain project planning accounts for this." In my environment, developers are frequently working on more than one project at a time. I need to consider the sanity and satisfaction of my developers as well as the dates - I can't pull them back and forth between projects at inconvenient points as it's too disruptive. "And the only way to make variable scope work is to use a short-cycle planning framework (call it iterative, agile, whatever)." Sure, but how is that incompatible with a fixed timeframe? We employ iterative development not because it improves accuracy in time estimates, but because it makes for better development and more transparency to the client.

save_clippy
save_clippy

Sounds like a plan. I tried something like that before in my last company, but all I got was "I need you to commit to a date"... and then as time went on, as expected, more and more features kept getting added on.

jmgarvin
jmgarvin

Statements of Work: Produce X with Y features by Z. I've had too many gigs go sour because somebody wanted to tack on extra crap towards the end or because they didn't understand their process, I was to blame when the software didn't work as requested.

AlphaW
AlphaW

I guess I am cynical too. That is all I ever get over here as a PM, and then constant scope creep. I try my best to do projects properly but here are the issues: 1. Sponsors (other managers) do not want to be bothered to define anything and expect mind reading. 2. No one cares that the development staff already has 50+ hours of work to do already, this "new" project is the most important one and they are all due in November. 4. Constant shifting of responsibility from the business units to IT staff. Aka - Logistics manager tells the CEO, if only IT would build this application we could get what you want done but not before. 5. CEO, COO, and CFO refuse to prioritize anything but always want to know in hindsight why something did not get done first. Guess this struck a nerve today...

lanabtg
lanabtg

AlphaW - you work where I work?? Unfortunately I can relate with ALL of your issues listed, they happen daily here, too.

Ian Thurston
Ian Thurston

There are things you can do to make this approach work well: 1. Bad news doesn't improve with age. For that matter, good news has a short shelf life too. Tell 'em what's going on, early and often. 2. Write it down! Write down the best case, likely case, and worst case estimates. If there are possible events down the road you can foresee that make the best case more likely, or ones that will lead to the worst case, write 'em down. Then, "when the stars align", you can let your customer know and aim for that target. "When the heavens conspire against you" - i.e., the events that will slow things down occur, you can advise your customer. In both cases, no surprise. Constant feedback is the key: "we're on track for November 15." or "If all continues as is, we'll come in closer to November 10." 3. "If" (I hear you snicker "when") the customer starts talking as if your best case was what you agreed on as your deliverable, remind them that the plan has a best case, likely case, and worst case. 4. If this IS a mission critical project, and things are going slow, make it the customer's decision to either accept the pace or call in the reserves: "We can get this done by November 15, but only if we put in substantial overtime or add some more people. What's your call?"

pameacs
pameacs

Yes that sort of crap goes on the Author has a system that a lot of good project managers, experienced with the people and product they are working with can provide to get it done. Two things your project manager was either incompetent or lazy. Good PM's eat this sort of stuff. And the scope creep well that is just plain ordinary. Remember the old adage if someone asks "there are three choices , speed, quality and cost, pick any two" You can only commit to a date when you have the data and the key one for a developer to estimate from is quality requirements, without those pad like hell

cb0503
cb0503

one of the fun things in planning is trying to balance the risk/uncertainty and hence build in "contingency" in a way that is believeable and doesn't just lead to someone demanding you adjust the plan and take it all back out again. If you built worst case into all tasks, it would look unrealistic. So it has to be balanced - and some tasks will come in over, some under. Then it is a question of your team being educated enough in the process to understand that ! I'm not aware of a project planning tool that allows me to put in a "90% certainty of completion in 8 weeks". So while it is an interesting (if a little unsubtle) example, it is not something you can just take away and use without some judgement and experience being applied..

Editor's Picks