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.

No matter what software development methodology you use — waterfall, Agile or some blend of the two — providing a project forecast challenges technology teams. An inaccurate forecast creates problems for business leaders as well. They want certainty in when “done” will happen, in spite of their own shifting definition of done.

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.

The constantly shifting variables that shape software estimation during the course of a project bring up another set of challenges:

How should the initial result of software estimation be connected to new needs as the project progresses? Once development starts, how quickly can the team assess actual progress vs. the initial estimate? When should updates be shared?

To maintain credibility, the technology team must have the ability to explain to business leaders any changes made to the estimate early and often.

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.

I have used this approach on dozens of projects directly and perhaps hundreds tangentially, and I would like to share some insights on how to apply it to software estimation.

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.

Years ago I worked with a client who demanded a certain system functionality. Several people told the client that an alternative approach was better. The client refused to listen. What was missing was that no one explained the costs to the client. But once the costs for the function were understood, the client’s demands changed and the team could arrive at a reasonable solution. The give and take of estimating will help to drive more realistic expectations from the beginning.

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).

This process will help the stakeholders understand what it will take to develop the software. Demanding more details upfront may seem to add time to project estimation, but the transparency it creates usually shortens the software estimation, improves quality and shortens the approval time through better understanding amongst stakeholders. Breaking the project down will also allow for the team to set milestones and measure against them during the project, contributing to project success.

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.

An area too often overlooked or skimped on when building a team is the resources necessary to build an effective QA testing plan. The team should be prepared to test early and often with a thorough and repeatable process to identify problems with the application while the code is fresh in the developer’s mind. The plan needs to ensure that the delivered code fulfills the requirements.

An approach that I have found to work in building the team is to use ratios of these roles to developers. A single BA can support only so many developers before the developers are coding faster than the BA can write requirements (an all-too-common problem that wastes developer dollars). A lack of good requirements wastes developers’ resources. This is also true of user experience and quality assurance. Developers who have a good supporting cast are better equipped to create good code that meets requirements, budget and scheduling needs.

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.

An overwhelmed product owner who splits time between too many duties imperils the project. This is another area where, if the product owner does not have clear authority and time to dedicate to the project, red flags should wave as expensive contingency plans add to estimated costs.

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.

When will the first release be ready?
How long after a developer joins a project will it take for them to be 100% productive?
How much development can a lead developer do when they are leading a team of two developers vs. a team of seven?
How will holidays and vacations affect the project?
If the project must be completed by a certain date, how many developers will it take?
What will it cost to develop a feature?

I have heard these and dozens of other questions during software estimation projects. Factoring in as many of these questions into the estimate helps to tell a better story to the executives who hold the purse strings and will ultimately approve the project. The better you understand the answers, the more likely you are to get the funding you need to succeed.

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.

Rethinking software estimation will also provide a beacon of reason for business leaders even when pivots are necessary or new challenges arise. Teams that remain agile and collaborate closely with empowered product owners take crucial steps towards building and releasing quality software that delivers value.

Original post can be found here.

Innovate with us. Click here to access all of our free resources.
Authored by Stanislas Walden.

Stan loves to make the obscure more apparent, the complicated more human and approachable. He strives to communicate the complex themes inherent in software development trends in a way that sparks curiosity and invites exploration.

As the Content Associate, Stan helps to develop content and coordinate communications that elevate MentorMate’s voice and connect people with vital information that helps them create tools that help other people.

When he’s not researching or publishing a new article, Stan enjoys running around a few of Minnesota’s many lakes and looking for new recipes.