8 Ways to Determine Software Development Costs

Lessons in Software Estimation

In my role as a solution architect, I need to develop project estimates quickly and be able to explain the logic behind the estimates. I also need to factor in a number of subjective variables into the estimate that can cause the project to struggle. Unpredictable influences can result in inaccurate results as the project size and time horizon increase. Predicting the weather can feel like a less daunting task.

Why Teams Must Evolve Alongside a Project

Requirements shift and technologies evolve, which make estimating the integration of legacy systems and data into a new application nearly impossible for technology teams. The experience is akin to remodeling a house. Disrupting surprises can lurk behind the walls. Meanwhile, customer demands, return on development investment and industry competition motivate business leaders to get to “done” faster (all while trying to determine just what “done” means). This is a recipe for conflict in technology teams. The pressure builds when clients need estimates in just a few days.

8 Steps to Better Software Estimation

There are as many ways to estimate the cost and timeline of a software project as there are development languages. Research has shown that if the project can broken down into small chunks of work, and each chunk estimated, the estimates tend to be more accurate.

1. Involve Business Stakeholders in the Software Estimation Process

Involving stakeholders early in the software estimation process helps to define more accurately what is important in the software development cycle. This helps both the business leaders and the technology team gain a shared understanding of the project. It also helps to hold everyone involved accountable to the initial estimate.

2. Ask, “Why Do Most Software Estimation Projects Fail?”

The answer is, poor requirements and weak leadership. The technology in itself is rarely the cause of project failure. Great technology and developers will fail without good requirements and leadership. Beware of this red flag: leadership that cannot explain the end goals or the business drivers behind software during estimating sessions with the project team. Developers can’t develop quality code when requirements are not clear. When developers run into roadblocks or have questions, leaders — especially the product owner — need to make quick and informed decisions. Otherwise they put their project timeline and budget at stake. When teams lack clear guidance on requirements and/or if leadership is not available to answer questions or clear roadblocks, any software estimation must include contingency plans in order to accommodate the uncertainty in the software development cycle. It’s better to uncover these issues during the estimation process than to allow them to derail progress down the road.

3. Break the Requirements Down to Increase Transparency in Software Estimation

Begin by breaking the requirements down far enough so that each requirement can be built in a short time by a single developer. Any requirement that cannot be broken down may not be understood well enough for accurate estimation (with some exceptions).

4. Tie the Estimate to Reality

Determine what you are going to measure against. This is a significant challenge. Find a piece of the project that everyone can agree is well defined and can be estimated to (ideally) about half of a day in development time. By establishing this baseline, it becomes easier to estimate the other work against this baseline. This will also allow the team to quickly re-estimate the work once the development starts and the team has worked through a portion of the project.

5. Build the Right Team

There’s more to a team than just developers. They need a good supporting cast and good requirements that hold everyone accountable. In order for the project to provide business value, users need to be able to use the application effectively. This means that the project must have good business analysts to write good requirements, which drive efficient development. The user experience is more than just how it looks. Include a designer on the project who can provide both an effective interface that is pleasant but also facilitates meaningful user flow.

6. Remember Why the Product Owner Matters

This is the single most important person on the project. The empowered product owner can focus on the project and make the important decisions. The product owner drives the requirements, arbitrates differences between the business and technology and prioritizes the work to allow the team to deliver business value as quickly as possible.

7. Good Software Estimation Metrics Should Reveal Problems Sooner

If the estimate is based on the developer’s velocity, then it is easier to determine whether a team is developing at the expected pace. Metrics allow you to identify team members that are not producing as expected. Rarely do all teams or developers produce at exactly the same speed. Some will work faster, some more slowly. If they are too slow, you can begin to investigate where friction occurs, from requirements to design, architecture, scope creep or lacking technical skills. Comparing actual velocity to original estimates allows stakeholders to identify budget misalignment sooner and take corrective action when needed. It is far better to identify a problem early and have time to fix it than to explain why you missed your goals after the fact.

8. Small Things Matter

Once you have estimated the requirements and assigned them to developers and their supporting cast, there are still details that can affect the estimate.

Why You Need to Rethink Your Software Estimation Tactics

Estimating the timeline of software development requires all hands on deck, from developers and QA leads to business leaders. When technical teams can cohere around useful and informative metrics that are ideated through collaboration with product owners, the rollout of the project will align more closely with initial estimates.

Digital Ideas Accelerated // Global software development team, 500 strong // Learn more: http://bit.ly/2jjoQsp