ICT Business and Systems Analysts and Architects
Design, develop, manage and evaluate ICT systems and software solutions, processes, methods and cloud infrastructure, and communicate with users to ensure outcomes meet their needs.
A workshop with three opinions
You are a business analyst at a consulting firm, running a workshop for a new patient records system with a regional health service. It is 10am on the second day of the workshop. The room has a manager, a nurse, a receptionist and a data officer. They have just discovered they disagree about almost everything, and the clock is ticking.
Choose what you would do. Then see what happens. There are often good reasons for each choice.
The most important thing is that nurses can see a patient's history at a glance. Everything else is secondary. I don't want us wasting time on forms and reports. Let's get this settled and move on.
Agree and note it as the top priority, since she runs the clinical side and knows the patients
The room goes quiet, and the receptionist and data officer stop contributing. Later, the system is built for nurses and unusable at the front desk. A priority agreed in a hurry often unravels.
Capture her requirement, then ask everyone else what they most need and show the list
The wall fills with notes and the group sees that the needs overlap more than they feared. People feel heard and the arguing eases. Seeing everything together makes the trade-offs visible.
Tell her that everything is equally important, and ask her to wait her turn like everyone else
It is fair, but Fiona feels pushed aside and holds back for the rest of the day. Being impartial needs a little warmth to work.
That's not how it works on the front desk. Nobody gives us the history first. They ring and say they feel sick and ask for a doctor, and we have to guess. Your drawing doesn't show that at all.
Ask her to talk you through a real call, step by step, and sketch it on the board as she speaks
Joy shows you something no one else saw, but the nurse and the data officer lose interest during the long walk-through. A short example works better than the whole story.
Say her point is valid, and explain that the first version will focus on the clinical side
Joy hears that her work does not matter and says nothing for the rest of the session. The front desk becomes the weak link in the new system.
Ask her for one recent example, sketch it with her and add the gap to the shared list of needs
The example is clear and short. The whole room recognises the problem, and the sketch changes the plan. Real examples beat opinions in every workshop.
I need you to tell me by Friday exactly when this system will be finished and what it will cost. I'm presenting to the board next week. Just give me a firm date, please.
Give him a firm date, because he needs one for the board and he can always adjust it later
The board is happy, but the date is a guess. When the work slips, Hugo is blamed and so are you. A date without a basis is a trap for both of you.
Give him a range, say what is still unknown and suggest a date for a firmer estimate
Hugo takes it to the board with honest caveats, and the board approves a stage-by-stage plan. Being straight about uncertainty is a skill, not a weakness.
Tell him it is impossible to say and that he will have to wait until the work is further along
Hugo goes to the board with nothing, and the board hears that the project is out of control. It is true that you cannot be certain, and refusing to help makes things worse.
How it went
The workshop ended with a shared list, a short example from the front desk and an honest range for the board. Analysts and architects work between people and technology, helping each side understand the other. It is a lot of listening and a lot of careful explaining. Could that be you?
This is a simplified, fictional situation to help you explore. It is not professional instruction or a test of your ability.
Case study: The booking system that nobody used
A fictional case set in a technology consulting team working with a fictional regional health service on a new booking system.
The situation
Omar was a business analyst at a consulting firm, hired by a regional health service to improve how appointments were booked. The first plan, written by managers, had a tidy online form. Omar noticed that the managers had never actually watched the front desk staff take a booking. The project had a fixed timeline, and spending a day at the front desk would eat into it.
What they did
Omar asked to sit beside a receptionist, Lena, for a morning. He saw that most bookings began with a phone call from someone who did not know which service they needed, and that Lena regularly used a handwritten list to guess. The online form assumed the caller already knew. Omar rewrote the requirements to start with a simple question to help callers find the right service, and showed Lena's list to the managers.
How it turned out
The managers agreed to change the plan, which added a few weeks to the timeline. The new system included a helper that Lena and her colleagues tested and trusted. When it went live, fewer calls ended with the wrong booking, and the project team kept sitting with users before each new phase.
What would you do?
- Why might the people who ask for a system not be the people who use it?
- How would you tell your client that their plan needs to change?
- What would you enjoy more: listening to people, drawing the plan or working out how the pieces fit?