How to make the initial budget for a software project?

Question

Context: I was "educated" in the methodology of Unified Process. I know Agile is very popular today, but I have very little knowledge of the process. I understand the philosophy that "changes are inevitable, it’s better to prepare to deal with them well than to try to avoid them", but that’s not much consolation when I’m charged with presenting a budget - even if initial - for a development project. By the PU, the conceptual design is first proposed (which is a simple matter of estimating the number of hours required to stand up and analyze all requirements, and with few negative consequences if the judgment is wrong) and the implementation project is based on this. In theory, it all sounds very good, but I lack practical experience to corroborate this statement.

Problem: I know the correct answer to "how to budget a software project" is: "it depends"; it depends on the scope, it depends on the specific requirements, it depends on the client... But the fact is that potential customers demand at least a preliminary forecast of deadlines and costs (and sometimes platform), before the requirements are even detailed. My difficulty is in establishing these initial parameters, or even adjusting my expectations about what is achievable in practice.

Question: What parameters should I observe to make a budget initial (or preliminary) to an arbitrary development project? More specifically:

• I must charge for the initial withdrawal of requirements/scope definition, or this is a burden I will have to assume?

  • And if the answer is "do not charge", should I insist to the client that it is not possible to budget anything before making this withdrawal? (the customer will not like it - since raising requirements requires involvement of your team as well, which brings you indirect costs even before you are sure that you will even sign with us)

• In the case of a project of great scope (although still quite undefined), should I separate it into a conceptual project and an implementation project? Or is that counterproductive?

  • Clarifying: conceptual design is the one in which I survey and analysis requirements, and the deliverable is a more budget specification for the implementation phase; the implementation project - this already done with more solid foundations - can rather be flexible with respect to changes, not needing to follow the specification by iron and fire. But it still needs a basis to be budgeted, and this basis would be achieved through conceptual design.
  • Why would it be counterproductive? I don’t know! It’s just what I always hear from Agile proponents: that it’s silly to do [large-scale] project before you start implementing (at least a "sprint" should be planned), that the requirements change all the time and in the end little of what was designed at the beginning will be implemented in fact, etc.

• In which terms should that budget be made? Ideally, changes in the requirements should reflect changes in deadlines and costs (in this the UP class and the Agile class agree), but if contractually I am obliged to deliver X on time Y upon payment of Z, it does not seem feasible to have a contractual change every time a renegotiation of deadlines and costs.

  • Legal issues aside (since this is obviously outside the scope of the site), what I ask is if it is better to make a "guesstimate" (preferably, on top) of the cost and refine over time (but committed to the completion of the project at all costs)or whether conditions should be laid down to ensure that - if the project cannot continue within the time limits and costs set - it is concluded by mutual agreement of both parties (as To do this, of course, is the responsibility of our lawyer).

Preferably, I would like answers based on previous experience (I know that not every developer is directly involved with this type of question, but at least those who occupy a leadership position should have already had to make estimates under uncertain bases). And not to get too broad, the central point of the question is: the how much I must assume onus when establishing a scope/preparing a proposal for free, and what are the minimum parameters I need to collect before saying: "from here, only paying me".

Answer 1

Scope and Pet

The budget of a software project is directly involved with the ability to define the scope and estimate the effort needed 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 objective during the project initiation phase, on which the budget depends, is to reach a consensus as close as possible to the reality about what should be done.

The two parties are very interested in the correct estimation, in order to minimize the risk 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 overestimated, it is possible that the client will give up a project that would otherwise be successful or that other projects will be harmed, since the workforce will be unnecessarily allocated.

Change of scope

"Traditional" (like the RUP) and agile processes have mechanisms to deal with the inevitable scope changes and mitigate risks.

The RUP, for example, mitigates the greatest risks first by prototyping the most complex requirements and generating an executable architecture in the drafting phase.

