Skip to main content

Tag: BPM

Why Business Analysis Processes are a Waste of Time

Kupe_Feature_Oct18_CroppedI recently read a sales blog post, Why Sales Scripts are a Waste of Time, where the author talked about the need for sales professionals to adapt their approach based on the customer they are selling to and not follow a standard script or process they learned through sales training.  Rather than follow a process step by step a sales professional should use the steps as a framework.

The same applies to the business analysis community and a business analysis process. There are techniques, skills, tasks and approaches you have at your disposal.  It is the collection of those that will help you adapt your approach for each project.   The projects our community works on are not to build widgets.  The Ford Motor Company requires a consistent manufacturing process. Ford wants to make sure every Ford Fusion that is built looks and acts the same.  They fine tune their manufacturing process and make sure it is as repeatable as possible. There are steps that are followed A to Z with no deviation to ensure consistency.  Yes, different lines of a model include different steps, but you get the picture. 

In manufacturing following a process step by step is a good thing. In our world this is not the case.  Following an A to Z process for every project is a bad thing.  Every project is different.  Different people, different risks, different priorities, etc.  You need to adapt your process to meet the needs of the project. With that said there are two must steps.  One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives.  There should be a consistent start and a consistent end.  Everything in between should be flexible.

At the beginning of a project or iteration you and the team need to plan the approach.  The team needs to determine what steps you’ll take during the project.  You as the expert need to provide your thoughts and advice for the analysis steps, but you should not determine your approach in a vacuum.  Your team needs to buy-in to the approach and ensure their needs will be met to ensure a successful project. 

Things never go perfectly, so you should be inspecting your approach as you go and make adjustments.  At the end of a project or iteration you should inspect and learn to improve for your next initiative.

Let me end by stating I don’t think you should have to make everything up in between your plan and retrospective for every project.  You should have a base approach that you use as a framework.  Just use that as a starting point to add and/or remove steps to customize your approach for the specific project. 

All the best,

Kupe

Don’t forget to leave your comments below.

Why is Business Process Design the Future of Business Analysis?

BaTimes_Feature_Nov2_cropped“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:

  1. to draw forth or bring out (something latent or potential)
  2. 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:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. 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.”
  3. 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.

Conclusion

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.”

http://www.performanceinnovation.com/
[email protected]
905-270-7591

 

 

Business Process; A Thing of Beauty

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘”Beauty is truth, truth beauty,” – that is all/Ye know on earth, and all ye need to know.’ This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

The previous articles in this series looked at seeking out good by setting the scene using a business context model, and at finding the truth within a business by understanding what real things exist and are true at any time of the day, however the business behaves, using a business domain model.  This article looks at why we model the dynamics of a business and its people.

Unless we can see how the business behaves, it is very hard to understand it. It is therefore important that we can encapsulate what the business does so that we can refine and streamline its behaviour, reduce unnecessary complexity and focus on purifying its business offering. As an analogy, an athlete will develop a process to maximise performance, eliminating all unnecessary activity. There may be a small measure of uniqueness in the process depending on the physical and mental nature and build of the particular athlete, but most athletes will follow a similar process for their sport.

There are two main camps nowadays when choosing a notation for modelling business process. I like to use the Unified Modelling Language (UML) because my business customers tell me that it is easy to pick up and read and because it covers all the types of business modelling that I require (dynamic and static). The Business Process Modelling Notation (BPMN) covers only business behaviour (both notations are owned and managed by the Object Management Group). In addition, many government bodies and industry groups such as the United Nations, the World Customs Organisation and the Telemanagement Forum set standards and industry patterns using the UML.

There is another faction – those who describe the business without a notation – the textual modellers who have the genuine concern that their business people will not like or understand the standard notation.

