For any type of project, requirements gathering, the elicitation of Stakeholder needs is a critical component of how successful the project will be. This is particularly true when developing software; studies have shown that as many as 4 out of 5 software development projects go over time, over budget or don't deliver expected results. When considering those statistics, it is interesting to consider what contributes to this result. It is generally understood that unclear requirements are at the root cause of project failures, and that many factors impact effective requirements gathering. 

Let’s look at a few of them.

1)     Insufficient understanding of the nature of the business problem that needs to be solved.

There is often an assumption that because business analysts work for a company, or have done other projects, they are familiar with operational processes or challenges that the business encounters. However, the nature of project work and the function of business analyst does not always allow for the analyst to be familiar with various aspects of the operation and/or the issues encountered by the business partners. Taking sufficient time to outline, demonstrate, and explain current “as –is” processes and problems with those processes at a detailed level is crucial to requirements gathering to ensure requirements are fully articulated and documented.

2)     Only focusing on the “happy path” (perfect processes) or conversely only focusing on certain exceptions.  In many projects, business analysts are focused on getting information on “standard” or normal processes, and the exception processes are often overlooked. Asking the question at all decision points and handoffs about “what happens if this fails“ allows for documentation of alternative business processes, possible recasting of a solution, or reconsideration of the overall project goals. Truth is no process, transaction, or function works perfectly every time. Understanding what the business wants to see with non-conforming items is as important to a successful project as delivering on time and on budget.

3)     Not having an outsider or disinterested third party read the requirements set for clarity and understanding. A good requirement set should be able to be read by someone outside of the business and your IT organization and be able to be understood for clarity, process, definition, and objectives. If not, the requirements may be too vague, unclearly written or perhaps based on faulty assumptions or unreasonable requests.  Often when projects fail, the comment from IT is “that is not what the requirements said” or “that was not stated in the requirements.” Understanding the construction of clear, concise and complete requirement statements is a very important skill of the business analyst when conducting requirements gathering.

The Requirements Gathering process is not only vital to project success, but is also a crucial skill for the Business Analyst. Continued training in Requirements Gathering techniques and methods reduces the opportunities for project failure caused by misunderstood, ambiguous and missed requirements.

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.