How large is your project?
It’s projected to cost $2,000,000.
That’s cost. not size!
How large is your project?
We believe it will take 14 months to complete.
That’s schedule, not size!
How large is your project?
It’s going to be a 25-person project.
That’s staff, not size!
Software estimators often think of project size as what a project produces (features, stories, requirements, function points, or code). These are what a project has to create or account for in order to fulfill its mission. Business leaders, understandably, are more likely to visualize project size in terms of resources expended (cost, time to market, or FTE staff). These competing definitions of “size” can produce confusion and ambiguity. Which leads us to Tip #1.
Tip 1
Be prepared to explain to business leaders how quantifying project size (as seen by an estimator) helps business leaders get more accurate estimates of the things that matter to them: cost, schedule, quality, and staffing. I find a graphic like the one below from SLIM-Estimate can be useful to illustrate the relationship between a project’s size (primarily of interest to development staff and project managers) and the major project management metrics of interest to the C-suite.
The dialog can go something like this: “This chart shows the relationship between how much software a project produces and the amount of time (schedule) required to design, code, and implement the finished product. The blue triangles represent duration in calendar months for completed software projects. The black square represents an estimate scenario. Note that, in general, as the amount of delivered software increases, so does project duration. Of course, there is some variability; but the relationship shown by the average trend lines is apparent. Similar graphs for cost, effort, and staff show the same behavior: increases to project “size” (delivered scope) are highly correlated with increases to the project’s final cost, schedule, staffing, and defects. So, when estimating cost, effort, schedule, and staff an important input is an estimate of what the project will produce.”
Be prepared to answer questions about the trend lines and the logarithmic scale on the axes; but be careful not to overwhelm your audience. The important point is that project size as you as an estimator understand it is a crucial factor in empirically determining what business leaders care most about: the resources required to execute the work.
Tip 2
Estimates are by nature uncertain. Consequently, presenting a probability range around your best estimates conveys the amount of risk (uncertainty) associated with various estimation scenarios. The default SLIM estimate has a 50% probability of completing within the cost, schedule, and staffing numbers it produces. SLIM tools model project risk by varying the inputs (assumptions) to the estimate using uncertainty ranges and Monte Carlo simulation. The result is a probability distribution for each major management metric that reflects the estimator’s confidence in the estimation assumptions. In effect, it translates uncertainty surrounding the inputs to uncertainty around the estimated cost, staffing, and schedule.
It will be wonderful if the project matches or outperforms your estimate; but half the time project cost, schedule, and resources will exceed their estimated values. To convey this very real “risk” succinctly, it can be useful to have a table like the one below to help the business leaders determine how much risk they are willing to accept.
If someone asks how these probabilities are determined be prepared to discuss how Monte Carlo simulation works with the uncertainly around size and productivity; but don’t go into this unless asked.
Tip 3
When possible, use multiple sizing techniques. Here are some possibilities:
- High level requirements
- Detailed requirements
- Function Points
- Epics
- User Stories
- RICEF objects (Reports, Interfaces, Conversions, Enhancements, Forms) for ERP implementations
- Use Cases
- Analogy (using the size of a similar completed project)
Story points, while useful for sprint planning and tracking, are less valuable for project estimation. Ideally, you want your size estimates to converge. If they don’t or there are outliers, it’s time to dig in deeper and determine why. Size estimates based on different metrics will never be the same. But when they converge, it increases confidence in their accuracy.
Tip 4
Be very clear about the project scope. Here, scope means the included tasks and activities. Does it include upfront planning (Phase I in SLIM-Estimate)? Is post-implementation (Phase IV in SLIM-Estimate) included?
Tip 5
Determine the project’s highest priorities, and tailor your estimate accordingly. The short list includes schedule, cost, staffing, and reliability. In many cases, optimizing one factor affects the others. For example, if schedule is the top priority, cost and staffing often increase and reliability suffers. If high reliability is the most important driver, as it is for example for software running medical devices, schedule length generally increases to deliver the required amount of testing and bug fixing.
Tip 6
Be prepared to discuss trade-offs. One of the real powers of SLIM-Estimate is its ability to do what-if analysis in a matter of moments, while a work breakdown structure estimate could take days or even longer to reconfigure. The trade-off relationship between cost/effort and schedule can be eye opening! For some reason, business leaders often want an “aggressive schedule”. But schedule compression has a very real impact to budget and quality. Using SLIM-Estimate’s empirically-based modelling, powered by thousands of successfully completed software projects, you can easily demonstrate how adding a month or two to a project significantly lowers its cost and improves quality. Another potential trade-off is to defer some functionality to a later release so that budget and schedule constraints can be met. An important point to make here is that this needs to be planned up-front. Like the cost/effort schedule trade-off, this one can be quickly and easily illustrated. This brings us to Tip #7.
Tip 7
Document, document, document! It is not at all uncommon to be asked about the assumptions you made for an estimate you created several months previously. If you have not documented your assumptions, you may have trouble reconstructing how and why certain decisions were made. At best, you’ll have to scramble to get the answers. At worst, hesitation could undermine the business leaders’ confidence in parametric estimation – and in you.
An underlying theme is to have good communication between estimators and business leaders. Each views software development from a different framework. It is important for estimators to listen carefully, ask questions to clarify, and address the leaders’ needs with their estimates.