If Your Employees Are Voting on AI Projects, Management Isn't Doing Its Job
Asking the whole company to vote on AI projects looks like inclusion, but it hands people a decision they cannot make. Here is how to pick AI projects instead: let employees name the problems, then you rank every idea by data readiness, cost and gain.
Where Software Projects Go to Die
I own an AI studio, and through it I work on AI projects for companies around the world. In this series, I write about some of the biggest mistakes I have seen in AI and software implementation projects, so that you can avoid making the same ones.
When I started working with one of my clients, a pet food manufacturer¹ that sells through pet shops and supermarkets, a lot had already happened before I arrived. Like many companies right now, they knew they wanted to start using data and AI, but not where to begin. So they had hired a consultancy to help them figure out where AI could actually make a difference in the business.
The consultants interviewed people across the company and went through its systems and data, looking for places where AI could save time or money, or help the company sell more. When they were done, they came back with a list of thirty projects. Each project came with a short description and an explanation of why it would be good for the business. One would predict which products were going to sell, so the factory would stop making more than the stores needed. Another would give the sales team a live view of what each store was ordering. A third would take some of the repetitive paperwork off people's desks. Almost everything on the list made sense on its own. What the list did not have was an order.
Almost every company is asking the same questions about AI right now. First, which projects could we do? And once there is a list, how do we choose between them without leaving our people behind, especially the ones who know the daily work best and might see something management doesn't? My client's answer was a vote. Management sent the list of thirty projects to the employees and asked them to pick the ones they wanted. On paper, it looks like textbook good leadership, because everyone gets a say.
The votes came in and the winners were counted. Then the list landed with the people who actually had to pay for it. The CEO and the people allocating the budget looked at what the employees had chosen and recognized that these were not projects they were willing to spend money on. So before anything was built, the CEO changed the picks.
I have worked 12 years in tech, and I have never and would never put something technical to a company-wide vote. Inclusion is not a setting you switch on for everything, and managers need to be extremely careful about what they are inclusive about. Asking the whole company to vote on AI projects looks like the inclusiveness you learn about in school, but in practice it is almost a joke. People are asked to make a decision they have no way of making, and then they watch it get overruled. That is not just rude. It is demotivating. The people who took the time to think about which projects would help them most find out that their answer never counted, and they carry that into the next thing management asks of them.
To me, this attempt at inclusion is almost a textbook example of the wrong vision of inclusion. However good the intentions were, the method could never give a good result. So in this article I don't just want to show you what went wrong. I want to show you how I would have done it.
Nobody did the hardest part of the job, which was choosing
It would be easy to blame the CEO for overruling the vote, but I think that misses where this actually went wrong. The vote should never have been proposed in the first place. I don't know whether the idea came from the consultants or from the CEO, but either way, the CEO should have stopped it. A company does not start an AI program without some idea of how much it is willing to spend, and in a normal engagement each project comes with at least a rough estimate of what it costs. Once you hold those two numbers side by side, you already know that most of the thirty projects will never happen. Putting all of them to a vote meant promising people a choice that did not exist.
I also don't think the consultants finished the job. Finding opportunities is only half of what a company pays for when it hires help with AI. The other half is being told which ones to do first, and that is how this kind of work is normally delivered. Microsoft's own guide to adopting AI tells companies to score every possible use case on business impact, technical complexity, resource requirements and fit with their goals, and then to "select top-priority use cases" and turn them into a roadmap. Gartner, the research firm, has described clients that start with more than 600 possible AI use cases, and advises them to rank those by business value and technical feasibility before committing serious money. An adviser who comes back with thirty projects and then steps back to let the client decide has handed over a menu, not advice.
Choosing is the work, and here both the consultants and management skipped it. The companies doing best with AI seem to know this. In a 2024 survey of 1,000 executives, Boston Consulting Group found that the AI leaders pursue only about half as many opportunities as everyone else, and expect more than twice the return. If management will not choose between thirty projects, why is it management?
Employees voted without knowing what any project would cost or return
That is not a criticism of the employees. Someone in accounting knows exactly where her week disappears. She knows which invoices she has to type in twice, and which monthly report she rebuilds by hand every time because two systems never show the same numbers. Someone in HR knows which forms nobody fills in correctly. I always want that knowledge, and most companies use far too little of it.
But ranking AI projects takes a completely different kind of knowledge. You need to know what each project will cost to build and to keep running, how much it will bring back, and how long that will take. You need to know whether the data it depends on exists and can be trusted, which is what people mean when they talk about data maturity. And you need to know what has to happen first, because a forecasting model is useless if the sales data underneath it is a mess. None of that is visible from the accounting department, so people vote for the pain they feel every day, or for whatever sounds most exciting.
Fact box: what data maturity means
Data maturity describes how ready a company's data is to be used for anything more ambitious than a monthly report. At the low end, information is scattered across spreadsheets, systems that don't talk to each other and people's inboxes, and two departments can give two different answers to the same question. In the middle, the data sits in one place, it has been cleaned, and everyone defines it the same way, so people trust it. At the high end, data flows in close to real time and is good enough to feed forecasts, automation and AI.
It matters for prioritizing because most AI projects quietly assume the high end. A demand forecast, a sales assistant or an automated report is only as good as the data underneath it. A company at the low end that funds the exciting project first usually ends up paying for the boring one anyway, only later and at a higher price.
A vote tells you how many people feel a problem. It tells you nothing about what solving it is worth. Every department gets the same say, so the projects that win are usually the ones that affect the most people's daily work, not the ones that would make the biggest difference to the business. BCG found that 62 percent of the value companies get from AI comes from core functions like operations, sales and product development, and not from support functions like accounting and HR.
A vote ranks projects by how many people feel the pain. A budget has to rank them by what they are worth.
THE VOTE
WHAT IT IS WORTH
How to read it. On the left, six typical projects from a list like my client's, ranked the way a company-wide vote tends to rank them: by how many people feel the problem every day. On the right, the same six ranked the way a budget has to rank them: by what they are worth, what they cost, whether the data is ready and what has to happen first. Cleaning up the sales data comes last in the vote and first in the budget, because the dashboard and the forecast both depend on it. The projects are illustrative, not my client's actual list.
Picking the wrong projects costs a company more than the money it sets aside for them. Most companies have one small data and IT team, and every project on the list competes for the same few people, often for months. A project built on data nobody trusts produces dashboards nobody uses. And while the team is busy with whatever won the vote, the work that would actually make a difference has to wait. Very often that is the unglamorous job of cleaning up the data first.
The CEO overruled the vote before anything was built
If management had simply picked three projects at the start, some people would have grumbled and everyone would have moved on. Overruling a vote is something else. When you ask people for their opinion, you promise to listen. When you ask them to vote, you promise that their answer decides. Researchers who study fairness have found the same thing: people value being heard even when they don't get their way, but a voice they believe has no real influence can do more damage than no voice at all. So never put to a vote a decision you are not prepared to let your employees make.
The vote did not just fail to pick the right projects. It also spent the goodwill the company was going to need later, because AI projects live or die on whether people actually use them. Employees who watch their vote overturned learn that the real decision was made somewhere else, with information nobody showed them, and they remember that the next time they are asked to try something new.
The decision was always going to be made by management. The only question was when.
How to read it. The top line is what my client did. The bottom line is the order I would have used. Both end with management making the decision. In the top line it happens last, after a promise has been made and broken. In the bottom line it happens in the middle, where it belongs, with the employees involved before and after it.
What I would have done instead: let people name the problems, then rank every idea by data, cost and gain
In my own companies we never let everybody vote. When we prioritized new features or new projects at CanopyLAB, we did not count how many people wanted something, because the loudest request is rarely the most valuable one. We looked at whether the data was mature enough to build on. We looked at the size of the investment, in money and in time, and at how difficult the work would be. And we looked at what we stood to gain if it worked. Here is how I would have handled this list of thirty.
- Ask employees for problems, not projects. This is where inclusion belongs. Ask people where their time goes, what they do by hand that a system should do, and where the numbers they get don't match reality. The person in accounting is the best person in the company to tell you that the sales figures she receives every month are wrong. She is not the person to work out why the data is wrong, or which system should fix it. That is management's job.
- Check the data before anything else. For every idea, ask whether the data it needs exists, whether it is clean and whether anyone is responsible for it. If the answer is no, the project waits, or fixing the data becomes the project.
- Count the full cost. Look at the full size of the investment. That means the money, but also how much time the project will take and how difficult it will be to build and to keep running. An idea that looks cheap but takes a year of the IT team's time is not cheap.
- Work out the gain. Ask what the company actually gets if the project works. That might be money earned or saved, hours given back to people, or fewer mistakes. Put a number on it where you can, and be honest about how sure you are.
- Decide, and say no out loud. Rank the ideas on data, cost and gain, pick the few at the top, and tell people which ideas did not make it and why. A no with a reason keeps people's trust. A vote that gets overruled does not.
- Bring the users back to test. Before anything rolls out, the people who will use it every day should try it on a normal working day. They will find what is wrong faster than any consultant.
Ask each question to the people who can actually answer it
How to read it. Each row is one question a company has to answer before it spends money on an AI project. Orange marks the questions employees are best placed to answer. Pink marks the ones that belong with management and the people who run the data. A company-wide vote asks every employee all five at once.
Run my client's thirty projects through those steps and the list sorts itself quickly. The ideas that have no reliable data behind them drop to the bottom, or they turn into a project to clean up the data first. The expensive ideas that would only bring a small gain fall away. What is left is a short list that management can defend, because every no comes with a reason.
When the list arrived, it looked like a map of the company's future. By the time the CEO changed the picks, it had become a record of a decision the company tried to give away and then had to take back. The ballots, the counting and the overruling were all work the company did to avoid saying one sentence at the very beginning: these three, and not the other twenty-seven.
¹ Every story in this series is real. To protect my clients, I change the details that could identify them, such as the industry, the products, the company's size and location, and the names of people and suppliers. What happened, the decisions that were made and the reasons they went wrong are kept as they were.
Sources
- Boston Consulting Group, "Where's the Value in AI?", October 2024.
- E. Allan Lind, Ruth Kanfer and P. Christopher Earley, "Voice, Control, and Procedural Justice", Journal of Personality and Social Psychology 59(5), 1990.
- Stacy G. Ulbig, "Voice Is Not Enough: The Importance of Influence in Political Trust and Policy Assessments", Public Opinion Quarterly 72(3), 2008.
- Microsoft, "Plan for AI adoption", Cloud Adoption Framework.
- Heather Wright, "The AI prioritisation problem", iStart, July 2, 2026.