TL;DR: Before you buy new software, work out what your team actually does, what information they need, and what questions your reports have to answer. Write that down, and every supplier can quote against the same clear brief.

• Poor requirements gathering is the leading cause in 39% of software project failures.

• Real requirements come from your staff, forms, reports and workarounds, and especially the exceptions.

• Decide your reports first, because no tool can report on information you never captured.

• A written brief lets you fairly compare improving, adding to or replacing your current system.

• Plan the training and testing as carefully as the technology.
  
  

Why does a good system still let you down?

When a business starts thinking about new software, the first instinct is usually to write a list of features and send it off to a few suppliers. I take a different approach. It’s slower at the start, and it’s the bit that decides whether the new system actually does the job.

Your current system is probably good at the job you bought it for. It holds customer records, memberships or accounts neatly, processes invoices without fuss, and keeps names and addresses up to date.

But the moment someone needs to manage an ongoing case, track what happened when something went off the normal path, or spot trends across hundreds of records, it’s got very little to offer. So staff keep side spreadsheets, copy details into Word documents, or rely on memory and long email trails. If you’re the person who knows which desktop the real list lives on, you know exactly what I mean.

That’s a normal situation, and nobody in your business made a bad call years ago. The work changed. The software didn’t.

The risk comes when you buy something new before you properly understand what the work needs. Research on software project failures shows poor requirements gathering is the leading cause in 39% of failures. So the groundwork matters more than which product you pick.

In short: an outgrown system is normal. Work out what your team actually needs before you go shopping for a replacement.

How do I work out what your business really needs?

I’ve been programming since the early 1980s. A good part of my working life has been spent either coding, or sitting with the people who do the actual work, and writing up specifications that developers can build from. The real requirements sit in the day-to-day detail of how your team works. The manager knows some of it. The software brochure knows even less.

So I start by talking with your staff and walking through real processes with them. I look at the forms they fill in and the reports they produce. I look for the places where someone types the same information twice, and the workarounds people have quietly built because the system wouldn’t do what they needed.

The exceptions get a lot of my attention. Probably more than the routine stuff, to be honest, because exceptions are where systems usually fall over.

The questions I ask are plain ones:

• What starts this process?

• Who needs to do what next?

• What information do they need at that moment?

• What happens when information is missing, or the usual process cannot be followed?

• What decisions should managers be able to make from the records this work creates?

The first answers are usually vague. That’s fine. I keep asking until the real requirement turns up.

Because a supplier can’t quote against “we need better tracking”. They can quote against “when a complaint comes in, these four pieces of information must be recorded, this person must be told within two days, and the manager must be able to report on open complaints by type and age”.

In short: the real requirements come from watching the work and asking plain questions until the vague answers turn specific.

Why does database understanding matter?

This is where my programming background earns its keep. A database stores information in fields, categories and links between records. Set those up well and you can compare things, count things and report on things reliably.

But when important information only lives in free-text notes, all you can really do is read each record, one at a time. You can’t run a report on three hundred staff members each describing things in their own words.

Getting this right means agreeing on consistent fields, clear categories and shared definitions before anyone builds anything. If one person records a status as “pending” and another types “waiting on client”, your reports will quietly mislead you.

I want to be honest about the limits, though. Professional judgement and nuance don’t squeeze into a dropdown box, and a good design leaves room for notes alongside the structured information.

So the skill is deciding which information has to be structured, because you’ll need to report on it, and which can stay as a story in the notes.

In short: if you’ll need to report on it, it needs a proper field. Everything else can live in the notes.

Why should you start with the reports?

Reporting requirements belong at the start of a project, well before anyone looks at products. Write down the questions you want your records to answer. How many cases did we handle last year, how long did each take, where do the delays happen, which types are increasing. Each question tells you exactly what you need to capture, in what form, and at what point in the process.

Collecting data and producing useful evidence are two different things. Plenty of systems collect data all day long and still can’t answer a simple management question, because the right details were never recorded in a form you can use.

And a shiny new reporting tool can’t recover information that was never captured. Your historical records might need their own look, too. They often need cleaning up or restructuring before they can sit alongside new data, which is a job in itself.

