I Failed a Major Project. Here Are the 11 Strategies I Was Missing.
Every Vision Needs a Strategy
My Disaster Story
There was a time when I was assigned a big project with my team.
It was a brand new product that required major changes in the existing system, involving 10–15 other teams.
I had no idea how to move it forward. 🤔
I thought: “Well, I’ll just get started.” So I started talking to different teams and asking for their help.
But I had no strategy in mind. I didn’t set milestones, and I didn’t know what the MVP should look like. I was just blindly walking into meeting rooms, talking to other teams about what we needed.
At the end of the day, I had scattered information from each team and still didn’t know what to do next.
After two months, the project had almost zero progress. Eventually, my manager removed me from that position.
The Illusion of Progress When There’s No Strategy
Here’s the truth: I felt busy all the time.
My calendar was packed with meetings. I was talking to stakeholders and engineers.
But being busy doesn’t mean being productive. That’s why we all need a strategy 📚.
Before starting a project, we need to clarify the goals, the options, and the unknown. Jumping right into action without a strategy almost guarantees failure, even if you know where you’re going.
I had already started seeing symptoms, but I ignored them. For example, I couldn’t resolve conflicting requirements, and meetings often ended with no action items.
So after that big failure, I looked back a lot and gradually picked up the strategies that I should have learned in the first place. Here’s what I’ve learned:
📚 Strategies to Handle Big Projects
#1: Define MVP and Break It Into Phases
The business always wants delivery at the earliest possible date. However, a long list of requirements plus a tight deadline usually lead to disaster.
The right way to do it is to prioritize MVP (minimum viable product). Core features come first, everything else is nice-to-have. This way, you ship faster, and requirements become more manageable in smaller chunks.
Always ask: “What’s the smallest version we can ship that proves this works?” Then break down the rest into phase 2, 3, and beyond. Things might also change after initial user feedback.
#2: Start With the Riskiest Part
It’s counterintuitive, but it’s helpful.
Most engineers (including past me) start with easy wins. It feels good to check things off the list. But that only delays the risks.
Identify the biggest unknown first. Handle it as priority if it could completely derail the timeline. For example, if you’re unsure whether the system can handle the expected traffic, build a performance test first. Don’t spend months building features only to discover the foundation doesn’t scale.
Starting with risk feels slower upfront. But it prevents failures later.
❓ Strategies to Handle Unknown
#3: Start with a POC
Sometimes you don’t even know if an approach will work. That’s when you build a POC (proof of concept).
It’s a quick experiment to answer a specific question. For example: Can the payment provider support all our use cases? Can we build a POC to test all the critical payment flows like quick refunds or blocking certain users?
Use POC as verifications. Test it. Evaluate it. Then make an informed decision. That’s better than working through the entire project without verifying the critical path.
#4: Always Have Multiple Options
Even when you have a recommended solution, keep multiple options in mind.
For example, when integrating with a payment service, should you choose PayPal or Stripe? What are the pros and cons? List all the information, start with the top priority, and fall back to other options if it doesn’t work.
Don’t put all the eggs in the same basket.
#5: Look for Similar Past Work
When you’re stuck, start from digging into the history.
Look for documentation like Google Docs, Confluence, Jira tickets, etc. for similar cases or projects. This works because engineering organizations repeat similar challenges: migrations, breaking down monolith, scaling up, etc.
You can also reach out to people who have done the same in the past. Set a quick meeting, or even a regular meeting if it’s a big project. Ask for shortcuts, hidden risks, etc. Unknowns get clarified fast when you talk to the right persons.
👨💼 Strategies for Stakeholder Management
#6: Regular Meetings for Alignment
Schedule recurring check-ins from day one. Weekly or bi-weekly, depending on the project timeline. Put them on the calendar before you start any work.
The objective is to keep everyone aligned on what’s happening. If there is any misunderstanding, you can correct it early.
A regular report should include what has been done, blockers, upcoming tasks, and if any help is needed, like a scrum daily meeting.
This is useful for managing stakeholder expectations. They won’t feel like engineers are building things in the dark.
#7: Communicate Blockers Early (and Escalate)
We all have that experience of last-minute issues. People bring up a blocker two days before the delivery deadline.
Having a regular meeting tends to solve this problem. It encourages members to report their issues early, and allows stakeholders to react in time. It also allows the team to escalate when they find any challenges.
💡 A simple rule: Report anything that’s blocking you for more than 24 hours.
🏃 Strategies to Speed Up Development
#8: API Contracts Go First
This is the gold standard of software development.
Cross-team collaborations involving server communications need teams to define API request/response formats, fields, error handling, etc. before starting the development.
In that case, teams can work on their side in parallel before doing integration testing.
#9: Parallel Assignment
As pointed out by The Mythical Man-Month, we cannot speed up development just by throwing more people to it. However, most software projects can break down into two or more parallel tracks.
For example:
Backend builds the business logic while frontend mocks responses
Infra team prepares environment changes while developers implement features
QA builds test cases while development is still ongoing
In a single domain like backend, you can further break it down for multiple developers to work on it at the same time. All you need to do is manage the multi-track management overhead (as pointed out in The Mythical Man-Month, having too many tracks will slow it down instead).
💡 The rule of thumb: If two tasks don’t depend on each other, they shouldn’t wait on each other.
⚠️ Strategies for Risk Management
#10: Technical Design Doc
Many projects get delayed because risks show up too late.
A good strategy to identify risks early is to have a technical design document, which includes fundamental details like:
Service workflow diagram
Edge cases
Testing plan
Etc.
You can search for “technical design doc template” to pick items required for your projects.
#11: A Review Process to Identify Risks
The technical design doc should be reviewed by those who might identify risks, such as senior engineers, stakeholders, QA team, security team, etc.
For example, you don’t want security red flags showing up after development is complete.
Last Words
Strategy isn’t a leadership buzzword. It’s how senior engineers survive large-scale projects.
Strategies in this post aren’t complicated. They serve as a framework.
Start with one habit at a time:
Communicate earlier than you think you need to.
Structure work so developers can move in parallel.
Create a tech design doc before the work begins.
Do these consistently, and you’ll be able to deliver faster and have less surprises.
Then you’ll become the person others rely on when the stakes get high.
What I’ve Read this Week
You’re doing everything right… so why aren’t you moving up? by
Top 5 Communication Frameworks for Engineers You Must Remember by
All we need is more creativity by
Thank you for reading the post!
❤️ Click the like button if you like this article.
🔁 Share this post to help others find it.
As always, I’ll see you in the next post. Have a nice day!
Adler from Tokyo Tech Lead