You start a pretty big IT project and you have to answer the questions coming from the board, investors and other stakeholders. One of which is undoubtedly: “How much will it cost?” Assuming that you have a precise project specification in the form of a set of screens, flow and a technical description (API documentation, cases and user scenarios), the exact project evaluation may take a team several hours, or even days, and it doesn’t mean that they made a correct estimate. This is caused by the nature of IT projects, which are usually extremely complex and depend on many factors. Experienced IT managers agree on this — you need a budget, not an estimation.
This article covers the approach to project budgeting in Agile methodology that depends on business goals and resources your organisation has. You’ll also learn how to manage such a process and what you can do in order to reduce the risk and convince the stakeholders.
Important takeaway points:
According to a survey conducted by the Harvard Business Review , 17% of IT projects exceed costs by 200%.
This is due to the desire to make an exact estimate for the entire project before starting work. In the case of large projects, this process takes many days and, unfortunately, is often ineffective. Why? Because the contractor is not able to predict all risks in advance. If you decide to start a project, you don’t need to know the exact price, but you need to have a rough cost estimation. Moreover, accurate estimation works against the agile approach to project management, as it eliminates its most important advantage — flexibility, which is increasingly important due to changes in user needs and technology.
The total cost of agile projects is a ballpark estimate, and we understand it by budgeting. Accurate estimation of particular project components (tasks) takes place at the stage of creating a backlog, when high-level assumptions such as hotel search engine break down into significantly smaller components (task & stories), which are then estimated by the developers. So, before each sprint you get a list of functions and their evaluation. You'll find more information about the Agile methodology in our article “ Fixed Price vs Time & Materials: How to Build a Risk-free Product ”.
Exact pricing requires a detailed specification. Your team together with the project contractor should go through a series of workshops that will produce a set of product mock-ups, functionality description, system architecture, info about integration with other applications and suppliers, API documentation. The whole process will take several weeks and at the end of it you should have a full technical documentation with a precise valuation prepared.
Don’t not want to spend so much time on planning and wish to immediately start the project? First, define business objectives that your future product has to meet. Think about what problem it is going to solve, how will it meet your target audience’s needs and what benefits will it bring. This will allow the team to create a list of features, visualise and test them during a Scoping Session or a Design Sprint.
If you want to utilise the full potential of the Agile methodology you need to change your thinking. You should change your initial question from “How much will this cost?” to “When do I want it and how many resources do I have for launching the product?”. Don’t be afraid to tell the software house about the budget you have . Giving the contractor information about your budget helps prioritise the next work stages and aids the contractor in delivering the highest possible value within the given budget.
If your potential contractors find that your budget is not enough to deliver the product that meets your needs they will definitely inform you about this. Remember that the first version of the product doesn’t have to have all the features you’ve come up with. Some of them may be attractive, but will be less important for the users. Fast product launch is crucial for it provides you with user feedback and allows continuous product improvement based on the customer opinion. In short, done is better than perfect.
Remember that estimating an IT project with a poor specification is not possible . Don’t ask a software house for a pricing if you are not ready for it. Nevertheless, require a budget — the software house is the right place to ask for it
Time to move on to budgeting (not estimation!) of your project. Software house should guide you through this process. It can be split into four steps:
1. Ask the right questions
Before you start any cost evaluation, you should consider what do you want to know. Without determining the questions both valuation and budgeting will be a waste of time. What questions should be asked?
Don’t go to the next section without defining the questions you want to ask!
2. Choose a few suppliers to talk to (two or three should be enough)
You probably think that the more contractors you ask and the more deals you get, the better the decision you'll make. That's only partly true. Talking to too many suppliers will consume a lot of your energy and attention. You will talk about general issues with each of them instead of gaining new knowledge out of every meeting. Secondly, if you don’t have exact specifications, comparing the offers you receive from suppliers will not be possible. Each of them will have their own criteria, which will be used during the offer preparation stage, and that makes it impossible to compare them 1:1. For this reason, when selecting project contractors, focus on analysing the projects in their portfolio that are similar in scale or complexity to your idea. You'll find more tips on how to choose the software house here .
3. Prepare a budget plan
If you make a strategic decision, use the "from the general to the particular" approach. Start with a level of detail that is sufficient to determine the approximate cost and make a decision to start the project. To better understand this process, we will use an example of a CRM system that uses AI to analyse sales. The main components of this product are:
Based on the above list we are not able to estimate the cost of product development. So, we have to go down a level. Let’s divide the sales module into detailed segments:
Our team is experienced in building similar software functions, so we can estimate that sales opportunities, funnel, contacts, and tasks range from 1000 to 1200 hours of work to make, analytical panel from 300 to 400h, and sales planning from 350 to 450h. All values include back-end and front end.
However, we still can’t say how much the whole system will cost. If we stick to the example above and estimate the price of the remaining 3 modules by multiplying the number of hours by the hourly rate (let's say $50/h) we get the following result:
Do we now have enough information to make the decision to build a CRM system? It depends. The estimated cost varies from $177,500 to $292,500.
With a budget of $240,000 we need to prioritise each function and separate the necessary elements from the “nice-to-have” type. In our case, we will focus on sales, marketing and analytical functions. The customer service module is not needed at this moment. Therefore, our table will look like this.
Once the team has defined the requirements and prioritised them, you will be able to clearly specify what functions will get developed for a certain amount of money. With a budget of $240,000 you can be sure that you will finish the top 6 priorities.
The entire process took a few hours instead of several days. The time you have earned can be spent on starting the system development. While the work progresses and assumptions are being validated the development team will have greater knowledge and will plan the budget for the next steps with more confidence.
The experience you will get when creating similar products and project preparation will not replace the actual work performed on your software. Below you’ll find a few tips on how to reduce the risks that may endanger your project:
The key to proper risk management in the project is the continuous analysis of the main factors — progress, cost and time. It should be noted here that Agile as a concept was created primarily as a response to the risk management problem in business projects. Challenges related to project management & control will be discussed in the future in a separate article. If you have any questions, write to us !