Scope and estimation

The budget of a software project is directly involved with the ability to define the scope and estimate the effort required to develop the solution. And any analyst with a minimum of experience knows that these are two extremely difficult things to do with accuracy.

The goal during the project initiation phase, on which the budget depends, is to reach a consensus as close to reality as possible on what should be done.

Both parties are very interested in the correct estimation, in order to minimize the risk of the project. This is the keyword here.

If the project is estimated less, the unforeseen events that will arise may make it impossible, in addition to losing the time to market. If it is overestimated, it is possible that the customer will give up on a project that would otherwise be successful or that other projects will be harmed, since the workforce will be unnecessarily crazy.

Change of scope

"Traditional" (such as the OR) and agile processes have mechanisms to deal with the inevitable changes in scope and mitigate risks.

The OR, for example, mitigates the biggest risks first by prototyping the most complex requirements and generating an executable architecture at the design stage.

Agile methodologies do this mitigation through constant, sometimes weekly, deliveries. They too they seek to postpone design decisions based on the idea that the earlier something is defined, the harder it will be to change later (casting).

The main difference when it comes to changes is that, while they are often treated as exceptional cases in "traditional" processes, in Agile methodologies they are the rule.

Scope open or closed?

Some time ago I wrote a article about the Iron Triangle to try to explain that in a project from software, we can't have everything .

The customer and some managers want us to deliver everything (scope), fast (time), cheap (cost) and with quality. But this is impossible!

The concept of the Triangle serves precisely to demonstrate that we must make choices, even if unconsciously.

For various reasons, "normal" development is done with fixed scope, time and cost. This means that when there are contingencies, the quality is sacrifice.

Agile methods try to fix the quality and keep the scope variable. This means that if a feature doesn't "fit" in the current sprint, it can be postponed.

Also, if the developers deliver a functional version of the system at each end of sprint , then the client may decide to extend the project to include more functionality or shorten it if they consider that the system is already good enough to production. This is supported by some research (lack of sources) that shows that users do not get to use most of the functions of a system.

In the ideal world of agile, the client would not need to receive a final budget for the entire project. Planning would be done on a relatively short horizon.

The problem with this is that if the customer wants to keep the scope fixed, then the cost and time would be variable, since New sprints would occur until that the scope was fully implemented.

Estimate

Postponing decisions and estimation is good because the requirements become clearer in the course of the project. At least in an ideal scenario. This is well represented by the Cone of uncertainty:

The problem is that this does not help in an initial project estimation! Even in Agile methods, initial estimation sessions are held to enable the sale of the project.

At the end of the day, it all comes down to the ability of professionals to estimate. This involves time, which, in turn, involves cost.

Effort to estimate

How much effort to spend on estimation? It is a complex question, but many authors agree that it can be neither little nor much.

"small" scope projects

For small projects, especially when the development process has already been repeated several times, there is not much discussion.

Think of websites, for example. A webdesigner can certainly visualize most of the activities of a "website project" while chatting with the client. There is not enough complexity that prevents the developer from creating a mental model of the problem.

"large" scope projects

Let's consider "large" scope projects those where the complexity is such that it makes it impossible for a single professional to keep in mind the entire project.

In these cases, in my experience, the best estimates happen when the requirements are evaluated by the development team and the implementation of each of them is discussed. I have never seen good estimates made by a "professional estimator", project manager or by a single analyst.

But in practice it is not feasible to interrupt the work of several people for each new proposal.

Pre-estimate

A solution that companies adopt to large projects is to make a pre-estimate. This would be a superficial analysis of the problem involving few specialists, in order to generate a range of values among which the final cost should remain.

The concept of range of values is very important. As can be seen in the Cone of uncertainty, this range turns out to be large in the beginning. The accuracy of the result depends on the experience of professionals and how many similar projects have already been develop.

Of the companies I know, no charges for a pre-estimate. It is a risk they take for themselves, diluting the cost of it in the projects actually contracted.

If there are too many requests for pre-estimates, you can filter the project proposals according to some criteria:

• verify that the project is in accordance with the profile of the contracted company. If the company has a focus on mobile solutions, it may not be feasible spend time with application proposals desktop .
• check customer profile. Are you a "strategic" client, that is, who has already hired or is planning to hire other projects? Are you a "serious" client, that is, who has need and interest in the project, or is he probing?

When to charge for the estimate

There are exceptions to what I presented above. In the case of too complex projects or when the customer wants estimates a " pet project "can then be proposed.

In this scenario, one should estimate how many hours it will take to perform the complete estimate. This can also include wireframes, prototypes and documents that leave the customer satisfied.

Conclusion

Although there is no absolute rule, I can formulate some principles based on what has been presented:

• estimate what the average flow of new projects and what the time medium that takes to make a good pet.
• then set a pool of monthly or weekly hours to invest in budgets.
• have the cost of these hours diluted to the remaining hours actually charged to customers.
• if a large-scope project is to require a much above average time, you can choose to:
  • invest more hours if you are a strategic customer.
  • inform the customer that a project this size requires a "pet project" (pre-estimate), then budgeting only this initial project.

Keep a history

It is very important to account for the effort spent negotiating, estimating, writing emails and everything else that is not part of a project itself.

It is not uncommon for a simple project to require a full day on the phone and in exchange for emails.

Annotating the hours will increase the visibility of where time is spent and will allow adjustments to be made to minimize waste.