Over the years, seemingly unquestionable truths begin to seem less obvious and indisputable. Perhaps the mind is losing its former flexibility and ability to accept new information. Or, on the contrary, he begins to look at things from a new angle…

..And he finds them not quite as they seemed. Take business analysts, for example. Try to imagine a collective image of a business analyst. I personally imagine a nice, sociable young girl (T.T., hi! J), running with a tablet from the customer to the developers and back, and bringing all the contradictory and incomprehensible thoughts into an orderly base of requirements, where each of them is numbered, traced and accompanied by mockups and test cases. Beauty!

If a business analyst is a programmer by training, who decided that programming itself is a little out of his field, but at the same time, until the end of his days, he understands the difference between an abstract and a virtual method, he will probably be a young man with a discerning eye and excellent English, understands the customer perfectly and quickly translates his thoughts into the language of components and interfaces. By the way, he will probably be calleda systems analyst. A sight for sore eyes!

Business analysts are translators from the bird’s language of the project’s subject area into requirements and use cases that are understandable to developers and testers. As with translations from other languages, errors and typos occur here. However – attention! – the cost of a mistake can be simply catastrophic. According to PMI.ORG statistics for 2014, based on data from more than 2,000 projects, the cause of failure for 47% of them was precisely incorrect requirements!

Of course, every failure has its own reason, necessarily unforeseen and unexpected. However, we can assume several general prerequisites that lead to discrepancies between the customer’s requirements and the result obtained:

1. Lack of time to formulate and agree on requirements. Each requirement goes through several stages, including at least:
   • Proposed
   • Drafted
   • Approved
   • Implemented
   • Verified
   • Deferred
   • Deleted
   • Rejected

If at some stage some check is not performed well enough, it is easy to get a feature that the customer did not actually request at all. Does everyone remember the rope swings?

2. Lack of a common vision for the project among all parties involved. Features must implement some kind of business logic and generate profit. Features that are useless, even if they are very necessary for developers to debug, should not be implemented in the first place.
3. Lack of a clear division of responsibilities between the parties involved in the project, in particular, identification of the role of each stakeholder and the completeness of the information they need to make management decisions. Lack of awareness can lead to poor decisions.
4. Lack of understanding of the inevitable uncertainty of the initial requirements and the need for their iterative refinement as the project progresses, even if the project is carried out using the most “difficult” methodology.
5. Lack or lack of formalized project documents. Even if at the beginning of the project development the team has achieved 100% understanding of the customer, the lack of clearly formulated acceptance criteria or performance requirements can lead you far astray.

On average in the industry, there are from 2 to 5 developers per analyst. This ratio varies depending on the specifics and phase of the project. We can also assume that the “affiliation” of analysts depends on the type of project:

• On projects with a fixed cost, the main risks fall on the shoulders of the contractor; accordingly, understanding exactly what the customer wants is a task of paramount importance. Obviously, business analysts should be part of the project team.
• On “dedicated team” or T&M-type projects, the performer becomes less interested in completing the project on time with a given result. The customer must provide his own team of analysts to monitor the result.

The benefits of analysts are undeniable. However, they can cause harm to the project, in particular due to:

• Incorrectly formulated (and, perhaps, hastily completed by the customer) requirements;
• A wasted project budget, for example, in the case when the requirements drawn by the customer on a piece of napkin in a cafe are in fact sufficient for their unambiguous understanding by the team of developers and testers, and their formal registration in the project base of an Agile project is unnecessary;
• Inconsistencies in the vision of the system between the systems analyst and the development team, in particular, the imposition of internal architecture from the outside.

What should an analyst (and not only him) do to bring only irreparable benefit to the project? Study, study, and study again! By the way, a recording of a virtual conference of business analysts is available on the PMI website until March 31 – who, if not Karl Wiggers, can explain the essence of business analysis in 45 minutes! Hurry up!