As a business analyst, I work together with contacts from your departments to determine the business requirements that a solution to be developed should meet.

Analysis Methods

Requirements elicitation can be done through briefings, functional teams, workshops, or a complete value stream mapping or a mix of the 4 methods. In value stream mapping, the current state is compared with a target state described via the strategic requirements, and from this, value streams with contained solutions are developed. These newly developed value streams are then adjusted and approved in one or more rounds of workshops. The advantage of working with business teams is that requirements are identified very quickly and comprehensively. The disadvantage is that these predominantly high-caliber personnel resources in the form of key users and department managers are not available for the actual operational tasks during the period of requirements determination. Nevertheless, I would always prefer to work with specialist teams, also because this is the only way to transfer knowledge to other areas of the company.

Challenge

I have both the methodological knowledge and the experience from numerous projects to capture the requirements efficiently and completely. A recurring challenge here is the mutual “shooting in” of business teams, the product owner and the development team, between which the business analyst interacts like a pinball. Experience has shown that this significantly reduces the amount of coordination required during the course of the project.

Implementation

As a business analyst, I “efficiently” guide a functional team through requirements elicitation – ideally based on a baseline or initial solution that needs to be further developed. To increase efficiency, I work with break outs and concept sprints – and where appropriate, with parallelization and time boxing. I document live in an appropriate and shared tool to avoid duplication and enable transparency.

A second area of responsibility is consulting based on experience from parallel or upstream requirements investigations and the transfer of knowledge and experience between the business teams as well as between the development teams. This transfer performance is the basis for the most extensive standardization of work processes possible, which significantly reduces both project and ongoing costs.

Demand

The business analyst is always indispensable when the business department does not have the technical or methodological knowledge required to implement a solution. A business analyst can be provided internally, especially in large companies, if the company maintains its own departments with the necessary knowledge to implement the solution – and then uses external service providers at most to supplement non-specialist manpower. If a company does not have the methodological and technical knowledge to implement a solution and therefore purchases the service from a service provider, then the use of a business analyst “from the service provider” is indispensable, because the analyst “must” have the necessary knowledge to implement the solution. This is always the case, especially when existing standard solutions from a supplier are to be implemented. A customer of such a solution rarely has sufficient competent internal resources.

So what happens when a company forgoes the use of a business analyst with the necessary knowledge?

• The departments do not know the methodology for efficient requirements elicitation
• Requirements
  • are not recorded correctly and completely
  • contradict each other
  • describe a supposed “how” and not “what” is required
  • are not recorded in the necessary sequence and the development team can therefore not start early with the solution implementation
• The company does not receive advice on
  • Good-Practices
  • Solution options
• The development team can do little or nothing with the requirements
• The product owner is burned out due to mutual lack of understanding between business departments and the development team
• The department teams are at a loss and lose their willingness to participate
• The development team is on its toes, but can’t implement anything because the requirements are not of the necessary quality.
• Das Programm und das Projekt als Ganzes verfehlen die technischen, zeitlichen und monetären Ziele
• The project fails, the personnel and financial effort must be written off without added value

The Business Analyst keeps getting cut for budgetary reasons. Just as often, projects fail because the abandonment of this important interface role creates an unnecessary and often insoluble field of tension.

The bottom line is that the business analyst should always be provided by the developer of the solution, so that the customer or department can concentrate entirely on its strengths and is penetrated as little as possible with tasks that are hardly solvable for the individual employees. This may sound more expensive at first, but in practice it saves a lot of money and nerves and significantly reduces the project risk.