Skip to main content

Tag: Business Intelligence

Forget SMART, Aim 4A Goal!

The SMART acronym is considered best practice for objective setting, yet somehow objectives which are ‘made SMART’ become uninspiring and unintelligible.


We are told that individual, team and organisational objectives need to be SMART (Specific, Measurable, Achievable, Realistic/ Relevant, Timebound). For the most part, goals and objectives should be something we set because we want to achieve them, but when we cryptically re-word, strip back to the specifics, take out the inspiration by dialling down to realistic and attach an (often) arbitrary deadline, they seem to lose their appeal.

How can we create goals we are actually inspired to work towards? By simplifying the processes and asking ourselves good questions.

Aim 4A Goal

4A is Achieve/Avoid/ Action Analysis. By creating an engaging table or diagram we can frame a goal that motivates us, identify what we need to be aware on pursuit of that goal and identify the next steps towards achieving it. Notice that is next steps, not every step. It is impossible to predict the future, but we can usually identify the activities which are a step in the right direction of the goal, even if we cannot yet see every move we will need to make.

Here are some of the questions to help to understand the goal and how to get there.


It’s difficult to work out what your goals are, it may need some dedicated time and a few false starts to get to the real goal(s).

  • what do you want to do?
  • when do you want to do it by?
  • why?

It’s ok to aim big, it can be broken down into steps, many of which you might not know yet. It’s also fine to have a very narrow scope, that can be achieved through a very small number of actions. The key is to be sufficiently motivated to do the actions!


Most things can be achieved, with enough time and attention, but at what cost? In the pursuit of goals we must consider the things which might distract us, and also the things we are unwilling to compromise on to achieve the goal.

  • what are the potential pit-falls?
  • what might get in the way?
  • what might be the unwanted impacts (on myself and others)?
  • what do I need to ensure I don’t neglect, in pursuit of this goal?
  • what risks am I unwilling to take?
  • what behaviours am I unwilling to engage in?
  • who might prevent it? (be honest).


Just as important as planning the things we will do, is to identify the things we will have to give up or are unwilling to do.


Actions need to be tailored to address the goal, and avoid the issues identified. If we don’t highlight the things we want to avoid, we may take the wrong actions.

  • what can I do right now that moves me closer to my goal?
  • who can help or advise me?

For every action we take, we can ask “Is this contributing to my goal?” If not, we may still choose to do it, but consciously rather than inadvertently. Add actions to the list as they become apparent, and the next best step to take.

Example Goal

Achieve: Speak at a conference or event in the next 12 months.

Avoid: Excessive travel costs, impact on my project work.

Actions: Identify local events, find out submission process and deadline, develop sessions ideas at weekends.

When these actions are complete, identify the next steps which move towards the goal.

Decision making

Achieve/Avoid/ Action Analysis (4A) is also incredibly useful as a decision making framework. It helps keep everyone on track – “what are we trying to accomplish with the outcome of this decision?”, “what impacts don’t we want”, “what possible actions achieve the outcome and avoid the impacts?”. Often group decision making is difficult because people are not trying to achieve the same thing from the decision. Using 4A give the opportunity to build consensus on what we are working towards, address concerns via the ‘avoid’ list and jointly agree the actions which best hold the ‘achieve’ and ‘avoid’ elements in balance.

Example Decision: “Shall we reduce the training budget to save money?”

Achieve: Cost savings of X in this financial year

Avoid: Impacting staff morale, having people who do not know how to do their job, impacting customer service.

Actions: Investigate online delivery options, prioritise the training needs, defer some of the training, use train-the-trainer approach.


SMART has had its chance, and it wasn’t helping. Set goals that inspire and motivate you, work out what you need to avoid in the pursuit of those goals, then develop a plan to achieve them.

We also need to accept that we may need to change our goals. We may decide we don’t want to achieve what we once thought was important. Don’t work towards something you no longer want, just because you wrote it down or told a few people. In that case, Aim 4A New Goal, work out what that looks like, what you need to avoid, and what next step you can take.

Improve Collaboration by Understanding Natural Human Instincts

Last January, I was lucky to have an article posted right here at BA Times.