Gartner puts the average cost of poor data quality at $9.7 million per year across the organisations it studied. That’s big-company money, sure. But it shows how expensive careless information capture gets over time.

In short: decide what your reports need to answer first, because no tool can report on information you never collected.

How do written requirements make the software decision easier?

Once the requirements are written down, you’ve got three broad options. Having them documented lets you weigh each one fairly:

• Improve the existing system, if it can be extended or configured to do what you need.

• Add a specialist application and connect it to what you already have.

• Replace the system, if the shortfalls run too deep to patch.

Each option comes with different staff effort, integration work, ongoing costs and reporting results. None of them is automatically right. And custom development definitely isn’t always needed.

The real value of a requirements document is that every supplier is now quoting against the same clear brief. So you can compare their quotes properly, and test their claims.

Research on project success backs this up. Where requirements were good, users were involved and requirements were managed well, 93% of projects succeeded.

In short: a written brief lets you compare improving, adding to or replacing your system on equal terms.

What can a scoped requirements engagement produce?

When I work with an organisation on business software requirements, we agree the scope first. What you get depends on that scope, and it can include:

• A documented current process and its main problems

• Agreed outcomes and reporting requirements

• Prioritised functional requirements

• Data and integration requirements

• Questions and assumptions that suppliers must confirm

• A supplier brief that supports comparable quotes

• Acceptance criteria for judging whether a proposed solution meets the requirements

• An outline of implementation, testing and training needs

Not every project needs every item. The right set depends on your situation, your budget and how far along you already are.

In short: you pick the pieces that fit where your business is right now.

Why does implementation need as much planning for people as for software?

Earlier in my career I was a training coordinator on a major software implementation, helping train around 1,000 users. That’s a lot of people learning a new system at once. It taught me that go-live day is the middle of the project, and the people side needs as much planning as the technical side.

Research says the same thing. Organisations spend an average of 92% of their implementation budget on technical work and only 8% on change management. That goes a long way to explaining why staff struggle with new systems.

A realistic implementation plan covers:

• Staff taking part in testing

• Checking that transferred information came across correctly

• Running real scenarios, messy cases included, instead of tidy demo data

• Proper training

• A clear answer on who keeps the information accurate once the consultants have gone home

Build those in from the start and your new system has a fair chance of doing what you bought it for.

In short: plan for your people as carefully as the software, because they’re the ones who’ll use it every day.

What’s a sensible first step?

If your current software handles part of your work well and leaves the rest to spreadsheets and workarounds, or you’re weighing up a system change, talk it through before you commit to anything. Get in touch through Gecko Gully for an initial conversation. From there we can work out whether a requirements and scoping engagement would be useful for your situation, and what it should cover.

And if you know a business owner who’s about to sign up for new software, send this their way first.

FAQ: business software requirements

What are business software requirements?

They’re a written description of how your work runs, what information you need to capture, and what decisions that information has to support. A feature list is only a small part of it.

Why do so many software projects fail?

Poor requirements gathering is the leading cause in 39% of software project failures. Businesses often buy before they understand what the work needs.

Should I replace my current system?

Maybe, maybe not. You can improve the existing system, add a specialist application, or replace it. The right choice depends on staff effort, integration work, ongoing costs and reporting.

Why should reporting requirements come first?

Because a reporting tool can only work with what was captured. Your management questions tell you what information to record, in what form, and when.

What’s wrong with keeping information in free-text notes?

Notes are fine for judgement and nuance. But you can’t reliably compare, count or report on them, so anything you need to report on needs a proper field.

What does a requirements engagement include?

It depends on the agreed scope. It can cover your current process, reporting requirements, functional and data requirements, a supplier brief, acceptance criteria, and implementation and training needs.

Why does training matter so much?

Organisations spend only 8% of their implementation budget on change management on average. Staff testing, real scenarios and proper training give a new system a fair chance of working.

Key Takeaways

• An outgrown system is normal. Buying a new one before you understand the work is the risk.

• The real requirements live in your team’s day-to-day work, the exceptions and the workarounds.

• Structure the information you need to report on, and leave room for notes.

• Write down your reporting questions first, then work backwards to what you capture.

• A clear brief makes supplier quotes comparable and their claims testable.

• Plan the people side of implementation as carefully as the technical side.