Software costs estimation types!

One of the hardest things to do in software development is to determine how long and how much it will take to deliver a new software product. Should it be so hard? The answer is not straightforward.

Software costs estimation is inherently difficult, and humans are terribly bad at predicting absolute outcomes. No two projects are the same; each is unique in what it sets out to achieve and unique in the myriad of parameters that form its existence. Often, what appears to be a simple problem on the surface is much harder or technically challenging to implement in reality. And, undoubtedly, there will be ‘unknowns’ with the project that can only be identified when they arise.

But when it comes to software, understanding duration and cost are key in making strategic business decisions and this is true whether you’re creating a startup, realizing a new business opportunity, or enabling your business to perform better. The timing, return on investment and benefit delivered can make, shake or break your business. You’ll be asking yourself: What do we get for our money? Can we predict our costs? What will it cost to create the product we want? When can we launch? Will we get a quality product for our investment? Will it grow with our business? Will it deliver business value?

Traditional Contract Pricing and Estimation:

Traditionally, using non-Agile practices, software projects have sought to fix functionality or scope and let time and cost be a variable.

This causes the following problems:

1. When functionality or scope are fixed, How do you know that the functionality you fix at the outset of a project really is the functionality that serves your business or customers best? More often than not, functionality or scope will change, which is why we hear about ‘scope creep,’ the outcome of desired needs being identified through the lifecycle of a project and being determined as necessary or compulsory
2. When cost becomes a variable, we lose control over the return on investment (ROI) that we’re seeking to achieve. Increased cost is often a product of unidentified risks or changing requirements, which means we have to add team members to do more work in the same time frame or keep team members longer. Neither is desirable
3. When time is a variable, we lose control over the position in our market. Perhaps we miss an important industry date or our competitors get their product out before us, thus losing any competitive advantage our project may have had.

There are many other outcomes of variable time and cost, which are often negative and undesirable. Of course, many customers and organizations seek to fix all three components of this ‘magic triangle’.

Buyers often outsource complex systems development to suppliers who have the ability to build the kinds of systems buyers need to run their business. There’s a continuum of approaches to contracting, ranging from firm fixed price to time and materials, with almost every point in between. Figure 1 characterizes these various approaches and also highlights the means by which the parties share risk.

Agile contracts & pricing:

Cost is a product of time and people (team members). Add more time, and you add cost for employing people for longer. Add more team members, and you increase the cost to deliver the same business value. The things we really want to avoid. This is why Agile principles believe in fixing time and team members and allowing the scope to be the variable component.

Which sounds better and increases stakeholder confidence, fixed cost or variable cost?

Of course, it’s important that a product delivers on its promises and the needs of its customers. It’s no good spending an exact amount of time and an exact amount of money if, in the end, you have a product that nobody wants or can use effectively.

So Agile contracts focus on the following:

• Fixed price work packages — The whole project is broken down into logical ‘mini’ releases which contribute to the full product outcome. Each release is a work package that is priced accordingly. As a work package is completed, future work packages are re-estimated based on what we have learned from the previous one. This avoids unnecessary contingency and allows for a level of re-prioritization and new/revised features to be defined by the customer.
• Flexible changes — Change is a theme that runs strong through the veins of Agile software delivery. We expect to not know everything we need to make a product successful from the outset. So, we promote change, based on relevant data and feedback, to ensure that the right product is delivered. At the end of an iteration, changes can be swapped out for old features no longer deemed necessary or a priority. As long as the change is of equal value, there is no further cost. If the change is of lower value, additional work can be identified or pulled forward from the remaining backlog. This clause is valid as long as the project team and customer have maintained a strong, trusting and close working collaborative relationship throughout the project.
• Additional work — Through the life of a project, more features may be identified that would not be achievable under the existing fixed price contract. For this scenario, either additional newly priced work packages can be added to the end of the project or revert to time and materials.
• Ranged estimates — There are two ways that estimates can be ranged in an Agile project contract: a range of duration or a range of features. A range of duration allows for an estimate to say that the project or work package will take 12 to 16 weeks for a given set of scope. However, adding duration adds cost as you keep project team members for longer, or it means they can’t be released to work on other development projects. Other option is range of features across a range of story points, keeping the scope as the variable but promising to deliver a minimum level of value to the customer within the fixed time frame of the work package or overall project.
• Early termination — This allows the customer to seek to terminate the project early if enough of the product has been delivered and there is no further ROI to be achieved by retaining a project team that will only continue to deliver marginal gains. This clause is typically allowed at any time and is valid as long as the project team and customer have maintained a strong, trusting and close working collaborative relationship. The benefit for the customer is that the project will finish early, having delivered all the valuable features necessary to make the product viable. In return, the supplier is paid 20 percent of the remaining contract value and offsets the risk of retaining staff.

It’s worth remembering that you can always add more scope later. Perhaps you’ve started to earn revenue, you’ve increased users or reduced costs. Either way, it’s much easier to ask for more money and time if you’ve already demonstrated a return or improvement and are delivering business value.

Resources:

https://www.scaledagileframework.com/agile-contracts/

https://www.toptal.com/agile/software-costs-estimation-in-agile-project-management