<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1308192452940245&amp;ev=PageView&amp;noscript=1">

Why You Should Plan for Failure if You Want To Succeed


IT project failure is much more common than you might think. Research by KPMG, AIPM and IPMA found just 19 percent of companies successfully deliver projects (most of the time). You don’t have to be on the wrong side of this statistic, though.

Here are four strategies that can help you avoid failure on your next project and move forward undefeated in your IT project development career.


Know the Costs of Failure

Failure isn’t a big deal, right? Wrong. The costs of a failed project can be high, and most organizations aren’t aware of them. Know what they are in advance and you’ll be better placed to avoid them in the first place.

The biggest cost of a failed IT project is usually financial. Spending six or seven figures on a new application or a cloud migration and having nothing to show for it isn’t uncommon. It’s not just the initial outlay that can make balance sheets look bad. Organizations also miss out on the return that investment could have delivered had it been spent elsewhere and then the additional cost of doing the project correctly the second time.

Time costs matter, too. The time organizations spend failing at an IT project could have been invested elsewhere. Development issues hamper product launches and can result in lost revenue that can never be made up.


Have a Plan but Make it Flexible

How much time did you invest into the discovery and planning process of your last project? Odds are it wasn’t enough. Properly planning your project gives you a roadmap for success and stops you from getting blindsided halfway through the process.

Take time to correctly model and map your entire project. This will highlight everything that needs to be done and when it needs to be completed, increasing project transparency and keeping everyone on the same page.

It will also identify any hurdles or pitfalls that may present themselves during development. Too many companies charge headlong into development and end up getting sidetracked by an issue that would have been simple to fix at the start.

That’s not to say your plan should be set in stone. By working in a set of rolling iterations and planning a maximum of 10 weeks in advance, there’s always time to pivot if required. A thorough business model and feature map also make it clear whether new features will marry with the overall vision of the project.


Plan for Change and Communicate

Avoiding failure isn’t just about contemplating the negatives. It’s also about communicating with teams and planning what day-to-day operations will look like when the project succeeds.

Any significant IT development necessitates a change in the daily workflows of an organization, and the better prepared employees are for that transition, the smoother it will be.

This is particularly important for projects like a cloud migration where transformational changes are likely to occur. Prepare teams by including them in discussions about planned changes and their impacts. In doing so, everyone will be able to spot potential issues and identify the best ways to avoid them.

Bring together internal and external development teams at this stage to get them on the same page, too. This will give the internal team the chance to articulate its vision for the build and encourage the external team to give insight into how to realize those goals.


Give Projects Attention Even After Completion

Work doesn’t stop when you’ve finished development. Learning the difference between a portfolio mindset and a project mindset (and adopting the former) can see the value of each development continue to increase long after it’s been completed.

With a project mindset, each piece of software is treated as an individual project with a set start and end date. Development stops when the project has been delivered.

A portfolio mindset, on the other hand, does away with due dates and forces companies to consider each project as a part of an overarching portfolio — one that needs to be constantly maintained if it’s to grow and deliver value.

Schedule time for the development team to maintain and update each project within a portfolio. Shorten feedback loops to deliver improvements in smaller increments if necessary and switch the focus to improving the end-user experience.

It’s also easier to keep track of software products when adopting a portfolio mindset. By regularly taking stock and improving past projects, you’ll naturally develop an awareness of your organization’s IT assets. This can transform your approach so that you treat your software product like the valuable assets they are.

Project failure is all too common in IT development, but that doesn’t mean you have to fail. Know the costs, have a plan, discuss the change and continue working on your projects after completion — success will come.


Images: Emma Dau

Learn about Kingsmen
Contact Us