I once stood in a conference room where the project sponsor kicked things off by saying, “We’re all excited about this—we just need to align on the vision, secure the budget, and figure out who’s actually available.” The coffee was still hot, but the project was already cold. I’d seen that look before: the polite nods, the vague timeline scribbled on a whiteboard, the unspoken understanding that this thing was going to limp along for months before someone quietly killed it. It’s not that anyone was malicious. It’s that nobody wanted to say out loud what was obvious: the project was doomed before it started.
I’m Simone Adeyemi, and I’ve spent years untangling tech and engineering projects that arrived at my desk already bleeding out. Not all of them died, but the ones that did shared the same early symptoms. Forget formal risk matrices and theoretical frameworks—I’m talking about the gut-punch signs you notice when you stop pretending everything is fine. Here’s what I’ve learned to spot, usually within the first week.
The Sponsorship Mirage
You need a sponsor who can actually sponsor. Not someone who just signed the charter because their boss told them to. A real sponsor has the authority to move money, reassign people, and tell another department head “no” without flinching. I’ve seen projects where the sponsor was a mid-level manager who had to ask permission to order more sticky notes. When a hard trade-off came—and it always does—they couldn’t protect the team from conflicting priorities. The project became a side hustle for everyone involved.
Watch for the sponsor who says things like, “I’ll need to run that by my leadership.” If they’re running every decision upstairs, they’re not a sponsor; they’re a messenger. Sooner or later, the message gets garbled, and you’re left building something nobody upstairs actually wants. I once had a sponsor who nodded through every sprint review, then admitted in month four that his VP had never approved the initial scope. The project had been running on fumes and assumption.
What I look for now: Does the sponsor attend steering meetings without checking their calendar twenty times? Can they articulate why this project matters beyond the bullet points in the business case? If the answer to either is “sort of,” I start updating my résumé—quietly.
The Requirements That Aren’t Requirements
There’s a special kind of hell reserved for projects where the requirements document is a wish list dressed up in technical jargon. I’ve been handed a 40-page spec that read like it was written by a committee who’d never spoken to an actual user. One line said, “The system shall be scalable,” with no definition of what scale meant. Another demanded integration with a legacy platform that had been sunsetted two years earlier. Nobody had checked.
This happens when stakeholders are asked what they want instead of what problem they’re trying to solve. They’ll describe a button color or a dashboard widget, but they can’t tell you what success looks like. The project becomes a collection of features searching for a purpose. I sat through a kickoff where the product owner proudly announced, “We’ve captured 200 requirements.” I counted. Only 14 of them were testable. The rest were variations of “make it better.”
Red flag exercise: Ask the room, “If we could only deliver one thing in the first release, what would it be?” If the answer is a long silence or a debate that derails the meeting, you’ve got a problem. Real requirements prioritize themselves because the pain of not having them is obvious.
The Timeline Written in Fairy Dust
I’ve lost count of how many project plans I’ve seen where the end date was picked to please a board meeting, not because anyone did the math. Some executive said, “We need this by Q3,” and suddenly Q3 was the deadline, regardless of whether the team needed twelve months or twelve miracles. The project manager builds a Gantt chart that fits the date, and everyone pretends the dependencies are realistic.
Early in my career, I worked on a data migration that was estimated at six months. The business demanded three. We compressed the schedule by overlapping phases that couldn’t logically overlap—testing started before development was done, and data cleansing happened after migration instead of before. The result was a corrupted database and a rollback that cost more than the original project. The deadline was met, technically, if you count deploying a broken system as “meeting” it.
Look for schedules where multiple critical-path tasks run concurrently with no buffer. Or where the PM says things like, “We’ll just have to work smarter.” That’s code for “We’ll burn people out and still miss the date.” A doomed project often has a timeline that feels aggressive in a way that makes your stomach hurt, not in a way that energizes the team.
The Team That Isn’t a Team
I once joined a project where the lead developer was assigned 60% of his time, the QA person was also supporting two other products, and the business analyst was a contractor who’d given notice but hadn’t told anyone yet. The project plan assumed full-time dedication from everyone. The reality was a patchwork of borrowed hours and divided attention.
If your critical resources are part-time, your project is part-time. It’s that simple. I’ve seen architects pulled into firefighting on legacy systems while the new project waited, and I’ve seen testers so overbooked they rubber-stamped every test case just to clear their queue. When you ask who’s actually available—not who’s on the org chart, but who’s got the hours—you often find the answer is nobody.
Another warning: the “we’ll hire for it” trap. The project kicks off with a placeholder for a senior engineer they haven’t found yet. Three months in, the req is still open, and the junior team is spinning its wheels. If the role isn’t filled by the time you’re writing user stories, assume it won’t be.
The Silence Around Risk
Healthy projects talk about what could go wrong. Doomed projects treat risk like a contagious disease. I’ve been in meetings where someone raised a legitimate concern—a vendor with a shaky track record, a dependency on an API that wasn’t documented—and the response was, “Let’s not be negative.” The issue log stayed empty, not because there were no issues, but because surfacing them felt career-limiting.
That silence festers. The vendor eventually misses a milestone, the API breaks, and suddenly the project is in crisis mode. But the seeds were there from the start. I now watch for how the team reacts when I ask, “What’s the worst thing that could happen in the first month?” If the answer is a polished nothingburger, I know the real risks are being buried.
One project I inherited had a risk register with three entries, all rated “low.” Within two weeks, I found a regulatory change that would invalidate half the architecture, a key stakeholder who’d never been consulted, and a technical debt balloon that made integration nearly impossible. Nobody had wanted to be the messenger. The project had been running on denial for months.
When the Vibe Is Off
This one sounds unscientific, but it’s the most reliable signal I have. Pay attention to the emotional weather in the room during early meetings. Are people asking sharp questions or just nodding? Does anyone crack a joke, or is the atmosphere funereal? I walked into a kickoff once where the project manager started with, “I know we’ve all got concerns, but let’s focus on the positive.” That sentence alone told me the project was in trouble—the concerns weren’t being addressed; they were being managed out of sight.
Another time, I noticed the senior developer kept his camera off and only unmuted to say “okay.” He’d been on three failed projects in two years and had learned to emotionally check out early. His disengagement was a rational response to a broken system. I pulled him aside later, and he laid out exactly why the architecture wouldn’t work. He’d tried to say it before and been ignored.
Trust your instincts. If the energy feels like a wake, it probably is. Projects that start with genuine curiosity and respectful debate have a chance. Projects that start with forced enthusiasm and suppressed doubts almost always go sideways.
What I Do Now
I’ve developed a few personal rituals for the first week of any new project. They’re not formal; they’re more like diagnostic questions I ask myself over bad coffee.
- I find the decision-maker. Not the person with the fancy title, but the one who can actually say “yes” or “no” to funding and scope changes. If I can’t identify them within three days, the project has no spine.
- I ask for the “one thing” list. I literally write on a whiteboard: “If this project could only accomplish one thing, what would it be?” If the answer doesn’t fit on a sticky note, the scope is already bloated.
- I audit the calendar. I look at the team’s actual schedules—not the plan, but the Outlook invites. If everyone’s double-booked, the project is a phantom limb.
- I poke the risk silence. I’ll ask something deliberately provocative, like, “What part of this plan is complete fiction?” The reaction tells me everything about the culture.
None of this guarantees a project will succeed. But it helps me recognize early when the odds are stacked so high that the only winning move is not to play—or at least to play with eyes wide open. I’ve walked away from projects after a week because the signs were too loud to ignore. It’s not quitting; it’s pattern recognition.
Frequently Asked Questions
What’s the single biggest sign a project is doomed from the start?
For me, it’s the absence of a real decision-maker. If nobody in the room can reallocate budget or tell another executive “not now,” the project will drift until it hits a hard obstacle and then stall out completely. Everything else—scope creep, resource gaps, unrealistic timelines—flows from that vacuum.
Can a doomed project ever be saved?
Rarely, but yes—if someone with authority is willing to reset expectations publicly. I’ve seen a project pulled back from the brink when a new sponsor came in, halved the scope, and told the business, “We’re delivering this small thing first, then we’ll talk.” Without that kind of brutal honesty, you’re just rearranging deck chairs.
How do I tell my boss the project is doomed without sounding negative?
Frame it in terms of trade-offs, not doom. Say, “Based on what we know now, we can hit the date if we cut the scope by 60%, or we can keep the scope if we add four months. Which would you prefer?” That turns a vague feeling of dread into a business decision. If they refuse to choose, you’ve confirmed the problem without having to say it outright.
Is it ever reasonable to leave a project because it seems doomed?
Absolutely. I’ve done it. If the project is set up to fail and nobody with power is willing to fix the fundamentals, staying can damage your reputation and your mental health. Be professional, document your concerns briefly, and move on. There’s a difference between perseverance and setting yourself on fire to keep a doomed project warm.