A Philosophy of Business Systems Analysis

By Dan Shumaker

The Importance of Mutual Understanding

I work in software development as a Business Systems Analyst. That means I help the business users of software, its developers, and all other stakeholders understand each other so well that the software delivered is what the business needs and wants.

The steps to facilitate that level of understanding involve a lot of conversations and documentation of the business expectations for the new or revised software - requirements - using a variety of documents and diagrams deliberately designed to facilitate mutual understanding. But it's easy to get caught up in delivering documents that record all that information and forget that the goal of this liaison role is mutual understanding, not mere agreement.

There can be a big difference between the two. Project stakeholders often understand the information in those deliverables differently. My experience is that these differences are usually only uncovered late in the software development project and are a major cause of project delays. And worse, the resulting software can miss the mark so far that it must be partially or fully discarded. Sometimes management becomes so frustrated with project failure that they purge development staff, abandon the whole project or completely outsource it - all for the lack of mutual understanding that went undetected.

It’s the BA’s job to make sure that doesn’t happen. A BA can achieve a high level of mutual understanding by acting as 1) a Facilitator of precise functional and technical communication, 2) a Translator of concepts and ideas into terms that all stakeholders understand the same way, and 3) an Author of documentation deliverables that record all this communication precisely.

Achieving mutual understanding is the Art of IT Business Analysis, behind all the use cases, diagrams and documents, and perhaps more critical. But how do you facilitate mutual understanding and how do you know when you've achieved it? That’s the topic of the next post.

The Significance of Ambiguity

So, achieving mutual understanding is a foundational objective in software development and effective IT Business Analysis. But how do we achieve it? And how do we know we’ve achieved it?

Beyond expert use of all the BA tools - the mechanical aspects of the job - the BA must be skilled in Identifying and Resolving all the latent Ambiguities that may exist in the project discussions and in the content of the deliverables. One stakeholder's concept of a requirement may not match that of others, even though they use the same terms and language, and express dogmatic agreement. For instance, the person requesting the software can use terms or phrases in a meeting that can have more than one meaning to, say, the programmer on the other side of the table. The programmer who doesn't probe for clarification is most likely not picking up on this potential for misunderstanding. It's the BA's job to realize this (Identify the Ambiguity), diplomatically point it out, determine the requestor's intended meaning (Resolve the Ambiguity) and facilitate unambiguous communication with all stakeholders. It's as likely as not that they weren't thinking the same thing but even if they were, the BA needs to make sure the requirements leave no doubt on the issue.

How do you know when you've identified and resolved all the ambiguities? It’s when you can't find any more. The problem when you’re trying to detect the absence of something is you don’t know what it is and you only recognize it when you see it. But this is hardly a metric for zero ambiguity.

The point is to keep looking for ambiguities and stop after a while when no more surface. You use the time available in the project schedule for individual and formal reviews to bubble up ambiguities. Then you assume you still may have missed one, so you keep your ambiguity meter running throughout the project. When you support the requirements through the Design and Test Planning stages, other ambiguities may surface that you will need to resolve.

But one technique could be helpful and give everyone a higher comfort level in the requirements. It requires a separate task in the project plan: a formal review of the requirements. Some methodologies require it; others don’t or only give it cursory attention. We can ask stakeholders in the review meeting to state in their own words what each requirement means, requires. If unanimity still reigns after the review, we can be reasonably certain that we’ve slain all the ambiguity monsters.

But how do you pick up on the fact that people who seem to agree don't really understand each other? I could say, "You just know," but that's not an answer either. To me, this is a primary, indispensable skill in business analysis - and perhaps the most important. All I can do is list the skills I learned to detect a disconnection in others’ communication. It boils down to this: you have to learn the languages of the stakeholders and be aware of the pitfalls of translation.

And what are the stakeholder languages that impact software development? That’s the topic of the next post.

The Importance of Effective Translation

The BA should understand of the “languages” being used by stakeholders to communicate the requirements of the project – and understand how to translate from one to the others. Knowing how to translate ideas from one person’s frame of reference to another’s helps you detect ambiguity or a potential for misunderstanding buried in the conversation, which may not be perceived by those who are conversing. I can’t say that every BA should follow my path but here are the 5 “language” steps that I count as very formative in my BA career.

