It’s no question that estimates still play a big role in modern-day planning. It’s easy to see why. Estimations give us a mental model of what’s possible in a given timeframe. Having an estimate gives us a sense of security that we know what’s coming and based on which we might drive the rest of our plans. There’s one big problem with it though – it’s often a false sense of security.
The time it takes for us to deliver expected results is a direct product of hundreds or thousands of decisions we make as we execute the work. In the software business, these decisions range from what kind of usability and function we want to deliver, how we design the software, where we add (or remove) code, who writes the code, who reviews it – an endless list, honestly. Adding to that, external factors and circumstances that we have little control over can easily throw off any picture you might have had about the future.
Essentially, estimating work makes assumptions about decisions that haven’t been made yet and circumstances that haven’t happened yet. That makes them mostly unreliable. Granted, some types of work require little decision making and are then easy to predict based on past experience. For the most part though, this is not the case. Think about it – when was the last time you actually felt confident about an estimate you made?
Priorities, outcomes, options, and decision factors
Planning is important, but I argue it should not be thought of as a decision in itself. Instead, the output should be a decision making framework. Here’s what I propose as a structure for planning, instead of the typical estimation model – priorities, outcomes, options, and decisions factors. For the giggles, let’s call it “POOD” for short.
First off is priorities. What are the most important things you need to get done in this timeframe? This parameter sets the tone for the most basic decision your team and its members will have to make every day – what do I work on now?
Second – outcomes. Does your team understand what the expected results are? This is fundamental to the widely-accepted practices of test-driven and behavior-driven development. Fully understanding expected outcomes allows everyone to be on the same page on what is actually “done” and that will serve as a driving factor in the decisions you make. There are two types of outcomes as well – your minimum definition of done, and your nice-to-haves. Identifying where each outcome belongs further helps your team make correct decisions on priorities.
Next up are your options and with that, the decision factors (or constraints) you need to establish. Options give you a decent picture of how things might play out without overcommitting to any particular route. Likewise, setting and aligning parameters on how your team should make decisions makes it easier to meet expectations.
While there are definitely decisions to be made when planning work, POOD leaves enough room for your teams to confidently make critical decisions as they’re needed.
Quality, cost, and delivery
In spite of all the outdated concepts in management, the QCD (quality-cost-delivery) triangle is one that has aged surprisingly well. It’s still applicable to this day and in both traditional and modern process models. Common in a lot of agile frameworks, for example, the principle of fixed-time, variable-scope is built on this very concept.
Instead of estimating work and trying to stick to those estimates, play around with the QCD triangle. If the delivery side is rigid (e.g. you have a fixed time to deliver or it will no longer be relevant nor useful), work out your cost and quality parameters and see if you can reset and adjust a bit in those areas. If the quality requirement is fixed (e.g. if you need to pass certifications to sell your product), consider stretching out your delivery and cost. Of course, communicating these priorities to your stakeholders is vital. Manage expectations on what’s flexible and what’s not, so that everyone is on board on whatever decisions might be made.
Being able to understand and work fluidly with your QCD triangle and the corresponding constraints will ultimately give you a much more useful mental model of what to expect – much better than estimates ever will.
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.