How To Get Requirements From Resistant SMEs Part 3. It is about what to do when your SMEs clam up. It mentions using a person’s natural human instincts to get them talking. One of the hardest things to do as a professional is to put theory into practice. I have been asked several times this year to elaborate on what I shared, by giving examples or case studies on How.

First let’s do a quick refresher, the FBI and Homeland Security states that these are the natural human instincts that trigger people to share information.

  • A desire to appear well informed, especially about our profession
  • A desire to feel appreciated and believe we are contributing to something important
  • A tendency to expand on a topic when given praise or encouragement; to show off
  • A tendency to correct others
  • A desire to convert someone to our opinion

Part of the reason people struggle with practical application is because you have to create a scenario that triggers someone to act on their instincts. I will share several examples or case studies that show you how others have successfully applied these techniques.

A Desire To Appear Well Informed

1. In larger groups, meetings, or messages

  1. “Jack, it has been a few weeks since our last show and tell, before our developer shows you wants coming up, why don’t you give us a quick summary of how our last release helped your team?”
  2. “Today is all about coming up with new ways to help our production support team reduce their backlog of support tickets, before we get started, Harry can you tell us what solutions or bandaids your team is already using?”

2. In small group conversations

  1. “James, have you met Nicki? Nicki you can explain what your team does better than I can…”
  2. “Ok I include the two of you in a half an hour meeting before the brain storming session. I was hoping that the two of you, who have a vast amount of knowledge, would mind talking through the most important points before the team got here, so that the meeting has a bit of a head start.”
  3. “Milly, we are about to go into another grooming session…which is going to end in you having to make all of the decisions any way. Can you do a quick pass before the meeting so that we don’t waste time going into detailed conversation for something you already know the priority for?”


A Desire To Contribute or Be Appreciated

  1. “Jonas, I just got out of a planning meeting and they finally approved us to start working on the improvements you guys have been asking for. Would you mind being my goto expert? I need someone who can help me focus on this from a user’s point of view.”
  2. Meeting Invite: I know we normally have James, Calvin, and Sanya in our kick off meetings but I have also added Stacey. I have noticed that when a lead from UX is involved from the beginning, we spend less time reworking usability issues from user acceptance.

A Tendency to Expand On A Topic

  1. “Greg that seems important to talk about, but not here in stand up. Why don’t we finish up the daily meeting and then can most of you guys stay on the line so Greg can explain the issue in detail and we can decide as a team what to do.”
  2. “Jeremy, let’s switch gears for just a minute. Instead of starting with a list of changes, can you tell me a little about what your team has accomplished recently and what they are looking to accomplish and improve on in the next cycle?”…”Ok now can we map those goals and accomplishments to the items in the list to see which ones should float to the top?”

A Tendency to Correct Others

  1. “So I hear your team would rather start from scratch learning a new system, than deal with the issues you are dealing with today.”
  2. “I am telling you the report is wrong, everytime I rerun it, it looks exactly the same!” “Oh so you are saying the report should always change each time you run it?”
  3. “James, can you do me a favor? Can you job shadow Erica and then share with me what she could do in her processes to be more efficient?”

A desire to convert someone to our opinion

  1. “Harry, can you tell Madu what you told us the other day. I may not have explained it right, but Madu completely disagreed with us.”
  2.  “Why is this so important that my team has to work 10 hours plus a day and work on the weekends?”

These are just a few examples, but I hope they inspire you to engage that reluctant SME or Stakeholder by triggering their Natural Human Instincts.

Adding BA value to your AWS cloud project

This article is intended for Business Analysts who are about to embark on a project that will use Amazon Web Services (AWS)

instead of on-premise servers to host a web application or other software service.

An understanding of the common AWS concepts and terms are helpful in two aspects of the BA role in the cloud project – Communication and Cost Analysis. AWS terms and product offerings can seem like a new language to the uninitiated. Adding these to your project vocabulary will enhance your standing and increase your contribution to the success of the project.


