General Document Skills

What do you use to compile requirements documentation? Microsoft Word. How about requirements sessions and presentations? Microsoft PowerPoint. Number crunching and data analysis? Microsoft Excel. Flowcharting and diagramming? Microsoft Visio.

These are merely examples, and there are other tools that can accomplish these tasks just as well. The key takeaway is that as a Business Analyst, you are expected to have a solid working knowledge of these tools on day 1 of a software development project.

What You Need to Know

I have yet to encounter a Business Analyst who is mediocre at using the Microsoft Office Suite of tools for documentation purposes, and if you are that unusual mediocre one, you can easily skill up in a few hours. A good way to, for example, upskill your Microsoft Office Suite skills is to review past documentation (if you can find it) and build on it.

You may feel like a bozo lost in the Word, Excel, PowerPoint, and Visio maze, but proficiency in this must-have skill is also the easiest to improve. There is a wealth of online resources that can be used to learn documentation skills, and depending on what needs to be learned, it can take anywhere from a few hours to a few days.

Software Development Methodologies Knowledge

While this is not a skill per se, it is important to know the differences between the major software development methodologies (Waterfall vs. Agile) as well as understand how they work. The mechanics of these software development have been explored in Chapter 2. As detailed in Chapter 2, a Business Analyst ought to know what software development methodologies are and more specifically the differences between Waterfall and Agile.

What You Need to Know

The methodologies in use on a project have direct impacts on Business Analyst deliverables and overall project delivery. Grasping the methodologies is a low-level effort, and the more projects a Business Analyst accomplishes, the more they are exposed to the finer details of software development methodologies.

Software Development Life Cycle Knowledge

This concept is also detailed in Chapter 2 and uses a case study that illustrates how the Software Development Life Cycle works on a real project. It refers to Business Analysts’ knowledge of the framework that governs the process of software development. Under this framework, the development of a software product goes through these phases or some variation of these phases: Analysis, Requirements Planning/Scoping, Product Design, Product Development, Testing, and Deployment (or Go Live/Product Launch).

What You Need to Know

This is an important concept that a Business Analyst should be familiar with. It’s also a straightforward one to learn and understand. Understanding this concept is enhanced with every additional software product development project a Business Analyst undertakes.

Technical Writing Skills

Technical writing has diverse practical applications in wide-ranging fields from technology to medicine to manufacturing, and it’s concerned with simplifying complexity.

The main purpose of technical writing is to convey technical concepts in a format that can be easily understood by consumers of the information. The format it takes usually depends on the presenter, the audience, and the material being presented. Ultimately, it’s best to accompany technical writing with illustrations, charts, screenshots, or process flow diagrams.

Technical writing is very useful during requirements scoping for it is important to communicate the desired outcomes without leaving gray areas, ambiguity, or confusion.

When a Business Analyst presents a requirement that is, for example, interpreted differently by different technical team members, then the technical writing has not effectively communicated the intention of the requirement. To be more specific, a software developer should review a requirement and be left in no doubt about the intention of that requirement.

Technical writing that clearly conveys the message in a communication gets everyone on the same page and saves a lot of time spent rewriting and clarifying that intent. Conversely, unclear technical writing creates holds up in the development life cycle as technical teams spend more time seeking clarifications. In extreme cases fuzzy technical writing can lead to the development of a product far removed from what end users asked for.

Business Analysts also need to be skilled technical writers when they draft end user instructional manuals as end users require this information in a writing style that they will easily understand

What You Need to Know

This is a learned skill, and there are bottomless resources on how to become an ace technical writer who delivers technical concepts using brevity, simplicity, and precision. Depending on the background of the Business Analyst, learning technical writing can be seamless, or it can take a while to become a well-polished skill. Business Analysts who have previously worked in sales/business operations or worked with IT/technical teams seem to have the lowest barriers to learning technical writing, but anyone can still master technical writing by self-practice and referring to online resources.

Creating Use Cases

