Estimating the solution
With your Work Breakdown Structure in hand, you can start estimating the real work involved in each group of tasks. Estimate the effort needed to perform the task in hours or days (measured in ideal engineering hours, assuming concentrated, uninterrupted work on the task). Don't fall into the trap of estimating in duration—duration estimates will vary wildly depending on how much non-project work the person doing the estimate expects to be doing at the same time.
Tip
Use small tasks
If you find that a work package has an estimate of more than 80 hours, revisit the Work Breakdown Structure and split the task into smaller subtasks. An estimate of 80+ hours very often indicates an incomplete understanding of the task and carries a large risk of overrunning the estimate.
The individual subsystem work packages might break the 80-hour limit and are, therefore, divided into subpackages.
Top-down estimate
If you are an experienced project manager, you can probably produce a rough estimate of the total effort involved in the project. For this, you rely on your experience with similar projects and your intuition.
Some project managers don't like the idea of using "intuition" because it does not feel scientific and exact. However, your other-than-conscious mind can process a lot of information and will be able to produce some quality input to your estimation process.
Of course, you don't start a multi-man-year project based solely on intuition—you combine the top-down estimate with a bottom-up estimate.
Bottom-up estimate
In order to produce the bottom-up estimate, you ask people capable of performing each task how much effort (in hours or days) it will take to produce the necessary output. Some projects prefer to let several people do independent estimates, while other project methodologies like Scrum prefer team estimates using collaborative techniques such as planning poker (see http://www.planningpoker.com).
Your work on the Proof of Concept will already have given you an idea of the effort involved in some common ADF development tasks, and the productivity you observed during the "infatuation" stage can provide a rough estimate of the final development speed.
You need to make clear what you include in the estimate—developers typically forget to include things such as technical documentation and repeatable test cases.
Note
The rest of this section describes an estimation technique often used for formal estimates that go into agreements and contracts—for example, when a system integrator is making an offer to a customer to build an application according to the agreed specifications. If you are an IT department building an application for internal use, Agile methods like Scrum, where development is done in a number of fixed time windows (called "sprints"), might fit your needs better.
If you ask someone for just one estimate, it is natural that the estimate will be padded with a bit of buffer time. All sorts of unforeseen complications may emerge, so a developer will try to anticipate these and include them in his or her estimate.
Unfortunately, even if complications do not occur, the task still tends to take the estimated time.
In order to respect the uncertainty of the task without padding every task with buffer time for worst-case scenarios, developers and others producing estimates should produce a three-point estimate for each task, detailed as follows:
- An optimistic estimate: This is the best case if things are easier than expected. You stumble upon a framework class that can perform the task, a wizard in JDeveloper generates code for you, and so on.
- A likely estimate: This is the time you realistically expect the task to take.
- A pessimistic estimate: This is the worst-case scenario if things are harder than expected. The class you thought you could use doesn't do exactly what you want it to, you run into a baffling bug when testing with multiple users, and so on.
Don't allow the pessimism to take overhand; you do not need the pessimistic estimate to include tornadoes destroying the test server.
Three-point estimates like these will clearly show the project manager which tasks are not clearly specified or carry a greater risk. If the pessimistic estimate is much higher than the likely estimate, the person doing the estimate is unsure about either the task or the means to complete it. This can be addressed by specifying the task in greater detail and possibly performing a short, dedicated Proof of Concept to allay any doubts the developer or other estimator has about the task.
The data set from three-point estimates can also be used to calculate an expected time according to the formula in Program Evaluation and Review Technique (PERT). This technique was developed by very clever people building Polaris nuclear submarines in the 1950s and has been used ever since.
The expected time is calculated as follows:
texpected = (toptimistic + 4 x tlikely + tpessimistic) / 6
This time takes the uncertainty into account and produces a better number than just using the most likely time. The three points will also be used for some clever math when we get to the end of the chapter, where we'll be adding everything up.
Your Work Breakdown Structure is likely to include many tasks of similar complexity. Naturally, you are not going to estimate each of these individually but rather estimate an average complexity for the whole group and simply multiply this effort with the number of code modules in the group to arrive at a total estimate.
For an ADF application, you might use the following grouping:
You can use more groups if your application has a wider variety of tasks, or you might estimate a few hard tasks individually if they are of a higher complexity than your other "hard" tasks.
Tip
Estimation: art or science?
Three-point estimates, as described earlier, are a way to add some scientific rigor to the experience-based estimates produced by developers. There are other estimation techniques like Function Point Analysis (http://en.wikipedia.org/wiki/Function_point) that attempt to apply an even more scientific method to the estimating process.
Research shows that the average of independent estimates from several people is likely to be closer to the correct value than any one estimate. Many Agile development methods also recommend you to involve developers, architects, testers, and customers in discussions of the estimate.
You can try this in the office: ask your colleagues what the distance between two well-known cities some distance away is. You'll find that the average of just five people will be pretty close to the real distance, even if some of the estimates are way off.
You don't need multiple estimates for all of the items in your Work Breakdown Structure, but for critical tasks or tasks where the worst-case estimate is far from the likely estimate, consider getting a second, third, or fourth opinion.
Tip
Just like the old one – the dangers of groupthink
If your requirements are a new system "just like the old one" and you are part of the team that built the old system, this averaging technique is not sufficient to arrive at a reasonable estimate. Developers who are intimately familiar with an application will underestimate the complexity of the solution dramatically. If you only have an estimate by developers of the legacy system you are replacing, experience shows that it is prudent to multiply that estimate by a factor of 2.
The following table shows examples of what estimates could look like for a few of the items from the WBS described earlier in the chapter. All estimates are in ideal engineering hours:
You'll notice that some tasks have larger variation than others. For example, usability testing is likely to take 80 hours, but might take up to 160 hours. The reason for the high pessimistic estimate is that we might need several iterations before the usability is as good as we want. For other tasks, the optimistic, likely, and pessimistic values are very close together. This indicates well-defined, low-risk tasks that we're pretty sure how to complete.