Skip to main content

Author: Angelo Baratta

Why is Business Process Design the Future of Business Analysis?

Written by Angelo Baratta on . Posted in Articles.

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

 

 

The Tyranny of Best Practice and Its Effect on Requirements Elicitation

Written by Angelo Baratta on . Posted in Articles. 1 Comment on The Tyranny of Best Practice and Its Effect on Requirements Elicitation

tyranny1How effective is today’s requirements elicitation? What do the statistics say? How long is your change request log? Did you ever wonder why there are so many changes during requirements definition? And why can so many project failures be traced back to the requirements?

I’d like to apologize because it’s partly my fault. I don’t mean just myself personally, but rather the generation of business analysts who crafted the foundation for today’s requirements elicitation best practices. That said, the blame shouldn’t be placed entirely on the shoulders of my generation. You see, part of the problem is our inability to learn, organizationally. Organizations have adopted a best practice approach to learning. And therein lies the problem. Let’s examine the serious drawbacks of this learning approach.

The best practice approach is based on evolution. It is slow, agonizingly slow. I don’t know what nature’s purpose is, but I can say with some certainty that in nature it is the strong and the prolific (great in numbers) that survive. Nature is not necessarily interested in keeping the “best”. So it is with best practices. How do best practices emerge?

It all starts with personal experience. We all have it, and we all develop personal practices around it. At some point, an organization may decide that it doesn’t want that many personal practices and it prefers a single organizational practice. So it sets about establishing one. A team is assembled, and based on their past experience, usually 5 – 10 years, they develop an organizational practice. But the one that ends up the winner, isn’t necessarily the best, but rather the one that gets consensus. Often this is a compromise close to the majority practice. Of course, we all know that the best is rarely in the majority. Practices are rarely subjected to verification. And so the strong survive, and we get an organizational practice. Now this practice needs to be propagated to the organization. The time-frame for this can easily be 5 – 10 years or even longer. So at the end of the day we have a practice based on experience that is 5 – 10 years old and which takes 5 – 10 years to spread through the organization. So we have a timeline of 10 – 20 years or more to develop an organizational practice.

Then along come consultants who notice these practices. In some they see an opportunity for business. And so, they get behind these practices. Of course, of the many practices out there, the ones with the greatest opportunity for them, are the ones that will get the most support. And so, these practices start to show up at conferences, in articles and in books. As more and more organizations are convinced to try them, we reach a critical point where hundred of organizations have tried the emerging “best practice”. Among the hundreds, we search for three to five organizations that are both well known, respected and successful. These become the poster boys for the marketing campaign to follow. Their success serves as the fuel for pushing the practice forward. The fact that failure rates for the practice exceed the 90% mark, are never revealed. All we need to show is that it can work, and that it has worked. Eventually, after 10 to 20 years or more, enough organizations are convinced, so we get a dramatic increase in adoption. Now it’s out of the hands of the proponents, the pushers, and into the hands of the adopters. The adopters now begin to talk to each other and stories of failures begin to increase. The true effectiveness begins to emerge. And within five to seven years, another best practice hits the dust.

And how long does all this take? It takes 10 to 50 years to discover that a best practice may not be that good. Can you afford to wait that long to try a practice developed by people based on experiences from decades ago? Six Sigma was branded in 1986 by Motorola based on principles that date back to 1920. It is just now beginning to achieve the level of adoption that immediately precedes abandonment. Lean was primarily developed following World War II by Toyota. The majority of Lean principles taught today were developed between 1945 and 1965. That’s practically ancient history. Again, it is just now beginning to achieve the level of adoption that immediately precedes abandonment. Now abandonment doesn’t mean it’ll completely disappear.

Hindsight is 20/20 – Until You Turn a Corner

Best practices are based on hindsight. The best practices for your job were developed primarily by people of my generation, based on our experience with Requirements Elicitation and Project Management. Unfortunately, our experiences were based on a completely different reality than today’s. We have turned a corner. Didn’t you get the email?

Today’s reality is considerably different. Our job was to automate well defined clerical jobs. Yours is to improve process performance. We dealt with departments with single points of authority. You deal with cross-functional groups with functional biases. We didn’t have change control. Change control has been introduced to fill an apparent oversight on our part. But actually, there was no oversight. We just didn’t have that many changes – our requirements were stable. Today the opposite is true. In fact you can view the length of your change control log as an indicator of risk. The longer your list, the more risky are your requirements.