We are called “Business” Analysts because we are the conduit between the technology teams and the business they are supporting. We bring to the project team an understanding of the user needs and of management’s expectations of how the technology product / output will benefit their organization. We translate technology-speak into business-speak to explain both limitations of the technical solution and opportunities that the technology has opened up that the business had not considered. This is especially important in the esoteric world of cloud computing.

Technical limitations in today’s cloud platforms do not generally impact the business, but business related limitations are presented in some of the pricing models. The section below explains some cloud cost concepts. Sizing, data usage and growth estimates are key non-functional requirements for cloud projects in order to get optimal balance between the high availability features of AWS and the pay-as you go pricing structure.

The business analyst can align their knowledge of cloud features with their understanding of the business to identify those features which may provide additional benefit to the business. In this role the BA acts as an advocate for the opportunities that new cloud technology can bring to the business. For example, how can the AWS data analytics tools help the business?

An effective Business Analyst does not have to be a Subject Matter Expert in cloud-speak or in the user’s business domain- but they should appear knowledgeable to the respective teams. They must have or learn sufficient subject matter knowledge of the business and the cloud technology to be an effective liaison between the customer and the developers. In the BA task of translator between business and technology you will be engaging with software engineers who are highly skilled and immersed in the cloud world. It helps to know what they are talking about. The sections below cover some of the key AWS concepts.

  • EC2 is the first term to understand. This stands for “Elastic Compute Cloud”, and is the Amazon equivalent of the on-premise servers or VMs. Amazon provides space on their server hardware, and services associated. “Elastic” in EC2 refers to the ability to scale your infrastructure. But see discussion later on costs.
  • Containers are self contained packages of code, configurations and libraries which are installed on the EC2 server. ECS is the AWS Elastic Container Service. Docker is a tool that packages software into containers. A Cluster is a group of containers.
  • S3 stands for Simple Storage Services, just one of the storage options in AWS.
  • RDS is the Relational Database Service, which manages any of the relational database products that AWS offers.
  • AWS has a broad product offering of their own tools such as Athena for SQL queries, Redshift for data warehousing, and QuickSight for data analytics.

Note: Some information in this article is taken directly from to ensure that I am using the correct terminology and phrasing. AWS online help is extensive and I encourage you to familiarize yourself with this before and during your project.


Cloud Costs

Two important concepts in cloud hosting costs are the payment grids and service sizing.

“Elastic” in EC2 refers to the ability to scale your infrastructure and also to the payment rate chart. The rate for a small pilot app with 16 GB memory could be 20 cents an hour per GB used, but the production installation with high usage and multi-gigabyte storage could be double the cost for the same transaction result because of the increasing complexity of the services needed to successfully and securely run the app.

EC2 pricing is based on instance type (standard, high cpu, high I/O). For example, an “a1.xlarge” provides 4 CPU’s and 8 Gig memory with low I/O while the “c4.xlarge” delivers 4 CPU’s and 3.75 Gig with high I/O. The hourly on-demand cost jumps from 10 cents to 20 cents. Storage sizing is another important second sizing and data input/output have an impact on the total cost of AWS.

Architectural sizing decisions are the responsibility of the project SA or SE, but are made based on forecasts of volume and usage from the business or app owners. A successful BA can help gather and interpret this valuable input for the team. Requirements should include data and usage patterns and estimates over time, not just the final max estimates.

The selection of best sizing is also dependent on the granularity of the system/app that is being built. Apps that are made up of small micro services are more cost effective in the cloud than those made of large complex services. The BA can support this in the use case analysis. A use case may begin as a high level story, which the BA can help break down into smaller services for the app team to develop. For example: The business use case may be “As a bank cardholder, I can insert my debit card into an ATM machine to get my account balance”. The micro services behind that request could include:

  1. As a card reader service I can read the account number from a debit card …
  2. As a PIN reader service I can collect PIN numbers for validation…
  3. As a PIN validation service I can validate a PIN value against an account number …
  4. As an account balance service, I can provide the current balance of an account …

These services are granular and reusable. The use case or user story template for a cloud project should provide the ability to cross reference reusable services between use cases / user stories.

