Visualising How a Business Analyst Delivers Value
Summary
The first article in this series described the concept of Business Architecture, and went on to introduce two powerful models used to build sound, robust architectural views, being the Capability Model, and the Value Stream. This second article seeks to solidify these models in the context of Business Analysis.
The International Institute of Business Analysis (IIBA) have identified a set of competencies they consider necessary for a practicing business analyst to be effective at their job. This article builds a capability view using these competencies as a foundation, and then considers the value streams that a business analyst uses to co-ordinate these competencies to perform their job.
Two distinct value streams emerge, one showing how a business analyst realises value on a project, and one showing how a business analyst realises value at an enterprise level.
What Do You Do?
As a business analyst, have you ever been asked to explain what you do for the organisation? The question may have come from a co-worker, but more likely you were asked by one of the more senior members of staff. The question can be quite a daunting one.
Since the field of IT business analysis is still relatively young, false impressions of what exactly a competent business analyst is, and more importantly what value they bring to their organisation generally, and their projects specifically, are rife. It is therefore important that the answer given to the question is clear and accurate.
Competency or Capability?
Before moving forward, we must first understand the difference between a capability and a competency.
Although often used interchangeably, "capability" and "competency" are quite different. Ulrich and Smallwood[1] make the distinction that individuals build competencies, while organisations exhibit capabilities.
The intention article is to produce a strategic view of the business analyst, describing their competencies using a capability model and value stream maps. In doing so, the aim is to provide a concrete example showing how to construct these two models using concepts that are familiar to analysts.
For the remainder of this article we are going to treat the individual BA competencies as analogous to organisational capabilities, whilst understanding the key difference highlighted above.
The BABOK, and the IIBA’s Competency Model
Let’s get back to the question that we posed to start with: “What Do You Do?”. The Business Analysis Body of Knowledge[2] (BABOK) is an excellent place to look to begin in formulating an answer.
The BABOK, and its supporting Competency Model[3], describes the knowledge, skills, abilities and other personal characteristics that an effective analyst perfects in time. Also laid out is a roadmap for an analyst to plan their career trajectory from junior to master analyst.
In addition to underlying competencies expected from a professional knowledge worker, the IIBA has identified 6 core knowledge areas that a business analyst must home in order to progress from beginner to competent to master in the practice of Business Analysis.
The competencies that we will use to build our model come from these 6 knowledge areas.
Strategic Modelling Step 1: The Business Analyst Competency Model
Let us start our example by considering the analyst to be an enterprise, and the competencies presented in the BABOK to be our Analyst-Enterprise’s capabilities. Our first step is to build a capability model that represents ‘what’ the Analyst-Enterprise is doing to create value.
This example is built using the Business Architecture Guild’s Level-1 Capability Model as a foundation for categorising each competency. For the sake of clarity, the Underlying Competencies are presented separately.
Since we are considering the ‘what’ and not the ‘how’, we must exclude all of the techniques that the BABOK list. Techniques are very much a ‘how’, and a senior analyst will use several techniques interchangeably, according to the needs of the project at hand.
The model is shown in Figure 1.
Figure 1: Business Analyst Competency Model
You will immediately notice two things in the model:
- first, the competencies, named as capabilities, have been renamed, and;
- second, ‘Transition Requirements Definition’ is highlighted in red.
Naming Capabilities
The reason for the name-change is that capabilities are named using nouns[4]. Remember that capabilities are an external, ‘black box’ view of a business function that encapsulates the people (stakeholders in our case), process (think of the techniques described in the BABOK), and platforms (in our case this includes such things as CASE tools or document repositories).
To assembling our capability model we are defining what is being done, not how. By using nouns we build in a cross-check that we are not including processes or value streams into the capability model.
During analysis, it is quite easy to get tangled in naming capabilities that you are identifying in the business. If you find yourself questioning whether you have identified a capability correctly, remember that you are working towards building a view of ‘what’, and not ‘how’. Take a step back and ask: “Does my capability encapsulate people, process and platform, or have I fallen into the ‘how-trap’ by describing process?”
Identifying Duplication
The reason that ‘Transition Requirements Definition’ is highlighted in red is that capabilities are unique, and must occur only once on the capability model. Let’s analyse ‘Transition Requirements Definition’ by refering to the BABOK definition:
Purpose: To define requirements for capabilities needed to transition from an existing solution to a new solution.
So, this competency talks to requirements definition, but with the narrow focus of transitioning a solution into the organisation. Therefore, it is comprised several of existing requirements-centric capabilities already on our map; it is in essence a specialisation that combines existing competencies.
This composite capability must thus be eliminated from the capability model.
Benefits of the Capability Model
Now that we have produced the model, let us consider the benefits of having produced a capability model for our hypothetical Analyst-Enterprise.
- The model provides us with a talking point. We can refer to it during discussions, and importantly it drives a common vocabulary into those discussions. Moreover, it is easy to discuss individual elements of the role, whilst not losing sight of the whole.
- We can quickly see, on a single page, the competencies that make a business analyst. Using this view an analyst can quickly focus on weak areas, and they can take steps to address these weaknesses.
- Further, the model can aid the planning that the analyst may do by allowing objective prioritisation of actions to address their areas of weakness.
The capability model is our blueprint. The model is a stable reference point throughout our career. We may need to change a great deal, through learning and experience, to cultivate mastery in the role, but the model remains the blueprint against which we will plan to develop ourselves further.
Strategic Modelling Step 2: The Business Analyst Value Streams
When considering how an analyst delivers value to an organisation, it emerges that there are two distinct levels that the analyst engages at.
The first emergent focus is bounded by a project, and the analyst works within the ambit of the project. Working at the project level, the analyst’s deliverables address the specific needs of their project.
The second focus is at an enterprise level, where the analyst is working with business leaders, and key decision makers. At this level the analyst is working to distill strategy into clear objectives. They work to understand the current state of the business, and to formulate the actions needed to achieve the desired future state. This analyst will often be responsible for the business plans that give rise to the projects mentioned above.
Junior and intermediate analysts will tend to have a project focus, while senior analyst will likely be found bringing their depth of experience to bear at the enterprise level.
Value Stream: Plan-to-Solution
Using the competencies identified by the IIBA, the value stream that expresses value delivery in the project context is presented below.
In the interests of simplicity, the ‘Transition Requirements Definition’ competency has not been decomposed into its discrete elements.
Since value streams are designed with improvement in mind, we can start to leverage our view of Plan-to-Solution for the purpose of improvement. Our goal may be to reduce cost by eliminating waste (maybe arising from poor upfront planning), or to produce the solution in time with customer expectation (by better managing scope and communication). Our goal is likely to vary from project to project.
Value Stream: Vision-to-Plan
Next up, let us examine how an enterprise analyst delivers value while conducting their duties.
Figure 3: Vision-to-Plan Value Stream
In this example we can see that the enterprise analyst is using many of the same value stream stages as the project analyst. This makes sense, as in both cases the analyst must plan, they must engage with identified stakeholders to elicit requirements, the must communicate and they validate outcomes. The main difference is the scope of the initiative, and the desired outcome.
Looking at both of the examples I am sure that you get a sense that the value stream presents a dynamic view of value delivery.
Key Principles of Value Streams to Remember[5]
The value stream is customer-focused. Our customer in either instance above is the Project Sponsor, and ultimately the business itself. You may choose to represent the customer in a number of ways, whether in the map directly, or in your supporting documentation.
Keep in mind that the value stream is value centric. At each value stream stage we should be able to identify at least one customer for whom we have created value. If we are not delivering value then we are wasting time and money. It is sometimes helpful to include a purpose and value statement below each value stream.
The value streams are a business-centric view of value creation. They are aimed at strategic decision-makers, and are intended to be simple to understand and interpret. Avoid making overly complex value streams that are more process-centric than is necessary. Getting back to the initial question posed in this article: Think how quickly you could answer the question with a value stream. The high-level nature of the steam does not put off senior members of staff, and they are able to quickly understand the value delivery mechanism.
Value streams are holistic, end-to-end views of value creation. They are by nature cross-cutting, and inclusive of external parties. This allows decision-makers to formulate a common approach that can be rolled out across the organisation without needing to be tailored for individual divisions, departments or sites.
Moreover, the value streams aggregate the underlying processes from across organisational silos, and even organisational boundaries. This allows similar processes to be rationalised and consolidated. Decision-makers are empowered by the holistic view to recognise redundant or duplicate process, and to implement common solutions in these identified areas. The business as a whole becomes more streamlined and efficient.
We can decompose the value streams. This allows the value stream to be tailored to meet the specific needs of an individual product line, or business unit in the context of the value delivery highlighted by the value stream.
Lastly, we can quickly understand how the value creation process leverages business capabilities. Resources can be brought to bear, in an objective way, on capabilities that are underperforming. For instance, we may quickly realise that we are not planning our activities well enough as we are weak in the ‘Business Analysis Activities Planning’ competency. We could then plan to work at improving this competency in upcoming projects.
Conclusion
By using our capability model and value streams we can lay down a blueprint that lets us envision ourselves in terms of what we do, they facilitate planning of a successful approach to improving our skill, and then guiding our development of these skills.
Crucially, we are able to express complex ideas simply, and effectively. The models tend to drive out a common language, and by allowing discussions to revolve around the models we can avoid ambiguity. Armed with these models it should be easy for an analyst to clearly answer the question ‘What do you do?’.
Exactly the same principles apply when you view the enterprise through these two lenses. The opportunities for improvement become quickly obvious. Business Architecture is becoming ever more important in linking the business strategy to explicit, achievable results. As this field matures it is going to become ever more important pillar that supports the overall Enterprise Architecture.
References
[1] Dave Ulrich and Norm Smallwood. “Capitalizing on Capabilities”.http://kwork.org/stars/Ulrich/Capabilities.pdf
[2] Business Analysis Body of Knowledge, version 2. 2009. Available from the International Institute of Business Analysis.
[3] International Institute of Business Analysis. “Business Analysis Competency Model Version 3.0”. 2010.
[4] William Ulrich & Michael Rosen. “The Business Capability Map - Rosetta Stone of Business-IT Alignment”. Enterprise Architecture Vol. 14, No. 2, 8 March 2011, available from Cutter Consortium.
[5] “The Business Architecture Body of Knowledge Handbook”. 2011. Available from The Business Architecture Guild.
