How to start a data analyst career with a small project

If you want to move into tech through data analysis, I would suggest a fairly ordinary starting point. Choose a small problem, collect some data and answer one question. Then show the result to someone who did not watch you build it. That exercise will quickly reveal what you actually need to learn next.

I started in customer service and learned Excel. That is part of my own route, rather than a compulsory sequence for everyone else. You might work in logistics, be studying or be returning to employment. Your starting point changes the time and material available. You can still practise moving from a table to a clear explanation.

The plan below is my proposed way to organise that practice. It sets no deadline for getting hired and makes no promise about your chances. The situations and numbers in the exercise are synthetic. My goal is to help you build evidence of a skill you can discuss. Saying that you want a job in tech gives an employer very little evidence by itself.

Decide which work you want to do

An analyst title can cover a wide range of responsibilities. One employer may need recurring operational summaries, another may need database queries, and another may need requirements for a new system. I would begin with several vacancies that actually interest you. Separate their duties, tools, essential requirements and optional skills. Every tool mentioned does not need to become a separate course immediately.

Microsoft’s description of a data analyst includes preparing data, modelling, reporting and working with stakeholders. That provides a useful reference for Power BI oriented roles. I would still read the actual vacancy carefully. A training path from one vendor cannot describe every analytical job or settle what a particular employer expects from a beginner.

Turn the vacancies into a working target. For example: I want to prepare operational reports from sales data using a spreadsheet and SQL. That gives you a reason to choose some exercises and postpone others. If the titles are confusing, read my comparison of business analysts, data analysts and BI developers, then look at which responsibilities you would like to perform more often.

Choose data you understand

For a first project, I would consider a small record of practice sessions, journey times or fictional orders. Familiarity has a practical advantage: you can spot an absurd value when you understand what a row represents. A huge dataset found online may look more impressive, but its size will not help if half the columns are a mystery to you.

A personal tracker also has a limitation. You must wait for observations to accumulate, and your recording method may change while you learn. Synthetic data is a reasonable alternative for a first version. Label it clearly. Invented sales should never be presented as records from a real employer, and their results cannot establish facts about an entire industry.

For public data, keep the source address, download date, field descriptions and reuse conditions. Check whether you can redistribute the material. For workplace information, agree the permitted use with the responsible person. Removing a name column does not automatically make everything else suitable for publication. A clearly shareable dataset makes a public learning project easier to manage from the beginning.

Build a table before a dashboard

Suppose the project concerns fictional support tickets. Each row represents one ticket. You need an identifier, a received date, a category and a status. If you want to measure resolution time, you also need a closing date. A useful question appears immediately: how will you represent tickets that are still open and therefore have no resolution time yet?

I would keep the input records separate from the summary. In the spreadsheet, each header should identify one field, with consistent meanings for dates and numbers. Microsoft’s guide to creating Excel tables explains selecting the range and identifying headers. For this exercise, I would get that basic structure right before spending time on the appearance of the final report.

Add a short definition for each column. A closed status might mean that the issue was solved, or that the requester withdrew it. You can store both events, but combining them without explanation makes interpretation harder. I want to know where a value came from and what it covers. A coloured cell cannot provide that explanation on your behalf.

Ask a question for a specific reader

“I will analyse support tickets” leaves a lot undecided. I would make the first question narrower: which category has the largest number of open tickets at the end of the week? The reader could be a fictional person assigning work. You now have a reason to show a particular number and a possible decision that follows from it.

Write down the boundaries. Does the week refer to when tickets arrived or when the snapshot was taken? Are all categories included? Does open include waiting for the customer? Without those decisions, two correctly built tables can produce different answers. This is a useful early lesson in why analytical work also depends on precise language and agreed definitions.

I would limit the first version to one main question and one supporting question. Perhaps also identify how many open tickets have been waiting longer than a week. Put additional ideas on a later list. Otherwise, two evenings can easily produce ten tabs, several unfinished dashboards and an increasingly elaborate explanation for why nothing is ready to show.

Work through a tiny result by hand

Our exercise has six tickets. In the access category, two are open and one is closed. In the equipment category, one is open and two are closed. For this snapshot, access has two open tickets and equipment has one. Three tickets remain open overall. You can understand that answer without a sophisticated tool or a large volume of records.

Before building a larger summary, reproduce this result on paper. Then check whether the tool agrees. If the summary shows four open tickets, look for a repeated identifier, a different filter or an ambiguous status. Finding the cause of a disagreement is part of learning. Changing the chart type cannot repair the underlying calculation, however attractive the new chart may be.

Keep the conclusion within the evidence. Two open access tickets compared with one equipment ticket does not show that the access team performs worse. The categories could differ in incoming volume and complexity. At this stage, you are describing the queue. That can be useful information, provided you do not attach an explanation that the available records cannot support.

Learn a tool while solving a task

In a spreadsheet, start by organising records, filtering them and producing a summary. You can then add a lookup from a second table. I would learn functions as they become useful to the project. Remembering a hundred formulas from a video says little about whether you can investigate a ticket identifier that appears twice or match a category correctly.

When you need information from several database tables, SQL becomes a natural next step. When importing and cleaning need to repeat, look at transformation tools. Python can follow if it supports your chosen responsibilities. I would avoid prescribing one compulsory order for every person and vacancy. Let the work you want to do give the learning plan some shape.

After each lesson, change something independently. Add a category, a different status or a record without a date. Before checking the result, write down what you expect and why. If you can work only with the exact file used by the instructor, give yourself another independent attempt. It is better to discover that dependence during practice than during a technical interview.

Use your current work where possible

If you already work in customer service, sales or administration, you may know useful analytical questions. Which requests keep coming back? Where does a process lose information? I would propose a small summary to the person responsible for that process. First, establish that you have the access, time and permission to do it within your current responsibilities.

