Why must the CFO invest in Business Analyst training for non-IT professionals?

In a word, Misunderstanding! Misunderstanding that results in a huge waste of time and money. The interface between IT and Business Owners is a shared responsibility. Concepts that are misunderstood waste valuable development resources, and useful production efficiencies are lost. To reduce the rate of software project failure, the role of the Business Analyst must be understood by both the business owners and the IT group.

The software projects that have the highest rate of deployment success are those where the communication interface between IT and the Business stakeholders has the least amount of resistance. Resistance has two forms; one, the IT department’s ability to comprehend the needs of the business, and two, the business unit’s ability to comprehend the technical capabilities required to meet their needs. An enthusiastic technical IT Business Analyst can overwhelm a business discussion with models and technical jargon used in the software industry. At the same time, business leaders express their needs using financial terms and complex dynamic relationships while their true needs and intentions can be lost in translation.

The initial meeting on a new project seems to start out fine, until the first draft of the requirements document appears, and the stakeholders feel that the IT department did not understand the intent, and instead, has come up with their own interpretation of the system requirements. This often happens because the IT department is re-using existing objects rather than taking the time to read into the business leaders’ intent and future needs. This is understandable because, with software projects, the challenge is to write the code once, and use it in many situations. In reality, business systems often require the design of unique code, and this is where the rework begins.

For the most part, traditional work flow is well understood, but the challenge is building systems that meet the business users intent and allow for rapid change management. The IT department can anticipate some level of future needs, and design systems accordingly, but stakeholders must share potential change requirements early in the process.

Both the IT organization and the business stakeholders need to develop a new vocabulary common to requirements gathering and system modeling. The probability of an on time and on budget deployment is directly proportionate to the common understanding across this interface. In some businesses, stakeholders have a deeper understanding of the technical bottlenecks their system programmers have and use this foresight to better articulate desired features and functionality. This additional knowledge makes it easier to communicate current and future requirements in less time, with more accuracy than a stakeholder who does not have the same level of understanding. These fortunate stakeholders consistently produce projects that also have a lower overall cost, as change management for future needs, is built into base architecture conversations.

There are no short cuts to success or intelligence gathering. The more time stakeholders spend learning about the technical capabilities of their support teams and the lingo they use, the wiser and more competitive they will become.

The CFO can help reduce R&D costs and remain competitive by increasing the rate of interdepartmental communication. The knowledge gap between IT and business can be reduced by requiring all business owners to attend Business Analyst training. IT people have been learning vertical industry lingo and procedures for years, but this is not enough. Both sides of this equation must reach out to each other to increase the rate of success.

In conclusion, as more business leaders adopt the role of the IT Business Analyst, they will dramatically improve their software deployment success rate, resulting in lower cost systems and more competitive products and services.