Skip to main content

Author: Rohela Raouf

Get the most out of your meetings: brush up on your facilitation skills

Business analysts are meant to be good at facilitating, it’s meant to be one of our key skills.

However, speaking to many of the BAs in my network, facilitation is the one area that they feel that they can do more. I guess one of the difficulties with facilitation is that you don’t always end up with a tangible outcome. This then makes it harder to determine the value in what you have achieved. No, one wants to go a two-hour meeting, where they sit around the desk and discuss the same things over and over again. Often, people state that they find meetings really unproductive and go far as to say that they are blockers in getting things done.  

I disagree with this, I recently attended the IRM business analysis conference where the keynote speaker Clive Woodward (famous rugby coach) stated that he couldn’t work out why people didn’t like meetings. I agree with him, meetings are meant to be a tool and if the tool is not being utilised productive manner then it becomes more of a people issue. Instead of blaming the tool, ask yourself if it is used in the most productive manner.

So, to avoid your meeting become stale and boring, we have created some top tips to get you to think outside your comfort zone for meetings. I am not going to state the obvious like making sure you have a set agenda for your meeting or defined outcomes that you want to achieve. As, a business analyst, I would expect you do this for any meeting that you facilitate.

Tips

1. Try a new type of meeting format – Lean coffee

  • • This is one of my favourite type of meetings. So, if you have not done this before it is quite an easy concept to follow. Everyone in the meeting writes on a post-it note, items that they want to discuss. Put the post-it notes on the wall. Carry out infinity sort, to understand if there are any key themes that have come out around what people want to discuss.
  • • Pick the most popular item- if you don’t have one then I would pick one at random. Discuss that item for a period of 5 mins and then ask everyone if they want to discuss it further after the first 5 minutes. If, yes discuss for another 5 mins and so forth
  • • Top tip- I would recommend not discussing anything longer than 15 minutes- I personally find after 15 minutes’ people start becoming disengaged with the subject matter. If you have not received a conclusion after 15 minutes, I would suggest you move this to the parked section and come back to it at a later stage if you need to. It is important that after 15 minutes, you move onto another topic- avoid talking for the sake of talking.

Advertisement

2. Pick a different location

  • • Unless you work at Google, your office will be a typical office- bright artificial lights if you are lucky you will have lots of glass or if you’re not then you will have white walls. If you are always meeting in the same location, then by human nature you tend to associate that space with certain emotions. So, if you have meetings that are lacklustre people then tend to associate that emotion with the meeting rooms that you have in office.
  • • So, once in a while go out of the office and go to the local coffee shop to hold your meeting there. Change of scenery is great, as it gets people to think in a different way. Also, walking to the local café will get people energised, as will the fresh air.

3. Observe where people are sitting

  • • If you have regular meetings, you will notice that people either sit in the same chair or they will sit next to the same people. By sitting next to the same person, you will end up inevitable. people embracing the same role each meeting. To avoid this happening. Mix it up a bit in your meeting, I am not suggesting you create a seating plan for your meetings. What, I am suggesting is that you gently steer people to sit in a different position.
  • • Top tip- if possible move the furniture around the room, this will naturally force people to sit in a different seating position to their usual. Also, make sure you are sitting in a different place to your usual seating position.

4. Give the dominated person a task

  • • We have all been in meetings, where there is one person who talks all the time. I would suggest, with that person give them either a flip chart pen or whiteboard marker and get them to make note of what everyone is saying. By, having to write they will naturally be focused on listening to everyone in the room. If that is not possible, then I would suggest you get them to read the actions from the last meeting. By giving them this role, you are getting them to focus on the other people in the room and the role that they place in the meeting.

5. Avoid multi-tasking

  • • Ban smartphones and laptops at meetings. When people are working on multiple things at the same time, they are not able to give 100% to either of these things. To avoid having semi-interested in people – ban the laptops. In my team, if we have a team meeting then everyone has to leave both their phones and laptops at their desks. This means people are more invested in the meeting and by having them more focused in the team discussion you are more likely to get a decision quicker.

