For ad hoc requests, I keep a log of all of them, then categorise them. This allows me to design and build a report for each category. The reports can be easily updated as data becomes available. This way, you have the answer sometimes before the questions come, and you can even train the requesters how to directly use the report to help themselves.

With regard to regular reports (weekly or monthly), I usually automate the process using a tool such as Visual Basic, which saves a lot of time.

In my previous role I was in the Strategy and Policy Team, which is part of a large directorate. I was the only data analyst in the team, so I worked with six other teams within three different departments in directorate: Finance, Project Management Office and Communications. My work sometimes extended to external organisations and third-party suppliers. You can only imagine the number of people this involved and the need to be a people person. Some people think being an analyst is just sitting at your desk and crunching all the data given to you. The truth about this role is that all the information you will need for your work is never in one place. Some of the data you need may belong to different departments or even different organisations, and you will not have direct access to such databases. You will, sometimes, have to rely on other analysts to extract the data sets you need to do your job.

What I also try to do often is to find time to go and observe other departments work. I realised that sitting with people in other departments to observe them helps me to understand an organisation better and how it works. How causes and effects are generated and how the business rules are arrived at. The more I get out there to talk to people in other departments, the better I am at deriving insights during analysis.

Many analysts I have met worry that they are not the sort of person that makes friends easily. Well, I wasn’t when I started, but I learnt quickly – we all learn and grow into it as time passes by. There are lots of training courses that help too.

Individuals may cause some of the issues with data gathering while trying to guard their departmental information. These can be people that are slow to adapt to the change that data is bringing. They find it hard to run with the fact that data is driving everything in this day and age. There are some others that just like to say no, hence consciously or unconsciously blocking or delaying my work.

The potential savings, in terms of time and cost, from data analysis work are very important, which means that things I work on really need to be quick and agile. Thus, if I try to win people over to play along without success, my personal approach is to go to someone higher.

This depends largely on the size and structure of the organisation. When I work in a big team and have a line management structure, it is not within my remit to make these decisions. But whenever I have the autonomy to move around and decide which project to work on, I usually use this approach and move up the hierarchy to get things done if necessary.

Whatever may be the case, I always inform the customers of the current status of their requests to enable them to manage their own expectation and goal setting. It is important to note that data analysis projects are not regular types of project where everything is specified and defined. Even in regular project settings, I have found that things do change from the initial plan – issues arise, so I tend to keep comprehensive issue logs and risk registers. I take into account all the data preparation and data cleaning I have to do, bearing in mind that I can only prepare and clean data after gathering it and, more often than not, the data comes from another department or third-party organisation, which I have no control over.

I also consider the time I use to interview people, who I need to interview, and whether it needs to be more than once. There is a lot of research that goes into this type of work, especially if it’s a completely new development and design project. Up to 75 per cent of my work goes into data prepping and cleaning, and, again, that is only when I have all the data – I cannot overemphasise this because it can get tricky. Then I can start driving insight, building models and so on. Safe to say that a lot of major data analysis projects I have worked on are not usually quick fixes.

I always make it clear to the requester what timeframe I anticipate being able to deliver within. This I do by giving myself ample time to plan before agreeing to any deadline, especially for new projects. It is better to under promise and over deliver. I also inform them ahead of time if I think an agreed deadline can no longer be met, and discuss the new deadline as early as possible so that they can adjust their own calendar or commitment.

I make sure that expectations are clear, and I avoid taking on more projects until I deliver the main project at hand.

We live in a time and age when everything we do accumulates data. Data is really taking over, from our wearable gadgets, to social media footprints and sensors that use data to feed into businesses to help decision-making. Data has changed the way things are done, not just in running businesses but also in politics and our personal life.

Everybody is now expected to know how to use a smartphone. This was not the case 10 years ago. It is safe to say that 10 years from now, everyone in a workplace will be expected to have some level of data literacy. As a data analyst, whenever I have the opportunity to talk to different people at different levels of my organisation, I always have at the back of my mind the intent of creating a data culture. I utilise every opportunity I have to work with people to express some form of data advocacy.

How do I do that? I feel it is my duty to show people how decisions based on data can make their work easier and even more interesting and satisfying. I try to help them to understand that apart from making their jobs easier, the world is moving towards data analysis and everything will be driven by it. Even if it is not compulsory to work with data now it will be in the near future, so the earlier they start becoming data friendly the better for them.

The people I win over at an early stage of my data advocacy have helped me in creating the data culture. They open up conversations on my behalf and it becomes easier to approach other people in the organisation.

Some people may think that creating such a culture is for the managers; I can assure you that anybody can embark on the task.

Having said that, common practice is that people will just come to me and ask me for an insight from a data set without any explanation or even the slightest idea of what they are looking for. In such cases, second meetings like this will take much more time and possibly end with a complete scope change. To bring that type of situation under control, I always make it clear from the start that I cannot just start working on a data set without proper discussion.