A second cost consideration is the multitude of add-on services that the AWS platform provides. Many of these are deceptively easy to initiate, with the cost not apparent until the monthly charges are reviewed. I know of a case where a cloud engineer with developer rights signed up for an annual data warehousing license from the AWS Marketplace. The cost was significant. Cost management is generally not part of the BA role, but on a cloud project the BA can help their Finance partners by gaining a knowledge of the services on the monthly – or daily – cost reports to assist in recognizing and questioning cloud services that have been incurred that were not part of the original plan.


The Business Analyst can add value to their cloud project by learning and understanding the concepts of cloud architecture and the services their cloud provider offers, so that they can enhance communication with the business and financial partners.

BA As Detective

Some of you know that I am a big fan of mystery fiction.

There are many aspects of this genre that I enjoy, but what I find the most interesting is watching the detective look for clues to help identify the problem, investigate alternatives, and finally offer the solution. In past articles I’ve noted some of my favorite detectives –Louise Penny’s Armand Gamache, Philip Kerr’s Bernie Gunther, Michael Connelly’s Harry Bosch and Tana French’s various detectives, to name just a few. They are all flawed, but amazingly talented at solving the fundamental problem of “who done it.” What is it that enables them to put seemingly disparate puzzle pieces together to solve the case? Characteristics that are also needed to succeed at doing business analysis work.
In my past articles I have drawn comparisons between the BA and detective. I have explored the need for both to connect the dots and solve problems creatively. I have discussed the need to rely not only on their intuition, but also their rational mind. I have discussed the importance of recognizing patterns, creating structure from chaos, and feeling comfortable with ambiguity. However, one comparison I haven’t explored is perhaps the most obvious and relevant one—the ability to ask good questions. 
As BAs we ask a lot of questions. As Penny’s Chief Inspector Gamache says, “The question that haunted every investigation was ‘why,’” also an important question for all BAs to ask in one form or another. But Gamache knew, as do BAS, that asking ‘why’ by itself is not enough. We need to ask contextual questions. Consider the quote from Dashiell Hammett’s famous detective Sam Spade: “Who shot him,” Spade asks a witness … The witness “scratched the back of his neck and said, someone with a gun.” Experienced BAs know that when we ask vague questions, we’ll get vague answers.
Not only do we need to ask good questions, but we need to be able to understand the answers provided. What happens when we want to ask follow-up questions, but are absolutely “clueless” about what the stakeholder is saying? This can be particularly unnerving when that stakeholder uses highly technical language such as a data scientist describing the algorithms that will be used in the latest AI effort. Like our detectives, we need to clarify. And if we don’t understand, we need to admit so. And if that technical guru asks us questions that make no sense to us (what ETLs need to be developed, for example), we need to admit that we don’t know. One of the tips Chief Inspector Gamache gives each new recruit, is to get clarification when needed. He says that one of the most important things “that leads to wisdom” is saying “I don’t know.” We need to have the courage to say those words modified, of course, for our own situation. 


Of course it gets trickier in the digital world. As BAs we cannot simply say, “I don’t know what you’re talking about,” or words to that effect. We can try the old standby, “Help me understand…” which is great, but we run the risk of still not understanding the explanation. What do we do when we don’t have experience even vaguely related to the stakeholder’s answer? As BAs we often find ourselves asking questions about all manner of things unfamiliar to us, but the world of AI can present new and unforeseen challenges. Yes, we can—and need to– prepare questions in advance. But how can we ask good questions, not just the fundamentals like “why” and “what,” when we know nothing about the subject? 
For example, let’s say I want to ask about algorithms, a subject that I know almost nothing about and therefore am terrified of. Sure, I do research, but when confronted with an answer that makes no sense to me, I might freeze. I want to ask about why one type of algorithm was used instead of another. I want to ask about built-in biases. But answers like “I chose a non-parametric algorithm which uses this method for classification and regression…” might give me pause. What helps me is to go back to the basics and start asking contextual questions, which provide a business context and can set the tone for other questions and answers. Once I establish a business perspective, I can put all my further questions into a business context as well. And importantly, it helps me say “I don’t know” without actually saying it. Remember those ETLS? We can rephrase our answer into a question about what the alternatives are and how each alternative provides the business what they’re looking for. 
We can also start out at a high-level discussion about the AI effort, what business problem it solves, and how it aligns with the organization’s strategic direction. Even if we’ve heard the answers from sponsors and other business stakeholders, we can encourage technical gurus to frame their answers in business terms. Once we have established the business context, we can move to more detailed questions about how a chosen algorithm helps the business, risks of built-in biases, and, as needed, ask about the data, its source, when it was cleansed, and so forth. Or start with a lower level of detail and work upwards. As good detectives, BAs know that solutions rarely occur when we try to investigate in a straight line. Detectives and BAs know that a question that leads to unexpected answers is a source of a myriad additional questions that take us in unexpected directions, but ultimately solve the problem more quickly. 
And that’s where some of the skills discussed in previous articles come in. These competencies. like the ability to connect the dots, help us solve problems and come up with creative solutions. These competencies allow us to follow unusual lines of questions, even if we have no idea what the outcome will be. They allow us to prioritize our work and the questions to ask each stakeholder. They allow us to uncover implicit and hidden requirements. And they enable us to make creative yet practical recommendations. In other words, they help us find “clues” that may seem meaningless at first, but which ultimately help us solve even the most difficult business problems. 

