In the last few years, the expectations around modern software development have changed more than those of possibly any other business process, and many IT leaders are still (understandably) playing catch-up. The result is that companies are throwing money at change management consultancies to fix their problems and improve their agility, but there's still a lot of work to be done.

Back in 2011, Forrester famously reported that 70% of all change management initiatives end in failure, and regardless of whether or not you believe in that precise number, the fact that it is so high in the first place says that even the best informed among us have struggled to find a silver bullet solution to the problem of enterprise agility in the age of consumerisation.

>See also: Digital transformation: are you living and breathing next practice or best practice?

A more recent study, conducted this year by IDG and iRise on the state of software development initiatives in particular, discovered that 50% of all IT leaders view at least half of such projects as failures. Given the amount of time, effort and money that goes into just one of these projects, a 50-50 success rate is unacceptable.

So what's a modern CIO to do when both software development projects and attempts to change those projects are failing? Here are a few proven tips that can get an IT team out of a rut.

1. Break the language barrier

We exist in a business landscape increasingly split between the highly skilled programmers in IT and the line-of-business folk who use the tools that IT creates. Because of their different work habits, communication between IT and the line of business is often a lower priority than it should be. The result of bad communication? A product that doesn't meet the needs of the business, which means another change order and another few weeks of production.

When developing software, IT and business should meet as often as possible – monthly is good, weekly is better, and daily (or even multiple times a day) is ideal. These departments should not be put in silos apart from one another, and any kind of institutional process that can be implemented for them to work more closely together should be implemented.

2. Use artifacts to encourage feedback in context

However, simply holding more meetings will not improve business agility or shorten your software development lifecycle by itself – the content of these meetings is important as well. Talking and white boarding are effective in many collaborative work sessions, but software development is much more complex, and demands a more complex learning aid to facilitate effective conversations.

Above all else, visuals are central to the software development process, and not just static images: Meetings between IT and business should use artifacts – or, working simulations of the project in question – if they are to be effective. By making the conversation visual and, ideally, interactive, it puts the project's status in context for the line of business folks, who can then provide accurate feedback to keep the project on track.

At a project level, institutionalising the use of artifacts for constant feedback minimises the amount of time wasted on change orders. Over time, this impacts the culture of the organisation as well – everyone involved with the software development project will stop expecting it to miss the mark, enabling the company to budget for more projects.

3. Own the transformation from an executive level

Getting a start on the above process is difficult, as it requires a commitment over an extended period of time from multiple parts of a business (IT and at least one other department) to pursue effectively. The easy fix for this is to make it a top-down commitment – the CIO needs to make sure their employees prioritize these meetings.

Furthermore, it is imperative that the top-level executives understand why they should prioritise these meetings. According to a 2013 survey by Towers Watson, 68% of senior managers typically understand the reasons for major organisational changes during a change management initiative – but that number falls significantly with more junior team members. While it is unrealistic to expect an executive to be consistently involved at the project level, they must take a personal stake in institutionalising these changes if they want to see them succeed.

>See also: Creating an agile IT team in a world of change

As with most business goals, the burden of success is as much on the leader as it is on the team that is trusted to execute on those goals. That burden becomes greater when the leader must respond to issues that are entirely new to the industry – such as the expectations around cloud, the Internet of Things and the consumerisation of IT.

Shifting software development procedures to become agile is more necessary now than it has ever been, and if your change management consultant isn't giving you advice that works, then maybe it's time to take things into your own hands.

Sourced from Emmet B. Keeffe III, CEO of iRise