Thus, while developing the data culture at work, I try to set expectations. I make it clear how my colleagues should put across their requests for capacity management and priority setting. There must be an initial meeting to elicit what is needed or the problem the requestor is facing. I make it a point of duty to remind them that every task or project should come to me as a business-specific problem. I work with them to pinpoint what the issues are and what they want to solve. Instead of dumping data on me and asking for insight, they should be able to come up with questions such as:

With those types of questions, I have an idea of what they are trying to look for. Those will actually help me to identify the right data set. Take, for instance, the question of receiving complaints over weekends; I may start with segmenting the callers by age, educational background or ethnicity. That way I will have a direction of travel for the analysis. The whole process of engaging in different analysis and deriving insights makes up the project journey. Sometimes I come up with insights that are irrelevant to the task at hand, but could be useful in solving other problems.

As I developed in the profession, emails like this became common; everyone comes to me for any issue they have. People in the organisation talk more about me and how I add value to the organisation – how I am the go-to person for solving difficult bottlenecks. I always end up with too many requests that I have no chance of handling on my own. That is when the word ‘no’ becomes very handy. Saying no in the workplace can be difficult because everyone is working for the same goal using different approaches.

Bearing in mind that all projects are important (at least, someone in the organisation thinks they are), I have learnt the best way to say ‘no’ in order not to compromise the good working relationships I’ve developed over time. Now, some projects may be interesting and others not so interesting, but as a data analyst, what guides my decision on which project is the priority is the business value it generates. I assess every project based on what the outcome will mean to the business – how much value the end product will add. I consider this for all the available options before selection. I never choose a project on the mere fact that it is most interesting to me personally or that the requester is my friend.

These decisions are not solely up to me much of the time. I may need to discuss them with my line manager, but I am always ready to put my views across. Consequently, I make sure I have developed criteria to back up my argument before going into such meetings.

I recently persuaded senior management in my organisation to approve the use of a proforma system for job requests. This is just a simple system where the requester will have to complete a proforma for every request. Everyone in the organisation is well aware that the request can come back as approved with a delivery date, be postponed or be redirected to another team. This has made it a lot easier to manage workload and has become so popular that they have rolled it out to the wider organisation. Sometimes I really don’t have to say the ‘no’ face to face.

However, this system does not stop me from scheduling 10–20 minutes to explain to the declined project requesters what other project I am working on and why I picked that over theirs. This is why it is important to have those job selection criteria at hand. Imagine if your decision is based on your personal interest, you will be making a lot of enemies in the organisation or even risk putting your job in jeopardy. Everyone usually understands a business value-driven decision.

The best way to say no is by starting with an explanation of how I come up with the decision of not taking up their project. So, never say ‘yes’ outright when a request is proposed. Always give yourself a little time to assess and evaluate each project.

I have done a project on patient access rate in NHS service providers. I was working for a central organisation that monitors such service providers. The problem was that the project requester believed that patient referral rate had a direct effect on the access rate. The task was to identify those service providers with lower referral rates. This allowed the support team from my organisation to develop a plan that helped them to increase referral rates. My initial analysis showed that a decrease in attrition rate would increase access rate. Further analysis and optimisation showed that reducing waiting time would decrease attrition, which would in turn increase access rate, even at the current referral rate. My recommendation made it easier to achieve the target access rate much more easily and cheaply for the organisations. After the project, I went back to the requester and the teams and offered to do a presentation of my work and how I arrived at my result and recommendation. They were very happy and grateful that I had made the gesture. They gained a better understanding of how the data was used to change the course of action more cheaply and quickly to reach the desired goal.

Presenting to the executives is always daunting, especially for me when I was just starting out. Whenever I step into a boardroom, I know right away that I will have to say something of value. I always prepare and accept the fact that it could be a scary experience, but I always have at the back of my mind that they are just humans. They are people like me, very busy, but still people.

I present to them like I would to every other audience. The only difference is the content of my presentation. Executives are impatient and always interested in the numbers – monetary values.

They are interested in:

Whatever I find during my analysis, I always try to quantify it in monetary values when presenting to executives.

But the truth is not always pretty. As a data analyst, I am looking at the facts and figures. Sometimes, I discover very uncomfortable truths that could be challenging to someone in the organisation. Sometimes, my findings will not resonate with the people I will be presenting them to. For instance, my analysis may uncover an inefficiency or performance issue in a popular department. I am always prepared for such awkward situations – it happens all the time as a data analyst, and I am used to it.

One way of getting myself prepared for such eventualities is by preparing my audience as well. I discuss it with them beforehand once my insight starts to show something ugly and unpalatable. This helps to prepare them; I try to let them know that I am mining for the facts and that some facts may not be what they will want to hear. That way, I am not taking them completely unawares when the final report arrives.

Most importantly, I find time to look at my write-up over and over again, adding or removing material as required, then rehearsing with my peers or colleagues if time permits; although I tend not to worry too much about remembering all I need to say or the order I have to say it. What I always have on my mind is how I am going to impress my audience. How I am going to share the knowledge and get them excited. Whenever I am in front of an audience, they can feel the passion for what I want to talk about.