Share
Big projects take forever, never get done, and lose relevancy for before anyone uses them. Building things nobody uses is a waste of time, and money, but we spend fortunes doing it, over and over again. There is a better way.
Many big IT projects fail. The Standish Group researched it. You don’t need to read the entire article here to conclude that this table says it all:
This article describes the five reasons why big IT projects don’t get done, and what to do about it, including:
· What to and not to plan
· How to deal with insights gathered along the way
· How to make sure the right things get built
· How to eliminate painful, big releases
The 5 Reasons why big IT projects don’t get done:
1 — You can’t estimate
Big projects have lots of details, and it’s impossible to know every one of them. You always run into surprises. You can’t estimate, you can only guess, and you certainly can’t estimate the unknown. Writing proper user stories helps, but you can’t think of everything before you start. As you get further into the project, more user stories appear until there’s no way of telling what needs doing to get the project done. Also, don’t try to estimate more than a month’s work. Pretty much every project I ever worked on that took longer than a month was overdue. The devil is in the details.
2 — You can’t know what to build
During the development of a project, business and IT both learn a lot. We learn as we do and get inspired along the way. The results produce new possibilities. We discover what works and what doesn’t, both technically and business-wise. We get carried away. We forget the minimal viable product and start building stuff we don’t need. Before we know it, we’re like dogs chasing our tail. We find ourselves improving things, too much. Know when to stop. Good enough is the new perfect!
It’s hard to realize what the scope of a big project is. The scope explodes when the customer and the team realize there are so many more edge cases that should be handled. Or when we realize many more technical aspects, we haven’t thought of yet are important too. Writing stories won’t cut it, you need to prototype things instead. Use spikes, design sprints or even sketch things up to gather these insights before you start building.
3 — It’s too late to change anything
The client describes his desires. The team listens, comprehends, and responds with a piece of software. Yet (regardless of fault), the result is always an interpretation by the developers, which is often (slightly) different from what the client actually wanted. After a month, you ship the product, debating whether or not to change or accept whatever’s wrong because it’s too entangled in the system to fix.
People generally misunderstand each other. Accept and cope with that fact. Make assumptions visible so you can validate them. Write small user stories that result in small, visible changes. Review built user stories continuously during the sprint. Get business involved; invite them to the sprint review. Yes, all this takes time, but it takes two to tango.
4 — By the time it’s finally done, no one cares anymore
Think of your development team as a retail shop for buying software — having unsold (unshipped) products on the shelf is a waste. An unshipped product doesn’t pay the bills. Shipping late is like aiming at a moving target. The client needed a solution yesterday, not next year. If the development team doesn’t fix a problem in time, the client will find another solution. People find different ways to solve problems that slow them down, annoy them or costs money. Maybe some cool, new app will do it, and before you know it, you’re out of business.
Build small solutions and ship them as soon as possible.
5 — Releasing is a nightmare
Releasing is more difficult when it’s not done regularly. Big releases are more complex. Configuration changes, infrastructure, SSL certificates, among other things, all need to be installed. Big checklists emerge that need to be executed, and all in an exact order.
The product might get shipped to a test environment regularly, and occasionally to an acceptance environment, which causes the installation routine to be different for each one. What about merging all of these branches — not to mention the migration. Work trunk-based and use feature flags to hide features that shouldn’t be available yet.
Ship the product continuously. Releasing should be a routine. Small releases can be fixed easily since the scope of the change (and likewise the fix) can’t be too big. Automate releases and automate testing. Make releasing easy as pie.
—
Bottom line? Don’t work on big IT projects. They never get done. Instead, work on small projects so you can start releasing usable things from day one. Less is more! Solutions that were envisioned yesterday, might not be relevant tomorrow. Don’t plan more than a month’s work, either. Make sure the team and the client understand each other. Gather feedback as soon as possible, and continuously. Keep adding small bits of value to the product and ship it all the way to production, as soon as it’s good enough. Make releasing and testing routine.
—
Despite all your efforts still struggling to put high-quality software into production whenever you want? Do you lack confidence in your existing setup to not automate it completely?
Find all your answers here
It is not just about forming DevOps teams, working Agile and setting up continuous integration and continuous delivery (CI/CD) pipelines. Get ready to take the final steps. Xebia helps you to grow the necessary confidence throughout your complete software delivery process.