Estimates are very important if you want to be successful at handling projects. If you start with a poor estimation process, the project likely will be doomed to failure. To better perform a promising estimate, you must guide each estimation-process issue toward a repeatable standard process.

Having a smart process helps reduce the uncertainty level. This is critical when facing presales stages because having the most accurate estimation results will help you deal with the project plan. This also allows the process to run more smoothly, even when you’re dealing with strict deadlines and deviation risks.

It is vital to involve a team of experts in both the estimation process and the early stages of the project. This helps the manager reach a more accurate estimation by maintaining a consistent team.

Lessons Learned

The estimation procedure must be a repeatable process the team performs at the beginning of any project, regardless of the methodology or development lifecycle being embraced.

It is also highly recommended that the team holds a “lessons learned” meeting at the end of each stage, with the ideas and decisions that come up during this session being used to plan the next stage. These sessions must be held to review the estimate the team assessed beforehand, introducing new variables that were not taken into account in previous stages or in former projects with a similar structure. This practice will allow the team to improve new estimations.

Usually, these “lessons learned” sessions are intended to review the following things:

• Stop: Which things didn’t work that we are going to stop doing?
• Start: Which things were missed that we are going to start doing?
• Continue: Which things have we done properly that we are going to continue doing?

Underlined by this sound basis, you have to review the efforts worth your time before facing each stage of the project.

For example, some testing tasks are disregarded due to the assumption that there will not be complex issues to be sorted. But when the test team faces its duties, it realizes there is a little bit more effort required for some test cases to be executed. This complexity can stem from technological issues, new alternative flows that weren’t considered in the first approach, and so on.

It is also common for teams to disregard testing efforts for changes that result in very low or insignificant development efforts. But any change, no matter its importance, may severely impact product quality.The development team has to solve defects that were informed just after finishing each test cycle. More often than not, this effort is not estimated and leads to over-budgeted projects. Your efforts can be effectively measured and improved after running several cycles.

Based on the team perspective, it is easy to disregard organizational issues in the estimation process. These issues can be more related to shared resources, knowledge management, and external risks, among other things. Nevertheless, in spite of the fact that these issues may affect the estimation’s outcome, the team must perform the estimation by considering task efforts only. Thus, organizational issues must be managed within the risk-management process, and they must be depicted in the project plan in addition to the estimation outcomes.

Breaking Down Buffers

More often than not, team members add a bit of extra effort to the original estimation, or a buffer, in order to be more loose-fitting. This is a bad practice. The estimation must be totally honest, with every possible issue put out in the open for all team members to see. It is essential that each member of the team manages the same concepts and assumptions. Any discrepancy will produce untrustworthy results.

In order to avoid incorrect numbers at the start of any estimation session, there must be clear directives and rules, such as:

• “We are going to estimate efforts, not risks.”
• “We are going to estimate in terms of man-hours,” or “We are going to estimate by complexity.”
• “We are going to estimate efforts assuming one person is working nonstop on each task. No breaks, no weekends, and no holidays. We are going to estimate efforts without assuming any schedule or timeline.”
• “We are going to estimate assuming a standard semisenior profile to perform tasks.”
• “We are not going to use buffers to save deviations.”

Estimation outcomes must only provide measurements in terms of effort or complexity, not taking into account coffee breaks, possible risks, or buffers. Risks, breaks, and buffers must be laid out in the project plan and schedules.

Each team member has to be clear on these rules to produce results based on common concepts and assumptions.

Sharing Different Points of View

A good way to lead the team to a consensus is to allow members to share opinions. When there are discrepancies or a huge gap between two or more measurements, it is smart to allow team members to expose their points of view and explain how they reached certain outcomes.

This method is implemented by several methodologies, such as Wideband Delphi, Scrum planning poker, and Extreme Programming. It is the best way to assure that the team is comfortable with the final results, as well as to be sure that there are no unresolved issues.

Once the differences have been discussed and members give their opinions, the point at issue must be estimated again until the team comes to a consensus.

From here on, it is important to distinguish between a leader and an enabler. The former will push the team to take his estimation, excluding other members from the decision-making process. This type of micromanagement does not usually work. On the contrary, the enabler will involve the team in decisions being made and will ask members to perform the assessment, making the estimation more honest and successful.

Done Is Done

Another issue that matters when performing good estimations is to agree on what “done” means. To better estimate efforts, it is vital that the team clearly knows when something is done and what items need to be completed to reach that state.

Controlling the Problem

Finally, one of the main things to keep in mind when estimating projects is breaking down the scoped work as much as possible. If you have to estimate a skyscraper, you probably don’t have any idea where to start. But if you figure out how many walls you have to rise up and how many bricks you’ll need per square meter, you will place yourself in a bargaining position to accurately draw the project plan.

When pieces of work are smaller, you have more control of this now measurable problem. You probably don’t know how to quote a skyscraper, but surely you know the price of one brick.