Author: Steve Blais

Knowing it All

Written by Steve Blais on February 25, 2014. Posted in Articles.

There are a lot of recurring questions in the business analysis arena. The reason the questions are recurring is probably because there is no answer. We would love to have definitive answers to some of the questions plaguing business analysts. And in truth there are definitive answers to some of the questions, but unfortunately those answers come too late for our purposes.

Are we there yet?

Take, for example, the question of when are we done defining requirements? How do we know when we are done? When do we have complete information so that we can know that the product being produced as a result of the project completely solves the business problem? We would love to have a checklist or formula that says, “when you have done this, or achieved this, or reached this point, you have completed the requirements process”.

Requirements are the result of information. The business analyst gathers information, analyzes the information and produces the requirements. In order to have ‘complete requirements’ you must have all the information relevant to the problem and solution, in the correct form, confirmed to be accurate, and without ambiguity or contradiction. This is ostensibly possible.

The problem is that you can never know that you have ‘complete information’ except in hindsight. In 46 years in the IT business I would venture to say that only once or twice in that time could we say that we had complete information (and therefore complete requirements) when we started coding (very small projects). Most of the time we were in the late stages of testing and still getting new information (and requirements). New information came up when the users actually saw the product. And there were many times when the product was delivered and it was only when the users used the functions or features in their day to day activities that we got the real information we needed (usually resulting in a subsequent release).

We have to accept the premise that complete information may not ever be available.

There is no blame here. No one is purposefully withholding information.. No one is providing purposefully false or contradictory information. Despite many developers (and business analysts) protestations to the contrary, users really do know what they want and may even be able to express it in an understandable fashion It’s just that after they see what we are developing their minds are changed by new information and viewpoints and ideas. There are simply things that we do not know and many times we don’t know that we do not know. And then, suddenly, we do. We discover new information in new circumstances and that new information many times renders old information useless or suspect. We call these ‘changes’, and we call those who give us the ‘changes’ something worse. For some reason IT has always expected the business to know exactly what they want and then not waver from that request, despite new information that arises during development.

The Information Gap

In software development and to a large degree in projects in general, we have devised many ways of mitigating the problems caused by the information gap. The agile approaches assume that we will learn as we go. Agile approaches advocate incremental delivery with a new ‘piece’ of the solution delivered every two weeks or so. This provides a continual flow of new information in the form of feedback.

Even in a linear management or waterfall software development approach we have tended to add prototyping to our processes so that the business people could see what they were going to get. And we could get more information in the form of feedback, information we could not possibly have obtained prior to that point. People respond better to a straw man than to a vague concept.

A linear or waterfall approach suggests that if we spend more time up front we can get a very large percent of that information, reducing the need for change, disappointment or outright failure. The agile approach assumes that we cannot get all the information up front or perhaps ever, so why try? Since much of the information is obtained after the product is at least somewhat operational, let’s get it working and adjust from there.

Both approaches may work, but management and the project team have to be prepared – appropriate budget, personnel, schedule – for whichever approach is used.
If you are looking for all the information to be present before design or code and you follow an agile approach you will be very frustrated with all the changes and the obvious lack of information that was obtained at the beginning. If you expect to get the information as you go in an agile manner and you follow waterfall, you will be very frustrated with the time spent initially gathering information that you are sure will change anyway.

The Requirements Document is a plan

Requirements are like plans. You could consider the requirements document as the plan for solving the problem or developing the product. (Requirements documents have been referred to as ‘blueprints’ by software development gurus for decades). As much as it makes sense to plan a project, it makes sense to have a plan of the product, as embodied in a set of requirements. However, the famous saying from Helmut von Moltke the Elder: “no plan survives contact with the enemy” applies to requirements as well: “no set of requirements survives contact with the developers (or the users, your choice)”. Similar advice about planning that can be applied to requirements comes from Dwight Eisenhower: “plans are nothing, planning is everything.” Applied to requirements the quote might read: “requirements are nothing, gathering the information and defining the requirements is everything”. In other words, it is the process of defining the requirements that is important and valuable to the project and the organization, not the requirements document itself.

In that case, why bother Documenting?

So, if we cannot really know when we have acquired the complete information and produced the complete requirements, when do we stop? And if the value is in the process rather than the document, what is the purpose of the document?

I am not suggesting that we do not produce hard copy of the requirements in some form: written user stories, feature lists, business requirements documents, or items on a product backlog. There is value in documenting the requirements. However, the document cannot be our primary goal. Solving the business problem is.

The goal of the requirements document, as with any document, is to prove that the process has been completed. A requirements document shows that the requirements process has been accomplished, up to that point. User stories are the result of information gathering and analysis of the features and functions required for a particular solution. In the case of user stories, one might suggest that the requirements process is just starting as the team then discusses and dissect the user story into smaller user stories perhaps and then requirements which may or may not be written down. The same attitude applies to the requirements document: As Alan Davis says, Requirements are “the control point for evolution of the system”, and the requirements evolve as well.

One Irreverent Solution

Since the requirements document is theoretically a complete, correct and accurate representation of the solution, you could always turn the requirements document in after the system goes into production. In contracts we did back in the 90s, we guaranteed that the software we delivered would exactly match the requirements, or the customer would not have to pay. We met that obligation by submitting the requirements when we submitted the completed and approved software. The customers accepted that the requirements document should reflect the installed software and what was delivered at the end might not look anything like what people had in mind at the beginning. So we evolved the requirements as we evolved the system. When we delivered the system, we did in fact deliver a complete set of requirements that matched that system. and we knew for a fact that we were done.

We can’t do that

Steve, it sounds like you are suggesting that we just start writing the software and define the requirements as we go along?

