Within scores of projects scattered over the last twenty years, I have been forced to think long and hard about the challenges that face organizations as they try to make sense of their businesses and to determine how technology might be leveraged to make things better. More recently this has led me to consider how the practice areas of Business Analysis and Technical Communication might be fruitfully coordinated to realize improved project results.

In particular, I have been thinking about how the skill set of the effective technical communicator may be an important asset for organizations to tap as they are forced, in an increasingly systemized world, to formalize their products and processes. Coming at the question from the other direction, I have been thinking about how the focus of business analysis, falling as it does on the tools and techniques that organizations can use to understand what they are doing and how they can do those things better, touches on subjects that technical communicators need to take on board in order to play a more complete, and more fully integrated, role in the product and process lifecycle.

I have touched upon aspects of this topic in a couple of previous posts: Intelligent Content and the Future of Technical Communications and The Curious Case of Business Analysis. The latter of these posts managed to get me into some trouble with the advocates and guardians of the Business Analysis practice area.

The premise that I am venturing on this occasion does not strike me as one that is at all controversial. Indeed, it strikes me as quite in line with the directions that one hears discussed within the respective communities of business analysis and technical communication. There are a number of tasks that need to be performed if an organization is to fully understand the requirements to be addressed, the capabilities available to respond to the needs, the opportunities that exist for improvement, and the operation and support of the products and processes that are accordingly put into place. Underlying everything is a single, common thread and that is "communication".

At every step in the business analysis activity, the task at hand is to gain an understanding of the plethora of details that invariably appear and to distill that understanding into forms that the numerous stakeholders can grasp and work with. In an increasing number of cases, formalized methods and tools exist or are emerging to provide ways to capture these details in a way that is suitable for use by system designers and developers. But in all cases there is a call for the ability to make the details accessible to people who need to understand things at a higher level. This latter group of people are important because they are made up of business executives on one hand and the all-powerful customers on the other.

As I mentioned, there is nothing controversial here, or at least I don't think so. The Business Analysis education programs I am aware of (including the one I undertook as a research project) place communication skills pretty prominently in their curricula and do so for good reason. Similarly, the technical communicators that I have encountered on countless projects are people who are skilled in documenting and illustrating complex details about products and processes. These technical communicators have also impressed me, time and again, with how much they come to know about the products and processes they are working with. This fact should not surprise us really when you think that these technical communicators provide one of the key connection points between the products and processes and the community of users who participate in training sessions, raise questions, identify problems and provide feedback. 

My point, modest as it may be, is that technical communicators possess a few things that organizations could be leveraging more effectively. One is that they are, first and foremost, people who excel at communicating complicated ideas. Making complicated concepts accessible is brutally hard work, as every business analyst will affirm from bitter experience. The second is that technical communicators, by virtue of their role as mediators between the people who have created the products or processes and the user community to which they are offered, come to have a unique and very valuable perspective on those products and processes. They come to see with the eyes of the users and when you come to appreciate this fact you realize just how valuable their knowledge is to the organization.

How then does this connect to my premise that organizations stand to benefit by more closely aligning the practice areas of business analysis and technical communication? Simply stated, if organizations come to recognize that their technical communicators possess valuable knowledge, then they need to consider how to plug that knowledge into how they come to understand, and continuously improve, their products and processes. Now this is typically the function assigned to business analysts. With this connection made, it is then a small step to see that the skills and knowledge of technical communicators are very much aligned with those one looks for in a good Business Analyst - and specifically the ability to facilitate effective communication.

Going a little further, we could suggest that organizations ultimately need to gain a more holistic understanding of their products and processes and that, one way or another, they must find a way to shorten the path between the needs and experiences of the end users and customers and the designs and plans that guide the evolution of products and processes. This premise remains valid in each of the two ways that one can see the practice areas of business analysis and technical communication being aligned.

One scenario sees business analysis as an integral part, and extension, of the Information Technology (IT) group (literally as its outreach arm that seeks to engage the business stakeholders more effectively). Under this first scenario, the technical communicators are seen as hailing from the business side and acting as a key touch point that business analysts work with to build up their understanding about the requisite business products and processes. Another scenario sees business analysis as an activity undertaken by the business community and performed as the way the business side pursues both its ends and communicates its needs to the IT community whenever systems need to be put into place and managed (which is effectively always). In this second scenario, the technical communicators can be seen as evolving into roles on the business side that increasingly fuse the responsibilities of business analysis and technical communication.

The latter of these two scenarios, where business analysis and technical communication are tightly integrated activities performed on the business side and applied with a view to facilitating and optimizing product and process lifecycles, is to my mind the most attractive. This assertion may well see me stumble back into controversy but I would stand by it nonetheless. I believe that the time has very much come for the business side of organizations to take full possession of their products and processes (as in establishing and evolving a clear understanding of these assets and the environments in which they are deployed) and to take on a much more complete responsibility for articulating, in a formal and disciplined way, the requirements for the supporting information technology.

Under the preferred model, the tasks of business analysis and technical communication are seen as fully intertwined and as being deeply embedded in all stages in the life of products and processes - market research, needs analysis, usability planning, requirements engineering (identification, definition, validation, prioritization, valuation, elaboration and management), product and process design, testing, documentation, training, community building, feedback facilitation, support, and retirement. It is not hard to see the emergent role as effectively providing the eyes and ears for the business and as supplying the understanding that really is the life blood of any sustainable organization.