Use cases consider the scenarios or situations where a software product or application is used by end users. At their most basic level, use cases define a set of interactions between users and systems in a given setting.

“What is the business use case for this requirement?” is a frequently asked question during requirements scoping phases and requirements discovery sessions.

The intention of such a question is to check that the scenario being discussed is valid and has been experienced by the users who are requesting changes to a system, process, or software product.

Consider a discount approval process that requires three managerial approvals. To sales teams this is an unreasonable process, and as a use case, it demonstrates why the process needs to be shortened, maybe by removing one manager from this process.

What You Need to Know

Use cases are a powerful tool in understanding why change is needed, a must-have asset for any Business Analyst but also an easily learned and understood concept. There are many reference sources online that Business Analysts can use to upskill use case knowledge.

Analytical Skills

This falls in both the technical and non-technical skills areas—technical because a Business Analyst will analyze an end user problem and the data supporting it and either devise a solution or builds a case for a solution.

It may be non-technical analysis in that it involves scenario building and the likely impacts on users and processes then devising strategies for end user acceptance of the solution.

As a Business Analyst, you need analytical skills so that you can review an issue and methodically, logically, and creatively work toward a solution while noting the potential impacts of the solution. It may sound like simultaneously juggling many balls, but we do this all the time at work and in our personal lives. Analytical skills will be reviewed in Chapter 8 as part of Creativity and Problem-Solving Skills.

What You Need to Know

This is a skill that comes with experience, and after spending considerable time in the trade, using the analytical muscle becomes second nature.

Database Knowledge

Databases are an essential pillar of how software products and applications work, and it’s important to have more than a passing knowledge of what they are and what they do.

In lay terms they are Excel like applications that store vast quantities of data points running into the millions. When an end user interacts with a software product or process by doing any type of data entry or data retrieval, just know there are many database functions going on in the background.

What You Need to Know

As a Business Analyst, you need to know the purpose and function of databases.

Most software development projects will at some point interface with changes to a database which could be data inputs, data retrieval, data storage, data analytics, and how different users access data. A few hours on Google will give you the critical knowledge you need for this key technical skill.

Data Analysis

Closely following on database knowledge is querying or searching the data inside databases using tools like SQL (Scripted Query Language). SQL queries extract data for export and consumption by end users like Business Analysts and other project team members. This is especially useful if you need to query large data sets to support business decisions or query datasets as part of software product testing.

Do you need to be a SQL expert to be an ace Business Analyst? Not at all.

While not all projects require SQL skills, some basic level of data querying knowledge is required as different software products on projects come equipped with reporting and analytics capabilities that can be used to query datasets.

To my mind it’s more important to know where the data you need is located and how you will access it instead of brushing up SQL skills you will likely never use on a project. If you know how to run SQL queries, that’s a great asset to have on a project especially if there is a need for it.

Conversely if you lack SQL skills and they are required on your project, you can acquire them in no time from a variety of online resources and public libraries. In general terms, even if you have zero SQL skills, there is no need to panic as depending on the project, you can still access and interpret data without running SQL queries.

Lately there are a number of powerful business analytics, dashboarding, and data visualization apps that not only help with generating large datasets but more importantly provide meaning and interpretation to those datasets. Data analysis is a wide discipline, and learning it takes some focus as well as dedicating a few hours for a couple of weeks to get a feel for how to use it depending on the requirement or the project.

What You Need to Know

Data analysis is a key component of the Software Development Life Cycle. Depending on the software product they are working with Business Analysts need to know how to access data for analysis and validation. What is important for this must-have skill is understanding how to access the data and its subsequent interpretation.

Process Mapping and Business Process Modeling

It is a general-purpose technique that visually illustrates a process flow, business workflow, or data flow. It can also be used to illustrate how different systems and process segments are related as well as how they deliver inputs or outputs to each other (see Figure 3-1). The main purpose of a process flow is to illustrate visually disparate process interconnections and relatedness.