Agile methodologies make this mitigation through constant, sometimes weekly deliveries. They also seek to postpone project decisions based on the idea that the sooner something is defined, the harder it will be to change afterwards (casting).

The main difference with regard to changes is that while they are often treated as exceptional cases in "traditional" processes, agile methodologies are the rule.

Open or closed scope?

Some time ago I wrote a article on the Iron Triangle to try to explain that in a software project, we can’t have it all.

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 unforeseen events, the quality is sacrificed.

Agile methods attempt fix the quality and keep the scope variable. This means that if a functionality does not "fit" the sprint current, it can be postponed.

In addition, if the developers deliver a functional version of the system at each end of sprint, then the customer can decide to extend the project to include more functionality or shorten it if he considers that the system is already good enough for production. This is supported by some surveys (lack of sources) that demonstrate that users do not get to use most functions of a system.

In the ideal world of Agile, the client would not need to receive a final budget of the entire project. Planning would be done in 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 the scope was fully implemented.

Pet

Postpone decisions and the pet 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 estimation of the project! Even in agile methods initial estimation sessions are held to enable the sale of the project.

Ultimately, it all comes down to the ability of professionals to estimate. It involves time, which in turn involves cost.

Pet effort

How much effort do you spend on estimating? It’s a complex question, but many authors agree it can’t be little or much.

Projects of "small scope"

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

Think about websites, for example. A webdesigner certainly can visualize most of the activities of a "website project" while talking to the customer. Not enough complexity to prevent the developer from creating a mental model of the problem.

Projects of "large scope"

Let’s consider projects of "large" scope those where the complexity is such that it makes it impossible for a single professional to keep in mind the whole 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 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 for large projects is to make a pre-estimate. This would be a superficial analysis of the problem involving few experts, so as to generate a range of values among which the final cost should be.

The concept of value range is very important. As can be seen in the Cone of Uncertainty, this band ends up being great at first. The accuracy of the result depends on the experience of the professionals and how many similar projects have been developed.

Of the companies I know, none of them charge for a preliminary 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 project proposals according to some criteria:

• Check if the project is in accordance with the profile of the contracted company. If the company is focused on solutions mobile, perhaps it is not feasible to spend time on application proposals desktop.
• Check the client’s profile. Is it a "strategic" client, that is, who has already hired or is expected to hire other projects? Is a "serious" client, that is, who has need and interest in the project, or is he probing?

When to charge for the pet

There are exceptions to what I have presented above. In the case of overly complex projects or when the client wants detailed estimates, one can then propose a "pet project".

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

Completion

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

• Estimate the average flow of new projects and the average time it takes to make a good estimate.
• So define a pool of monthly or weekly hours to invest in budgets.
• Make the cost of these hours be diluted in the other hours effectively charged from customers.
• If a large-scope project is time-consuming well above average, you can choose to:
  • Invest more hours if you are a strategic client.
  • Inform the client that a project of this size requires a "pet project" (pre-estimate), then making the budget only of this initial project.

Keep a record

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 project to simply require a full day on the phone and in exchange for emails.

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

Answer 2

I believe that to estimate a budget you must:

• Knowing the client’s request
• Split client requests into tasks
• Knowing the team’s ability
• Budget the time your team members will spend to develop the solution
• Calculate the costs you will have to do the project (infra, displacement, accommodation and etc...)

With this you will have an approximate cost of the minimum you will spend to do the service and not have profit. The more detailed this initial survey is, the closer to a real base cost you will get. This calculation will improve over time, add a percentage on this amount to cover any extra expenses. And don’t forget to add your profit and value to after-sale costs (support, training and warranty)

There are specific methodologies to deal with cost management PMI is one of them.

A link to get more information, because what I’m talking about is very superficial would be: http://blog.mundopm.com.br/2013/08/22/gerenciamento-de-custos/ and http://www.ufpi.br/subsiteFiles/pasn/arquivos/files/Aula09_Desenvolving%20o%20Check%20of%20Project.pdf