“Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”
– BABOK V2, page 3.
In order to achieve the objective of enabling the organization to achieve its goals, the business analyst engages in Requirements Elicitation. The following is extracted from the BABOK:
“The definition of elicitation is:
- to draw forth or bring out (something latent or potential)
- to call forth or draw out (as information or a response)
These definitions highlight the need to actively engage the stakeholders in defining requirements.”
– BABOK V2 (page 53)
The implication is that requirements come from subject matter experts (SMEs) and that the BA must extract them or draw them forth. But where did the SMEs get the requirements? Did they make them up? Do they represent their personal preferences? If the answer is yes to either, then requirements become virtually untouchable statements that can only be verified by the person who verbalized them. If the answer is yes, then a requirement can change at the whim of its originator.
Requirements are not and should not represent personal preferences that can’t be independently verified. Requirements must be owned by the organization. But what do they represent? Let’s again turn to the BABOK.
“A requirement is:
- A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.”
- A documented representation of a condition or capability as in (1) or (2).”
– BABOK V2 (pages 4-5)
The difficulty with these definitions is that they portray requirements as already existing prior to the start of the BA’s work. The BA’s challenge, then, is to somehow pry or draw out the requirement from its source-the stakeholder, the contract, the standard, or other imposed document. They imply that requirements are the output of some other process but somehow they were never properly recorded. So, in rides the BA to record them. If that were truly the case, then requirements would be captured correctly the first time, for the most part, because the stakeholders already know them. Requirements would be unlikely to change.
We know that this is not consistent with reality. Requirements are often wrong, irrelevant, or incomplete, and not because they were misunderstood. They were wrong from the start. In addition, requirements statements tend to change frequently and continuously. Why would that be? A reasonable conclusion is that the requirements that we are trying to elicit (draw out) don’t actually exist yet. It is the process of drawing them out that is making people think about them-possibly for the first time. That’s why they change so often. In other words, people are designing their process on the fly and in an unstructured and unreliable manner.
|“No matter how hard individuals work, they cannot overcome a flawed process design, much less the burden of no design at all.”
Michael Hammer, The Agenda.
So what should requirements be? As per the definition, they represent a condition required to solve a problem or achieve a solution. Or they are constraints imposed from the outside. If a requirement is something needed to solve a problem, then we need to have developed the solution to the problem. In other words, we need to have gone through proper design.
This leads to an alternative way to view a requirement-as an output of process design. True Requirements can only be produced if and while a process is properly designed. That means that in order for a business analyst to achieve the intent of business analysis-recommend solutions that enable the organization to achieve its goals-the BA must engage the Requirements Team in designing the business process. Design is the activity. It must be carried out overtly and systematically and not as a side-effect of elicitation. Requirements are the output. They must be overtly documented in the form of a business blueprint.
|Requirements should not be drawn forth. They should be hammered out as part of a structured process of design activity.|
Process Design is the Future for Business Analysis
When the going gets tough, the middleman is the first to go. The BA, today, plays too much of a middleperson role. The future BA will be a process design master that leads SMEs and other stakeholders in process design. The endgame is a better process, not just requirements. And a better process requires a structured approach to process design.
The future business analyst will lead a structured design process that produces a process blueprint which contains structured requirements. The blueprint will represent organization needs that can be independently verified for correctness and completeness. The blueprint will separate out any personal preferences from process needs.
The separation of personal preferences is important because these account for many of the unnecessary conflicts that arise in requirements statements. Of course, in order to achieve this a few role changes are required.
The business analyst will no longer be a go-between. Instead she will lead a cross-functional team in the all important activity of designing the business. Today, the BA is master of few things. A BA knows project management but not as well as a project manager. The BA understands technology but not as well as the developer. The BA knows the target business domain but not as well as the subject matter experts. Today the BA is a jack of too many trades and a master of no particular one. This presents a clear and present danger for the BA. In the future, the BA will be the master in process design.
The process owner role needs to disappear. Firstly, few organizations have successfully implemented such a role. Think of ownership and what it implies. An owner can do what he likes to what he owns. That implies that a process owner can do whatever he likes to his process. But value delivering processes are cross-functional with functional owners. That leads to conflict. It leads to processes with two sets of owners, one for the cross-functional process, and one for each functional component. However, it is the organization that should own the business process. Process owners need to be replaced by process governors. A governor manages within a given framework. This makes more sense. The organization owns the process and defines the performance framework for it. The process governor manages that process within the given framework. He is not completely free to do whatever he wants. He must manage within boundaries.
Subject Matter Experts are not the customer. The customer does not change based on perspective. The external customer is the customer. A business process should be designed to deliver value to the external customer. The SMEs are participants of the business process. When the SME or other internal stakeholder becomes a customer, the risk is that their personal needs hijack the true needs. So SMEs,, developers, and other stakeholders become key process participants. Like the process governor, internal participants need to act in accordance with the process blueprint. That ensures that everyone is aligned to the process blueprint which represents the intent of the process.
|Of what use is a business process blueprint?
“People who are aligned around a common goal but lack the discipline of a well-designed process will go nowhere … likewise the best-designed process has no chance of survival when people aren’t aligned around the process and its goals.”
Michael Hammer, The Agenda.
Design is the defining discipline of this decade. Structured Process Design is the new discipline whose mastery will set the business analyst apart. Process design will produce, as an output, the business process blueprint, which will contain structured requirements. These will be the foundation for developing strong and useful software applications. Process Mastery is the key future capability that will distinguish the business analyst from other roles.
Elicitation is a middleperson activity that will disappear and no one will mourn its passing. Incorrect, incomplete, irrelevant, and conflicting requirements will be dramatically reduced. Requirements will be independently verified and first pass quality will rise. More projects will be a business success and they will deliver more stakeholder value.
Roles will change to make accountability clear. Teamwork will need to rise. The BA will be the design team leader with SMEs, developers, and other stakeholders as team members. The process blueprint will become a persistent, reusable organization resource for managing process performance rather than a temporary throw-away project resource.
A focus away from elicitation to design will yield benefits for everyone. It will increase productivity and more importantly it will increase value delivered to the organization. Of course, the shift has to be driven by someone. If you like your current job as a requirements order taker, then you don’t need to take any action. But if you prefer the more proactive role of Process Design Master, then you should take the initiative in driving the future, if you haven’t already done so.
Don’t forget to leave your comments below
Angelo Baratta’s focus is advancing human mindware. Based on 30+ years cross-industry experience and over 10,000 hours of R&D comes ePPM by Design – a framework for structured process design (SPD) and requirements.
Learn more about SPD from his book “More Perfect by Design: A framework for designing more perfect business processes” available soon.
In progress is “Getting to Understanding: A framework for Structured Requirements.”