I'm a junior sysadmin at a small nonprofit, and management seems reluctant to change long-standing systems. Our custom helpdesk tool has bugs, lacks reporting, and some users can't submit their own tickets.
I've raised the problems and put together a proposal comparing alternatives, but we're still told to work with what we have. How can I make progress without trying to change everything at once?
I'd narrow the next conversation to one failure, not the whole helpdesk replacement. For example, which users can't submit tickets, how often does that happen, and how much staff time does the workaround take? Track it for a few weeks if you don't already have the numbers.
Then ask for a specific decision: fix that access problem, approve a small trial of another intake method, or accept the workaround for now. Include the effort and cost for each option. A full vendor comparison is useful, but it can be a lot to absorb when the director hasn't agreed that the problem is worth solving yet.
Ask the director what makes the current setup preferable to changing it. There may be concerns about staff time, disruption, ownership of the custom system, or something else that hasn't come up. It might also help to ask what evidence would make the issue worth revisiting.
Try not to frame the developer's work as the problem. Talk with them about whether the ticket issue can be fixed within the existing system and what that would take. A targeted fix may get further than replacing a tool tied to the organization's main CRM.
Put the impact in terms management can use. Time spent manually creating tickets is one cost. Missed requests, lack of visibility, and difficulty reporting on workload may matter too, but only claim what you can actually demonstrate.
Keep a short record of the problem, options, estimated costs, and the decision made. If a proposal is declined, ask when it should be reviewed again and what work should take priority instead. That makes the tradeoff visible without turning every conversation into the same argument.
Be open to the possibility that some of the old setup has constraints you haven't seen yet. A system can be frustrating and still serve functions that would be expensive or risky to replace. Ask the senior sysadmin and the people who use the CRM what a change would affect before settling on a solution.
For security-related changes, a framework such as CIS Controls can help explain priorities, but it won't decide the budget or make a helpdesk replacement necessary by itself.
There's a limit to what you can authorize as a junior. You can make a clear case and document the decision, but you don't have to take responsibility for management declining it. Work on improvements within your remit, and keep building your skills in case the lack of progress becomes a long-term problem for you.
Answers are reviewed before publication.
G6+Pexlow:
A trial should have an owner, a time limit, and a way to judge whether it helped. Make sure it's approved before introducing another tool.