It has happened to all of us: you are asked to give a quick ballpark estimate – and suddenly your ballpark becomes precisely what you have to work with. You usually cannot avoid the question – as the questioner is often an influential stakeholder. But, in answering the question you may have to live with the answer.
We will look at ways to answer the question – and convey meaningful estimate information without pulling an excessive number of project resources from current project activity. And we will look at how preliminary estimates can shortcut the inquiry and provide decision-makers with sufficient information.
Top-Down vs. Bottom-Up Estimating
Each of these practices begin with a top-down estimating approach. A top-down estimate is one where a general number is identified and then broken down to help expose assumptions and refine for accuracy. Top-down estimates tend to be faster, but the speed comes at the expense of accuracy. You can quickly begin to assume the risk you are hoping to avoid.
By contrast, bottom-up estimates look at the individual activities involved in completing the work. The sum of the individually estimated parts rolls up to a total estimate – from the “bottom-up.” Bottom-up estimating is typically preferable as it provides a more thoroughly vetted answer. But, as we have said – in a pinch – you might not have the bandwidth to bottom-up an estimate.
Estimating by Business Value
Determining the business value of the activity will not tell you how much something will cost or how much time is required. What it can tell you is how much it can cost or how much time can be used before it is not worth doing. This estimating practice is typical of efforts to create an early business case for a project or phase. It can also be applied throughout the project to provide preliminary numbers before investing time in a more laborious bottom-up estimating practice.
A starting point is to anticipated the longevity of the outcome and determine how value of that outcome will be assessed. By dividing the two, you can then determine the necessary annual value for this area of the project for the work to be worth completing. If the annual value is unrealistically high to be worthwhile – you may have quickly disqualified the work effort.
On a recent project, we completed an early estimate for the cost of integrating an online fundraising system with a new CRM. We understand that the online fundraising system is going through a substantial overhaul and therefore was likely to change significantly in the next few years. We also knew that the deployment of the CRM will require roughly a year of implementation starting in the next few months. If we assume that the online fundraising system will change significantly 3 years from now (a generous margin) and subtract 15 months for CRM deployment – then we arrive at a lifespan of for the integration at 21 months or less.
This is our business value schedule baseline: we must be able to realize a business value greater than whatever it costs within 21 months. In this case, business value is primarily assessed in fundraising dollars – as both systems are part of the fundraising architecture.
Few organizations would pay $1 in integration for $1 in fundraising value as it would imply that every dollar raised was used to pay for the integration that enabled raising it (plus any other overhead). Our math quickly refined the value as needing to realize at least 400% the value of the cost in 21 months. In other words, if the integration were to cost $200,000, we would need to see $800,000 in value (e.g. fundraising dollars) directly attributable to the integration within 21 months – or roughly $450,000 /year.
The organization might decide there are other factors such as the constituent experience. Or, more greatly value those donors generated via this system and adjust the multiplier accordingly. But, the exercise quickly began to provide us with an umbrella number under which we needed to consider our options. We began to step back from putting energy into real-time integration in favor of a nightly batching process. We also began to reset expectations around integration scale and complexity.
Again, this approach does not tell us how much time or energy the task will require. It simply tells us how much it can cost. This information begins to steer us in the direction of a set of options that can be explored in greater detail to define a more precise estimate – or it can quickly disprove the activity altogether.
Estimating Against the Triple Constraint
Project Management literature often refers to a triple constraint of schedule, budget and scope. Impacting one directly impacts one or both of the others. They are directly tied together. While this is typically seen as a limiting factor – this relationship can be used to triangulate an early estimate. This approach is best applied when two of the constraints are known and fixed.
For example, if you have a fixed schedule and budget (as we often do in the nonprofit sector) you can more easily identify the scope. I ran into this most recently on a project where the go-live date was fixed at four months out and (without going back to the board) discretionary funds were capped at $50,000. When asked about the impact of adding a new element to the project our team was able to communicate that the real question was what scope could be accomplished within the known timeline (5 months) and budget ($50,000) – and we began our analysis from there.
The triple constraint approach does not fully answer the question. What it does do is begin to communicate what is reasonably viable on the project. It also provides an early opportunity for the party you are reporting to – often a sponsor or advisory board – to have enough information to decide whether to shut down the work or to dedicate additional project resources to more thoroughly estimating the work effort.
Estimating for the Possible
A third technique is to recognize the impossible early – and reorient the focus of estimating activity. The two prior practices share something in common – they might provide an impossible (or illogical) result and therefore end the estimating process before significant energy was applied to it. Estimating for the possible seeks to turn the question on its head.
The reality of project management is that there are unsolvable problems. Projects can and do fail. Good project managers have a sense of where the edges are – or the places beyond which a project cannot recover. Great project managers are the ones that can articulate the impact of falling off such an edge and steer the team clear of the danger.
On a recent project I was asked to estimate the level of effort of storing many hundreds of gig of data in a CRM system. The project team made clear that this was impossible (not merely improbable) in the current architecture even with an extravagant increase in budget. It was also entirely unnecessary as much of the data volume was duplicative, deeply lapsed or corrupted. Our focus was not on solving the impossible problem (storing the data), it was to solve for an alternate, solvable problem (reducing the file size). Our escalation was to request 30 days to analyze the problem – and prescribe a solution.
Summary and Conclusions
It is often said that you only truly understand the level of effort required to complete a project on its final day. There are simply too many unknowns throughout making any point – except for that final day – too early to truly be able to estimate a project. But, this will not stop our sponsors or advisory committees from asking. Our best bet is often to apply early estimating techniques to apply what we do know – about value, constraints and viable options – and communicate meaningful analysis based on the information available to us.