How to Plan a Custom Software Project When Tech Is Not Your Trade

Having custom software, an ERP or a business application built for you is a big project, and knowing how to plan a custom software project is what keeps it on the rails from day one. Here are the explanations and the steps to follow so you are ready to ask for quotes that cover not only your own criteria, but also the elements you have probably never thought about.

Describing what you do: the requirements brief

If you want a quote that reflects a real price, one that will not swing wildly the moment something unexpected shows up, the requirements brief we ask you for serves exactly one purpose: letting a developer who has never set foot in your company understand how your processes actually work. A list written on a Sunday afternoon, where every line begins with “the system must”, is not enough, and for several reasons. It describes the software you picture in your head, but understanding the context matters just as much if the whole thing is going to run smoothly.

That is where the misunderstanding starts. You are most likely describing screens and buttons; the developer reads features and prices features. The exceptions, the ones that actually decide the price and the schedule, stand very little chance of showing up in a list like that, and even less chance of showing up in the number built on top of it. Without clear context, there was no way for the developer to guess them.

Describing the context in real detail is where you start when you want to design software without being a programmer. The raw material is one real day in your business, seen through the eyes of the person who does the work.

Follow a single order, from the customer call to the payment

Take one situation or one problem your software will have to handle, neither too simple nor too convoluted, and write down as much context as you possibly can. Who took the call, and what did they write it down on? Who set the price, and what information did they have in front of them? How did the order get to the technician, and when did the money actually come in? One or two pages, written the way you would explain it to a new hire, is plenty.

Name the roles and the documents the way your team actually names them: the work order, the cut list. Then add the cases that are unusual or inconvenient. The customer who pays in two or more instalments and for whom the invoicing form has no box. The production order carrying a handwritten note that says “ask the foreman”. If one order in ten falls outside the normal frame at your shop, that is the one that will add a screen to the software, and it is exactly the one everybody forgets to write down. These are only a few concrete examples, and they all point to the same thing: the full context is critical to spell out.

Next, have the person who handles the following step read your context write-up. If the dispatcher and the technician describe the same work order in two different ways, you have just found the first thing the software will have to settle. Better to settle it among yourselves than with a developer who bills by the hour.

That written account stands in for a requirements brief at the start. A software development firm can read it in a few minutes and come back to you with precise questions.

Choose what the first version will leave out

Once the transaction is written down, decide what the first version will not do. That decision takes about one solid meeting. How much it saves you afterwards depends on how rigorous the discussion in that meeting was. If you cannot bring yourself to remove a single item from your list, the project may not be ready to go out for quotes.

If you get a feature wrong, it does not mean everything has to be rebuilt, on one condition: that feature has to have been built as a detachable piece, and not as a central pillar that will be painful to pull out. Whatever you set aside goes into a dated, detailed list in the product backlog, to be reviewed once version 1 has been running for a month. With that kind of discipline, you get close to the steps that cut down on extras and misunderstandings.

A mockup answers one question, a prototype answers another

A mockup is a low fidelity drawing of the software’s pages, with no code behind it. Working through a sample scenario, it checks that the salesperson finds their quote where they go looking for it, and that the field filled in twenty times a day falls right under their hand. A clickable prototype strings those pages together; it checks the order of the steps, and the look and feel can wait.

A proof of concept (POC) is not about the user at all. It answers a technical question nobody can answer off the top of their head. Does the vehicle tracking system let another program read the technicians’ positions? Can the production file, with its yellow column whose meaning is written down nowhere, be read without errors? A POC is paid for separately and ends in a yes or a no.

If all three show up in a proposal, ask which question each one settles in your particular case. For a tool meant for two employees, a morning spent with them and a sheet of paper often tells you more.

Your data already lives somewhere, and that changes the project

If your quotes live in a spreadsheet and your customers live in the accounting system, the new software is not starting from zero; in our jargon, we say it inherits. You will have to decide what gets migrated and what stays connected. Connected means the software talks to the accounting system through an API, a door the vendor built in so data can be exchanged. If yours does not offer one, say so early: the connection then has to be made another way, and it costs more to maintain.

If the new software has to replace an in-house program that is already running, the project changes nature. Rewriting an older piece of software is decided on a different set of criteria, which we cover in a separate article.

The moment the software records a customer’s name or a technician’s cell number, Quebec’s Law 25 applies. It requires the design itself to account for who sees what, how long personal information is kept, and where it is hosted. Some projects call for a privacy impact assessment. The Commission d’accès à l’information publishes guides; a legal advisor handles the grey areas. Software is never “compliant” in and of itself; what you do with it after delivery counts just as much.

Four ways to get the software built, and where each one fits

A no-code platform suits straightforward cases that come down to a form and a list: booking the training room, tracking the keys in the garage. It helps if someone on your team enjoys building their own tools, and if you can count the users on one hand. No-code development is a weaker fit as soon as the exceptions pile up, or as soon as the accounting system has to receive every invoice without anyone touching it. Check as well that an off-the-shelf product does not already cover almost the entire transaction; where the purchased tool stops and the custom build begins is the subject of another article.

Hiring a developer becomes necessary if there will still be work for them once version 1 ships. If your idea is a product for your industry, look at this option and at the firm option first: a product gets updated for years. A lone developer carries the whole project on their shoulders; plan for who reviews their code and who covers for them over the summer.

That leaves the firm. Reread your requirements brief or your short written account: if it holds more than three exception cases, or if another system has to receive what comes out of it, the firm comes ahead of the other three options. You pay more up front. In exchange, you are buying a team instead of one person, and someone still answers after delivery.

How many people will use the software, and for how many years will it need to be touched? Those two questions are essential if you want to judge whether a budget is serious enough to see you through the long term, instead of forcing you to rewrite everything within two years or less because the situation was handled with makeshift fixes and no-code solutions that were never the right fit.

What a first meeting checks before a quote is presented

We ask for two things before the first meeting: the complete walkthrough, and the context of the employee who will be doing the software-related tasks every single day. Read access to your existing data helps, without being mandatory. During the meeting, a CyberPerformance programmer reads the account through with that person and stops them at every “it depends”. Every “it depends” is a business rule the software will have to know, and the price depends on how many of those rules there are.

By the end of the meeting, we can usually tell you whether the project is measured in weeks or in months, and which piece to build first. The piece we recommend you hold off on is part of that answer too. What we will not give you that day is an exact dollar figure. We run a deeper analysis before doing that, so nothing is left in a blind spot. The needs analysis begins with that read-through.

Before you sign anything, ask these questions of every firm you meet, ours included:

• What did you understand my need to be? Have them tell it back to you; if the textbook case of the customer who pays in two instalments is missing, the account was not properly understood.

• What would you remove from version 1 if the budget were cut in half?

• Which of my “it depends” answers will you settle before writing a line of code?

• If version 1 turns out to be wrong on one point, what does the change cost, and who decides?

How to plan a custom software project: your first step, this week

Having a good team beside you to frame the project properly is essential. We have delivered more than 150 digital projects, and that is where the best practices we apply to complex builds come from.

Get in touch with us through the Contact Us section to set up a Google Meet so we can go over what you are expecting.