The IT Analyst job can be compared to that of a translator. Being a liaison between clients and development, they translate business to technology.
Have you ever played Chinese Whispers (also known as Telephone)? It’s the time-killing game often used for ice-breaking among kids. One person comes up with a phrase which then circulates via whispering and comes back to the source. More often than not, the outcome is a complete abomination compared to the original sentence, but that’s what it’s all about – fun and games.
Sometimes it’s not a game. And it’s not quite fun either. Digital development companies often find themselves playing Chinese Whispers, what – instead of a good laugh – results in heaps of frustration and a lot of money sent down the drain. That’s exactly why each one of them decides to hire an analyst. The guy that ruins the game and writes the whispered phrase straight down on paper.
A Business Analyst? A Systems Analyst? An IT Analyst? An IT Business Systems Analyst?
You might have heard this “fun fact” about Inuits (not Eskimos!) having over 50 names for snow. This way-too-popular linguistic trivia has been proved as wrong (or not exactly correct), but there are many more fascinating examples of polyonymy (the use of many names for the same thing) to bring up.
When I met up with Adrian, HeroDOT’s [blank space] Analyst, I wasn’t exactly sure how to address his role. In our company records he’s listed as an IT Analyst, yet his LinkedIn profile made me consider that he might in fact be more of a Business Systems Analyst.
As it (unsurprisingly) turned out, Adrian’s role is basically a business version of Inuit snow. Let’s paraphrase a joke to sum it all up.
The company door opens. A Business Analyst, a Systems Analyst and an IT Analyst walk in.
– Oh, hi Adrian – everyone says.
All those names fit into the same semantic wheelhouse. They in fact can mean exactly the same thing, but it’s on the company to lie out what roles and responsibilities they expect when hiring an Analyst. If you take a while to look at ads for this kind of job, you’ll notice that they can all be completely different.
Note: at HeroDOT we use the term “IT Analyst”, as it’s the closest to fully describing our expectations towards this role.
Is It Finally Time for an IT Analyst Definition?
To make the role of an IT Analyst as clear as possible to understand, we need to highlight three key “entities”:
- The Client
- The Development Team
- The IT Analyst
and two key “processes”
- Handing off the solution
Now let’s take a hypothetical situation: No IT Analyst on board. In fact – no Analyst at all. The client approaches company X, with only a minimal idea of what they need. A digital solution, a CMS for example. Now, without studying the client's needs (both those implicit and explicit), designing is a game of guessing.
For both sides.
The devs may not exactly be experts in drawing the client’s insights, and at the same time – the client might struggle to understand how his expectations translate to digital.
That’s where the “native” speaker of both languages steps in. An IT Analyst, in simple words, translates the client’s expectations to the devs’ workflow. They hold the ability to discover and fully understand the client’s business processes (which are directly influential to the entire project) and then effectively turn them into agreed requirements for IT systems.
You might say – that sounds pretty much like a Business Analyst. Yes (to a certain extent), the major difference being that an IT Analyst’s primary focus is putting forward and consulting matching digital solutions. Having the processes already analysed, the Analyst also comes up with a software to improve (or implement) them.
So, an IT Analyst serves as a bridge between the developers and the client. Let’s say they’re directly in between. They don’t write code or stand behind the back of those who do, but provide support and required details. On the other hand, they’re not looking to make profit themselves, but seek the most efficient solutions on the client’s behalf.
An IT Analyst in Agile Project Management
At HeroDOT, we work on our projects using the Agile methodology. Depending on the size, we pick either Scrum or Kanban. Experience in working with these methodologies is vital for an IT Analyst.
If the project is significant in size, most likely a Scrum team will be assembled. The backlog is pre-planned every two weeks after a sprint. The Product Owner then hands out tasks, which have been agreed with the client.
To showcase the role of an IT Analyst in the process, let’s use an example. For context, the project’s about e-commerce. Now, once the tasks are written out, they have to be comprehended (and that’s often easier said than done). It’s a decent practice to consult any potential queries with the client themselves, to avoid misunderstandings.
Then the first analysis happens – at this point they’re less of an IT, more of a Business Analyst. They verify and gain knowledge about the client’s business processes by asking questions. These apply to both the current situation and requirements for the solution (closely related to the former). Hypothetical questions could be:
- What does the ordering process look like?
- What types of payment are there?
- Are there any existing loyalty programs?
Once data is collected, the IT Analyst moves on to consulting the outcome with the devs, system architect, and the team overall (e.g. certain information could be key for the marketers) to verify whether the client’s expectations are approachable and possible to carry out, all things considered*.
*This means not only the sheer technical feasibility, but mainly the budget-expectations proportion (devs claim that “there’s nothing that can’t be done”). If the latter strongly exceeds the former, the team needs to take a new approach and carry out an alternative proposition.
At this point, the IT Analyst starts to prepare the project documentation (more on that below), which is passed on to the team. Discussion is crucial. It provides quality feedback, which the Analyst then applies to the documents. Completed by visuals and prototypes, a full package is sent to the client.
During the project’s lifespan, the IT Analyst serves the role of a lifeguard – they’re ever-present, ready to throw themselves to help fight a potential crisis. During daily calls, they make sure everything is going as planned.
Skills Every IT Analyst Needs
Almost every IT Analyst job description you’ll find will have a similar list of rigid expectations (that’s also exactly what you’d expect from this form of literacy). You get to verify the need of knowing UML and BPMN notations, what documents you’ll be required to prepare, all topped off with a reassurance you’re on the brink of becoming a member of a young and dynamic crew.
But what else is there to know about IT Analyst jobs? What skills aren’t mentioned in the ads, but seem to be necessary to excel in this role?
Great Communication Skills Fueled by Inquisitiveness
Clients aren’t open books. In fact, they’re more comparable to an almost pretentious multi-dimensional films, which rush you to seek explanations on internet forums as soon as they ends. Or just poetry, for that matter.
An IT Analyst is tasked to communicate with (and more importantly – thoroughly understand) the client. They negotiate and establish key requirements, being responsible for extracting both the client’s existing business processes and their implicit expectations.
This is where it’s crucial to be inquisitive – the other party may be reluctant to share a real image of their business reality, uncovering only textbook definitions. This will (rather sooner than later) turn back on them, as it’s near impossible to match a system to a non-existing process. Imagine being a suit tailor, and the only reference for measures your client provided is a photo of them in smoking hot summer form. The truth, however ugly, is needed.
Same goes for the aforementioned expectations. The client might be die-hard convinced he wants this and that, until… he gets asked why? Pulling on these threads might me perceived as being a nuisance, but asking questions can often lead to completely new perspectives for both parties.
Closely related to the above. If briefing the client exposes certain discrepancies between what they imagine or visualise and what is possible (or profitable) to carry out, the IT Analyst must point that out. It’s their responsibility to provide the best feasible solution for all parties, but that needs to be explained in a reasonable manner.
“Your app does not need a QR Code scanner” – a wise (and fully hypothetical) IT Analyst could have once said, preventing a potential disaster.
A Problem-Solving and Compromise-Seeking Attitude
As said. It’s not always easy and straightforward. Sometimes the IT Analyst will find himself in a position between two or more stakeholders, all looking at him with an admit-that-I’m-right-and-they’re-not facial expression. It’s natural for business to become a clash of extremes, so the IT Analyst is tasked with finding the golden mean, while still keeping the process on track.
Although the perfect process is linear and starts at A, finishing at Z, reality is often different. Sometimes random situations occur, and the IT Analyst enters the project in one of the middle stages. He then has to get familiar with the documentation in a heartbeat, to understand all the crucial processes without being there from the beginning.
Understanding Programming Issues
A seamless and productive communication process with the client has been mentioned above, but building an understanding-based relationship with the development team is equally important. And make no mistake, the IT Analyst needs not to be a coding guru with Haskel and Lisp in their fingertips. In fact, he doesn’t need to know any programming language whatsoever. It’s a “nice to have” in ads for IT Analyst jobs, but not a must.
What they need to know is what the code does. What it’s capable of. And effectively – how it responds to the business processes. They need to meticulously explain to the devs which way the project is going and what requirements need to be matched (those couldn’t be established with the client in the first place, if the IT Analyst didn’t understand programming).
Instead of coding per se, the IT Analyst needs to know, e.g. how to work with relational databases or SQL queries. The development is left to those who are best at it.
Documentation – Icing on the Cake
Possibly the most important part of the IT Analyst job is preparing and aggregating project documentation. These, to a major extent, don’t differ from those compiled by a Business Analyst. Analytic documents intend to pave the direction for the devs, but also confirm arrangements with the client. Here presented are the most common documents used by Adrian at HeroDOT.
BPMN – Diagrams in the Business Process Modelling Notation are an everyday tool for Business Analysts. They’re also universal enough to be used to illustrate more technical processes. It’s the most popular approach, utilising visual flow charts in an efficient, intuitive and easily readable way. By creating a “Pool” (the process participants) with multiple “Swim Lanes” (sub-partitions representing departments or groups involved in the process), the Analyst has the freedom to visualise the entire business process flow.
UML – There are plenty of Unified Modeling Languages. Their core purpose is to clearly lay out the system’s functioning scope, taking into account all the interactions between elements. UML is commonly used for drawing Use Case diagrams. These perfectly show how the Actors’ path towards the goal, points of interaction with other Actors, and the whole system’s scope.
User Stories are non-descriptive user expectations, which the system must address in order to be fully functional. When preparing this type of document, the IT Analyst repeatedly asks himself three questions, over and over again.
- Who am I? (Am I a client? Am I a system admin? Am I logged in?)
- What action do I want to perform?
- Why do I want to do this?
For this blog post, one of the user stories could be the following:
As a reader, I want to click on a backlink, so that I can complete my reading experience.
It’s important to know that user stories can be written with a varying level of detail. Sometimes, the “so that” component is omitted, leaving just the user and his need. If a functionality doesn’t fit into a user story pattern, it gets split into smaller user stories.
The main property of a story is to fit within a single sprint. That’s why they’re often laconic and depraved of detail.
The document also contains Acceptance Criteria – this is a list of conditions that need to be fulfilled for the Product Owner to confirm that the functionality is ready to pass on to the client.
Use Cases essentially have the same purpose as User Stories, but convey them in a more descriptive manner. There’s an ongoing dispute on which one is the way-to-go as the better method to describe the user and their goal. However, they’re certainly not synonymous or interchangeable.
Use Cases contain 3 key elements:
- Actors – these are all the entities that in some way influence the functionality. An Actor could be (most commonly) the users themselves, but also different, non-human triggers, such as time, other systems or events.
- Pre- and Postconditions – Preconditions are a list of everything that needs to be considered in order to commence the operation. Analogically, Postconditions need to be checked in order to be sure the flow works as planned.
- Event flow – a description of the interactions between the Actors, based on an action-reaction scheme (Actor A’s movement meets an immediate response from Actor B etc.). Two approaches have to be designed:
The Main Event Flow – the so called “Happy Path”, which means that the user completes every action with success and seamlessly reaches the desired target.
The Alternative Event Flow – it’s important to consider all potential obstacles on the Happy Path. For example, in a case where the user’s goal is to purchase a ticket, those may be out of stock. It’s necessary to plan out what the system’s reaction will be.
It’s a good practice for the IT Analyst to work on previously drawn out outlines – these should be consulted with the devs, to make the process consistent.
Every Man Has His Tools
So do women, of course. And so do IT Analysts. Here’s a compact set of tools that make their lives easier.
Jira with Confluence
Surprise, surprise. Actually, no surprise at all. As Professor McGonagall said in the 6th Harry Potter film: “Why is it, when something happens, it’s always you
three two?” She obviously meant everyone’s favourite Atlassian tools. Jira is essential to Scrum management, yet it’s Confluence that’s more important to the IT Analyst. That’s where all documentation (all heaps of it) are stored, nice and tidy. In some projects, Notion is used as a substitute for this exact purpose.
Diagram Drawing Software
Difficult to pick one, as there’s a multitude of programs created for this matter. The one you’ll most likely find in an IT Analyst job description is Enterprise Architect, the industry’s strongest player. But there are plenty alternatives out there, e.g. Camunda, Lucidchart, Visual Paradigm or BPMN Studio. A one that might have gone under your radar is Miro, which is essentially perfect for any kind of task, IT analysis included.
Word, Docs, Pages…
You name it. Every software allowing its user to type is a must-have. It’s good to have some presets ready, to avoid starting from scratch each time.
Semantics aside (Business Systems Analyst, Computer Systems Analyst, or just our way), an IT Analyst is essential for any digital project. On the other hand, it’s key to remember that they aren’t a guaranteed problem solver – the work of an IT Analyst can be simplified to “improving communication”. Communication between the team and the client, the team and the management team member and team member, etc.
That said, if properly “implemented”, the Analyst can play a vital role in project management, significantly speeding up processes that may have otherwise taken ages. If not properly implemented, the process may look like this.
You most definitely don’t want that.