So, next time you are going to facilitate a meeting, try one of the above tips and see what difference it can make to your meetings.

Business Analysts Embrace Non-Functional Requirements

It is often argued that business analysts like functional requirements, so, therefore, they tend to naturally gravitate towards these.

On the other hand, the humble non-functional requirements are left in the shadow and rarely given a second thought until the last minute. Doing, this causes many issues when you are about to go live with a system. While the system/product may look great, if the performance is not there then no one will use it. This will impact the business a lot more than if a nice to have a feature is not included in the final product.

Differences

Functional requirements fall into ‘WHAT’ the product is trying to do while the non-functional requirement falls into ‘HOW’ it is going to do it. So, it is naturally understandable why BAs like to focus on functional requirements- you can show the users, customers, and managers what the product is going to be doing. It is a lot more difficult to get the managers or the customers excited about non-functional requirements.

Coffee cup

While it can be argued that non-functional requirements are not glamorous as functional requirements. I am just not sure really why non-functional requirements are left to the last minute. When I purchase a takeaway coffee, I want the company who created the container to have paid the same amount of attention to how it was going to be transported as well what is going to be in the container. Let’s, take this further I regularly access BBC website, the reason I use this product is not only because of the content but also how well it performs i.e. how quickly the pages load.

Twitter fail whale

Raouf 122817

There have been many high-profile cases where the business has not paid full attention to non-functional requirements. You will frequently hear about how a website has crashed because the business had not fully anticipated the capacity required. If you used Twitter in its early day you would have come across this whale, when Twitter was over capacity and therefore was unable to handle the demand. This naturally caused a high level of frustration of the service and they were very vocal about their unhappiness. Twitter fail whale is a great example of what happens when the business does not forecast correctly the level of capacity or understand the scalability of its product.


Advertisement

Key things to look for :

If you are new to non-functional requirements, the following are different areas of non-functional requirements that you need to look at when you are eliciting these requirements.

  • Performance: What should system response times be, as measured from any point, under what circumstances?
  • Volumetric: what is the volume of users that are going to be accessing the system?
  • Scalability: what is the peak transaction volume? Peak user levels?
  • Capacity: what is the volume of users that are going to be accessing the system?
  • Availability: what are the hours and days that the system is going to be available?
  • Reliability: what reliability (excluding planned outages) is needed?
  • Maintainability: how is the system going to be maintained? Who is responsible for the maintenance
  • Security: how is the system going to be protected from hacking? What will happen if it does get hacked
  • Auditing: how long do you need to retain the data? Do you need to who is accessing the system and what they are accessing?
  • Recoverability: what is the disaster recovery policy if the system goes down?

There are other non-functional requirements that I have not stated above that you may want to look at; Interoperability, regulatory, serviceability, usability

Eliciting non-functional requirements

Eliciting non-functional requirements is not easy as asking the business what do you think are the ‘maintainability requirements’. You will need to speak to other members of the project team, for example, the technical architect should be able to help you with most of these requirements.

If you do not or unable to speak to technical architect then speak to the end users of the system to get a baseline to what is current ‘As is’ situation. By getting a baseline you will be able to categorise the information. For example, a sale assistant has bring up a sale order screen when talking to customer

Objective: what is the objective behind this scenario
Process requirement: retrieve customer details
Non-functional requirement: how quickly should the screen load 

By categorizing the information in the above manner, it allows you to analyze and assess whether there is a need for a requirement and what the priority is this for the requirement.

It is important when you are looking at non-functional requirements that you do not elicit them in isolation.

Documenting

Dependent on the type of the project methodology that you are using will depend on the artifact that you are going to use for documents. For waterfall projects, you will use requirement catalogue to document the non-functional requirements. In Agile, you should document them on the back of a card.

So, next time when you are about to elicit requirements, start with the non-functional first.