General Business Analysis

After doing business analysis in the tech industry for ten years, I’ve spent the last 2 years as a product manager. During this period, I’ve realized there’s more in common between the roles of IT business analyst and product manager than I had expected. On the other hand, there are also some aspects of the job that translate into valuable lessons for any BA interested in increasing the value they deliver to their organizations...

Whenever I mention I am in the "Systems" business, people generally look at me befuddled, smile, and shake their heads. I can tell they haven't got a clue what I am talking about. Many assume it has something to do with computers, and those in the technology sector assume I am referring to software. Frankly, no.

This article provides an in depth study on the concept of traceability, together with its implications and applications within a business context. Traceability is a term used in the IIBA BABOK, among other professional practices, in the context of requirements where requirements are said to be traced that provides alignment of requirements to each other. This implies that there are different classes or abstractions of requirements such as stakeholder, business and functional requirements. Traceability allows the alignment between all types or abstractions of requirements, telling a kind of story to how they all interrelate. 

Solution Anthropology encompasses the work of anyone who works directly with the end users so the work is coordinated and consistent. Therefore Solution Anthropology is not one role, but a team of people with the responsibility to delight the end user and a broad skill set to accomplish just that.

Observation as a tool is used to understand people and their environments. It is a tool best used not in situations where we are verifying fairly well-understood information, but rather in situations where we do not really know what we are looking for. Observation is not about validating assumptions, but rather is a tool to find out what we don’t know that we don’t know. Observation should bring out the surprising and the unexpected. Of course observation has a purpose. But the purpose can be fairly broad.

So many BAs complain that their role is under-appreciated, and that their voices are not heard when they have a recommendation for the business stakeholders or the delivery team. In these types of organizations, explaining the true BA role can be an uphill battle.

This article looks at practical experiences of implementing business rules using TDM and SAP from several angles, while also raising some of the questions which I find asked most frequently and insistently in my work, such as:

• Why do I need anything other than an existing rules engine to define and manage business rules?
• Why would I want specialized tooling for business rules when I already have tooling for requirements gathering?
• How does improved business rules definition help me with testing?

In parallel with my consulting work, I teach an online course for business analysts on writing better requirements. Invariably, the most skilled participants of the course are the ones who seem less confident when submitting their assignments. “Please let me know if this is not what you expected”, or “I hope I understood the assignment correctly” are phrases I typically get from these participants, while the weaker BAs typically write “here’s my assignment for Lesson 3”, without any caveats.

I’ve had the great pleasure of working through audits with the business I support over the last 2 years. It’s been a journey for sure and as regulators, internal audit teams and testing teams work to ensure that are processes are solid. First, let’s start with what does this word compliance mean? Compliance means conforming to a rule, such as a specification, policy, standard or law.

 

In this article, we discuss three of the basic elicitation techniques used in business analysis in order to obtain the requirements for the system being designed: Interviewing, Job Shadowing and Facilitation.

2015 has kicked off and most of us are already fully entangled in the daily grind. Unlike people, projects show no sign of a ‘getting back into the swing of things’ period. The pressure keeps building as organisations are pushed to keep up with industry in order to stay competitive and profitable. So what does 2015 have in store for us? My view is that the following 4 trends can be expected to be prevalent for Business Analysts during the year.

With 24-hours a day, unceasing news being forced in our ears and down our throats, with computers that blog, phones that text and everything that twitters, we have information rushing back and forth at us at speeds that can only be measured in nanoseconds. It is information on steroids and it can and often does get us in trouble[1]. Analyzing, corroborating, vetting and authenticating this rush of information, misinformation and hyperinformation are at times almost impossible.

More successful business analysts seek out feedback, face tense situations head-on, and actively pursue new challenges. While they don’t necessarily like to fail, they trust in their ability to bounce back so they choose the difficult over the simple.  It’s not uncommon for a successful business analyst to need to navigate any of the following situations, with grace.

The question of efficiency in business analysis and, what is more, of potential obstacles that prevent an analyst from being efficient, has always been considered very important. It goes without saying that there are some more or less objective reasons that prevent analysis from being done properly... There are however some types of problems that are caused by not so obvious reasons.

The purpose of this article is to show the expansion of an existing Business Process Model and Notation (BPMN) model due to an increased interest in a partner’s processes.  In a previous article, I developed a BPMN model on a home medical process associated with peritoneal dialysis. In that article, I modeled a process, Ship Dialysis Equipment, as a black box pool;