Data & Decisions · 11 min read
Data-Driven Project Management: Measure What Moves the Result
Data does not manage projects, people do. How to pick the few numbers that change decisions, collect them without drama and act on them every week.
Dennis AlejoBusiness consultant · Project & operations manager · · 2,493 words
Two projects start on the same Monday with the same budget, the same deadline and equally talented teams. Six months later, one of them is quietly delivering. The other is in an emergency meeting trying to understand how it ended up three weeks late and twenty percent over budget. The difference is rarely talent or effort. Very often it is information: one team knew early, in plain numbers, that something was drifting, and the other found out when the drift became a crisis.
That is the promise of data-driven project management, and it is also the reason the phrase has been so badly abused. For many teams it now means a wall of charts nobody reads, a monthly report that arrives after the decisions were already made, or a spreadsheet that only one person understands. That is data decoration, not data-driven work.
In this article I want to give you a practical version, one that fits a startup, a restaurant opening, a road maintenance program or a software launch. I will use examples from very different kinds of projects on purpose, because the central idea of this whole series is that the kind of project you are running changes which information matters and what you do with it. Along the way there is a short interactive check you can run on your own project, and at the end a thirty-day plan to start.
What "data-driven" really means
A data-driven project is one where important decisions are made with evidence rather than with volume, hierarchy or mood. That is the whole definition. Notice what is missing: it does not say that you need software, a data team or a hundred metrics. It says that when the schedule slips, when a vendor asks for more money, or when someone proposes adding a feature, the conversation starts from facts that everyone can see.
Anyone who has worked on large construction programs has seen teams argue for hours about whether a milestone was "basically done." Building a database platform to track sixteen projects across three owners taught me the same lesson from the other side: nothing about people's skill or goodwill needs to change. What changes is that "basically done" has to become a date, a percentage or a yes or no. The debates do not disappear, but they get shorter and much more useful because they are about the same numbers.
There is a second half to the definition that people forget: data-driven also means being honest about what you cannot measure. A project manager who says "I do not have a reliable number for this yet, and here is how I will get one" is more data-driven than one who invents precision.
Start with the decision, not the dashboard
The most common mistake is to start from the data that happens to be available. A tool exports twenty charts, so the team puts twenty charts on a screen. Instead, work backward from the decisions.
Ask: what are the five or six decisions that will most affect the result of this project? For a restaurant opening they might be when to order equipment, when to hire the kitchen team, whether to delay the opening date and how much inventory to buy. For an exploration project in the mining sector, such as Llama Purisima, they might be where to place the next drill hole, whether the first results justify the next phase and when to release funds. For a software launch they might be what to cut from the first version and when to stop testing.
For each decision, ask what you would want to know to make it well. Then ask what number, if any, would answer that. The chain is decision, question, number. If you cannot name the decision a number supports, that number is a candidate for deletion.
Leading and lagging indicators
Most project reports are made of lagging indicators: things that tell you what already happened. Final cost, delivery date and customer satisfaction are lagging. They matter, but by the time they move, it is too late to change the outcome. Leading indicators move earlier and predict the lagging ones.
On a construction site, the final cost is lagging. A leading indicator is the number of tasks starting on their planned date this week, because late starts today become late finishes next month. In a sales project, revenue is lagging while the number of follow-ups sent within twenty-four hours is leading. In a clinic opening, the date of the opening is lagging, whereas the number of equipment items confirmed for delivery and the number of staff trained are leading. I explain how this plays out in how a clinic opens on time.
A good rule is to have at least one leading indicator per project that the team can influence directly. If everything you track is lagging, you are driving by looking in the rear-view mirror.
Pick three numbers per project
If you remember only one practical rule from this article, make it this one: each project gets about three numbers that the whole team can recite from memory. One measures the outcome (what the project is for), one measures progress (how far along it is) and one measures health (what is at risk of going wrong).
Here is how that looks across very different projects:
- A restaurant opening: outcome is covers served in the first month, progress is the percentage of opening checklist items done, health is the number of open critical issues such as permits or equipment.
- A road maintenance program: outcome is kilometers completed to specification, progress is milestones met on their planned date, health is the cost variance against budget.
- An exploration drilling program: outcome is meters drilled and logged with approved results, progress is holes completed against plan, health is core recovery and lab turnaround time.
- A startup sprint: outcome is paying customers, progress is qualified conversations started per week, health is the share of the week spent on the three chosen projects. This is the pattern in the 90-day sprint.
- A process improvement: outcome is hours saved per week, progress is steps automated, health is the number of exceptions people had to handle by hand.
Notice how the same three-number pattern produces completely different numbers depending on the project. That is the point. A generic dashboard cannot know what matters on your project. You have to decide.
Why three? Because humans can hold about that many in their heads during a conversation, and because forcing a choice reveals what you actually believe the project is about. When a team cannot agree on its three numbers, it has usually discovered that it does not agree on the goal.
Collect data without drama
Once you know your numbers, the next fight is getting them reliably. Most data projects fail here, not in the analysis. Four habits make the difference.
First, give every number one owner. Not a team, a person. That person is responsible for the number being updated and for explaining it, not for making it look good.
Second, write a one-line definition. "Tasks completed" means nothing until you say whether partially done tasks count. "On time" means nothing until you decide whether it is measured against the original baseline or the latest revised date. The definition takes thirty seconds to write and prevents months of arguments.
Third, keep one source of truth. When the same figure lives in a spreadsheet, an email and someone's notebook, people choose the version that flatters them. Choose one place, publish it, and retire the others. This is the same lesson from the deadline article: a single schedule that everyone can see is worth more than five perfect ones that nobody agrees on.
Fourth, make collecting the data a by-product of the work, not an extra chore. If people must fill in a form at the end of the week to feed a report, the data will be late and rosy. If checking off a task in the tool that runs the work automatically updates the numbers, you get honest data for free. This is also where automation shines, as described in seven workflows to run on autopilot.
The weekly review: where data becomes decisions
Data that nobody discusses is just storage. The place where it becomes a decision is a short, fixed, weekly review. Thirty minutes is enough for most projects, and a rhythm beats a perfect agenda.
A simple structure works well. Spend the first ten minutes on the three numbers: where they are, where they should be and what changed. Spend the next ten on exceptions, meaning anything that is off-track and needs attention. Spend the last ten on decisions: what we will do, who owns it and when we will check. Write the decisions down in a log and read it at the start of the next meeting. If a number did not trigger a single decision in a month, ask whether it belongs on the list.
The tone matters as much as the structure. When a number goes red, the first question should be "what will you do about it?" and not "who is responsible?" Teams that punish bad numbers learn to hide them, and a hidden number is worse than a bad one.
Try the short check below on one of your own projects. It takes a minute and it will probably show you the one habit worth fixing first.
Three traps to avoid
Even with good habits, a few traps catch almost everyone.
Targets that bend behavior. There is an old observation, often called Goodhart's law, that when a measure becomes a target it stops being a good measure. If you reward a team for closing tickets, you get many small tickets. If you track hours on site, you get long days instead of finished work. Whenever you attach a reward or a penalty to a number, ask how a smart, tired person could hit it without achieving the goal, and add a second number that would reveal that.
False precision. A forecast of "finishing on March 14" sounds scientific and is usually a guess dressed up as a fact. It is more honest, and more useful, to say "between the second and fourth week of March, and here is what would move it." Early in a project, ranges are the truth. Reporting a single date too early teaches the team and the sponsor to distrust all your numbers later.
Data theater. This is the beautiful dashboard that exists to reassure people rather than to help decide. You can recognize it because nobody changes plans after looking at it. If the review ends with "looks good" every week for a quarter, either the project is remarkably healthy or the numbers are too gentle.
How different projects change which data matters
It helps to see how the project type bends the whole approach.
On a construction project, schedule and cost data are tightly linked, so progress is usually measured against a baseline and combined with cost into a single view. I cover that technique in earned value in plain English. The data is physical and visible, which makes cheating hard.
On a software or digital project, the work is invisible, so you rely on throughput, such as items finished per week, and on quality signals such as defects found after release. Estimates are shakier, so trends matter more than single readings.
On a hospitality project, such as the opening of a lodge like Comtury Lodge, the numbers that matter move from construction readiness to operational readiness: staff trained, supplies stocked, bookings confirmed and guest feedback after the first weeks.
On a research or exploration project, results come in uneven jumps. A single hole can change the picture. Here the discipline is in recording what was done and what was found, honestly and in the same format each time, so decisions about the next phase rest on the whole record and not only on the most exciting result. That is the reason the Trade Arena project publishes a scoreboard that starts at zero and moves only when a strategy earns it.
On an improvement or change project, the most important number is often one that arrives late: whether people actually use the new way of working. That is why I pair data with the people side, as discussed in change management and the people side of projects.
The lesson across all five is that the method stays the same while the numbers change. Decide, define, own, review.
Where automation and AI help
Automation is excellent at the boring middle of data work: pulling numbers from the tools where work already happens, compiling them into one page, flagging anything that moved more than expected and sending the summary before the meeting. An AI assistant can also draft the first version of the weekly summary and highlight the three biggest changes, which saves a surprising amount of time.
What it should not do is decide. The decision belongs to the person who owns the outcome. A useful pattern is to let automation assemble and a human interpret. If you want a deeper look at where to start, AI agents for sales shows how to introduce an assistant without losing control, and the same logic applies to reporting.
A thirty-day starter plan
You do not need a data platform to begin. In the first week, choose one project and write down its five most important decisions. For each, find the number that would help. Cut the list to three.
In the second week, define each number in one line, name an owner and choose a single place where they will live. A shared document is fine. Resist the urge to build something fancy.
In the third week, hold your first thirty-minute review with the structure above and keep a decision log. Expect the first one to be awkward and the numbers to be rough. That is normal.
In the fourth week, review the review. Which numbers triggered decisions? Which did not? Remove one, adjust one and add a leading indicator if you do not have one. Then repeat. By the end of the month you will have something most teams never get: a small, trusted set of numbers that change what people do on Monday morning.
Data-driven project management is not about being clever with charts. It is about making sure that when something starts to drift, the team knows early and acts calmly. If you want help setting this up for a team or a company, the Project Focus method builds exactly this rhythm into the way you run projects, and the automation and AI service takes care of the collection and reporting.
Which single number would change the most decisions on your current project? Tell me in the comments.
Frequently asked questions
What is data-driven project management?
It is managing a project by making key decisions with evidence rather than opinion. In practice that means choosing a small set of meaningful numbers, defining them clearly, giving each an owner and reviewing them on a fixed weekly rhythm so that problems are spotted early.
How many metrics should a project track?
About three per project for the team to remember and discuss: one for the outcome, one for progress and one for health. You can keep more in the background for reference, but if a number never changes a decision it is probably not worth showing.
What is the difference between leading and lagging indicators?
Lagging indicators, such as final cost or delivery date, tell you what already happened. Leading indicators, such as tasks starting on time or follow-ups sent within a day, move earlier and predict the lagging results, so they give you time to act.
Do I need special software to be data-driven?
No. A shared document or spreadsheet with clear definitions, one owner per number and a weekly review is enough to start. Tools help later with collection and reporting, but the discipline comes first.
Join the conversation
Did this help? A quick reaction tells me what to write next.
Be the first to react.
Loading comments…