I appreciate the compliment you are paying us, by basing your approach on ours. But you really shouldn’t have. We were working on cars, and you’re working on jets. Our world moved slowly so we could rely on personal practice to develop best practices. The timelines fit. But at today’s speeds, this approach doesn’t work. We were the more educated within the organization. We worked with dedicated but less educated employees, performing simpler jobs and were willing to be told what to do. You are working with a workforce that is more educated than yesterday’s most educated. Their work is more complex and more varied. And it changes more often and more quickly. As a business analyst, or process analyst, you have little hope of being able to understand to any level of detail all the work required in a complex process simply through interviewing, workshops and software.

But let’s review the conditions prevalent at the time:

  1. Computers were new and expensive.
  2. We didn’t have users yet. We had job experts.
  3. The job experts knew their jobs.
  4. The job experts didn’t know what computers could do. So they didn’t know what they wanted and we didn’t ask them what they wanted.
  5. Departments were full of people who did the same repetitive work and had been doing so for a long time.

So how did we gather requirements? We asked people what they did. We usually asked a few people knowing that everyone didn’t do things exactly the same way. Then based on what we understood from what they did, we designed a computer system to automate their job.

There are a few really important things to understand:

  1. We didn’t get many changes, because there was no opportunity for changes. If you ask someone what they do, and they have been doing it for years, they are not going to come back two weeks later and change their mind about what they did. We asked the job experts a question to which they had a firm, correct, and unchanging answer.
  2. The job experts didn’t have any notions of what computers could do, and so they didn’t interfere in the design process.
  3. The power of the computer to automate the simple jobs was so great, that it was difficult to fail.

How does that differ from today:

  1. You don’t ask subject matter experts what they do. You ask them what they need? The first is a question to which they have the answer. The second is a question to which they do NOT have the answer. The result is that the answer keeps changing. Hence, the long list of changes requests. Answering the question becomes a learning process.
  2. You aren’t in control of the design process. In fact, for most organizations, the design process has been abdicated to the SME committee. The assumption is that because you know how to assemble a car, you must also know how to design an assembly line. Clearly this is a false assumption. Designing and doing are two different disciplines. The people who design race cars are not the ones driving them, and vice versa.

We designed processes by looking backwards to what worked – best practices. We had the time. We had the stability. You have neither. You have little time and lots of change. You need to drop the best practice approach, because “best practices” are no longer a “best practice”. The world has moved on and so has your job. The paradigm has shifted. But the methods have not. That’s the bad news.

The good news is that the future business analyst job is more sophisticated, more impressive, will produce greater results for which you will be rewarded. You will be appreciated for your talent and your unique abilities. You will be seen as part of the business and not just a necessary appendage. But since your job has moved, so must you. Your new approach must be based on designing forward, rather than looking back. This requires that you move away from best practice and towards engineered design driven by performance. It means you have to move away from waiting for the market to accept a principle and towards testing it yourself to see if it works in your environment. It means that you can no longer speak to subject matter experts from across the table to elicit requirements they don’t have, but rather you must lead them in discovering what the higher level process needs in order to produce the desired value. Subject matter experts are not your customers in this exercise. They are part of a team. You are part of the same team, but you have a different role. So do they.

Designing to performance is a totally different paradigm from designing from experience. Designing to performance requires the introduction of science to the art of design. It requires concepts to be tested in real time, rather than distilled through generations of experience. Designing to performance takes the profession to a true profession based on scientific based knowledge, not committee-based knowledge. When medicine was based on best practice, leaches and blood-letting were accepted practices for centuries. Today’s medicine, based on science, has had more advances in one year than was possible in a century under the best practices approach. Best practices dissuade new approaches. Science kills ineffective approaches.

The choice is simple. You can continue to look behind you, after you have turned the corner. Or you can design to the future, while retaining not past practices, but rather enduring principles. You can continue to struggle along a winding mountain road on foot or switch to an automobile on a highway. For sure, it will take some time and effort to learn to drive, but isn’t it worth the ride?

How do you know when it’s time to shift to a new paradigm? When the conditions that lead to the current paradigm no longer exist, then we know we have turned a corner. The time to develop a new paradigm is just before we turn that corner. Unfortunately, we have turned that corner over two decades ago. Best practices are now holding us back. We must shift paradigms before someone switches us.

Don’t forget to leave your comments below

Angelo Baratta PMP, CMC, President of Performance Innovation is a practitioner and researcher. He has combined 25+ years of practical business experience with over 10,000 hours of research and development to produce ePPM Future Blue DesignTM – the art and science of discovering near perfect requirements. Used with Lean or Six Sigma it can help you to deliver from double to 10 times more value and turn Lean into a living and evolving methodology. Angelo’s experience comes from services, consulting, financial and manufacturing sectors allowing him to apply solutions across industry sectors. He is also a writer, presenter, instructor, consultant and coach. Angelo can be reached through www.PerformanceInnovation.com.