“What’s the level of effort?”

The dreaded question.

School taught you how long you could procrastinate before starting an assignment…and then starting just a bit beyond that point. Early on, it’s an innocent enough question. Those with a few wrinkles on their head know the underlying evil associated with The LOE. My team gets a good chuckle when I skim over their technical explanations and then not-so-subtly request, “So…what’s the level of effort?” They see me as a developer no more.

Developers tend to work on projects for a fairly long time. As time passes, passionate, devoted developers become personally invested in projects. They want to see it succeed and do well. Projects are like a relationship and estimates are the first impression. Nothing saps a human being’s spirit more than a volatile project built on a poorly constructed estimate. Let’s look at several common offenses that can doom your project from the start.

1. Rushing
We live in an age where technology is being pumped out. We, the tech industry, have set the precedent of high competitiveness and capability to build quickly. So are we really surprised that our non-tech coworkers have quick turnaround expectations on estimations? Doing an estimate the proper way without commandeering others’ busy schedules takes time. And, typically, tech projects require the largest piece of the pie. So why not slow down and do it the right way?  Rushing makes you miss important details that will haunt you later on.

2. Sloppy or nonexistent requirements
Technology does not infer anything; every logical step is explicitly instructed to execute. The more ambiguous a project is defined, the greater risk the project will miss the target and/or vision.

Sometimes requirements have to be left open to allow creative flexibility during the design phase of the project. If that’s true, tech needs to be re-estimated afterwards or aimed unnecessarily high upfront to compensate for the unknown functionality that has to be implemented. Let’s not mix goals/desires with requirements.

I had a good Dilbert comic strip to share here, but I didn’t want to pay the license fees for it.  Just google “Dilbert Estimate” and get quite a few “I’m laughing because it’s true” moments.

3. Weak assumptions
One would think the contract defines what you are going to do and if not explicitly written, it’s an easy discussion. Wrong. The funny thing about words is people imply so many things from them. Having to explain your estimate didn’t account for something because it was not explicitly written and your stakeholder thought that it was covered is still an unpleasant conversation. Suddenly, your client either feels like they had been deceived or they feel ignorant for not understanding. That’s not the goal! You’re setup for success if they are setup for success. Get into their head and write down explicit assumptions that protects your scope and their integrity.

4. Forgetting Life
Bathroom breaks, vacation, administrative work, emergencies, etc.. Life happens (a common theme of this blog!) and to not figure that into your estimates and timelines puts one or all of your goals at significant risk. Tech is expensive and many forces want to cut down estimates, but neglecting to consider incorporating contingency hours is eventually going to cause the train to go right off the tracks.

5. Shotgun Estimating
Building a large project in haste without proper planning or requirements (see everything above) in the hopes of it sorting itself out during the course of the project has historically not worked well in my experience. Large buckets of money can disappear very quickly when you get deep into highly complex software projects. It’s better to break projects down into more consumable portions and put down wide ranges for the future phases noting that they’ll have to be re-estimated once you get the current phases done. If you’re dealing with a large budget, start breaking it down into milestones as quickly as you can. Continue the estimation phase even if it’s already done.

6. Percentages
Using percentages is a crime. It’s an insult to the people who have very real, day-to-day, time-consuming objectives throughout the course of the project. Every resource should have X amount of hours for each and every task they are planning to do. At the end, you want to compare how close you came in on each task. You gain nothing from a having a resource that’s 15% of some arbitrary number.

7. Going Solo
I have my weaknesses and my strengths, as does each and everyone on my team. The strongest estimate is one that is done divvying up the various tasks to best fit the team’s strengths accordingly. If you are filling in hours for another resource or team, you could be greatly missing the mark. Let them have a say and furthermore, let them take ownership of hitting/missing their hours. If they miss the random hours you put in, it’s really easy for them to put the onus on you.

8.Estimating in Silos
Estimating processes often turn up like Jr. High dances: no one goes across the room to talk to the other side. Stop that. Gathering details of what creative, UX, strategy, marketing, copywriting, etc. are envisioning can only help your team bolster hours to ensure they can meet the expectations. Also, providing feedback to those other disciplines can shed light and make them compromise accordingly to ensure a sound scope.

9.Taking it Personal
Estimates are always negotiations. It amazes me how many people get personally offended when their hours are questioned. There needs to be push and pull for the betterment of you, your team AND your stakeholders. Don’t let this drag you down or threaten your numbers. A reduction of your hours should always come along with stronger, more limiting assumptions and requirements. You need to take this hardline stance to ensure your project’s success.

Summary
I was taken aback a few months ago when I was complimented on how well I do estimates. Quite honestly, it’s hard to feel like this is a skill given how non-scientific it is often approached. Nonetheless, I’ve refined my approach through countless experiences and missteps. I’m guilty of all the “sins” above. I’ve tracked all of this closely and made sure to learn and grow each time. The one thing I know is estimates are often a very, VERY small portion of the overall project and doing them wrong can make long, drawn out projects incredibly taxing. It behooves me to fight the good fight up front no matter how unpleasant any conversation may be. Because a good estimate often leads to a happy team, satisfied stakeholders, a quality project and a reasonable budget that can be done within a reasonable time.  You’ve heard this before.