Why Common Sense is Not Good for Software Development Teams

Recently, I had to create an account for one of my children’s school-related matters.

Once the account was created, a token to verify the email address was sent to my email address.

Emails sent to this email address are retrieved by another email provider using the old POP3 protocol. When the email with the token arrived and I clicked the link, the requesting server replied, “The supplied token is incorrect or has expired”.

I obtained a new token but it also expired, and the next one did too and so on! The time allowed to respond was set too short for this particular POP3 scenario, which meant I was stuck between clicks, and unable to continue.

I was able to overcome the problem eventually, but the point is that during software development and testing of the account creation feature, this particular scenario was somehow overlooked. The dev team may have used, common sense or the “very rare, not worthwhile” argument to avoid doing further analysis or simply, nobody thought about it.

In this case, there were no huge consequences (only a few hairs of the few I have left were pulled out), however, in a different situation, not deriving important business scenarios from requirements, user stories or features may be a very costly oversight.


More than common sense

Agile practitioners sometimes characterise Business Analysis (BA) as nothing more than “common sense”, thus precluding any further efforts to understand important aspects of features. i.e., a customer’s real needs, and the business context where the needs are drawn from.

We claim allegiance to “customer satisfaction”, or to “improving product’s user experience”, but do we only go as far as “common sense”? Business Analysts are actually very weary if “common sense” is proposed, particularly when it is used as a means to jump into “quick solution” mode.

More often than not, ‘common sense’ only leads to lacklustre solutions, or increased development and/or testing time due to lack of understanding. Emulating the term “technical debt” used in agile dev teams we could say lack of true business understanding generates a kind of “business debt” potentially rendering a piece of software code unsuitable.

This is why BAs are not mere “problem solvers”, but far more importantly, they are “problem understand-ers”.

A wealth of BA skills can be used to explore, analyse, and understand real needs and business context. Scenario analysis, personas, customer journeys maps, and conditions of business value are some popular ones that come to mind.

The right mindset

A colleague at work recently mentioned that while “anybody can take a photo, not everybody is a photographer”. He was quite right!

Skills and the techniques by themselves are not enough to understand something. They necessary, but they are only the “what” without a sense of “how” they can be applied.

This brings to the fore an important competency of Business Analysts, namely the “BA mindset”. The BA mindset has its foundation and focus on delivering business value from accumulated knowledge and ability, and helps determine how well you can use skills and techniques in a specific situation. Just like a professional photographer.

Agile teams not only produce software, but they must also produce “valuable” software and “value” pertains to the business domain. The business domain needs to be explored and understood if we want to deliver value in the first place. That is what BAs do!

The “analysis” task within an Agile team, no matter who performs it, beyond common sense requires business analysis techniques, and the skills and competencies of business analysts. Although these can be learnt, in order to truly build a great analysis capability within Agile teams a dedicated member of that team is best, regardless of title, role or where they sit on the development team. If not a BA, a BA can coach them!