Even with highly intelligent people working in IT, projects will continue to fail if business processes are not well defined and intimately understood, according to a 20-year IT consulting veteran.
Jed Simms, executive chairman of Australian consultancy Capability Management, who has also worked for the likes of the Boston Consulting Group, says there is a real paradox in the IT industry today.
“I used to work for a bank where we were spending millions of dollars on IT without any perceived value,” he says.
“We have a paradox — the IT industry employs the brightest people on the planet, but, repeatedly, the research shows the number of projects that deliver on time [and] on budget is around 35%.”
While at Boston Consulting Group, he says, the root causes of failure were researched and the biggest single cause was found to be the way the required business outcomes of a project were determined. He says there was either a lack thereof or there were poorly conceived requirements.
As an industry, IT is making a real skill of “stuffing up” these required outcomes and business is the main culprit, he says.
“[IT] wants to get into developing the system but business wants action and doesn’t often see the requirements stage as action, therefore IT tries to guess the requirements, which is fatal.”
Once the business knows the requirements for a project, it works through a process of translating them into technical-speak.
However, because the English language is highly ambiguous, people have to be quite specific about what they communicate, Simms says.
Even then, there’s more scope for mishaps because “then it’s all processed by different people and can be performed offshore as well,” he says.
“Ask CIOs how many people in the IT [team] could give a presentation on what your company does. How can people improve a company they know nothing about?”
Simms says the process is to blame for up to 95% of business problems, and all too often the solutions put forward simply reinforce the symptoms.
“We’ve got to get the business process right first [and] you’ve got to think of the processes all the time,” he says.
“From that, we can define the required business outcomes.”
It’s this end-to-end process visibility, and recognition of the need to keep going back to that big picture, that will help IT achieve better project outcomes. If projects aren’t run in alignment with business benefits “we shouldn’t be starting”.
Offshoring, Simms says, can make things even worse.
“I worry when things go to India [and] they have no idea what company they are working for.
“You can have excellent processes for producing bad code.”
With one third of projects “consistently” on rework — a mystery to most business people — the business learns to work around the system deficiencies, he says.