No. It was the requirements document we delivered at the end, not the requirements. In most cases there was a proposal involved or a business case. We wrote all the software support systems for an insurance company in Evanston, IL based on our proposal and an initial overview, and of course our knowledge of the industry in general. The same held true to a degree for a janitorial supply company and for the billing system for a telecom. However, we wrote the system for a prosthetics maker which was a business that was completely new to us, and another system for a company that imported and exported rags. (I didn’t even know there was a thriving business in such things) In these cases, we did business analysis work: we asked questions until we understood the business or at least the problem domain, assembled the information, confirmed our understanding of what was being done and what was needed, and then laid out the solution at a conceptual level. From there the requirements evolved with the system development and were delivered, completed, at the end of the project.

Now, I am not suggesting that you change your approach to requirements and system development. Proposing to your management that you deliver the Business Requirements Document along with the finished system might not win you any political points, if you are not laughed out of the room or placed on forced mental health leave. However, you can start your requirements process with the attitude that you will not have “complete” information about your problem and solution (and therefore ‘complete’ requirements) until the solution is implemented. You can assume additional information will continue to come in while the team is developing the solution and adjust your mindset and your project and software development process to accommodate this fact.

I can see no end in Sight

But how do we know we are done? The normal process is to say we are done when the fixed and approved set of requirements have been turned into code or otherwise implemented and are ready for production. If the requirements are not fixed at some point, when is the project done?

In agile, the answer generally is “never”, but more realistically “whenever”. That “whenever” means, “whenever the money runs out or is reallocated to a higher priority project” or “whenever the product owner (customer) decides that the project is over”. As a business analyst you can determine completeness based on your experience, intuition, and more pedestrian factors, such as a time limit or deadline. You determine ‘completeness’ when you have ‘enough’ information to concoct a viable solution. Basically the fundamental question that determines that the document is done is, “do these requirements define a complete solution to the problem?”

And when the project is complete, you can say that, except for the changes to be added in the next release (or next sprint), the requirements are complete based on the information you have at this time. Up until that point, you can never really know what you don’t know.

Don’t forget to leave your comments below.

What is an AGILE Business Analyst?

Written by Steve Blais on January 21, 2014. Posted in Articles. 1 Comment on What is an AGILE Business Analyst?

There is a lot of talk among business analysts nowadays about something called an agile business analyst. This appellation is generally applied to business analysts who work in an agile software development environment. This is a topic of discussion among business analysts throughout the industry. Courses are being written and delivered about how to be an “agile business analyst”. There is a discussion group on LinkedIn, with the title “Agile Business Analyst”. One thread on that discussion group was started by Leslie Monday, August 29, 2011, titled “What Is An Agile Business Analyst” and it is still going strong. There are at least a dozen other threads in other business analysis oriented discussion groups on LinkedIn, attempting to answer the same question, and I’m sure there are similar discussions being carried on in other communities around the Internet, and most likely in local IIBA and other business analyst organization meetings.

In some cases the discussions have a certain desperation to them because the agile community itself has in the past, eliminated the business analyst role from the agile software development process. The anti-business business analyst vitriol has been quite strong over the years. The claim has been that the developers can do their own business analysis and an extra person in the position of business analyst simply gets in the way.

In these discussions there are those, myself included, who claim that a business analyst is, and really always has been agile. (A discussion started by Louise McDonnell that lasted several months challenged discussion members to come up with a clear differentiation between a business analyst and an “agile” business analyst.) The profession of analyzing the business requires flexibility, responsiveness, creativity, innovative thinking, acceptance of change, and a dependence on individuals and interactions. Such qualities are desired, if not required, regardless of whether the business analyst is involved with agile software development, traditional software development, or no software development at all.

So are agile business analysts “agile” because they work on an agile software development team? And if so, does that imply that those not working on an agile software development team are not agile? I contend that in business analysis, agility is a mindset having nothing to do with the framework in which the practitioner of business analysis works. In other words, an agile business analyst is agile whether he works on a scrum team, any other agile team, or no agile team.

Let me illustrate my point by differentiating between a business analyst working on an agile team, or a developer playing the role of the business analyst, on an agile team, and an agile business analyst. Before the agilists start screaming, I am not suggesting that this is a binary or exclusive differentiation. In the annals of agile, there is a constant reference to the difference between “doing agile” and “being agile”. I am trying to demonstrate the difference between “doing agile” and “being agile” as it relates to the business analyst.

We can look at an agile business analyst manifesto of sorts to describe what an AGILE BA is. You may find that the tenets of this “manifesto” apply to you even if you are not associated with anything remotely resembling agile software development. If so then you can call yourself agile for no other reason than the acronym associated with AGILE BA.

The characteristics of an AGILE Business Analyst

Adaptability

Clearly everyone associated with agile must be adaptable, since that is the essence of agility, according to the manifesto and those who promote it. However, the adaptability inherent in the agile software development approaches is focused on the flexibility required is a natural part of software development. The AGILE BA is not solely focused on software development or defining requirements for development teams. The AGILE BA defines improvements to business processes, assists decision-makers in gathering information to make decisions, helps quality assurance test solutions and products, designs user interfaces and even steps in as a product owner, scrum master, or project manager as the occasion calls for. The AGILE BA may define a set of requirements as a standalone document to outline what must be done by the organization to move to new facilities and then prepare the user stories in a just in time approach for an agile development team. The AGILE BA is not committed or bound by any specific process (software development or other). The AGILE BA is committed to solving business problems wherever they occur in the business however they may be solved. Therefore, the AGILE BA must be able to adapt to the business process, the software development process, or even a lack of process, and to any and all management directives, and not be focused on a single process or framework.

