ICT Managers
Plan, organise, direct, control and coordinate ICT projects, service delivery, systems and infrastructure within organisations.
Go-live Friday
You are an ICT manager at a council, running a staged launch of a new online system for booking community halls. It is Wednesday and the launch is set for Friday. The council's customer service team is nervous, the contractor is behind on one fix, and the mayor has already mentioned the date in a speech.
Choose what you would do. Then see what happens. There are often good reasons for each choice.
We found a bug where two people can book the same hall at the same time. It happens rarely, but it happens. I can fix it by Friday if I skip some testing, or we fix it properly and launch Monday. Your call.
Launch Friday with the quick fix, and test it properly over the weekend while staff stay on call
The quick fix creates a second, quieter bug. By Saturday morning, a wedding and a funeral are both booked into the same hall. The date held, and trust did not.
Delay to Monday and tell everyone it is because of a serious fault in the booking system
The system is sound, but describing a rare bug as serious worries people unnecessarily. You made the right call, and explained it in a way that frightened more than it informed.
Move to Monday, tell the mayor's office and customer service now, and prepare staff
The mayor's office adjusts the message, customer service gets a calm weekend of training and the launch goes smoothly. A short delay announced early is much easier than a failure announced late.
My team have two hours of training scheduled, but the new screens are different from what they know. They are worried about the first week. Some are saying they would rather keep the old system. How do I reassure them?
Tell her the system is simple and they will pick it up quickly
It is meant kindly, but it dismisses their worry. The team feels unheard and a few of them hold back from asking questions when they need to.
Offer more hands-on practice with real examples, plus a quick-help sheet and a named person to call in the first week
Dorothea's team practises on realistic bookings and knows exactly who to call. People accept change much better when they have been given the tools to succeed at it.
Say the decision has been made and it is not up to staff to choose
Technically true, but the team feels pushed. A few start looking for problems, and every small glitch becomes proof that the change was a mistake.
I have been told there might be a delay. I have made promises to local clubs about using this system for their annual events. Can you just tell me it will be ready, whatever it takes?
Promise it will definitely be ready, because it is easier on everyone and the clubs have planned for it
The promise goes into the club newsletter. When Monday comes with a small problem, the councillor feels misled and you have lost goodwill you will need later.
Tell him honestly what is certain and what is not, and offer a manual booking fallback
The councillor gets a message he can pass on, and the clubs have a fallback. Committing to a backup plan is more useful than a promise you cannot control.
Refer him to the director, because commitments like this are not your decision to make
It is correct, but he is left with nothing to say to the clubs, and the director is annoyed to receive a call that you could have helped to answer.
How it went
The launch moves to Monday, the staff are ready and the clubs have a backup plan. ICT managers keep technology working while keeping people, deadlines and expectations in line. Would you enjoy being the person who makes the technical and the human sides meet?
This is a simplified, fictional situation to help you explore. It is not professional instruction or a test of your ability.
Case study: The upgrade that kept slipping
A fictional case set in the technology services department of a fictional regional council.
The situation
Council IT project manager Haruto Nakamura was nine weeks into replacing the system that handles rates payments and customer requests. Each week, the status report said green. But developers told him privately that the data transfer was taking far longer than planned. The go-live date had been promised to councillors and published in the newsletter. Reporting amber now would mean uncomfortable questions from the director, who had already said she did not want surprises.
What they did
Haruto changed the status to amber that week and wrote a two-page note with the reason, the options and what he recommended. He met the director before sending it. The options were to move the date by three weeks, cut one lower-priority feature, or add a contractor. He explained the risk in each, and recommended a mix of the first two. He then briefed the team so everyone gave the same account.
How it turned out
The director was frustrated but chose the mixed option, and announced the new date herself. The project went live a few weeks later than first promised, with only minor problems. Haruto learned that reporting green when it is not is the quickest way to lose the trust you need most.
What would you do?
- Why did Haruto talk to the director before sending the note?
- What would make it difficult to report a problem when people expect good news?
- How might a technology manager explain a delay to people who do not use technical language?