A Short Guide to Project Cost Estimation in Software Development Outsourcing
by Andrew M. on Jun 23, 2022
People often confuse an estimate for a budget, when in fact the difference between the estimated and actual software development costs depends on a lot of different factors and events. This includes the estimation approach you’ve chosen, the mistakes you didn’t allow to happen in the project cost estimation process, and the experience you and your software development partner possess in the matter.
Determining how much effort, time, and budget it will take to deliver a project is one of the biggest responsibilities and most important stages in software development. By industry standards, the difference between the estimated and actual cost of a project should be no more than 5-10%. And often, what appears to be a simple project on the surface turns out to have contingencies that your vendor has to consider when calculating your software development cost.
Following our 20 years of experience as a full-cycle software development company, we prepared this short guide to help our clients learn the industry-best practices to project cost estimation, understand the process step by step, and be aware of the pitfalls to avoid.
What is project cost estimation in software development?
“Project cost estimation is a complex process of predicting the most realistic amount of effort, time, and money required for the development and testing of a software product and/or its deployment and maintenance.”
The cost estimation process is the initial and one of the most important steps in software development outsourcing. With analysis and planning carried out properly, an estimate creates a solid foundation for all of the subsequent decision-making efforts and project management stages you will go through together with your trusted software development company. It’s a rather sophisticated piece of work that requires active collaboration and real experience on both sides, you and your vendor. An estimate gives you certainty that the vendor is committed to completing the project within the specified scope and time frame. It also helps avoid any ambiguity or false assumptions that would jeopardize your entire project.
Here are the key factors that affect the precision and quality of a software development project estimate:
Project scope and deliverables
This means a detailed breakdown of what each service your vendor will provide on the project entails. This includes design, development, testing, deployment, and maintenance combined or as separate tasks/stages depending on a particular work order. When you have all the specific goals, tasks, and deliverables well documented, it helps you avoid any confusion and disputes on the project. You will know exactly the range of services your vendor is obliged to cover for the agreed reward and what things will most likely come at an extra fee.
Resources
The biggest price component in project cost estimation in software development outsourcing will always be person-hours—the number of specialists and the effort needed to complete each task or activity in the course of a project. The number of hours required to deliver the project will mainly depend on the skills and experience of the engineers and managers involved in the process. Therefore, it’s crucial to make sure that the vendor you hired for the job has a clear understanding of the scope of your project, so that they could provide you with an accurate cost to time ratio. They must also pay attention to the required skill level (junior, middle, senior) to allocate people as efficiently as possible. This is especially important for long-term projects.
“For example, it would take 15 hours for a senior engineer to complete a particular task while a middle developer would be able to carry out the same work in about 18 hours. Yes, a senior engineer would complete a task slightly faster, however, given that their time costs nearly twice as much as that of a middle developer, hiring a senior engineer for a small, simple project that a middle could easily handle might be an overkill.”
Roman continues:
“On the other hand, when we’re talking about large projects that rely on complex software architecture, you absolutely must entrust building one to the most experienced and skilled engineers in order to ensure that you have a high-quality foundation for further development and encounter no blockers along the way.”
Person-hours is not the only component of an estimate. There are other expenses that usually make up no more than 10% of the budget. This includes:
- reusable software components (e.g. third-party APIs, libraries, frameworks, etc.)
- equipment (custom hardware, server equipment, IoT devices, etc.)
- Third-party services (hosting, on-demand computer system resources, platform fees, etc.)
- accounts and licenses (Google Play or App Store accounts, validation services, industry-related licenses and accreditations, etc.)
Have a project at hand but no team to deliver?
Let us help you assemble a team with the skills and domain expertise that suit your goals best!
Timeline
As part of a project plan, a timeline serves as a concise representation of the steps required to complete each piece of work. It shows the project duration in days, weeks, months (sometimes even years) to give you a high-level understanding of the time your vendor needs to complete the project. Timeline highlights every important dependency, milestone, and deliverable. It shows the time each phase is scheduled to begin and end as well as the team members involved on each stage.
It is important to point out that the estimated person-hours and the estimated timeline are two drastically different things.
Risks
In project management a risk is any unexpected event that could jeopardize the timely and on-budget delivery of your software product. As one of the key factors to project success, risk assessment plays an important role in project cost estimation.
Assessment of potential risks can be broken down into three stages:
- Predicting the events or conditions that may occur in the course of software delivery.
- The likelihood of their occurrence.
- The impact they may have on your project.
“Risk mitigation is particularly important at the early stages of a project when risk is typically at its highest.”
Beware of outsourcing vendors that are overly optimistic in assessing the risks on your project. In the hopes to entice you with a lower price tag, they may ignore potential issues and the long-term consequences these issues can have on your project. And remember that even the most experienced software engineers can’t guarantee that your project won’t face any blockers. So go with a software development company that provides you with realistic risk analysis and percentage of contingency built into an estimate.
“Contingency is the amount added to the estimate in order to cover potential project risks. The calculation is performed for every identified project risk and then added together. It’s a crucial part of risk management that helps you minimize the probability and mitigate the impact of unfavorable events.”
The more accurate the risk assessment is, the better prepared your project will be to deal with potential issues. This also means that your vendor will be able to build stronger risk management plans and lower the likelihood and impact of unfavorable events and conditions with efficient mitigation strategies.
Why is project cost estimation important?
Now that you have learned what exactly project cost estimation is and know its key factors in software engineering, let’s go a little deeper into why it is so critical to make your estimates as accurate as possible (apart from the obvious “keep the project within the budget”).
Estimation gives you clarity
When a client comes to a software development company with a project, it’s important to bring everyone on the same page about what needs to be done. When the outsourcing company you’ve hired goes through your project requirements, user stories, and any other documentation you provided, their experts, both business and technical, form independent conclusions about the complexity of the project and the effort required to complete it.
Sometimes team members will have different perspectives on the problem and how to solve it. Their implementation ideas can be far apart and the project development approaches they propose may differ from one another.
For example, a software architect may propose adjustments to your tech stack or offer to use a tool that would drastically improve the quality of your product or speed up the delivery process. This may lead to a somewhat lower estimate for the project. At the same time, a business analyst may identify a serious pitfall in your project documentation or insist on adding a crucial feature others have forgotten about, which may lead to a considerably higher estimate.
When team members provide you with a whole range of different options on how to optimize the development process or the solution itself, these independent conclusions give you a lot of crucial information for further planning and accurate low-level estimation of the project. This means your vendor won’t miss any important signals and will be well prepared for any turn of events during the actual development phase.
Estimation helps you manage trade-offs
If you’re running short on time and budget in the course of development, you will most definitely have to make sacrifices, be it the functional features of your software product or its quality requirements. From serious maintenance and extension issues to a complete failure of your software solution, these trade-offs may lead to a whole variety of problems you don’t want to deal with. And that’s what the software development cost estimation process can save you from before it’s too late.
Project cost estimation process allows your development team to refine your project requirements and adjust the course of action before the actual work begins—before the team runs into any unexpected complications or blockers that would put your project at risk. Such thorough analysis of the project scope helps your vendor identify issues and prepare a baseline to effectively tackle them: adjust the scope, expand the timeline, extend the team, etc.
Requirements analysis in the course of the software development cost estimation process helps you better manage trade-offs on complex projects. An accurate estimate, whether it is lower or higher than you expected, raises important discussions on the scope of the project. It enables you to:
- rethink the set of features you planned for your software solution
- prioritize tasks more effectively
- identify and give way to a critical component that was buried somewhere deep among the less important ones
- scale back your solution to improve your time to market and take advantage of several quick wins
The cost estimation process is the best time for you to raise discussions on scoping and adjustments if you want to keep the project within the allocated budget.
Estimation saves you from getting lowballed
When your estimates are significantly off, you essentially kill the project before it even starts. And let’s face it, no one normally overestimates the amount of work to be done—it’s the underestimates that may become the nail in the coffin of your project. A bad estimate is a pitfall you will find extremely hard to deal with the deeper you are into the development phase.
As we mentioned before, an underestimate may serve as a means of deception that a dishonest outsourcing vendor is using to hook you with a lower price tag. However, it may also be the planning fallacy so common in today’s fast-paced digital world. After all, people do tend to underestimate the time needed for a lot of things from simple chores like cooking breakfast to responsibilities such as implementing a software development project. Another possible cause of underestimation may very well be the aggressive goals you’ve set in the hopes to push better productivity or achieve a faster time to market. And the next thing you know, your overly ambitious goals backfire and are rapidly dragging your entire project down.
When forced to finish the project on time and within the allocated budget, your development team takes shortcuts, sacrificing features and letting a whole myriad of bugs and errors infest your code. The quality and scalability of the underlying architecture may also be put at risk when rushing to meet a deadline. Suddenly, your software solution is not nearly as polished as expected and a lot of work is deemed “non-essential” as you’re trying to avoid the financial burden of accumulating even more technical debt. Future extension is slowed down as your vendor is locked in the repeating cycle of fixing bugs and other quality issues.
Code quality requires a lot more work than you normally expect and it should never be underestimated in the planning phase. Otherwise, you’ll be stuck dealing with functional and non-functional issues for a long long time. You may not just end up late and significantly over-budget with your release, but the project may turn out such a failure that it’s future wouldn’t be even worth fighting for. To avoid underestimation and get the quality you’re aiming for, there is a wide range of methods to help you estimate software development.
Project cost estimation approaches and techniques
There are so many software development projects, each with different requirements, goals, and conditions, that there is no single, perfect way to accurately estimate their costs. But it’s your vendor’s job to analyze your project documentation and find what development approaches and technologies suit your project goals best. And therefore, your vendor may have to apply a whole range of different techniques to estimate the project adequately.
These are the project estimation approaches that our company has the most success using:
Three-point estimation
Probably the safest and most Agile way to estimate the time, effort, and cost of a software development project today is the three-point estimation technique. Rather than assuming one estimate, software development companies use this estimation technique to calculate the most optimistic and pessimistic values that are then averaged to determine the most likely cost of a project. Thus, we get three points:
- optimistic estimate
- pessimistic estimate
- most likely estimate
As you have probably figured out, the optimistic estimate is your best possible outcome that represents the expected amount of effort, time, and money required to complete a project assuming there will be no blockers or unfavorable events hindering the delivery process.
Then there’s a pessimistic estimate—the worst-case scenario that takes into account all the possible risks that might affect the delivery process and result in cost escalation.
By calculating the average in between these two extreme points, we get a somewhat realistic estimate. This would be called the triangular distribution of three-point estimates—an ideal solution for estimating small, simple projects where there is no reason to dig deeper.
However, this may not be the best case for complex, large-scale, and enterprise-level projects where you need to be more thorough with risk assessment and really tighten the most likely estimate. In this case, the project should use PERT estimation.
PERT (Program Evaluation and Review Technique)
The PERT distribution of three-point estimates implies overweighting the most likely estimate to convert a simpler triangular three-point curve into a bell-shaped one. The PERT method provides you with a better, more accurate means of estimating probabilities of ranges of expected values.
It’s also advisable for complex projects to go the extra mile and enhance the precision of your software development cost estimation with other task-level techniques such as expert judgement, analogous estimation, and parametric estimation.
Expert judgement
Following this technique, the people responsible for estimating your project involve an additional specialist who double-checks and narrows down the estimates. The involved expert can be anyone from a project manager, software architect, or business analyst to stakeholders, consultants, and subject matter experts. Whether you need to involve an additional niche expert in the software development cost estimation process depends on the level of technical or business complexity of the project at hand.
“Expert judgement means that we involve a niche specialist with broad experience in a particular area to help us with the estimates. They will either do the job themselves or refine the estimates developed by a different specialist who is possibly not as experienced in the relevant tech or business domain.”
Whether it is the relevant experience, niche skills, industry-specific knowledge, or accurate historical data that this person possesses, they utilize it to provide deeper insight into the project requirements and work out/correct the estimates to be the most precise. Expert judgement is best applied to create efficient strategies around risk mitigation and change management as well as identify project opportunities hidden to an untrained eye. When working on a large-scale software solution, your vendor may need to gather an entire team of technical and domain experts to help with project cost estimation.
Analogous (comparative) estimation
As a combination of expert judgement and historical data analysis, estimation by analogy requires your vendor to involve experienced specialists to produce an accurate output. The scope, resources, deliverables, timeline, and risks of similar projects are reviewed and compared to what you have in mind with your project—the more similarities, the better. When the best analogy is found and the possible differences are analyzed and considered, the resulting project cost estimation should be fairly accurate.
The comparative estimation approach is preferable when the information you possess about the project is limited. These high-level estimates usually take no longer than a couple of days to pull together and serve as a good tool to make sure everyone is on the same page before either you or the software development company you’re about to hire invests any more time into further project planning. It’s worth mentioning that for analogous estimation to be accurate, your vendor must have many years of experience and a pretty solid portfolio.
Parametric estimation
Both parametric and analogous estimation techniques use historical data to produce estimates. The parametric method, however, requires a higher effort upfront and is often perceived as a more accurate alternative to the analogous method. What makes a substantial difference between the two is the process each of the approaches uses to perform the calculations.
While in the analogous approach your vendor would simply compare and adjust values from past projects with a similar scope, parametric estimation provides an additional estimation layer on top of that using a set of algorithms. It applies a statistical or mathematical approach to the historical data your vendor has collected—uses the relationship between variables (i.e. unit cost/duration and number of units) from similar projects and applies them to the one at hand to estimate the cost, duration, and effort needed.
“In parametric estimation, units represent the parts and tasks required to complete a project. The software development estimate can be broken down into units such as deliverables, actions, and stages. Such an approach makes it easier to calculate and compare the number of units, cost per unit, and time per unit on a current project against historical data from similar ones.”
Simply put, this is how it works:
- The team pinpoints the units based on project requirements, complexity, tech, and other variables from similar projects with consideration of the scale differences.
- The data on the required effort/cost/time to complete one relevant unit is then calculated against the total number of such units in the current project.
- The estimates are derived from the empirical relationship between the relevant unit rates and the total number of such units.
Top-down approach
The top-down approach is a project-level estimation technique that uses known data points and specific parameters to first establish the scope/cost/duration of the entire project and then apportion this data into individual tasks and deliverables using the task-level techniques listed above. It is generally restricted to projects where your vendor deals with a predetermined project budget and/or duration.
For example, you have determined the budget in advance and set a strict deadline for the project. Using the top-down approach, your vendor will take these parameters and break them down into the effort, time, and cost estimates for each activity within the project. They will analyze the impact on project complexity and see how realistic the project scope is against the given time and budget constraints. If the matter is open to debate, your vendor will offer a range of solutions to how they could adjust, optimize the scope to make the project viable (in case it isn’t).
Similar to the analogous technique, this rough approach is mostly used for the initial stage of project cost estimation to see if the project can be implemented within the given parameters. It also helps with strategic decision-making in situations where the information on the project is insufficient or the requirements are still floating.
Bottom-up approach
The exact opposite of the top-down approach (as you have already guessed), the bottom-up estimation approximates the cost, duration, and resource requirements of the project at a very granular level. This technique involves working your way up from estimating individual low-level activities and work packages to phases and deliverables to, eventually, rolling these up into overall project estimates.
Bottom-up estimation is significantly more accurate, but the trade-off is that it is a lot more time-consuming than the top-down approach. This is because your vendor has to gradually collect the smallest pieces of information into a whole and thoroughly estimate each and every one of them to get a good understanding of the big picture at play.
The level of detail available for estimation will highly depend on the maturity of the project and the quality of documentation you provide to your trusted software development partner. Therefore, it’s probably a wrong path for immature projects with little information and floating requirements.
Approximate the cost of your project in just a couple of clicks with our convenient software development cost calculator.
Project cost estimation process step by step
Clients come to us with all kinds of different requests we need to thoroughly analyze and provide accurate estimates for in order to get a green light for the delivery phase. Considering the variety of requests we get and the broad range of services our company provides, every project requires a unique approach and has a different life cycle.
Some clients come to us with defined and well-documented requirements that make it very easy for us to estimate the project and get on the same page without any additional discussions. Some submit requests with mere vision boards or references to apps and websites, saying that they want their solution to be “something like that.” And then there are clients that seek our help in fixing the mess some other company did on their project.
So, knowing the algorithms and understanding the techniques is one thing, but it’s the experience and mature estimation processes honed over years of delivering full-cycle software development projects that distinguish the good from the best. Now let’s break down the project cost estimation process and walk through it step by step.
Pre-sale phase
It all begins when you submit your request to us. Our account manager responds within a day, and we normally start our relationship by signing an NDA in accordance with the information security standards our company follows. Then we send you a project template to fill so that we could get a better understanding of the project and determine whether the information is sufficient enough for our team to start working on high-level estimates. In addition to project requirements that may vary in their quality and level of detail, you can also share the budget, deadline, preferred collaboration model, maturity/stage of the project, and other information that could help us provide accurate estimates.
Following the greets and meets and all the request processing procedures, a delivery manager is assigned on the project. They carefully analyze the information you provided and decide whether it is sufficient for high-level estimation. There can be two different scenarios. If the information you provided is enough for us to start working on estimations, we do without delay. In case there’s any ambiguity in the provided documentation or we require more details to provide an accurate project cost estimate, we prepare a concise and well-structured list of questions, followed by one or several calls to clear things out.
“In addition to an account manager and delivery manager, a software architect, business analyst, or any other specialist with relevant niche skills and domain expertise may also be invited to the call. Thus, we make sure no issue is left unattended.”
With every issue discussed and settled, we move on to the actual software development cost estimation process.
High-level estimation and resource analysis
With sufficient information on the project, the assigned delivery manager can start coordinating with our software architecture team to look at what architectural choices and options we’ve got. Sometimes they are dictated by you and your stakeholders, depending on the stage of development and your current or preferred tech stack. In this case, the assigned software architect can immediately start working on project estimation. Alternatively, you may choose for us to provide suggestions and tech solutions most suitable to your project goals. When that is the case, the software architect decides on the appropriate tech stacks and development approaches. They also suggest potential people within the company it would be logical to involve in order to provide an appropriate estimate.
To make sure that the right people are made available to do the estimates, the delivery manager and software architect will liaise with our resource managers. Our HR department will then provide a list of available specialists who possess the required professional skills, domain knowledge, and experience. Together with the software architect, the delivery manager will assemble a team from best-fitting candidates and finalize the high-level estimates.
Finally, the resource, cost, and project duration estimates are validated by the delivery director and sent to you for approval. The high-level estimation process takes one day in person-hours for small and medium projects and two days for large projects. The timeline for the estimation shouldn’t be longer than one week regardless of the scope and complexity of the project.
As a result of high-level estimation, the client receives two documents:
Proposal
Not to be confused with RFP (Request for Proposal), this document represents the way we see the project, how we plan to implement it, and by what means. It walks you through the tech solutions and business approaches we’ve chosen for the implementation of your project. Depending on the project, a proposal document may include information such as:
- project scope
- project management plan
- key deliverables
- timeframes and milestones
- required access to environments
- required third-party components and/or services
- known risks, assumptions, and mitigation strategies
- portfolio with relevant case studies
High-level estimate
The estimation document is broken down into tasks, deliverables, and their descriptions followed by the expected time required to complete each task, the hourly rates of resources assigned, and finally the costs of each and every phase and deliverable.
“Following the industry-best standards and our years of experience in the market, we have refined our templates to make them as concise and easy to understand as possible. We often receive positive feedback from our clients on how on-point and clear our proposal and estimation documents are.”
After you have received and studied these two documents, we arrange a call to get feedback and discuss further action. Our next step essentially depends on the scope and complexity of the project. If it’s a small and simple app/website we’re talking about, we can skip the discovery phase, sign the contract, and go straight into the delivery phase. On a large-scale project, however, especially the one with documentation that doesn’t inspire much confidence, we always insist on a thorough discovery phase.
Prepare your project for future success!
Let us know about the project cost estimation challenges you’re facing, and we will connect you with an expert best equipped to help you solve them.
Discovery phase
The role of the discovery phase in the software development cost estimation process is to dive deep into the tech and business analysis, discovering possible flaws, inconsistencies, and opportunities to then adjust the estimates accordingly—make them as accurate as ever. Without it, both your company and the software development vendor on the job can suffer huge financial losses.
The discovery phase helps us achieve certainty in that the project requirements are final and there will be no sudden/drastic change of course. It also helps us refine assumptions and reveal hidden risks or potential blockers—lay the groundwork for delivery on time and within budget.
“Most projects simply must go into the discovery phase before starting actual development. When refining the requirements, it often happens that the client decides to add some functionality shortly into the discovery phase. As a result, our previous estimate, acceptance criteria, and risk mitigation strategies have to be revised. And it’s in the best interest of everyone involved to do this during discovery rather than the delivery phase.”
Back to the process now. When you have approved the high-level estimate and accepted the proposal, we proceed to signing the contract for the discovery phase. Then we begin to put together the development team approved for the project. In addition to the delivery manager and software architect, the team for the discovery phase may consist of a UI/UX designer, niche developer, business analyst, QA engineer, subject matter expert, and even a DevOps engineer, depending on the complexity and scope of the project.
We tell everyone their role on the project, the tasks they are expected to complete during the discovery phase, and the artifacts that should be produced as a result.
Discovery phase artifacts
This section describes the artifacts you get as a result of a discovery phase and their importance in the software development cost estimation process. If you are an experienced entrepreneur, well versed in project management documentation and how it correlates with software cost estimation, feel free to skip ahead to the next step of the process.
Project Management Plan
A project management plan (also known as Project Initiation Document) refers to a series of documents that define the execution and control stages on the project. This includes roles and responsibilities on the project, communication, risk management, resource management, quality control, change control as well as the scope, deliverables, and timeline. Project management plan provides insight into the escalation process between the client and the software development team.
Product Backlog
As described in the Scrum Guide, “the Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.”
The project roadmap and requirements provide the foundation for this crucial artifact in Agile software development. Here the most important activities/deliverables are shown at the very top so that the development team could prioritize what to deliver first.
Acceptance Criteria
In Agile software development, the term acceptance criteria refers to the conditions that a software product must meet in order for a project to be accepted by the client. Acceptance criteria are based on the scope and requirements of the project—the work the development team has to complete in order to consider the project successfully delivered and the contract fulfilled.
Well-defined acceptance criteria help set and manage expectations, reducing ambiguity on the project and unifying the product vision of the client and the development team. They protect the project from scope creep and make sure the team sticks to the predetermined course of action.
On the subject of project cost estimation in software development outsourcing, the crucial function that acceptance criteria perform is change control—the matter of utter importance in fixed cost projects.
For example, a client adjusted their business strategy and decided that they need a couple more features to be added to the software solution we are developing for them. For us as a software development company this means additional effort and the risk of going over budget. In such a case, we refer to the acceptance criteria where we check if the requested features are part of the predetermined project plan. If they aren’t, we gather a change control meeting to create the necessary change requests.
“There is an industry-standard policy that we follow regarding change control. The project team will update the acceptance criteria and introduce the necessary estimation adjustments only after they’ve received an appropriate change request document. The same applies to changes in the project management plan. Otherwise, we stick to the previously agreed course of action.”
Work Breakdown Structure
The Project Management Book of Knowledge (PMBOK) defines the Work Breakdown Structure (WBS) as a “hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.”
WBS is a deliverable-oriented technique in Agile project management that software development companies use to break down a project into smaller, more manageable components—phases, deliverables, and work packages. Organized on a low level, such hierarchical and incremental decomposition serves your project team as a reliable framework for accurate project cost estimation, project planning, and control of a contract.
UI/UX approach
When it comes to design, the discovery phase output really depends on the scope of the project and the steps UX and UI design hold on the priority ladder. In most cases, a UI/UX designer provides a preliminary UX prototype in the form of flowcharts and wireframes to show the client the general design approach chosen for their software solution. On smaller projects, however, the designer may provide you with a clickable prototype that includes elements of graphic UI design, animations, transitions, sliders, etc.
Architectural approach
The software architect’s job in the course of the discovery phase is to build a comprehensive conceptual model of the future technical structure of the software product. This includes information such as system behaviors, components and subsystems, processing logic, operating environment, etc. This document may also include references to existing software solutions and relevant historical data.
Business approach
In case it’s a product development project, the client may also require the help of a business analyst on the vendor’s part. If so, the assigned business analyst will be responsible for producing the next artifacts:
- A business requirements specification that may contain data such as a problem statement, business use cases, business drivers, and business model.
- Functional requirements specification that is the collection of all the functional features planned for the product.
- Non-functional requirements specification that covers quality indicators such as performance, security, maintainability, etc.
“From my perspective, a discovery phase may be a few days up to two-three weeks for a potential large-scale enterprise project. This is a good step to ensure that we understand all of the client’s corresponding needs, and they understand the work that is going to be entailed and how it is going to physically be done by the development teams before we move into a formal contract for the delivery process.”
Seal the deal
Following the discovery phase, comes the presentation of our solution to you. There are times when we revise the budget both up and down, depending on whether we were faced with additional risks and complications or, on the contrary, refined the requirements and developed a more efficient delivery plan. As a result, if you are satisfied with the low-level estimate we provided, the team commits to the project, we sign the delivery agreement, and the work begins.
Why can two similar projects be priced differently?
The exponential growth of all things digital makes the market an increasingly tight environment for b
“The important difference is that person-hours represent the total time a specialist will dedicate to the project while a timeline breaks this time into phases. Say, an engineer needs 20 hours total to complete a task but in fact it will take them two weeks as their involvement in the completion of the task will depend on other people’s work through different phases.”
Roman Lyha,
Delivery Manager at QArea