Goal orientation

The AGILE BA’s goal is to add value to the organization by solving business problems. While the developers are focusing on producing new pieces of working software every two weeks, the AGILE BA has a focus on the overall problem that will be solved when the entire project is completed. The AGILE BA is also the weathervane indicating when a project has outlived its usefulness and is becoming a zombie project. The AGILE BA, always having the goal or the solution in front of her, is able to determine whether the project is still on track, the problem can be solved, or the problem has already been solved. This goal orientation is the result of the AGILE BA’s system thinking capabilities and the business analyst’s ability to see the big picture in addition to the detailed tasks necessary to complete the next Sprint.

Innovation

While the solution development team is focusing on completing the items on the backlog in a reactionary mode to be sure that software is developed every two weeks, the AGILE BA is looking for new approaches to solving the business problem and improvements to the business processes in which the problem exists. The solution development team must follow the dictates of the product owner as reflected by the prioritized product backlog. The AGILE BA challenges the business manager, sponsor, problem owner and users to define the real business problem behind the expressed “needs” to ensure that the solution team is solving the right problem, and not providing the right solution to the wrong problem. Innovation requires a modicum of critical thinking that may generate conflict and change, moving people out of comfort zones, and taking risks. Such risks are not commonly undertaken when the driving force is producing releasable software every two weeks and the whole idea of the fixed time box approach to agile software development is to create a comfortable rhythm for the development team to produce software. Breaking out of this comfort zone is not a desirable activity.

Leadership

The AGILE BA is a leader providing solutions to business problems and continuous improvement to the organization. This leadership factor is not achieved through authority, but through influence and through facilitation and communication. A recent book edited by Penny Pullan, titled “Business Analysis And Leadership: Influencing Change”, written for “all who practice business analysis, whatever their job title.” Suggests that “business analyst lead through their work with stakeholders as they build understanding of what’s needed and look to the future”. The leadership of the business analyst on the agile team is usually focused on the team and the project, and the emphasis in agile approaches is on teamwork rather than individual leadership. To again quote from Penny Pullan: “while many business analysts see no need to look beyond their immediate project, outstanding ones will always have one eye on the organization they work within. They realize that, in order to make change stick, they need to understand and engage widely across their whole organization. This requires an understanding of the entire system, the ability to deal with power and politics, skills and working across boundaries of culture, and an understanding of both strategy and commercial realities.” And this defines the AGILE BA.

Empathy

Throughout all the AGILE BA dealings with the business sponsor, customers, process worker’s, users, solution team, technical personnel and upper level management, the AGILE BA exhibits empathy and understanding and provides an intermediary who is a mediator, a calming center in the midst of the storm of controversy and confrontation that usually accompanies organizational change. A certain amount of empathy is needed on an agile team in order for it to function as a high-performing team. That empathy does not have to extend much beyond the team since, as defined by the agile frameworks, there is only one business person to talk to who represents the entire business organization. The AGILE BA is thinking relationship across organizational boundaries, and indeed outside the organization, empathizing with customers, both internal and external, which includes a wide range of personalities and attitudes.

Business orientation

Let’s face it, the agile software development team is focused on the technological issues of producing working software every two weeks. Granted, this working software must be oriented toward the business because it must produce value to the business, but many agile teams depend on the Product Owner or similar role to provide the business justification so they can focus on the production of software. The AGILE BA is unashamedly business oriented, thinking continuously about what can be done to improve the business, and the business processes which drive the business. The AGILE BA is thinking about what the business needs to do to solve the business problems in addition to what the solution team needs to do. The AGILE BA is as comfortable talking to senior executives about business matters, the marketplace and competition, as to the development team about user stories.

Anticipation

In a timebox driven, delivery focused agile process, the general guideline is to not plan more than one or two iterations ahead. As Jim Highsmith advises,” The agile approach assumes that the project plan is fundamentally irresolvable past a very simple approximation. There is no amount of information that will provide the resolution to the project issues beyond that point”. And that point is generally two – four weeks and within the somewhat narrow focus of the project itself: the system and the features or functions being developed. The AGILE BA is completely familiar with the problem domain, the business area in which the problem exists and is able to anticipate positive and negative impacts to other areas of the organization. However, the solution should be the best for the whole organization, and not just a particular business area. Therefore the AGILE BA has to retain enough independence to evaluate potential solutions based on the overall impact to the organization rather than the influence of the particular business area and its managers. Solving a business problem solely for the business unit might have immediate benefits; solving a business problem from the perspective of the whole organization brings much more lasting value.

So there you have it, a clever acronym to distinguish what an agile BA is. And, as mentioned earlier, to many business analysts following the tenets stated above, the words “AGILE BA” could be replaced by “business analyst” because the tenets define the job of analyzing the business, or being a business analyst, whether agile or not.

