It is indeed an eye-opener that between one and two thirds of IT projects are unsuccessful. This may sound rather daunting to companies who are embarking on custom development projects of their own, that come at a significant investment in time and money. But thankfully, a reason for many of these project failures is glaringly obvious. It all comes down to remaining focused on your core objective.
Software development is about taking a good business process and automating it. It exists for one reason, and one reason only: to create value for the business. Too often, people lose sight of this. It is often far too easy for product owners to get carried away by the potential of a system which leads to unnecessary complications early on in its lifecycle. As a result, it's also easy to lose focus of the core objectives set out for a system to achieve.
Typically, a project is initiated when someone in the organisation has an idea for a process that could be automated or re-engineered. But often more and more people get involved and the idea warps into a final solution that solves problems that never existed in the first place. I love this graphic produced by Kathy Sierra that speaks volumes about the dangers of design by consensus.
As they say, 'a camel is a horse designed by a committee'. Focus gets lost.
When applications get too big, they risk losing their core purpose, and yet costs continue ramping up. In industry, it is not uncommon to see the classic 80/20 scenario play itself out where only 20% of the functionality in a system is core, or even adds any value to begin with. In addition what may look like small additional requests on paper quickly transform into rather large spanners in the works for the development team. If nothing else, attention gets shifted away from the core functionality of a system that you want everyone to focus on to ensure something truly exceptional is developed. Gartner research on why projects fail has also found that the failure rate for larger projects ($350 000+) is 50% higher than their smaller counterparts, this should be reason enough to try and keep your projects as small as is possible.
As you incorporate features into the solution, ask yourself how much value they really add. If you struggle to quantify it, then don't implement it! Besides the impact to the successful completion of the project, the end users may well be less happy with the end result. Chances are that some of your favourite applications have something in common… they solve one problem, and they solve it exceptionally well. Simplicity is king. Another one of Kathy's graphics is a beautiful illustration of the risk of adding too much functionality.
The trick is for your application to reach the happy user peak and not go over it.
To avoid unnecessary complications and remain focused on the core objectives, here are a few simple guidelines to consider as a product owner:
- Projects need leaders who understand the core purpose of the undertaking, who can communicate them effectively, and who hold everyone accountable to remaining focused on them.
- A definition for what value would look like needs to be defined and shared. What are the key success factors? What is important and what is not? From the word go, make sure that all the important stakeholders are on board and all have realistic expectations.
- Be sure to assist the analyst in gaining a deep understanding of the core business problem at hand. This will enable the analyst to create a process that will address the real issues.
- Requirements should be defined upfront and kept at the top of mind at all times.
- As the solution is defined, it is important to ensure all processes are kept simple. In most scenarios, if a process is too complicated in 'real life', it is too complicated period!
- Ensure short and realistic timelines are being targeted following an iterative demo cycle. It is better to produce something that can be reviewed and improved on, than to spend a long time building a complex system that may be regarded as a failure due to misalignment.
- Have frequent retrospectives on progress to track that the focus on business value is still being adhered to.
At Open Box, our development team is committed to understanding the business value that needs to be derived, while remaining focused on building a solution that meets the core requirements using the right technologies. If you need to add additional functionality for a future release, you'll have a good strong base to grow from. What's more, you'll be able to measure how much value you're adding at each stage.
At the end of the day, solid requirement planning is absolutely key. And remaining loyal to this is just as important. Ignore the noise, dispel distractions, and remember the one question that you should never tire of asking, "Does this add real VALUE to the system and business?"