Gathering internal support for a software project is mostly a matter of preparation. Colleagues back a proposal when they recognise the problem, can see what it costs them, are asked for a decision small enough to make and find that their objections have already been thought about. They resist when they are presented with a solution to a problem nobody has shown them. The tips below follow that order: the problem, the people, the size of the request, the risks and the meeting itself.
Start with the problem and what it costs
You probably arrived at the idea by seeing something that does not work. The people whose support you need have not necessarily seen it, so begin there and leave the software until later.
Put figures on it, using your own organisation’s numbers:
- Time. How many hours a week go on re-keying, chasing, correcting and working around the current system. Ask the people who do the work; they know.
- Errors. What a wrong invoice, a missed order or a double booking costs when it happens, and how often it does.
- Risk. Whether the current system depends on one person, or on a platform that is no longer supported. Dates help here because they are not a matter of opinion: Windows Server 2016, for example, stops receiving security fixes on 12 January 2027. Our end-of-support pages list the dates for the common Microsoft platforms.
- Missed opportunity. What the business cannot do at present, such as taking orders online or giving customers their own login.
Then say what happens if nothing is done. Doing nothing is always one of the options in front of the board, and it is rarely free. When should you replace legacy software has more on building this kind of case for an existing system.
Know who has to agree, and what each of them needs
A proposal is heard differently by each person in the room. Work out in advance who can approve it, who can block it and who will have to live with it, then prepare for each.
| Person | What they are weighing | What to bring them |
|---|---|---|
| Owner or managing director | Whether this deserves attention ahead of everything else | The problem in two sentences and the cost of leaving it |
| Finance director | Total cost, certainty and payback | A costed problem, a priced first step and the running costs afterwards |
| IT manager | Security, support burden and fit with existing systems | Where it will run, who will maintain it and what it replaces |
| Department heads | Disruption to their teams | What changes for their staff, when, and what help they will get |
| The people who use the system | Whether their day gets harder | A chance to see it early and to be listened to |
Use each person’s own terms. “Fewer manual journal corrections at month end” means something to a finance director that “better integration” does not.
It also pays to find a sponsor: one senior person who wants the project to happen and will say so when you are not in the room.
Talk to them early, and listen
Speak to each person individually before any meeting at which a decision is expected. A proposal that people meet for the first time in a meeting tends to be picked apart there. One they have already discussed with you tends to be approved.
Treat objections as information. “We tried this before and it failed” tells you there is a history to understand. “My team has no time for this” tells you the rollout plan needs to protect that team’s busy periods. Change your proposal where the objection is sound, and tell the person that you did. People support what they have helped to shape.
Include the people who will use the system, not only their managers. They know where the current process really breaks, and their quiet resistance after launch can undo a project that the board approved unanimously. We cover that side in managing user expectations.
Ask for a small first step
“Approve a new operations system” is a large, uncertain decision, and the safe answer to it is no. A smaller request is easier to approve and tells everyone more:
- a short discovery exercise that produces a written scope and a price;
- an independent review of the existing system, such as a code audit, to establish whether it should be kept, improved or replaced;
- a working prototype of the one screen people argue about most;
- a first phase that solves one costed problem and can stand on its own.
Each of these has a known cost and a definite end, and leaves the organisation free to stop. If you need a rough budget figure for the whole project before anyone will discuss it, our software development cost calculator gives a range to start from.
Answer the risks before you are asked
Decision-makers are more comfortable with someone who has listed the risks than with someone who appears not to have noticed them. The usual concerns, and the kind of answer that settles them:
- It will cost more than we are told. A fixed price is possible once the scope and the acceptance checks are agreed, which is another reason to ask for a discovery step first.
- It will disrupt the business. Describe a staged rollout: one team or one process first, with the old system kept available until the new one is proven.
- We will be tied to the supplier. Make it a condition that the organisation owns the source code and holds the hosting accounts in its own name. Take legal advice on the contract wording.
- Staff will not use it. Explain how users will be involved before launch and trained at it.
- The data will not come across cleanly. Propose an early trial migration so that the true state of the data is known before the budget is fixed.
If you do not have an answer to one of these, say so and say how you will find out. An honest gap does less harm than a confident guess.
Keep the support you have won
Approval is the start of the work. Report progress in the terms you used to make the case, show working software as soon as there is any and tell the sponsor early if something slips. Give credit to the people whose suggestions shaped the project. Support that is neglected after the decision is hard to win a second time, and most systems need a second decision eventually.
A one-page case to take to the meeting
Before you ask for a decision, see whether you can fill one page under these headings:
- The problem, in two sentences.
- What it costs now, with figures and where they came from.
- What happens if we do nothing.
- What I propose, in plain words.
- The first step, its cost and how long it takes.
- The main risks and how each is handled.
- Who I have already spoken to, and what they said.
- The decision I need today.
If any heading is hard to complete, that is the part of the case to work on before the meeting. Once the project is approved, the best way to kick off a new software project covers what to do next.