Don`t forget to leave your comments below.

References:

Pullan, Penny and Archer, James, “Business Analysis and Leadership: Influencing Change”, Kogan-Page Limited, 2013
Highsmith, James, “Agile Software Development Ecosystems”, Addison-Wesley Publishers, 2002

Thinking Like a Business Analyst

Written by Steve Blais on November 26, 2013. Posted in Articles. 1 Comment on Thinking Like a Business Analyst

I was flattered recently during a meeting about a proposed merger when I was waxing eloquent, or perhaps ineloquent, about a review of the business processes and seeing how the business processes matched in each organization. I was suggesting a ‘pick of the litter’ approach. One of the directors at the meeting said that I was “thinking like a business analyst”. I doubt he was thinking about requirements or projects. The business analysts he probably was referring to were those who analyzed the businesses of organizations the company was contemplating merging with or acquiring. He may also have been accusing me of some negative attribute he associated with business analysts, but I took it as a complement, nonetheless. Regardless, it got me to thinking about thinking.

Thinking Fluently

The thing is that we don’t think in words, we think in pictures, images, concepts, and so forth and then translate them into words in order to communicate them. Perhaps fluency, or “thinking like…” is a matter of seeing and understanding the pictures or concepts instead of or in addition to the words. For example when you learn a second language you spend lots of time translating the words. To understand a word in the second language, you translate it first into a corresponding word in your native language which produces an image in your mind. An English speaker learning Spanish would translate “el vaso de agua sobre la mesa” into “the glass of water on the table” and then see the image of the glass on the table in her mind. A Spanish speaker would see the image in her mind immediately. When you are fluent in the second language, you are able to do the same as the native speaker: see the image without exchanging the words in your frontal cortex. Of course each of us has a different image in our heads of what a glass of water on the table looks like, but that’s fodder for another article later.

So we might conclude that if we are “thinking like” some role, or profession that we find ourselves fluent in that role, or profession, or in other words, we see the concepts and images instead of just the words. There may be other phrases or descriptions for the same thing, such as someone “getting it”, whatever “it” is, or to borrow a phrase from the current discussions of agile, “you don’t do agile, you are agile”.

Thinking like…

I think we all have roles or positions or times in our life when we can say we were or are fluent in something, other than a language. For example, at times in my life, I have felt myself fluent in several roles.

In my early years I thought like a programmer. When presented a problem. I could see the code that would be written that would solve that problem. Unfortunately, I probably suffered from what Gerry Weinberg calls the “No Problem Syndrome” in which case I was probably mentally seeing a solution in code before the problem was fully explained. Too many jumping to solutions in that way is another definition of “thinking like a programmer”.

There was also a time that I felt as though I thought like a system analyst or designer. I could see the software programs interconnecting, accessing data, and even the hardware devices on which they would reside. As an analyst I could see the pieces of a larger problem, sometimes with an inability to see the larger problem itself. As a data modeler, for example, I would think in terms of entities, relationships, foreign and primary keys, even when conducting the initial interviews with the users and business stakeholders. This, as you can imagine, resulted in some rather interesting miscommunications during the elicitation phase.

On the other hand, I was never much good at thinking like a project manager. While I had my successes in project management, there were those of my peers who could see a Gantt chart in their heads when presented with the project charter. They could mentally break down the scope into a work breakdown structure and could see the precedence network in their heads with all resources arranged and delegated amongst the tasks. I needed to go through the routine of decomposing and organizing the project with the team. I tended to think technically rather than managerially. It wasn’t ‘instinctive’ to me until I had spent many years managing, at least not as instinctive as writing code or designing systems.

Not a success guarantee, but certainly an indicator

Fluency, or “thinking like..”, is not a guarantee of success in any given profession or role. In other words, you can certainly be a success in a given role without becoming so invested in that role that your thinking is consumed by it. There is certainly evidence and cognitive behavior studies that indicate that we have predilections for fluency in certain areas. Some people have a natural ability to learn languages and the intonations and inflections that make their recitation in that language seem natural, even to a native speaker. Others struggle just to learn enough vocabulary to understand, much less speak. Similarly, some people will find it much easier to be fluent in a programming language than others. However, fluent or not, a person may be a highly successful programmer, designer, project manager, speaker of a second language, or business analyst without necessarily being fluent.

On the other hand, there is also evidence that indicates with focus, attention, practice, and intent, one can master a role, and become fluent in it, even without a predilection toward it. In the book outliers, Malcolm Gladwell suggests that one can become an expert, be fully fluent, in a role or profession by practicing that role or profession for 10,000 hours.

Regardless of whether you have a penchant for it or not or whether you are fluent in business analysis or not, you will be more successful as a business analyst when you think as a business analyst. So what does it mean to ‘think like a business analyst’?

Thinking like a business analyst

The problem with ‘thinking like a business analyst’ is that the role of business analyst is so vague. A programmer programs, she writes code that makes computers do things. A system analyst or designer analyzes problems and creates computer-based systems to solve those problems. What is the specific activity that the business analyst thinks about?

Requirements? Can you imagine thinking about everything in terms of requirements, as in “It is dinner time, what are my requirements for dinner?”
Documentation? Yes, the business analyst seems to do a lot of documentation such that sometimes his entire role seems to be about documentation, but thinking in documentation, as in “let me write down what I am going to wear to work today” doesn’t seem to be applicable.
Liaison or translator between the business and IT? Your thinking might run like this: “let me explain to you what is going on with this television show, dear”. No, that doesn’t quite get it either.

Since all business analysts regardless of assignment or interpretation of the position or role are problem solvers, (the business analyst’s mission: Business, the final frontier. This is the mission of the business analyst: to go identify business problems, to seek out new solutions, to boldly go where no business analyst has gone before. [1]) perhaps thinking like a business analyst is thinking as a problem solver. Sherlock Holmes comes to mind as an example. Mr. Spock is another.

We are all born with the capacity to solve problems. Many of us let that capacity atrophy as we get older for a variety of reasons, mostly cultural and social. After all, Holmes and Spock are not the most lovable of characters. If you look at problem solving thinking, you see a number of different modes of thinking that may go into solving problems.

Critical thinking is a form of reasoning that challenges thinking and beliefs to determine what is true, partially true, or false. For example, a business analyst thinking critically would question the problem statement to make sure that it is the real problem statement and not the description of a symptom before proceeding with the analysis. Critical thinking underlies the other business analyst problem solving thinking modes. Sherlock Holmes is an example of a critical thinker, constantly challenging LeStrade’s and others’ assumptions of guilt or innocence as not being based on facts.

System thinking is the process of viewing problems as parts of whole systems rather than individual occurrences. The business analyst needs to view the organization and its business processes as a system or systems within systems to truly understand the impacts of the changes to the organization that the business analyst is bringing about. There have been a number of discussions on LinkedIn business analyst discussion groups lately about the application of system thinking to business analysis masterfully led by Duane Banks and Julian Sammy.

Strategic thinking as applied by an individual involves the generation and application of insights and opportunities that extend beyond the present timeframe. While system thinking provides the business analyst the larger view in terms of breadth, depth and context, strategic thinking provides the business analyst a larger view in terms of time. While strategic thinking is not usually associated with the business analyst who typically works on projects which are tactical in nature, the business analyst, being in the center of business and IT is usually in a prime position to understand the strategic implications of the projects and products on the organization.

Analytical thinking is essential to problem solving and goes hand in hand with critical thinking. Critical thinking and analytical thinking are sometimes considered synonymous. Critical thinking is specifically focused on thinking while analytical thinking is focused on everything else. Since it is often difficult to see the complete problem or the entire situation in which the problem exists given the complexities of business and technology today, the business analyst breaks the larger picture into smaller more manageable images to make examination and understanding easier. Again, Sherlock Holmes broke crime scenes down to pieces of evidence that, when put all together, assembled a complete picture of the crime and the perpetrator. This reassembly of the evidence or the pieces back into a complete whole to determine the ‘crime’ is what allows business analysts to be both system thinkers and analytical thinkers successfully. The two modes of thinking are not diametrically opposed or mutually exclusive.

Visual thinking is perhaps the only mode that might require a bit of predilection in that some people are more visual than others. But this thinking mode brings us all the way back to the initial premise that we don’t think in words, but in images and concepts: visions. To the degree that we as business analysts can visualize the problem and solution and describe that vision or render the vision into graphical form is the degree that we will be understood in our efforts to communicate.

Now that I think about it…

Thinking like a business analyst might be simply thinking first:

Thinking before reacting,
Questioning before accepting,
Verifying before assuming,
Understanding before judging,
Viewing the whole process before focusing in on the detail issue,
Analyzing before concluding,
Visualizing before writing.

While we as business analysts value the activities on the right hand side we value the activities on the left side more (to paraphrase the Agile Manifesto). Thinking like a business analyst may simply be a matter of reasoning about problems, visualizing solutions, and asking more questions.

Don’t forget to leave your comments below.

The Business Analysis Profession has no Principles!

Written by Steve Blais on October 29, 2013. Posted in Articles. 1 Comment on The Business Analysis Profession has no Principles!

We business analysts often complain and wring our hands over the lack of respect we get as a profession. We debate what we are and what our profession is and does. Why don’t we have the respect that the medical profession has, or architecture, or even software development? Why don’t we get the same respect as lawyers and politicians…well, maybe we don’t want to go that far.

What have they got that we don’t have?

Recall the end of The Wizard of Oz. The Wizard granted everyone’s wishes, but in a way that was not the magic that was expected. He gave the Lion courage by vesting him with a medal. And he gave the scarecrow brains by giving him a piece of paper bestowing a degree. Upon receiving the “degree” the scare crow immediately spouted some brilliant equation showing that he suddenly had brains. The Tin Woodman was given a “heart”.

Suppose what makes a profession is simply a series of accoutrements such as a Manifesto or a Bill of Rights or a set of Principles? After all, doctors have the Hippocratic Oath. Politicians have the words that they agree to when they are sworn in (defend and uphold…). Lawyers have…well, they have something. Agile software developers have the Programmer’s Bill of Rights written by Ron Jeffries.

So I propose that we have some statements of purpose and goal and principles that will govern and guide our profession.

Since a Manifesto seems to be the rage nowadays, let’s start with a Business Analyst Manifesto. This Manifesto was created by Laura Brandenburg

Out of chaos, we create order.

Out of disagreement, we create alignment.

Out of ambiguity, we create clarity.

But most of all, we create positive change for the organizations we serve. [1]

Doug Engelbart a computer pioneer and inventor of the mouse among other innovations, may contribute our statement of purpose (paraphrased):

The business analyst increases the capability of the organization to approach a complex problem situation, to gain comprehension to suit the organization’s particular needs, and to derive solutions to problems.

I might add a Bill of Rights and Empowerments that I posted several years ago: [2]

As a business analyst you have the right to:

Ask questions
Understand the problem and problem domain first
Make sure you are solving the right problem
Challenge the business
Challenge the solution team (to explain why they are choosing to solve the problem in a certain way)
Come up with solutions
Define the problem domain
Solve the problem

As a business analyst, you are empowered to:

Ask questions
Challenge the norms, the “way things are done” both on the business side and on the development side
Try new techniques, methods, and processes to perform your job
Suggest new methods or ways of executing business processes in the organization
Analyze instead of accept
Get and understand information first before committing to a solution
Ask more questions
Do the good quality job for the organization as a whole instead of only individual organizational entities
Define and solve the business problem

While these are three years old, they still apply to today’s challenging environment, and are perfectly applicable to an agile development approach as well.

Finally, we should have some principles or guidelines to follow, some large scale best practices which unify and coalesce what we do. I submit that we can collectively perhaps assemble applicable principles amongst us. I will humbly step into the gap with some principles that might be adopted:

Principle 1 – Focus on the Product

The business analyst focuses on the product not on the project

Understand what a solution is worth to the business

While the project manager focuses on the project to make sure that the project is on time, within budget and delivers everything required, the business analyst focuses on what is to be delivered to make sure the real problem is solved and there is a discernible benefit to the organization when the project is complete.

Principle 2 – First Define the Problem and Then the Solution

Paraphrasing Davy Crockett: Be sure you know what the real business problem is and then go ahead.

Too many times business analysts assume that a statement given to them by the business is a problem when in reality, the business provides a solution. That solution may not be the most efficient or effective solution; in fact that solution may not even be right. And when the business complains that their problem is not solved even though you implemented their solution, you will likely be blamed for the failure. Spend the extra time up front to make sure that you are dealing with the real problem that needs solving.

Principle 3 – Users Do Not Have Requirements

Users do not have requirements; stakeholders do not have requirements – they just have information The business analyst seeks that information and analyzes it to produce the solution document containing the requirements.

Starting with the assumption that the requirements only exist when the business analyst analyzes them into existence is a good starting point for solution development. Taking the opposite assumption – the users know exactly what they want and what the technology can do to solve their problem – is a recipe for long meetings, continuous turmoil and change, and consistent conflict resolution.

Principle 4 – Focus on Information Not Individuals

The problem in elicitation is not finding the right individuals to talk to; it is finding the right information regardless of source.

Too many times the business analyst is told to go get the requirements from certain individuals. Those individuals may not be available or may not know they are supposed to be the repository for all answers. Sometimes Subject Matter Experts aren’t. The best approach for the business analyst is to determine what information the business analyst needs so that the business analyst understands the problem and can create a solution, and only then determine where that information is located. If some individuals cannot be accessed, most likely the information still can be acquired through other sources.

Principle 5 – Separate Elicitation from Analysis

When eliciting information, do not analyze; when in analysis, do not create information.

When you analyze while gathering information the responders interpret the analysis as judgment on the information provided or on themselves. This stems the flow of information. To keep the information flowing, keep the judgment and analysis out of the interchange.
Similarly when you are analyzing the information, and you add new information not obtained through elicitation, you are making assumptions about that information. You are weakening your analytic conclusion. Turn any supposed information not based on elicitation or deductive conclusions into questions that require further elicitation.

Principle 6 – Improve the Process First then Add Technology

Evaluate non-IT solutions first before resorting to computers and software to solve the business problem. Focus on the business, and how IT can be used to improve and enhance the business’s status quo

Constantly review and appraise the organization’s processes and operations to determine where changes can be made that will add value to the organization

Our job, as business analysts, is to add value to the organization by solving business problems. Suzanne Robertson puts it this way, “The job of a business analyst is to identify what people need so that they can improve the way that they do their work and to communicate those needs to people who can implement solutions”” [3] In other words, determine what will make things better for the business then determine what the technical solution might be, if any.

Principle 7 – Do not let documentation substitute for communication and collaboration

Requirements describe the solution to a defined, understood and approved business problem

Over the years the emphasis in the requirements process of software development has been on the production of a requirements document. Whole business analyst teams have been organized around the creation of said document. It becomes a project is and of itself. And while it may well be a good idea to treat the definition of the solution as a project, it is not a good idea to replace solid communication with a document. Remember that the document should be the recording of all the communication that has occurred beforehand, not the communication itself.

Principle 8 – Gain Acceptance before you gain Approval

Acceptability of a solution is not the same as approval of a solution. There are different dynamics at play.

All sorts of problems occur when the person who has the authority to approve is in the same meeting as those who need to confirm that the solution will work for them. Separate the confirmation or verification process from the approval process. Get the solution definition confirmed by those who are eventually going to use the solution in real life: “Yes this will solve our problem!” and accepted by those who are going to implement the solution: “yes, we can do this within the project constraints!” before passing the solution to those who need to authorize the funds or resources to implement the solution.

Principle 9 – Make Sure the Business Community is Ready for the Product / Solution

The business problem is not solved until the solution is being used in the business environment.

You can have the best solution, a Nobel Prize winning solution, and have it never used because the business people who have to use it don’t use it for whatever reason. Perhaps they are not ready for it. Perhaps they really like their work-around. Perhaps they have had too many changes in the recent past to be able to assimilate this one. The business analyst needs to lead the Transition from the current process to the new, improved process. Not only does the business analyst need to make sure that the new process and / or system is ready for the users, but that the users are ready for the new process and / or system.

Principle 10 – Communicate, Cooperate, Collaborate

Keep communications flowing in all directions

Live on the Feedback

Above all, communicate. Never let a day go by without an interesting discussion or provocative dialog. Turn conflict into cooperation. Turn contention into collaboration. Eliminate uncertainty and risk by the exposure of new information.. Never be a bottleneck of information. Learn. Teach. Spread the information and expand it. Know more today than you did yesterday

So there are ten principles to start our Principles of the Profession. I am sure there are more that you can think of to add to our list.

Don’t forget to leave your comments below.

[1] Brandenburg, “The Business analyst Manifesto”, Bridging the Gap, 12/17/2009

[2] Blais, “Business Analyst Rights and Empowerment”, Bridging the Gap, 4/29/1020

[3] Pullman & Archer (ed), Business Analysis and Leadership: Influencing Change, Kogan Page, Ltd, London, 2013

Getting Ahead in Business: What Do They Want?

Written by Steve Blais on September 24, 2013. Posted in Articles. 1 Comment on Getting Ahead in Business: What Do They Want?

When I was in my twenties, the world of course was different than today. We were more concerned with just staying alive and getting a job done. The prevailing notion at the time was that hard work would be rewarded appropriately and we would be elevated in our company and in society in general as a result (in other words, planning ahead for a move into the executive suites was not a consideration). This approach worked for some of us, although in my case, I had to leave the confines of the company and the organizational structure to get ahead.

Nowadays, the younger generation, coming into the work force, is already eyeing the corporate penthouses and is not shy about stating it publicly. How do I know? I just spent the summer with recent college graduates starting out in a number of different companies and the most frequent question I was asked, as an elder in the industry, is “what do I need to do to get ahead in business?” Last year I heard the same type of questions: “what are the managers looking for us to have?” “What will get us promoted?”

So I decided to seek out the answer. I knew what I thought to be the answer, but I wanted to see what the managers and executives of today are really looking for. I asked the executives I worked with, and the managers. I asked recruiters and my fellow consultants. Then I distilled the responses to four basic traits. It wasn’t hard. Most of the conversations came to the same conclusions whether talking to my generation of semi-retired executives or the succeeding generation of mid- to senior level managers. And those who varied in their answers did not vary too far from the mainstream.

Here are the four traits or skills that you need to become noticed by upper level management in your organization or other organizations in the order of importance:

Verbal Communication (influence)
Written Communication (organization)
Execution (discipline)
Performance (follow through)

Fortunately, all of the four traits of skills are learnable. You don’t have to be born with an innate ability to influence or write well. Even discipline can be learned. And all four can be perfected, or at least improved considerably, through practice. The more you write, the more proficient you become at writing and the organization of thought that goes with writing well. The more follow through you exhibit, the greater your overall performance will be, and as your good performance becomes more visible, the more follow through you will exhibit, and so forth. Underlying all four traits is the concept of confidence.

So what are we really talking about? Let’s look at each of the four traits along with some simple ways you can acquire or improve each of them.

Verbal Communication (influence)

The most often cited skill for those thinking about moving up in the organization is that of verbal communication. Managers, clients, executives, and everyone appreciates someone who can put together their ideas in a logical, compelling fashion and present these ideas verbally. Business analysts are constantly engaged in verbal communication: facilitating meetings, asking questions, eliciting information, making presentations, and so forth. Verbal communication includes the following:

Expressing your ideas and position in a meeting setting
Conducting a formal presentation to various levels of the organization
Giving a status or other report to a group of peers, managers or upper level management
Influencing another party or other parties to adopt a particular plan of action
Negotiating or mediating conflict
And so forth

Underlying the ability to put together words in a meaningful fashion in front of an audience (one or more people) is the concept of influence. Influence is getting people to do something without the exertion of authority. If you can demonstrate the ability to influence, you also demonstrate your ability to communicate verbally: with purpose, intention, logic and appropriate emphasis. People who have the ability to successfully influence those around them are in big demand in the executive suites and are in little supply. There are few classes, if any, in “Influence 101” in university, even in MBA programs.

How can you gain or improve this trait?

You can increase your knowledge of public speaking by joining Toastmasters or any organization in which speaking, as in meetings for example, is a focal point of the activities.
Actively solicit feedback from those around you. Ask if you have been understood and if not, why not.
Be more aware of how your words affect others by observing the body language reactions of the listeners.
Overcome your fears of speaking in public by taking small steps. In each meeting make an effort to ask at least one question or make at least one comment.
Instead of writing a text or a tweet or even an email, talk to the correspondent verbally over the phone, or in person. Practice your verbal interchanges.

Just focusing on your verbal skills will bring about an improvement, and with that improvement you will gain confidence and then more improvement.

You know you are on the right track when management asks you to make the presentation at meetings.

Written Communication (Organization)

Second only to verbal communication is written communication. In the Internet age many people forget that most communication is still written, especially in business. Upper level management is always on the look out for staff members who can put words together in written form. Business analysts write a lot. They write requirements, memos, business cases, project charters, reports, debriefs, decision papers, and so on. While verbal communication has the impact of emotion and personal influence, the impact may fade and die a short time after utterance, written communication is persistent and may last forever, whether on paper or in bits. I may be able to deny saying something or claim misunderstanding of a verbal dialog, but my there is non-repudiation in my written words. And that is all writing, not just formal reports or contracts. This includes:

Formal written reports
Written proposals both formal and informal
Business cases and other decision papers
Informal written reports
Memos
Emails
Texts
Twitters
Postings
And just about anything you have written that is shared with anyone in the organization

Behind the words, however, lurks another trait that shines through: organization. Writing success requires organized thought. A person who writes well demonstrates an ability to organize his or her thoughts well enough to render those thoughts into meaningful words and sentences so that other people can read and understand. This is a different skill than verbal communication. There are many who can write well but not put two words together meaningfully in front of an audience or even an individual. And there are those who can express their thoughts well standing on their feet but have no concept of how to put those same words on the page.

The organization skills which support writing skills do not go unnoticed by those in the executive suites. Those who write well recognize good writing, in fact everyone does: the clarity of thought, the use of the precisely correct word, getting your point across in fewer words (concision), and arranging sentences in a way that is easy to understand by your audience. One of the easier ways to gain recognition is to write well. Your verbal communication has a limited audience; your written communication does not.

How do you become a better writer?

Read more. Read what successful writers have written (fiction, non-fiction, essays, articles, etc.). You will begin to hear the rhythms of their sentences and paragraphs and it will work its way into your writing.
Ask for feedback specifically on grammar and sentence construction. The rules of grammar we were taught in school are designed to help us write clearly and others understand our writing.
Think about what you are writing before you write it and review it afterwards, even tweets, texts, and emails. The act of correcting a grammatical error will imprint the correction in your mind and you will be less likely to make that error in the future.
Take notes in every meeting and purposefully rewrite your notes into a report for yourself (you don’t have to show it to anyone).
And, over all other recommendations: to become a better write, write more.

Just as your Facebook pictures and posts can be read by recruiters and others, and you have heard stories about people losing jobs because of inappropriate Facebook postings, what you write and how you write it are also reflections of you as a person and a business analyst or whatever position you currently have or wish to attain. If you want to get ahead, pay attention to what you write. As you begin to write better you will gain confidence in your ability to write well and that will spur you to writing more.

You know you are on the right track when management asks you to provide a written summary of a meeting or project, especially an executive summary.

Execution (Discipline)

There are those who talk a good game, both verbally and in writing, but never seem to get anything done. You may know people like that. There are those who are great at recognizing a problem, and even coming up with the perfect solution and then they consider their job done and go off to something else. Business Analysis is all about solving business problems for the organization. And the problem is not solved until the solution is being used in the business environment. In the end there is a job that needs to get done.

The ongoing and seemingly everlasting debate about the value of university degrees is an example. Putting aside all the education and social aspects of college, to management of a company having the degree designation behind your name shows that you have the persistence and determination to complete the four to eight years of school work and complete the job, and the degree is proof. And persistence and determination are valuable traits in the work environment. I’m using the word ‘discipline’ to represent the persistence, determination, stamina, and focus necessary at times to get the job done despite interruptions, distractions, diversions, and the siren calls of emails, tweets, unfinished online games, Google, etc. The successful business analyst and the one being tracked by senior management is the one who shows that determination and discipline by having a reputation for successfully completing jobs.

After noticing you through your writing and verbal communication, management looks to see if you can do what you say you can do. Do you complete the work? Do you get it done on time? Do you keep your promises, even when such promises are only implied? Are you a person of your words?

How do you gain a reputation for execution?

Obviously by executing. If you are not able to get ‘into the groove’ or the ‘flow’, practice doing so.
Reduce distractions.
Focus.
When you find yourself drifting and engaging in activities that lead you away from executing, stop, take a breath, and refocus.
Some people find meditation helps to increase their overall focus, even meditating a few minutes during the day when the ‘noise’ gets too invasive.
Become consciously aware of how often you find excuses to avoid doing something you find boring, tedious, or unchallenging.

As you pay attention to what keeps you from completing a job or task, you will discover that your ability to focus and execute will improve automatically. As your focus increases, so will your confidence that you can execute jobs that are assigned to you and you will find yourself volunteering for more jobs which in turn increases your confidence. (Be careful not to overbook and end up not completing anything).

You know you are on the right track when managers come to you to get things done or call you in to pick up the ball dropped by someone else.

Performance (Follow through)

You buy a new car and drive it off the lot. It runs well and you are delighted with the car’s execution and the dealer who sold it to you. However, after a few hundred miles of driving the car begins to exhibit suspicious traits: engine cuts out at inopportune times, brakes squeal, exhaust goes from colorless to dark black. You determine that the performance of the car is less than stellar. You then evaluate the performance of the dealership based on how well the dealership responds to the problems your car is exhibiting.

So it is with a project or the result of a project. In the end, how the product performs over the long run will be the measure of the product’s value to the organization, and the measure of the value of those who delivered the product. The successful business analyst follows through with the commitment to solve the business’ problem by making sure that the solution works well in operation and continues to work well. The successful business analyst assumes that the solution may not be perfect and seeks out ways to improve the solution once it is in operation. Upper level management notices the business analyst’s attention to value of performance and the business analyst’s focus on ensuring the long-term success of the solution.

How do you increase your focus on performance?

By taking the project lessons learned or retrospective sessions seriously.
Perform a lessons learned on your work whether the project manager calls for it or not.
Act on the suggested improvements that come up during such sessions so that your personal performance and that of the team improves with each succeeding project or sprint.
Seek out those who might be against the project or the product or who may be critical of what was done and find out why they feel that way.
Continuously ask Goethe’s three critical questions:

What did I (we) do?

Was it done well?

Was it worth doing?

Consider the situation of completing a successful project and then taking a new position in another company, or even in the same organization. What will your legacy at the previous position be based on? Your relationship with your team members (who themselves may have moved on)? The beauty of your written requirements? Your negotiation ability during the never ending project meetings? No. Your legacy is the result of the successful project. You can take pride in pointing to systems or solutions that you worked on that are still in operation, generating value for the organization, years after you have left. As you recognize and publicize your success in adding durable value to the organization you will gain confidence in your ability as a business analyst which in turn will result in better solutions.

You know you are on the right track when management introduces you as one of the prime movers behind a system or solution that is bringing benefits to the organization.

Confidence

As I said in the first paragraph, there was a notion that doing good work would be noticed and rewarded in its own right. Unfortunately that is not always so. In all the rush and stress of everyday business, managers may overlook the quiet, competent worker who always gets the job done. While there is a lot to be said for the concept of “doing a good job is reward in itself”, this article is for those who are seeking to move up or ahead. Excelling in any one of the four traits will draw positive attention from above. Excelling in all four puts you on the fast track to the executive suite, at least according to the executives I talked to.

Each of the four traits is linked by confidence: confidence in yourself and in your actions. As you gain confidence in one area or trait, that confidence flows over to assist you in improving another trait. You may choose to improve the trait that you are most comfortable with, such as speaking, or you may choose to focus on the one that you feel is most in need of improvement. It doesn’t matter. You can choose to focus on one trait a month and repeat the focus three times a year. Or you can focus on the trait that brings you the most positive feedback from management and peers. Any improvements in any of the four traits increase your chances of moving up in the organization.

In the end, improving your knowledge, skills and abilities in verbal communication, written communication, execution, and performance contributes to your overall confidence. Confidence in yourself and what you do is a compelling prerequisite to success in business.

Don’t forget to leave your comments below.