Ensure ROI is a priority for your software project, by using this software development brief

When scoping a software project, communication is extremely important.

From our perspective, scoping out a project consists of developing an in depth understanding of your situation and pain points, and then working with you to identify how to generate the maximum return on investment by solving those pain points.

However, at the start of every conversation, there is naturally a knowledge gap. Naturally we understand tech and you understand your business and pain points, we must bridge that gap!

Based on over a decade of experience, we’ve put together a template detailing how to prime a development agency like us, with the information we need to understand your project.

Why write a software development brief?

Simply, it lets you and your team evaluate the problem at hand, and give that to solutions providers like us in a consistent and detailed way.

If done in the right way (see our template!), it ensures proposals are geared to solve your problem and generating ROI

If the conversation is only orientated towards a solution, how are you able to guarantee that a proposal:

Generates ROI for your business
Solves real pain points in your business
Has a measurable/positive impact on the business

Detailing the objectives, measures and values up front in a software development brief, allows you to assess proposals against these and answer the above questions

It makes it more likely quotes you receive are comparable

Consider engaging with multiple solution providers without this, will all of them have the same information? If all solutions providers have different information, will they all be providing proposals for the same problems?

It should provide wider context of your business and objectives, but also laser focus on the problems at hand

It’s important that a project has clear objectives which are measurable, and that the value of the project is understood.

At the same time, sight of the wider context allows a solution provider like us to recommend strategic decisions which provide more value now, or make decisions for the solution which deliver more value in the long run.

It may sting if a solution implemented now has to be changed in consideration of your wider objectives – knowing these earlier allows us to make informed decisions.

How should you describe your business in the software brief?

About you

Firstly, it’s important to know about your business, who you are and what the ambitions are.

You likely have this information already – just copy and paste this from your website!

Consider adding to this with information on the business ambitions and objectives:

What made you want to start this project?
What are your business objectives over the next 12 months and 5 years?
Where have you been as a business? Are you growing rapidly? Have you recently had any major changes?
How many people do you employ right now? How has this changed over the last 12 months and how will this change going forward?

What problems do you want to solve?

List 3 to 5 high level pain points which are important to solve

What are the most important pain points, in order, which you are looking to solve during this project?

How do these translate to key objectives?

E.g.

E.g. We have to manually move lots of data which is time consuming and error prone
E.g. We use Excel, and constantly muddle up and overwrite each other’s work
E.g. We are not able to make reports which make sense, and can’t make data driven decisions

Consider how solving these problems will generate an ROI for your business. Please see our article 21 Indicators that lack of tech is slowing scaleup growth, for inspiration on these.

Why are these problems worth solving? What does that mean to you and the business?

How do we ensure that we aren’t solving problems for the sake of it?

How do we ensure that solving a problem has a positive impact for the business?

Ensuring that solving a pain point generates a return on investment, or empowers the achievement of strategic objectives make a problem worth solving. Do the problems you want to solve generate enough value to make it worth the investment of time and money?

Summarising why these problems are worth solving helps gauge the value of completing the project, and allows us to set measures of success – how do we know it was done correctly?

Consider answering the following questions

What growth opportunities are unlocked by solving the pain points above?
How will it either save you money, or allow you to generate more revenue?
How will this project better allow you to achieve business objectives?
How will you measure the success of this project?
Why is solving these problems, and this project valuable to the business?

What has been tried so far?

You may have already tried to solve some of the pain points in this software brief. If so, what have you tried? What worked well and what failed?

Understanding this allows us as solution providers to learn from your previous work, and rule in/out solutions going forward.

For example, have you tried any off the shelf software to solve the problem? If so, why didn’t this work? Did aspects of it work? How would you implement a better solution?

If you have documentation for the processes at hand, also consider including those here.

What other software are you using right now which relates to this problem?

Understanding what else is in play ensures we don’t get tunnel vision, and that we consider the wider landscape. Consider listing the following:

Current software you use which you believe should be replaced
Current software you think might be impacted by this project
Current software you want to keep, and integrate into this solution (e.g. we use accountancy software X, and want invoices to be created automatically)
Software you’ve seen and think would be beneficial for your business

What do I need to add to understand the solution?

What key features do you see being present in the solution?

You may have already ideated a solution, if so, feel free to bullet point how you see this working, or attach any documentation, mind maps etc you’ve put together. E.g.

We want this to integrate with our accounting software, so that we don’t need to manually create invoices
We need our clients to log into a portal and see information about their account without having to contact us
We need to have a reporting suite to we are able to see real time information on the use of the system and the revenue generated through it at any one time

Budget: What are you willing to invest to solve this problem?

This can be tricky, most people don’t know how much software costs! Why would you? It’s like someone knowing how much a cake factory costs.

It’s important to assess a budget against the Return on Investment the project will generate for the business, so it’s an investment and not a blind cost.

For example, “It will cost £50k” might look scary with no context, however, “The project will create £150k in cost savings for a £50k investment” is a much clearer decision!

