Architecture-First Project Estimating
Architecture-First Project Estimating
Overview
Project estimating is difficult. A familiar saying is 'the most accurate estimate can be determined when the project is finished', but obviously that is too late.
In general, projects have to be estimated before they are started. Unfortunately, not all the information needed to estimate is available during the early estimation process. At that point, there are plenty of unknowns and the strategy to build the application is not fully thought through yet. Equally problematic, the estimation process might occur before the Use Cases are created.
Some projects use the Time and Material model, but many projects are Fixed Price or Budget-based. In the Fixed Price or Budget-based projects, the team gives an estimate to the stakeholders so the project can be properly planned and staffed. The accuracy of the estimate can determine the success or failure of the project.
Overestimating leads to wasted money and possibly project cancellation before it even starts. Underestimating leads to bad decisions and poor quality.
Impact of Estimates
Impacts of inaccurate estimates are never good. Neither the stakeholders nor the project team will be happy.
There are plenty of impediments that can produce an inaccurate estimate. For instance, if the requirements are not fully developed then the estimate will be wrong already. In some cases, the project based on inaccurate estimates cannot recover and will experience significant problems.
Overestimates
Overestimates can also lead to big problems. If the entire project is overestimated it is possible that the project becomes to expensive build and is cancelled. It is also possible that the project is sent to another team that has a lower estimate.
If certain tasks within the project are overestimated it will affect the utilization of the team members. On the schedule, some members are blocked waiting for other members to finish. When members finish early then there may not be any tasks waiting for them to work on.
Underestimates
Underestimates are the worst of the estimating problems. They inevitably lead to poor quality and reduced features. At best, many features have to be de-scoped in order to meet the timeline and budget.
A project under this scenario has little chance of success. If a project is greatly underestimated it is impossible to make up the time difference.
A savvy stakeholder may successfully negotiate the project estimate downward, but may inadvertently seal the fate of the project. If there is not enough time to implement the features properly the application will not have the desired quality.
Task Estimate
The estimate above is part of a larger project that was estimated down to the task level. The estimate for the task is 40 hours and was underestimated by half where the real duration was 80 hours. This highly inaccurate estimate leads to some solutions below.
Task Duration with Heavy Overtime
If the developer works 10 hours a day every day then the task will still be late by one day (80 - 70 = 10). The heavy overtime approach does not fully solve the problem. Also, this overtime solution only helps the schedule and does not help the budget unless the developer does not log the overtime.
Of course, this solution can only be asked for during emergencies and in short durations. Therefore, the project will be be even later if the developer does not work consistent overtime.
Task Duration with Reduced Quality
The developer may work overtime, but not the extent needed and makes up for it by coding less. This approach is missing 30 hours of development and these are realized as missing iterations in the code.
The diagram above shows the normal developer lifecycle before a task is completed in hours. The developer performs analysis on the requirements and then proceeds to code iteratively. It is important to realize that all coding is done iteratively. Each iteration increases the accuracy and quality of the code.
The code after iteration 1 may work, but only for happy paths. It may also have large blocks of duplicate code or may improperly handle requests. Iteration 2 may include refactoring and unit testing. Each further iteration will produce better and better code.
In the diagram, the estimate of 40 hours only covers analysis and the first iteration of development. If the developer notices that the task is severely underestimated the developer may choose to use a short-cut solution. In other cases, the developer may deliver the code after only one iteration that will contain technical debt.
Producing Good Estimates
As discussed, estimates are difficult and can make or break a project. There are two main types of estimates: Coarse-Grained and Fine-Grained
Coarse-Grained Estimate
Coarse-Grained Estimates are often performed at the Inception Phase of the project. They may occur in a Request for Proposal (RFP) response or in Project Sizing. The estimators are often given a small amount of time to produce estimates due to a hot business item or equivalent.
The challenge is to produce good estimates with minimal information, minimal lead time and within a minimal duration. If bidding against competitors the estimate might occur without the ability to fully question the stakeholders.
These are essentially rough estimates. Unfortunately, these estimates may still be used in a binding fashion for the entire project.
The Architecture-First technique for Coarse-Grained Estimates is to grade the requirements on complexity. The grading is analogous to Story Points. It can be (Small, Medium, Large, Extra Large), (Low, Medium, High, Very High) or equivalent.
An additional estimation factor is the technical complexity, which can use the same scale. The technical complexity can vary based on items, such as
use of a current infrastructure versus a new one
new technologies that have not been used before by the team
team experience on related projects
The next step is to apply numeric values based on which roles will be required to fulfil a certain feature. These values are summed up and given as the rough project size estimate.
Fine-Grained Estimate
The Fine-Grained Estimate is far more accurate than the Coarse-Grained Estimate. The estimate can occur after the Use Cases and Domain Model have been created. The Fine-Grained Estimators know more about the system than the Coarse-Grained Estimators. It is the preferred Architecture-First estimation type if there is sufficient time to create them.
The Fine-Grained Estimate requires sufficient time to estimate properly. It is based on the estimators thinking through each Use Case and Feature to determine how to implement and who needs to be involved. The estimating process itself may find missing items in the requirements that must be supplied.
It is up to the project team to estimate in the most comfortable way, but a generally successful technique is to use the Work Breakdown Structure (WBS) technique. In the WBS technique, the solution to support the Use Case is determined and the related resources assigned tasks needed to implement the Use Case. Each of these tasks are estimated. The more fine-grained the estimate the more accurate. Therefore, if the lowest estimate is a week then there is a chance that something has not been thought through that can lead to slippage. If the lowest estimate is a day then there is less chance of that happening.
The tasks can be further broken down to the day range if necessary. There should be an estimate per Use Case at minimum.
Finally
Producing good estimates is critical to project success. Having solid requirements and Use Cases can help make accurate estimates. On the downside, if the estimates are off by too big a factor the project is in trouble before it even starts.
A project cannot make up for bad estimates. Either there will be significant date slippage or there will be a reduction of features and quality.