With the massive shift to working from home we now see a plethora of tech companies flogging new employee surveillance tools. You can readily see their appeal to command-and-control thinkers. If you think, as they do, that managing employee activity is crucial, then to know who’s doing things and who’s taking the mickey is grist to their mill. But these tools will undermine performance and morale.

Think about it from the employee’s point of view. Your boss can see your emails, any documents you read or create, your appointments, who you talk to, and when; can listen to or read transcriptions of your calls. Your boss can see your computer screen, can monitor your internet use, the sites you visit and for how long. Your boss can even turn on your camera and watch you at work.

Product configuration requirements are a specialized type of requirement when an information system supports product-related needs through data values. Where there are specific changes to business processes needed to sell and/or operate a new product, the requirements for the information system to support activities within those processes involve standard functional requirements.

Whether an information system can support a product though configuration or requires custom development, when an information system is involved there are standard pre-go-live activities that need to be performed (e.g. testing). Requirements support those activities.

A diagram is a 2-dimensional representation of a story, which shows elements and their relationships on a single canvas. An element is shown on a single diagram. (To show the same element information on a 2 diagrams, the element is duplicated.) When the properties of a diagram element are changed, the change is reflected only on that diagram.

A model is a 3-dimensional representation of a collection of related stories, which captures diagram elements as model components. A component includes all element properties and relationships between different elements on all diagrams. A single model component can be shown as elements on several diagrams. A change to the properties of a diagram element or model component is reflected on every diagram where that component is displayed.

A model does not necessarily need to include any diagrams. Diagramming is the most common method for creating and maintaining model components, but the diagrams can be deleted without changing the model.

If a picture is worth a thousand words, then a diagram converts those words into a story. A model organizes those stories into a book.

How can we ensure that as Business Analysts, we are seen as an essential service for our organisation? It was a really interesting question. I thought I should elaborate on my answer I gave and write this article. I thought it will be helpful for:

a) Business Analysts to understand how they can operate within their organisation during this stressful time and
b) Companies to realise the value of Business Analysts and how they can use them to their advantage.

I wish to focus on explaining the reasons why a company should hold on to Business Analysts and leverage their skills in a way that will help them through these economically challenging times due to the pandemic.

Business analysts should bring more than an ad-hoc or experience-based business process modeling competence to digital transformation projects.  This article explains why and practically, how.  Here are 5 ways to improve your business process modeling competence and become better prepared for producing high-quality business process models that serve digital transformation projects

The reason to bring this up here in this post is to talk about the business analyst's role as a navigator. How good we are as navigators? In helping the conversations and collaborations? In writing the specs? Business analysts ensure that the system is being on the desired path and not on the exception path! I am sure we can argue that we want to build exception paths, errors, and scenarios that break the system. It is true. If we observe everyday linguistic patterns, there is a natural human tendency to talk about what we do 'not' want. Whereas what we 'want' is something that needs to succinctly be delved into. Is this a clever play of words? No. It is about utilizing 80/20 rule in thinking through what process or system you want to build. 80% on where you want to do and 20% on what exception and roundabout scenarios you can expect of. Let's take a few simple examples as we relate this to a business analyst's role.

Culture determines how people behave. If you want to change behaviour, you have to look to changing the culture. This is the story of how we changed the culture of a team of business analysts.

We inherited this team; they worked in an organisation where the culture was pretty poor. People were uninterested in their work. They resented the time they spent at work; they cheated on timecards; they simply did not do any work whenever they thought they could get away with it. Naturally enough, performance and productivity were abysmal.

Software handovers between teams and individuals in any ecosystem can be a minefield, often threatening to disrupt continuity and harmony across teams and organizations. In most cases, handovers result in knowledge loss, which in turn leads to chaos and time wastage when a critical issue hits the system. As a business analyst (BA), you will invariably be a part of the process, both at a junior and senior level. It is better to be fully aware of the complexities and pitfalls associated with taking part in a handover. You’ll eventually be able to apply some best practices to navigate around it (some of mine i hope and some of yours based on your context and area of operation).

How do we know when a user story is “done“? Can we say that the user story is done when it is coded and all acceptance tests for it are passed? Business representatives may say yes, but they do not know all the peculiarities of software development. So, such criteria as quality are not fully visible to them.

Or let’s have a look at another situation: a new feature that changed the business process was developed and tested according to the best software practices, but users struggle to use this feature because they are not sure about the changes this feature brings. Maybe a proper user manual or user training is needed in this case?

In this article, a simple, but very powerful technique which is called Definition of Done (DoD) is explained.

As mentioned in my previous article Three Myths About Data Science Debunked, sooner or later business analysts will be involved a project with a machine learning or AI component. While BAs don’t necessarily need to know how statistical models work, understanding how to interpret their results can give them a competitive advantage.

This article discusses three concepts that can help analysts add value to data science projects (future articles will cover additional ones). Cultivating skills in these areas will increase your ability to build cross-functional alignment between business and data science teams and prevent bad decisions based on flawed analyses.

What are the most common elicitation challenges? This is one of the most discussed topics from my business analysis training sessions. A business analyst extracts information in various forms, from various sources, and transforms those findings into requirements and design artifacts. Let’s take a look at some of the common challenges during the elicitation process and how to address them.

Integration requirements are critical for any Project’s success when Business Processes flow across multiple systems. As a Business Analyst it’s our responsibility to understand the end-to-end Business and Systems Process flow and document the hand off as part of the requirements gatherings process. A systematic approach to gather the requirements for integration between systems will ensure that there is a smooth interaction between the systems and hence the Business Process flow. The below Framework on Integration Requirements Analysis provides a systematic approach to document requirements for an Integration Project

In all my years as a Consultant Business Analyst, having reached a level of proficiency, I have realised that being a business analyst is seldom about the hard skills. In fact, it is more about the soft skills and BAs who operate at that level are more impressive and effective in their job. Hard skills like documentation, requirements elicitation, process maps etc. are easily taught and acquired but the soft skills are developed with experience and the right attitude towards this role. Over time I feel the perception of the value of BAs has diluted and I blame those who have been superficial about performing this role. Those who think their role is just about the tangible artefacts like the business requirements document, process maps, business case, etc. Those who think they are here to deliver a project and nothing else. Those who think the BA’s job is to take orders and execute. But the fact is that the role of a BA is a lot more subtle than one thinks. There is a much broader aspect to this role, which is often forgotten, and we get caught in deliverables and artefacts.

Let’s look at some aspects of this role, which are common knowledge and broaden our perspective of that. When the mindset of the Business Analyst changes to the bigger picture and to the more delicate facets to this role, you perform much better as a business analyst and are a more reliable and thus a desirable professional for companies.

My experience taught me that the Scrum process framework is not the complete story. Scrum does not identify roles for the business analyst, system architect, tester, UI designer or deployment engineers. Instead, the work normally performed by these roles is performed by the development team or the product owner. It is possible that the Scrum development team includes people with all of these skills, but the problem is that all the development team work is performed within a sprint cycle. The only activity that Scrum identifies outside a sprint cycle is maintenance of a product backlog (and even then it is not documented as an activity in the Scrum framework).

Ever wondered how to write foolproof acceptance criteria? Or even wondered what a business analyst can do to ensure that requirements are testable? Acceptance criteria define the minimum requirements the solution must meet. A business analyst plays a key role in defining the tests around it. The acceptance tests can be at various levels of requirements detail. Starting from high-level requirements to detailed requirements. Let’s take a look at common challenges involved in this part of the world, along with a few ideas to overcome those.