In any case, consider a budget, even if it’s just how many 0’s the investment level has. A good solution provider will bring up budget before proposal, and an open and honest conversation should ensue.

Timescales

Timescales must align between your business, and those put forth by a solutions provider.

For example, a solutions provider will likely already have a pipeline of work and will not likely be able to start the project immediately – it has to be scheduled in. Knowing that in advance allows for an alignment of expectations before a proposal is put forward, and saves everyone time.

If you have key dates which must be met, add these here. Consider the following:

Financial year & budgets
Marketing campaigns
Key stakeholders, e.g. if you must onboard your clients, are the clients themselves on a cycle which could line up with a launch of software

Stakeholders

Consider who is important to engage with for the solution. We advocate that the following people are involved in the process:

Who ever is making the final decision, this is generally the managing director, or someone from the leadership team if that decision is designated. Involving them too late is likely to lead to a situation where they do not have the information they need to make a decision
Who will be managing the project day to day from your perspective? Ensure they are involved from the get go
Who are the key users of the software to be implemented? Ensure they are a part of the process when defining the problem and the solution – having these people invested and bought into the process makes it easier to implement the software into your business later

Decision Criteria

It’s important to decide what you’re looking for from a proposal, and how you will choose the best proposal for your business. This makes it clear internally from the outset what you’re looking for, and makes it easier for you to communicate that with suppliers throughout the buying process.

For example, you may feel that one of price, ROI, experience, timescales or quality of the solution are important.

If a supplier puts forward a proposal focussing on the shortest timescale, but you actually care about the highest ROI, the process with that supplier may not have been the best use of time.

Having these also makes it easier for you to score proposals objectively, meaning you are able to pick the proposal best for your business.

What are common mistakes I must avoid?

Lacking detail

It’s common for us to see a one page software development brief summarising how a solution might look, with a request for a quote on that solution.

It’s great that effort has been made to document the project, but in this form it’s generally not informational enough to go straight to a proposal.

You will likely receive a proposal with lots of assumption, and detailing a solution which will not fit your needs as a business. You may also receive proposals which are solving different problems (as they are assumed), so it’s hard to compare them like for like.

Designing a solution, without detailing/understanding pain points, objectives or ROI

When bypassing these steps and looking straight at a solution, how are we sure that the solution actually solves your problems?

How do we sense check it to make sure it hits business objectives?

How do we assess the investment required for the solution and check that there is a positive Return on Investment?

How will we mutually be confident the project is worth doing?

Without answering these questions, you may not feel confident making a decision once you have proposals, simply because it’s ambiguous whether the project is even worth doing.

Answering these questions first, ensures the project is viable before jumping into designing a solution.

Providing a software brief which is the solution

We always think it’s great when this has been thought through, but we will still advocate that we go through our process to understand the problems and ROI.

If we do not, you face 2 key risks:

How do we ensure we understand the problems and value? How do we ensure that the solution you’ve design fixes these?
How do we ensure that the solution is the best solution possible?

It’s also worth considering why you are engaging a solution provider in the first place. Is it because they are technically competent and experienced? If so, are they the best people to design the solution alongside you, based on problems you’ve put forth?

Pushing for a proposal/cost before understanding ROI and value

The problems this causes have a lot of cross over with the above. This generally involves short cutting the process and putting forward a proposal without answering key questions about the project.

When we’re put in this position, we will always bow out rather than put forth a proposal, as it’s morally better for us to shake hands and call it a day, rather than putting forward a solution which we simply cannot justify.

We must follow our process to ensure we have a mutual agreement with you that the project has value.

If a project is started under these circumstances, it makes it hard at the end of a project to understand whether it was a success or not. The software may have been delivered successfully, but has it actually had a positive impact on the business?

Equally, it may be discovered that a project is actually not worth doing or the ROI doesn’t stack up, and this is also fine!

A good solution provider will discover this early in the process, and will not want to spend your money on a project which does not generate ROI.

Assuming a project is able to start immediately after contract award

Solutions providers like us generally have carefully managed project plans with multiple ongoing projects, it’s rare that we’re able to start immediately.

For example, we’re generally able to start planning, discussing and designing the solution fairly quickly, but we typically have a lead time of weeks, at any given time, before core development on a project can start.

It’s worth assuming that a lead time of 8 weeks may be typical, but this will vary amongst solution providers.

Conclusion

Technology can be hard. Most businesses don’t have anyone in the leadership team who are professionally qualified to understand it.

However, what you do know are your business, your objectives, and the problems you face. Writing a software development brief which highlights these, along side your objectives, allows a solutions provider to design a technical solution which solves these, and for you to assess the best provider.

In summary:

Focus on the problems & objectives, the value solving these generates, and how that should be measured
Summarise this as an ROI for the business, how much money is saved, or revenue is generated by achieving this?
Putting thought into a solution is great, but making this the sole objective must be avoided, to ensure the solution providers are able to put forth a solution which they believe solves your problems and generates ROI

If you use this software development brief, please feel free to also submit it to us to start a conversation around your project!