How We Price Software Projects

Demonstrating ROI on IT Projects: A 345 Technology Guide

Introduction to Software Projects

With IT software projects, pricing is such a key thing.  Customers want value for money and IT service providers generally want to deliver this.  However, commercial factors and price often damage an otherwise good working relationship.

This page takes you through the basics of pricing so that you have an understanding of how we price at 345 Technology.  This won’t be too much different from how anyone else does it – what will vary is how transparent the pricing is!  For the purpose of this page, I’m talking about software delivery projects based on professional services rather than software licences or support contracts.

Base calculation

Time is money.  For professional services, the price of the project is related directly to the amount of effort expended on the project, usually measured in man-days.

Price = day rate * effort in days

If this seems too simple, you’d be right – but it’s a good approximation.  Obviously different roles have different rates, but you still calculate in a similar way.

For agile projects the calculation is very similar, still coming down to effort in days, but we tend to price per sprint for a team of people.

Price per sprint = number of team members * average day rate * sprint duration (usually 10 days)

Day rate

As a business, we have to pay salaries, taxes, office costs and other expenses and each consultant has a certain number of days per year that we are likely able to charge for.  At 345, we calculate how much it costs us to employ each grade of consultant.  We then need to make some margin on this – to fund the business overheads and future investment – and that’s how we get to a day rate.  We’re broadly comparable with other similar UK companies.

Day rate = (employment costs + internal costs + margin) / (days worked)

Effort and productivity and effect on day rate

You’d think that the amount of effort spent on a project would be comparable between different IT companies.  It isn’t by a long way! 

At one extreme, you have companies with lower skill levels and fewer tools and processes.  Lower productivity.  This type of company will probably sell to you on a lower day rate, but they will likely need a lot more days to deliver.  This will erase the savings you thought you might have made on rates.

At the other end – where 345 Technology is – we have efficient and effective processes to maximise the productivity of our people.  We invest in tools, frameworks, processes and skills so that we can achieve results faster and with better repeatability.  Our people have access to training to improve their skills, which means less days are available for billing.  Generally, companies like ours will have a higher day rate because of the investment in people and systems but we generally need fewer days’ effort to deliver our work.  We’re good value.

Risk

On a software development project, we usually regard risk as:

  • Things that impact on the timescale of the project (usually needing more effort)
  • Things that just require more effort

 

This makes the calculation more like this:

Price = day rate * effort in days + risk

We generally see these different strategies to deal with risk:

  • Ignore it and hope bad things don’t happen
  • Manage the risk yourself
  • Get your supplier to manage the risk

 

As you can imagine, the first option is not one we would recommend.  It is surprisingly common though.  We may get asked for a quote – “how much effort do you think this will take?”  You might then get this budget and come back and buy that much effort from us, but then get left short if some risks materialise.  In our experience, this can often be the cause of major breakdowns in customer-supplier relationships.  Unless what we’re working on is very simple, we’ll always try to advise you of what contingency you might need.

When you manage the risk yourself, you first evaluate the level of risk and then set an appropriate contingency budget.  For a low risk project this might be 20%, but for a high risk project with new technology or unclear requirements you might literally add 100% as contingency.  You then engage your suppliers on a time and materials (T&M) basis and when additional costs materialise you allocate some of your contingency.  The advantage of doing this?  When things go well you get to keep your contingency, you can be more agile because decisions can be deferred to later in the project.

When you ask your supplier to manage the risk – through fixed price or fixed outcome contracts – what we do is to create that contingency budget and add it onto the cost of the project.  We then try to manage the project to the initial estimate and use the contingency when problems arise.  The advantage of this approach to you?  You put a limit on your risk.  The disadvantages?  You need to fix scope early on, which means a lot more up-front work to specify the solution and requirements.  You always have a need to change requirements or scope, and so you will also have to pay for change requests.  This can also be a cause of breakdown in customer-supplier relationships.

The way we prefer to work is what we call “Agile T&M”.  We advise you on your risk level and you set the contingency.  We supply a fixed team – with predictable pricing – and we measure progress throughout the project.  This makes overruns easy to spot, and the cost of them is very transparent.

Building up estimates

When we estimate for projects, we have a comprehensive framework that captures the full set of activities we need to perform to deliver a predictable and high-quality outcome for you.  This includes:

  • Project initiation and setup
  • Architecture, design and documentation
  • Agile project management, including running the ceremonies and backlog management.
  • Test strategy, planning and execution
  • Transition to production, handover and hypercare
  • …and, of course, software development activities!

 

Ultimately, this comes down to us building a big spreadsheet that calculates the total effort we believe is required for the project.  We then look at the mix of skills and roles we need and the number of days required for each.  Contingency is added as a % based on risk.

For agile projects, we look at how many sprints we need with a team to deliver all the work.  Contingency will be a number of additional sprints that may be required.

Discounting

Discounting is all about give-and-take.  For us as a company, if we’re chopping and changing people between software projects we usually end up with more days where we can’t charge for our people.  This is factored into the day rate calculation.  When our people are engaged full-time for longer durations we can get higher utilisation, meaning their costs can be spread over more days.  We then offer this back to you in the form of discounts.  Typically, volume discounts are applied at 3, 6 and 12 months and can vary from 5-10%.

Depending on the engagement, we may also offer you incentives based on the following:

  • Named case studies.
  • Being your partner of record for Azure consumption.
  • Sharing IP that we can reuse.

Conclusions

In our experience, transparent pricing is a key foundation of trust in relationships with our customers and our suppliers.  This page gives you an overview of how we calculate pricing for your software projects.  No hidden surprises and everything clear and transparent.

The key takeaways:

  • Don’t focus just on day rate, look at productivity and overall project cost.
  • The key to negotiating better prices is committing to longer durations, plus you have other things to trade.
  • Make sure that you understand and minimise risks, as you pay for this one way or another.

Further reading