5 Rules for Succeeding at Project Estimation

Recently, I've made a change from working in consulting for the entirety of my career to taking on a product engineering role. I'm excited about the change, but now that I'm no longer going to be consulting day to day, I want to contribute my experience back to the community.

A project can fail before it even starts. If the project estimates are off, no amount of technical or management excellence will save the project team from pain or at the worst prevent the project from failing.

Through years of experience and failure, I've honed guidelines to help me ensure that projects I estimate can be completed within time and budget.

Before we start the post or your estimate, lets all stand up and repeat the estimator's mantra:

Hi, my name is {YOUR_NAME_HERE} and I am bad at estimating work.

Now that we've come clean, let's see what we can do to work past our imperfections and create as accurate estimates as possible given the limitations we're working under.

#1 - Failure is Always an Option

No matter what we want to think, failure is always an option.

The key, as stoic thinkers realized, is to anticipate how the failure could occur. For project estimations, anticipating failure risks allows us to plan around or document these risks. While no project can nor should be without risk, being aware of risk points allows the project team and client to plan and measure against where the failures are likely to occur. And if you can document the risk and the mitigation strategy, this could represent a significant advantage and opportunity in the pursuit for work.

To guard against surprising failures practice negative visualization by imaging that the project failed and asking: how did this occur? Was there another project that experienced similar problems? What did you or others do in that case?

Negative visualization seems counter-intuitive, after all, who wants to think about failing? However, the practice helps us hedge around the biggest challenges in estimating: the unknowns.

#2 Timing

Projects do not occur in a vacuum. To estimate accurately, you must consider the timing  of the key milestones and events occurring both within and external to the project. This does not mean you need to create a timeline to the nth degree, but you should at least get to the sprint level.

Beyond the basics of laying out the timeline, there are some helpful guidelines to consider:

• For initial project launches, at least two weeks should be allocated for launch preparations as well as a week for the launch itself
• At least two (up to 4) weeks lead should be expected for core team members to onboard / gather requirements before starting execution team members. 
• Clear due dates should be defined for all inter-team / client dependencies, common examples include:
  • Designs
  • Data Schemas
  • Integrations
  • Software / Hardware requisitions
• In addition to the in-scope tasks, time should be planned for:
  • Initial project setup
  • Discovery / documentation
  • CI/CD process definition
  • Content authoring / support
  • Data migration / support
  • Training / knowledge transition
    

Laying out the Project

There are two primary methods for planning a project timeline, depending on the primary constraint for the project:

Deadline Based

If the project is primarily deadline constrained, you will have to "back into" the timeline by adding team capacity to ensure delivery within the expected timeline based on the estimated effort.

Budget Based

If the budget is the primary constraint, you may be able to extend the timeline to reduce cost, but have to balance the overhead cost.

Once you have your effort estimations and team allocations, you can use this to lay out your project timeline. When laying out the project timeline and make sure you have:

• Enough time to kick-off and wrap up
• Realistic timeframes to get all of your dependencies when you expect them
• Considerations for holidays, shutdowns, etc

#3 Coverage

The entire project should have coverage for technical, operational, and functional roles. This sounds simple, but when the budget starts to crunch, it's easy to accidentally cut too much and end up proposing a team and project that won't work without a change order.

A common temptation is to roll off Business Analysts or Architects early since they tend to be expensive. Avoid this temptation, if at all possible, as senior support is vital for project launch / wrap-up. 

After all, you don't want a Junior Developer pushing the application live, right?

Be sure to consider all integration points with the solution. Do you have all the roles covered or do you need to bring in colleagues from other disciplines? This is both an opportunity and a potential risk. I've seen far too many silo'd experts in a particular stack think an ancillary technology is "easy" only to find that it's a project onto itself. Rely on and consult the experts.

When reviewing the project plan, every task needs an assignee, even if on the client side. The client (or any upstream teams) don't necessarily need to name a person, but they need to acknowledge they will do so and this should be called out in the contract. 

You also need feel that the assignee / client can realistically deliver the work. It's a delicate conversation to communicate a lack of capability. If the client is not willing to listen it's better to handle this with clear dependencies and contract terms.

#4 Estimation

Estimations should start bottom up, estimating the work at a task level. Break down tasks as granularly as possible. Having a bunch of one-line tasks is better for estimating than a paragraph explaining a blob of work. 

A good rule of thumb is to take what you think a task will take, then double it. Remember, the goal of a consulting organization is to leverage resources, so on average, the people doing the work will be less experienced than the people estimating the work.

When estimating tasks, be pessimistic but realistic. Channel your inner stoic, what could go wrong? Of that, what can you assume out (make sure these make it into the contract)? Anything else needs to be planned for.

Once the estimate is complete, align the estimate into a staffing plan with realistic timelines and complete coverage. Always calculate development time broken down by track and compare it to the estimates. It is easy to accidentally misallocate.

• Quality Assurance should represent 30-40% of the development effort, depending on scope and complexity
• 1 Business Analyst and 1 Architect can support a team of approximately 6 full-time developers. Larger teams will need more support
• Adding more resources does not reduce duration linearly. Coordination effort increases at a geometric rate as more team members are added
• Plan for meetings; developers will not be productive 40 hours a week.
• Team lead should be planned to be productive no more than 20 hours a week.

#5 Trust Your Instincts

Most of us know when something is too good to be true, we just want so bad to believe it's true we overlook the obvious. Similarly, with estimates, we'd rather believe a timeline is realistic than confront the challenging work to communicating reality to combative clients and eager sales people. 

If a client is reasonable, they will take reasonable recommendations and value your consulting expertise. Providing feedback and clarification up front is mutually beneficial as both parties reduce their risk.