I have only ever experienced positive feedback on the notation, willingness and enthusiasm from the business and an immediate understanding of a few simple symbols, but, it is our job to create and communicate understanding, not the notation’s job. The notation is simply a language with a ‘dictionary’ and some ‘grammar’ rules. It is our job to ask all the right questions in the workshop (remembering we should always model with the business), to apply logic to a number of jumbled verbal descriptions of what is going on and to label each model element in a meaningful way in order to communicate the understanding reached. Otherwise the business will not understand the result! It is the combination of analytical skill and of the UML notation which won the following accolade. Recently during a domain modelling session (please see the article “The Importance of Business Domain Modelling“), a fellow business analyst, new to the UML, told me that he had looked down to think about something, then had looked back up at the whiteboard and exclaimed to himself how well the entire discussion had been recorded in a matter of seconds.

Most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) UML activity model of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

businessprocess_1.png

Note that a business process always has a starting point, a finishing point and directions on where to go when there are several paths to choose from. These are three of the most frequent review comments I make. Apply rigour and logic! For instance, I can only trade goods if a certificate was issued. Also note that the activity swimlanes (Goods Trader and Certification above) can be derived from the business context model (please see the article “The Business Context Model: As Good as it Gets“) by reusing the actors and business services or areas of interest already identified. The most frequent review comment I make is about the words used to name an activity. Each element in any model must be labelled in a meaningful way. I often see activities labelled like this – “Do Administration” or worse “Enter Data”. These have no meaningful business goal and therefore we cannot hope for good understanding.

Incidentally, it is useful to model at a higher level as we learn about the business; the business use case model is an ideal way to model disjointed business processes that do not logically flow one to another. For example, in international trade, we might identify the processes that are important to our piece of work in the following way, perhaps including a description (in a good modelling tool of course) before we model each process. They should be named to express an important result of value to the business or a major goal. We could even use the strategic business objective as the business use case name.

businessprocess_2.png 

A business use case is also a useful container for business policies, business rules and constraints which can later be inherited by any software specified.

While some people think that specifying software requirements is the only aim of a business analyst, my view is that this activity should be regarded as a possible end goal depending on the findings of analysing the business. While the focus of this series is on business analysis, I will diverge a little to help refocus our attention on the business when we do step further into software specification i.e. to specify structured functional software requirements as system use cases (because a use case describes a single interaction between a user and a system that meets a goal of the user). There is misunderstanding about why we have use cases. Briefly, a system use case exists to partially or wholly automate and support a business activity in a business process. Therefore, we should not invent use cases from thin air. They should be derived. I have just read an article giving guidance on how to choose whether to model use cases or business process. I claim that we cannot know which use cases we need without studying the business process they are there to support. Otherwise, it’s like administering medicine without knowing what’s wrong with the patient.

businessprocess_3.png

How do we derive use cases? By studying the current behaviour of the business and improving it to a more desired state and then by looking at which activities we can enhance and support further. Please reference the Capability Maturity Model Integration [CMMI] which is an open framework for business process improvement describing five levels of business maturity: Level One is otherwise known as the ‘Beast’, and we might nickname Level Five as ‘Beauty‘.  This begs the question – how do we know when we have found a system use case? The answer is when the goals of the business process are understood. What I mean is that we must model goal focused activities and those goals, once recognised, will guide us in informatively naming those activities in Verb + Noun format. When we understand the goal we have a system use case – possibly with the same name. If we don’t understand the goal of an activity, then we must look closer, like we do when showing a bee on a flower to a child – what is the bee doing and why? It may be that the activity identified is too ‘big’ or too ‘small’ and we need to ask many more questions.

Only by deriving use cases from a good logically thought out business activity model can we be sure that our software requirements analysis will be fit for purpose. How else would we know? By writing down the wish list of our business people, hoping that everyone can remember exactly what they said in the requirements meetings so that the 300 pages of free text that resulted are not subject to an endless round of revision? In addition, praying that the statements made can act, in a timely manner, as an accurate specification that really does meet the subset of business goals and objectives assigned to the piece of work from the overall business strategy?