First, I took Latin in High School and minored in French in college. When learning a foreign language, you realize that word-for-word translation is usually not possible and that historical and cultural contexts give words different meanings, nuances and connotations. Translation attempts to determine and relay the intended meanings and nuances, not just words. The same is true of business communication and software programming contexts. Again, learning a foreign language isn’t a requirement of BAs but it can help.

Second, my college major was History, the study of which taught me the language of research: not just how to collect information but how to identify what’s significant & pivotal and what’s not, how to determine the meaning behind events, their sequence and causality, and how to organize that information for presentation to others. I learned how to be coldly objective as well as how to express opinions supported by solid rationale. I also learned how to decide what information to leave out or include based on its pertinence to the topic, as well as how to interpret events and determine whether a fact or statement is accurate and true. And it was important to learn whether stated conclusions are supported by the data or involve a leap in logic, and to detect bias in myself and others. A BA must be a careful and thorough researcher.

Third, my experience in programming taught me the language of software development. Sure, I learned how to write software: programs, macros, libraries, data structures, routines, and jobs. But more crucial was

learning how translate requirements and solutions into software, as well as how programmers think, what makes good software design, what makes good data design, how data structure can model business functions, and how data should be stored, processed, transformed and presented - depending on business needs. BAs don’t have to have programming experience but I count mine as invaluable.

Fourth, my master's degree in Business Information Systems taught me the thought processes and language of businesses, what's important to them, their objectives, concerns, the flows of their work and how the money follows the work. I learned that decisions that face the business require the support of data, metrics and KPIs, and how the collection, transformation and presentation of that data can render it reliable. Somehow a BA must acquire a solid foundation in business and especially be conversant in the terminology and work flows of the particular business the BA is supporting.

Fifth was a college course called Discussion. It dealt with the language of group dynamics, how leadership and supporting participants develop in their roles or degenerate to ineffectiveness, how to shift group process from conflict to collaboration and mediate differences, how to recognize, adapt to and leverage personalities so that the group becomes productive. In short, it was a course in group problem-solving, an invaluable preparation for the BA function as liaison.

_____________

Many BAs perform very well with backgrounds very different from mine; there's no one way to prepare for the role. But the ability to identify and resolve ambiguities and thus achieve mutual understanding requires at least these skills:

Recognizing when stakeholders are speaking different “languages” and knowing how to translate for their mutual understanding;

Knowing sound logic principles and how to identify and address reasoning unsupported by the facts;

Knowing how to research to obtain enough correct information to support conclusions and identify solutions;

Knowing how to communicate with programmers and those who will implement software solutions;

Understanding concepts of business in general and the business work flows the BA is supporting in specific; and

Skill in effective group process.

The Trickle-Down Economy of Mutual Understanding

There are at least three end-of-project indicators that software requirements have reached mutual understanding, two tangible and one intangible. The two most obvious indicators are:

The business is pleased with the software they receive and any defects are minor, easily addressed, and

The software is delivered in a timely manner – or none of the delays were due to misunderstood requirements.

A third, less intangible, end-of-project indicator of reaching a mutual understanding of the requirements is that project stakeholders come away with a deeper sense of common purpose - they understand each other better and cooperate better on future projects. This state of cooperation grows organically over time, one project at a time. It can't be measured but it's easy to notice.

Sure, a successful project relies on many other factors than just the BA performing the role effectively; all other participants must also perform their roles effectively. And some sets of stakeholders naturally get along with each other better than others, with or without a good BA on the team. It’s rare, but it occurs.

But a BA who has solid understanding of all aspects of software development and the knack to detect a lack of mutual understanding can learn to facilitate the other team members’ roles, to grease the wheels of the entire project.

I’ll also add my opinion that BAs who really want the stakeholders to understand each other, to get along and cooperate with each other, are the ones who are the most effective. A good BA has a “we” attitude that treats the project team as a team and helps them be a team. Those BAs will keep trying different methods of communication and translation until hitting on the right one that achieves mutual understanding.

_____________

An important strategy for project success is for team members to understand one another better and the BA is perhaps in the best position to facilitate that. When the team reaches Mutual Understanding Nirvana, the result is better cooperation and synergy, otherwise known as teamwork. And attaining that objective is the aspect of Business Analysis that gives me the most job satisfaction.

**********

Dan Shumaker is a Sr. Business Systems Analyst and consultant. He has worked as a consultant for the past 15 years and his IT career spans 30 years. He holds a Master of Business Information Systems degree from Georgia State University and lives in Colorado.