Everybody is building software nowadays. Companies of all sizes and industries are afraid of getting left behind so the innovation hype is stronger than ever.
Speaking to companies, I realize there's one thing they all share - stories of failed/late/expensive projects, regardless of whether internal or external teams were involved.
Some online sources state that 75% of the executives expect for their software projects to fail and less than 30% of all initiatives were completed on time and budget over the last year.
If you don’t want to join the club, in couple posts I'll outline some common mistakes you should avoid. Starting with a few non-technology related ones today:
The project scope is too big
A project that is too big is a classic recipe for disaster.
Big = expensive, long, lots of room for trouble
Just think about these phrases: "Big, efficient software", "Long, on time project", "Massive, scalable system" - they don't come very realistic.
Instead of going big from the beginning, your odds would be way better if you start small, one problem at a time, iterate quickly and scale based on feedback. Always try to boil down a potential solution to its basics and build up from there.
You are building the wrong solution
I keep receiving these huge scope specifications and RFPs with hundreds of pages of detailed features sets, user flows and what not.
My general experience is that 30% to 50% of these represent 80% to 90% of the actual solution. Would the remaining 10% be worth 50% of the budget?
Optimal solutions are built through prototyping, feedback loops with real users and constant adjustments. Drop the "we know it all" attitude and consider doing a design sprint (grab Jake Knapp's Sprint).
The team is having poor (or lacking) processes
A project, big or small, treated like a weekend hackathon, would rarely yield the desired results. Hiring couple developers and letting them play around is not going to cut it.
Recently someone told me “So, Johny from sales once worked for a software company back in 2004 so we are managing this project under his terms” - that's not a sustainable way to run a project.
Efficient processes are crucial for delivering business value so either hire a team with an established workflow or be honest with yourself and get a consultant to help your internal team.
Lack of involvement
That's another common pattern - stakeholders and peers are initially excited about a project, but as time passes, the involvement gracefully drops to non-existent. Yet progress is still expected to be made.
That leaves the software team working without feedback. At the same time, everybody else loses realistic idea of where the project is at until it's launch time.
Late launches
Speaking of launches, that's another common mistake I see.
Teams often wait too long to launch a piece of software because they want it to be better/perfect, but that just postpones the potential problems and failures.
Identifying problems early in the lifecycle leaves room for adjustments before it's too late. It's essential to launch as soon as possible and start gathering real-world insights you can then use to improve upon.
Overall, if you want your initiatives to be more successful, start small, launch early, learn and improve in the process. Embrace Lean and leave the old practices behind.
These were some of the mistakes I wanted to pinpoint. In my next post, I'll dig into some technological pitfalls.