The truth behind "working as intended"

blog-author-qual-it.jpg

By Qual IT | 27 September 2016

photo 1461749280684 dccba630e2f6

I once worked with a senior developer who, when confronted with the suggestion that a feature of his latest software release didn’t support the business process effectively, would respond that it was “working as intended” and refuse any further discussion.

“Working as intended” is a dangerous phrase within the business world. It works to justify something while not saying anything about it at all. This may be correct, the software working to specification, having been tested and approved for release, but does that mean it should be?

Billions of dollars every year are thrown at software development and too many times these developments result in failures; not making any money for the company or simply not working at all. In 2015, it is estimated that the United States economy lost up to $150 billion due to failed projects, while the European Union lost up to €142 billion.

The study, published by the Harvard Business Review in 2015, analysed over 1,400 IT projects within the US and estimated the failure rates were between 5% and 15%.

One common reason for the failures is that the software developed isn’t delivering business benefit, meaning that the targeted user sees no value in the software or feature of the software.

This brings us back to working as intended. These failed projects would have gone through an entire process being justified and signed off as “working as intended”, but no one along the way stopped to ask whether it should exist at all.

It is in this gap that the Business Analyst (BA) lives and strives to narrow. Their role is to analyse each part of the process, ensuring that the outcome is going to be the most beneficial for the organisation and its users. In successful projects typically a BA is involved at each stage of the process, ensuring a focus on the right outcome.

The challenge for many organisations is having the right BA resources available. Internal BAs often bring strong domain knowledge, but may have less experience industry best practice; while vendor BAs have high levels of expertise in their solution, but struggle to provide independence. Many organisations are using external BAs to gain access to best practice, be assured of independence and be able to easily scale BA resource as required.

Getting the right kind of BA in place early in the process makes the chance of success a lot higher than it would be otherwise. It also gives an organisation confidence when told that the development “works as intended”, it is to specifications and in a way that will be deliver value.

Qual IT have published a white paper that discusses the role of the BA in an IT project’s success, ways in which they can be better utilised, and be their own kryptonite. Download the white paper “Creating more BA superheroes” to learn more.