Many business process modellers like to model in ‘layers’ and I am often asked how many layers one should model and what level of detail is required at each level. Some industry standards also model in layers, such as the Telemanagement Forum’s eTOM business process model. My preference is not to layer the business process, because I want the model to be public and exposed, say on my business owner’s wall, and I want the model to be useful as a focus for meetings and discussions. This means that it must fit on one page if printed! I have often seen four walls completely covered by a single layer process, or layers upon layers of business process never used again after the model is “completed” – incidentally the model can never be completed in my book. It is really a judgement for each modeller to make depending on their piece of work, but I prefer a single layer with exceptions modelled on further pages so that I can keep the main process on one page (“main” = what happens most of the time with exception activities shown to indicate when something goes wrong). This may mean that I must keep the goal of each activity quite ‘big’.

Of course, the best businesses are never complacent, always proactively striving for enduring beauty: measuring and optimising business objectives and activities; and visualising the business economics (cost, revenue, benefits). Therefore a model of the business process can never be complete – it is a snapshot of an ever evolving set of activities.

With a smoother running process, we can focus our attention on what really counts – the value chain; designing and pricing products and services. It can be a painful realisation when we know we must actively go looking for inefficiencies in our daily business life. After all, beauty is pain, so the saying goes.

Fill-in-the-blanks: A Process / Content Framework

If you’ve read the previous entries in this blog, you have seen that we’ve been building up to something, and this new entry will hopefully bring us to our first conceptual plateau, upon which there is much more to build.

What we’ve done so far is to reorient our view of requirements and the BABOK, by going from this (based on BABOK 1.6):

Fill-In1.gif

to this (based on IIBA guidance on BABOK 2.0 direction and the concepts from the three previous blog entries):

Fill-In2.gif

Following the previous blog entry about content vs. process, we are naturally led to the above structure which manifests that distinction and also provides a framework within which we can indicate the appropriate methods, tools, techniques, and standards for the corresponding process phase, within the corresponding language domain.

For example, in the Software Development x Elicitation cell, we would typically find UML, prototyping, consideration of legacy systems, etc.; while in the Enterprise e-Learning Infrastructure x Elicitation cell, we might find multimedia complexity requirements analysis, consideration of training data privacy laws, task analysis, etc.

This view brings up some interesting questions about

  • Ownership of the process itself (process design, continual improvement, and governance)
  • Whether this view contributes to or hinders senior management’s ability to obtain a dashboard view of the benefits, costs, and risks related to current requirements management efforts
  • The potential benefit to the enterprise as a whole should this view be adopted by managers and individual contributors involved in managing or meeting requirements

We’ll tackle one of those in the next entry. Meanwhile, I, and I am certain your colleagues, would love to hear your comments.

Enterprise Analysis: Process or Content?

In earlier posts, I have been reasoning that the IIBA and BABOK are on their way to defining a generally applicable framework for requirements management best practices, and that the BABOK 2.0 will be the first significant manifestation of the distinction between process (the requirements life cycle) and content (the nature, or domain, of the requirements being managed).

Viewing the requirements management life cycle in that way, however, requires us to scrutinize the way in which Enterprise Analysis (EA), as currently defined in the BABOK, fits in:

  • EA is content because it is carried out specifically in the domain of business planning and business strategy.
  • EA is process as well, because it is a crucial first step in the requirements life cycle.

The question becomes: is there an EA-like step in the requirements life cycle within other domains?  Let’s explore this question by considering another domain, that of enterprise e-learning infrastructure and delivery (there are many other domains we could choose as well).  From the business strategy point of view, this is a tactical and operational aspect of the enterprise.  But from the e-learning director’s point of view, there is, of course, strategy involved, addressing questions about workforce trends, globalization of the enterprise, the presence of electronic performance support practices, learning-related data privacy, and many others.

So the e-learning director must:

  • Create and maintain the e-learning architecture
  • Conduct feasibility studies of e-learning infrastructure and delivery solutions
  • Determine the scope of e-learning infrastructure and delivery projects
  • Authorize the initiation of those projects
  • Interface with the project team to manage the projects’ value, track benefits, manage change and risk, etc.

Hmmmm.  Looks a lot like BABOK’s Chapter 2: Enterprise Analysis.  Which is the point being made. “Enterprise” is the content.  “Analysis” is the process.  An e-learning director reading BABOK Chapter 2, while pretending the title was “E-Learning Infrastructure and Delivery Analysis” would get some great guidance.