Some employers cannot give you room for an additional report. Some roles also restrict how you can access or use data. A public project remains a useful exercise when that happens. I would treat the lack of an internal opportunity as a constraint on the plan. You do not have to invent commercial experience or abandon practice because one route is unavailable.

When describing experience, separate work you performed from a new learning exercise. “Prepared a weekly summary of open requests for the team” is concrete if you actually did that. “Optimised the whole customer service operation” requires much stronger evidence. Avoid adding time savings you never measured or claiming influence over an outcome you cannot explain or attribute to your own work.

Prepare a version other people can inspect

A useful portfolio lets the reader understand the question, the data, your method and the result. I would include short instructions and explain the two most significant decisions. For example, why tickets are counted by identifier, and why unresolved tickets have no resolution duration. Those explanations reveal more about your thinking than ten nearly identical screenshots of a dashboard.

If you choose Tableau Public, read Tableau’s publishing guidance. Published workbooks and data are publicly accessible. Hiding a visualisation from your profile does not turn it into a secure place for employer information. Use material that you are allowed to show to anyone who receives the link. Decide that before uploading anything.

Keep the presentation readable. A single screen with the question, a clear summary and a limitation may serve the reader better than an elaborate wall of indicators. Open the project on a small screen. Ask someone to describe its result without an introduction from you. If they cannot understand what it shows, you have found a specific improvement for the next version.

Explain your decisions in an interview

I would prepare a short account of the project: the problem, why I chose those records, what I checked, what I found and what remains unknown. You do not need to memorise a speech. You need an order of thought that still works when someone interrupts to ask about a column, a filter or an unexpected record.

For our example, you could say: “I compared open tickets by category at an agreed snapshot date. I checked identifiers and status definitions. Access had two open cases and equipment had one. I did not assess team productivity because I had no information about working hours or case complexity.” The project is small, but its boundaries and the meaning of its result are clear.

For a course project, identify the source and your own contribution. You can honestly explain that you added a duplicate check or changed the question independently. There is no need to present it as a client engagement. The interviewer should be able to separate the instructions you followed from the choices you made. That distinction makes later questions much easier to answer.

Apply by responsibilities and use feedback carefully

I would avoid waiting for a feeling of complete readiness, because that feeling is difficult to measure. Compare your evidence with the actual duties instead. If you can perform the central work and lack an optional tool, applying may make sense. If developing models is the central duty and your experience is limited to spreadsheet filters, the preparation gap is larger.

Keep a simple application record: the role’s scope, the CV version, the stage reached and any feedback. One rejection supports very little diagnosis. If a difficulty repeats, examine something concrete. Is the project description understandable? Do your technical answers explain your reasoning? Are the roles aligned with your preparation? Silence from an employer does not reveal its cause, so avoid treating speculation as feedback.

I would also avoid automatically offering a dramatically lower salary as an entry strategy. Evaluate employment terms against the responsibilities and your own situation. Wanting to learn does not oblige you to accept arbitrary conditions. High enthusiasm does not guarantee an offer either. You can improve your preparation and search process while acknowledging that the employer’s decision is outside your control.

See whether the project survives another input

A first version can work because its author remembers all six rows. Add a second small file from the same fictional process. Keep the field definitions, but change the record order and the category counts. Can you prepare the summary again without manually repairing each cell? That gives you a concrete way to discuss repeatability when you explain the project later.

Then introduce one exception: an unfamiliar status or a missing identifier. Decide what should happen. I would keep it separate from confirmed closed cases, showing unresolved records and the condition for resolving them. A report with a visible problem gives its reader an opportunity to respond. Silently discarding inconvenient rows removes that opportunity while making the table look pleasantly tidy.

Finally, ask another person to reproduce the result from your instructions. Resist immediately telling them where to click. Notice the missing step or undefined term instead. If the solution works only while you are sitting beside its reader, handover needs another attempt. Discovering that in a small portfolio project is useful preparation for later work with other people.

Separate a skill gap from a lack of learning capacity

When a plan stalls, identify the constraint. Do you misunderstand a join, lack access to the tool or try to fit five hours of practice into one available hour? Those problems need different responses. Another course may help the first one, but it cannot create an extra evening or grant access to a restricted workplace computer.

For a technical difficulty, reduce the example to two tiny tables and write down the expected result. For a tool constraint, find a permitted alternative or change the exercise. For a time constraint, reduce the deliverable. I would rather deliberately postpone an additional chart than maintain an imaginary schedule in which every practice session begins with an accumulating sense of falling behind.

Record questions you need help answering. “Excel does not work” is difficult to resolve in a short conversation. “These three tickets should contain two open cases, but I get three; here is the status definition” gives someone a starting point. Preparing that question is part of analytical practice too, even when it is not listed as a separate requirement in a vacancy.

Plan the next finished step

For the next stage, choose a small deliverable: a description of the data, one summary and a short explanation. Allocate time you can maintain alongside your other responsibilities. If an evening disappears, return to the next scheduled task. An elaborate penalty for a missed practice session usually creates more unfinished work inside the plan you designed to help yourself.

After the first version, request a specific comment. “What is unclear about my definition of an open ticket?” is more useful than “Is my dashboard good?”. Record the improvement and show a second version. Using that feedback is a skill worth practising, because workplace requests rarely arrive with every definition and edge case settled neatly in advance.

Only then increase the difficulty. Add a second table, a longer period or a repeatable refresh. A finished small project with explained limitations gives you a reference point. If you need help organising spreadsheet practice, see my Excel learning plan. For today, choosing a question and preparing the first few clearly described rows is a perfectly concrete start.