A Philosophy of IT Business Analysis
The Importance of Mutual Understanding
I work in software development as an IT 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 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 in understanding are usually 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 that they purge development staff, abandon the whole project or outsource it – all for a want of mutual understanding that went undetected.
A BA can achieve that 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.
Knowing when mutual understanding has been achieved is the Art of IT Business Analysis, behind all the use cases, diagrams and documents, and no less critical. But how do you facilitate mutual understanding and how do you know when you’ve achieved it?
The Significance of Ambiguity
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 content of those deliverables. One stakeholder’s concept of a requirement may not match that of others, even though they express dogmatic agreement. For instance, the person requesting the software can use terms or phrases in a meeting that 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), point it out and facilitate and find out the requestor’s intended meaning (Resolve the Ambiguity). It’s as likely as not that they weren’t thinking the same thing. Even if they were, the BA needs to make sure the requirements leave no doubt.
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. However, all I can do is tell you how I learned to detect when there’s a lack of mutual understanding: you have to know the languages and the pitfalls of translation. (To me, this is a primary, indespensible skill in business analysis – and perhaps the most important.)
The Importance of Effective Translation
Four ingredients of my background, along with a level of OCD that is sometimes annoying, have made me more sensitive to ambiguous communication. First, I took Latin in High School and minored in French in college. When learning another 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 relay the intended meaning, not just words. The same is true of business and software programming contexts.
Second, my college major was History, the study of which taught me how to research, to seek patterns and meaning behind events, their sequence and causality, and to organize that information for presentation to others. But History is not just a collection of dates, names and places. Most historians allow their own bias and background to affect which events they leave out or include, how they interpret them, and deciding whether a fact or statement is pertinent, accurate and true. The influence of bias exists even when they have no agenda and strive for complete objectivity, which is more rare than we’d like to think.
The same is true of the authors and audiences of business communication. The process of collecting and interpreting information, and determining what’s pertinent and the level of its significance, are all shaped by prior experience and knowledge. We must extrapolate constantly from them to new contexts.
Third, my years spent learning and writing the language of software – programs, macros, libraries, data structures, routines, jobs – taught me how programmers think, what makes a good design and how data can and should be stored, processed and presented, depending on… a lot of things. And fourth, my master’s degree in Business Information Systems taught me the language and thinking of businesses: what’s important to them, their objectives, concerns, work flows and how the money follows the work. Again, languages with concepts, nuances, and connotations – and lots of potential for misunderstanding.
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 ambiguities, to know when mutual understanding is absent, is crucial in any communication, and particularly in business analysis. The above components just happened to be what shaped that ability in me. When we identify and resolve all the ambiguities, mutual understanding emerges. How do you know you’ve resolved them all? When you can’t find any more.
The Trickle Down Economy of Mutual Understanding
There are at least three end-of-project indicators that sofware requirements have reached mutual understanding, two tangible and one intangible. The two most obvious indicators are that the business is pleased with the software they receive and it is delivered in a timely manner. Delays may be due to poor planning, estimates or resource allocation but more often they result from unidentified misunderstandings that surface only in testing.
A third, intangible, end-of-project indicator of reaching a mutual understanding of the software requirements is that project stakeholders come away with a deeper sense of common purpose – they understand each other better – and that yields better cooperation on future projects. This state of software development nirvana grows organically over time, with each project. It can’t be measured but it’s easy to notice.
Sure, a successful project relies on many other factors and on all participants performing their roles effectively. But a BA who has deep understanding of every aspect of software development and the knack to see a lack of mutual understanding can perform as BA in a way that supplies what others need to do their jobs well. And since the primary objective is that team members understand one another better, the BA is in a great position to facilitate better cooperation and synergy, otherwise known as teamwork.
Do you need this kind of BA, this level of facilitation and quality, in the software development projects at your company? I can help you achieve it. Please contact me.
Don’t forget to leave your comments below.