Some requirements are best explained by showing project stakeholders a process map or diagram instead of verbalizing it. While the Microsoft Office Suite (especially Visio) is well equipped with process diagramming tools, there are many newer process mapping apps that are just as capable.

What You Need to Know

Process diagramming is a basic but essential tool in the Business Analyst toolkit for it puts the visual into the verbal and simplifies hitherto complex concepts. This is another easily learned technical skill that mostly requires practice to get a grip on it. There are also abundant online resources that provide instruction on learning and improving the use of process mapping.

Entity Relationship Diagrams (ERDs)

ERDs may look like process maps, but they are more focused on visually illustrating how the entities of an information system or data model are related to each other (See Figure 3-2). ERDs have their origins in the early phases of database development where they were developed for modeling databases.

While they are still used for data modeling, ERDs also have wider applications like illustrating information systems and the relationships between different entities and attributes. As an aside, ERDs use specific data modeling notations (for example 1..1 in the figure) that relay meaning to the different aspects of a data model or information system.

What You Need to Know

ERDs may not be easy on the eye at first glance, but users can become adept at using them if they repeatedly draft or interpret them. This is not a must-have technical skill, but you can be certain that at some point in your Business Analyst career, there will be a need to interpret an ERD diagram. Knowing when to use ERDs will put you in a good position when that time comes around. Just like process mapping, there are many online resources and publications that provide instruction on how to use ERDs.

Data Mapping

Data mapping is documentation that shows how data is mapped from one information system (or data model) to another information system (or data model) (Figure 3-3). You can take this advice to the bank: migrating and integrating data are processes that should never see the light of day without data mapping in place.

In its simplest form, data mapping is a guide that states how data points in an originating system are mapped to similar data points in another destination system.

It may for instance state that Point 3 in System A will send the data it collects to Point 3 in System X. In simple terms, if System A is shut down, the data will still be available in System X, and users can check Point 3 in System X to retrieve it.

This is a very vital component for data migrations. Mismatches or the lack of data mapping results in incorrect mappings that can severely compromise the quality of data in a data model or information system.

What You Need to Know

The first time I was asked to do data mapping, I went into a cold sweat for it was so intimidating and technically exotic. It turned out to be much easier than I thought. Don’t let the term fool you; it’s exactly what it is: data mapping between two information systems—an important skill that you will require if your project intends to work with data migrations and integrations.

Data mapping is mostly learned by doing, and in the event that a Business Analyst has zero data mapping knowledge, they can use online resources and data-related publications for upskilling which shouldn’t take more than a few hours.

Product Testing

This covers basic knowledge about quality assurance (QA) and the role it plays in software product development. Business Analysts conduct product testing before formal User Acceptance Testing which is testing by end users or the eventual owners of the software product. As previously mentioned in Chapter 2, it is best practice for Business Analysts to test any product that has been given a clean bill of health by the development team before it is handed over to end users for testing.

What You Need to Know

Product testing is exactly what it means: you get to test whether a software product works as intended by the initial requirement. For Business Analysts the purpose of product testing is to validate that the delivered product meets the need that was requested by the requirement. This is a must-have skill that can be learned on day 1 of a software development project; it’s that easy.

Wireframing and Prototyping

This refers to the “likeness” of a software product. As an example, it may be a sketch of a web application that shows the different web pages, or it may be a sketch of a web page that mimics a page on a web site. As with data analysis there are several prototyping apps that use color, content, and graphical elements to give a prototype or demo a richer life as well as a more realistic feel. Business Analysts with graphic design or photoshopping experience tend to shine when prototyping is required.

What You Need to Know

This is a great tool for demonstrating software product concepts to end users or audiences without information technology backgrounds. Prototyping is another skill that grows by practice, and learning it is largely dependent on the tool used by a Business Analyst as some tools are easier than others to use.

Project Management Skills

I have held both Business Analyst and Project Manager roles on the same project in a previous life, and it is important to understand that while the roles overlap, they are different. These are the instances when Business Analysts will occasionally wear the Project Manager’s hat.