Projects fail or underperform
Go over budget
Miss their deadline
These aren't random statistics. This is what I see in Kenya's tech industry every year.
Businesses lose millions of shillings on software projects that never launch, don't work properly, or get abandoned halfway through.
The painful truth? Most of these failures are completely avoidable.
Let me walk you through the 7 biggest reasons projects fail—and exactly what you can do differently.
Reason 1: Unclear Requirements
The Problem
"Just build me something like Jumia" or "I want an app like Uber." These vague briefs set projects up for failure from day one.
Real Story
A retailer in Westlands came to us wanting "an e-commerce platform." After we started building, they kept adding requirements: "Oh, I also need inventory management." "Can you add a loyalty program?" "What about WhatsApp integration?"
The project that was quoted at KSh 400,000 ended up costing KSh 900,000 and took 4 months instead of 6 weeks.
The Solution
- Write everything down. Every feature. Every screen. Every user action.
- Create user stories: "As a customer, I want to search products so I can find what I need quickly."
- Prioritize ruthlessly. What's essential for launch? What can wait?
- Get sign-off before development starts.
Reason 2: Choosing the Cheapest Developer
The Problem
A company quotes KSh 800,000. Another quotes KSh 150,000 for the "same" work. The business owner chooses the cheap option. Six months later, they have an unusable product and need to start over.
I understand. Budgets are tight. But here's what really happens with extremely cheap developers:
- Poor code quality that breaks constantly
- No documentation so no one else can maintain it
- Security vulnerabilities that put your data at risk
- They disappear when problems arise
- Hidden costs appear mid-project
The Solution
- Check portfolios. Have they built similar projects?
- Ask for references. Call their previous clients.
- Understand their process. How do they handle changes? Testing?
- Meet the actual developers. Not just the salesperson.
- If a quote seems too good to be true, it probably is.
Reason 3: No User Involvement
The Problem
The MD decides what the app should do. Developers build it. Three months later, the actual users—the sales team—can't use it. It doesn't match how they actually work.
I've seen beautiful systems that nobody uses because:
- The workflow doesn't match real processes
- Essential daily tasks are buried in complex menus
- It takes 10 clicks to do something that takes 2 on paper
The Solution
- Involve actual end users from day one.
- Observe how they currently work. Don't just ask—watch.
- Show prototypes early. Get feedback before coding starts.
- Test with real users during development. Not just at the end.
Reason 4: Unrealistic Timelines
The Problem
"We need this launched before the trade show next month." The developer agrees because they want the business. Then delivers half-baked software that crashes in front of clients.
Good software takes time. Period.
When you rush developers, you get:
- Corners cut on testing
- Security vulnerabilities
- Bugs that appear at the worst moments
- Technical debt that makes future changes expensive
The Solution
- Trust the developer's timeline estimate. They know their capacity.
- Build in buffer time. Add 20-30% to any estimate.
- If you have a hard deadline, reduce scope. Launch with core features only.
- Plan projects 2-3 months before you need them.
Reason 5: Scope Creep
The Problem
"While you're at it, can you also add..." This innocent phrase has killed more projects than any technical issue.
Real Story
A client wanted a simple appointment booking system. During development:
- "Can we add a patient history feature?"
- "What about prescription management?"
- "Can doctors do video consultations?"
- "We need lab result integration."
The "simple booking system" became a full hospital management system. Budget tripled. Timeline extended by 6 months. The project was eventually abandoned.
The Solution
- Lock requirements before development. Changes after this cost extra.
- Use a change request process. Every new feature gets a separate quote and timeline.
- Launch V1 first. Add new features in V2, V3, etc.
- Ask yourself: "Do we need this for launch, or is this nice to have?"
Reason 6: Poor Communication
The Problem
Client and developer only talk at project start and project end. Everything in between is a mystery. When the software is delivered, it's nothing like what was expected.
The Solution
- Weekly check-ins. Even just 30 minutes keeps everyone aligned.
- Demo sessions. See the actual software every 1-2 weeks.
- Use project management tools. Trello, Asana, or even a shared WhatsApp group.
- Ask questions immediately. Don't wait until something is completely wrong.
Reason 7: No Testing Before Launch
The Problem
"It works on my computer" doesn't mean it works everywhere. Skipping proper testing means your customers become the testers—and they won't be happy about it.
The Solution
- Test on multiple devices and browsers.
- Test with real data, not just sample data.
- Test the complete user journey, from sign-up to purchase to support.
- Have non-technical people test it. They'll find things developers miss.
- Allocate 15-20% of project time for testing.
Your Project Success Checklist
Before You Start Development
- Written requirements document with all features listed
- Clear prioritization (must-have vs nice-to-have)
- Realistic budget with 20% buffer for surprises
- Realistic timeline (don't rush good software)
- Checked developer's portfolio and references
- Clear communication plan (weekly meetings?)
- Identified who will test and provide feedback
- Signed contract with payment milestones
Frequently Asked Questions
Key Takeaway
Failed projects aren't bad luck—they're the result of preventable mistakes. Clear requirements, the right partner, regular communication, and realistic expectations are your recipe for success.
Don't Want to Be a Statistic?
Let's discuss your project and create a realistic plan for success. No pressure, no obligations—just honest advice.
Let's Talk