Skip to main content

Tag: Leadership

Recruitment Metrics for BA Teams

Being involved in BA recruitment is a big responsibility. It’s hard to recruit right now, and it’s easy to blame the competitive market and skills shortage. It’s tempting to leave measurement and metrics to HR teams, but there are a number of key concepts all those involved in BA recruitment need to understand.

 

Time To Fill

From the point we become aware that a new or replacement BA role is needed, a clock starts ticking. Whether someone has handed in their notice, or a new project has emerged, we now have a gap that needs to be filled. It is so important to understand our average time to fill (TTF) for each role on the BA career path, as this aids decision making, including the use of short term resources such as consultants, contractors and secondments.

Typically more senior roles take longer to fill, because the talent pool is smaller and the demand greater. Having internal talent pipelines reduces the TTF and creates internal progression routes and clear BA career pathways. Ensuring these are in place improves knowledge retention, employee loyalty and morale and serves as an attraction factor for BAs outside the organization.

TTF includes internal processes of gaining agreement and approvals, getting a role posted and engaging with recruiters. This is often a hidden time over-head, and usually an area where organizations can speed up their recruitment.

 

Time To Hire

This marks the time between making a role available for applications and having someone in post. It includes the interview process and the notice period of the candidate.

Recruiting managers often put pressure on candidates to try to reduce their notice period. This is unfair, when it is the only period of time in the whole process which is outside of the recruiting organizations’ control. If we want people in faster, we should look to improve our own processes! Sometimes organizations exclude notice periods from their time to hire metric, to stay focused on the elements within their control.

Knowing the average time to hire helps us keep stakeholders informed, and contributes to better planning and onboarding.

 

Advertisement

 

Conversion

At each stage of our recruitment process people drop out or are ruled out. This can be visualized as a recruitment funnel. Understanding the conversion rates between different steps in the process allow us to answer question such as:

  • How many applications do we typically need to find one appointable BA? [conversion rate from application to accepted offer].
  • How many candidates accept our offer? [conversion rate from interview to accepted offer].
  • What can we do to improve our conversion rates? (Faster processes? Better marketing of roles? Better communication with applicants?…)

 

If we understand where in the process we are losing people, and really consider the candidate experience, we increase the chances of a successful recruitment outcome, and save both time and money. Different organizations have different levels of formality, and may include more or less interview rounds and steps in the process. However formal or informal, it is valuable to understand the key conversion rates.

 

Attrition/Turnover

This is the rate which we lose BAs from the team over a given period. Not all attrition is bad, we need to support people to move to new and appropriate roles, and we need to allow BAs with new ideas and different experiences to join the team. Generally an attrition rate of less than 10% is considered healthy for team stability and business continuity.

Retention is the opposite measurement to attrition. This is the percentage of the team that stay during a given period. Focusing on ‘increasing retention’ is a more positive framing of the issues than ‘reducing attrition’. Recruitment is expensive, the cost of replacing BAs is far more than the cost of investing in appropriate initiatives which retain talented BAs in the organization. By asking and listening to what individual team members want from their role and employer we can increase retention rates (money will be a key factor, but not the only one!).

 

Tenure

This means understanding how long people stay with us and can be considered  at different levels:

  • Average length of time in each role/grade within the BA structure
  • How long people stay within the BA team
  • Total amount of time spent within the organization.

 

This is helpful to understand the rates of progression within the team. If we have entry level/development roles within the team, how long before people typically progress to a practitioner role? It allows trends and patterns to be explored. If we find people either stay less than 1 year or more than 10 years, what insights can be gained? What does that tell us about our recruitment and retention processes?

With further analysis we can understand the push and pull factors which keep BAs within the team or encourage them to look elsewhere. It also allows us to consider what internal development routes we offer into related professional disciplines.

 

Conclusion

In this competitive market, with increased demand for business analysis skills and the ‘great resignation’ making people consider their options, BA teams need to fully understand our own processes and look for improvements. A greater focus is needed on recruitment and retention, and we can no longer rely on ‘recruiting as we always’ have to make great appointments and grow our teams.

 

Further reading
Are you Losing BAs? C Lovelock, February 2022
Job Crafting for BAs C Lovelock, July 2021

The Better Meeting Manifesto – Stop Having Terrible Meetings!

Terrible meetings are an unfortunate feature of modern working life.  It doesn’t have to be this way: read on to find out how you can take a stand and achieve better meetings for all!

 

Encountering a terrible meeting in the wild

Most of us have suffered through a terrible meeting.  You know the scenario.  A group has assembled in an airless meeting room in response to a calendar invitation.  The AV equipment is faulty, so the unlucky person with the controls has spent the past 10 minutes trying to connect to the remote attendees.  Everyone else is making small talk or discussing the previous meeting.  When the equipment finally cooperates, you all realise that the meeting organiser isn’t in attendance.  Undeterred, you check the meeting invitation – only to find it unhelpfully blank.  The group makes a valiant attempt to progress things; however, you can only get so far with the main person missing.  The meeting finishes early; the group sighs and agrees to reconvene another day.

 

Then there is the alternative, more insidious variant.  At first glance, things begin well: the meeting logistics are on point, the right people are in the room, and you received the outline ahead of time.  Yet once the meeting starts, issues soon become apparent.  There are too many items for discussion.  Due to aggressive timeboxing, there is little scope for more than brief comments regarding each.  People grow increasingly frustrated with the lack of opportunity for input, the schedule drifts, the meeting overruns and several agenda items are never reached.  The group makes little progress; the attendees are sentenced to a re-match to address the same material the following week.

 

Regrettably, these experiences are far from rare.  Is it little wonder, then, that we sometimes find it hard to get our stakeholders to make time in their diaries for yet another meeting?

 

Trojan horse meetings: a false solution

To combat meeting aversion, some session organizers resort to subterfuge.  One such ploy is the classic Trojan horse maneuver: book meetings into the calendar under the guise of something more palatable.  Often, the decoy is a workshop.  For example, a document sign-off meeting might be billed as a ‘requirement sign-off workshop’, even though the session is less about facilitated qualitative review and more about sitting around a table together to agree that the ensuing work can proceed.  A stakeholder interview to elicit information about a particular aspect of their role might appear in the calendar as a ‘process workshop’.  A team meeting might become a ‘team workshop’, and so on.

 

Superficially, this tactic can bear fruit – at least in the short term.  So why do people feel more positive about workshops over meetings?

 

  • Meeting fatigue

The first reason is novelty, pure and simple.  People want respite from busy calendars booked up with tedious and unproductive meetings.  Workshops are attractive because they generally feature interactive activities instead of the usual dry discourse.  Even the mere hint of this variety can suffice to lure stakeholders into believing they are in for a welcome change.

 

  • Productivity by association

A workshop is a facilitated intervention that seeks constructive input from all attendees to achieve a defined output.  In positioning their meeting as a workshop, the organiser aims to appropriate the qualities of focused, engaged participation and demonstrable productivity from the workshop format and confer them upon their meeting session.

 

Unfortunately, the aspiration of engagement and productivity will only get you so far.  Without good facilitation, a meeting will still be terrible no matter how you dress it up.  Worse: a bad ‘workshop-but-actually-a-meeting’ experience might harm your work by putting stakeholders off attending workshops in the future.

 

Advertisement

 

Another way

Rather than deflecting attention from the problem, it’s time to take a long, hard stare at the meetings in our lives.  Faced with a wilderness of terrible meetings, how can we act to change things for the better, no matter which end of the calendar invitation we are on?

 

  1. Make meetings pointy

All meetings should have a clearly defined purpose and intended outcome.  No point?  No meeting.


As the organizer:

If you are responsible for setting up a meeting but cannot answer the questions ‘Why are we meeting?’ and ‘What should we have achieved by the end of the meeting?’, this is a sign that you should reconsider.  Is a meeting necessary, or might there be another way to work with your stakeholders (e.g. using your organisation’s preferred collaboration tool)?  Don’t be afraid to postpone or cancel a meeting if circumstances change.

 

As an attendee:

Your time is as valuable as anyone else’s.  Invitations are not obligations.  If you receive a vague meeting invitation, contact the organizer and politely ask them to clarify the meeting’s purpose.  A helpful sentence to use is ‘Please could you confirm what will be covered in this meeting so that I can prepare?’ – it helps you sound engaged while also acting as a prompt for the organizer to step up their game.

 

  1. Energize and engage

Meetings can’t always be fun, but don’t make them any more painful than they have to be.  Start with the intended outcome and take active responsibility for getting there.

 

As the organizer:

A great tip from BA guru Angela Wick is to ‘verb-noun’ your meeting titles to set the intention for the session outcome: instead of ‘Requirements Review Meeting’, try ‘Finalise Requirements for Procurement’.  It instantly puts your attendees into a more active mode of thinking which will carry into the meeting itself.  Set a clear schedule with realistic timings and manage the session actively to keep things on track.  Don’t let people doze off: check in frequently with all attendees (particularly those attending remotely) to ensure that everyone feels involved and has the opportunity to provide input, even if it’s just a quick thumbs-up/thumbs-down vote.

 

As an attendee:

It might not be your meeting, but you are part of it – and its success or failure.  Help things go smoothly by doing any necessary pre-work ahead of time and coming to the meeting prepared.  Be fully present and listen actively – nobody wants to recap points made five minutes ago because you were not paying attention.  Consider whether your comments contribute usefully to the intended outcome before speaking.  Where you can, support the facilitator.  For example, can you help by relaying remote attendees’ comments to the room?

  1. Master your meeting modes

Following the recent pandemic, many of us continue to work flexibly between the office and home; meetings now frequently mix face-to-face and remote attendance.  These ‘hybrid’ sessions can be tricky to get right, but it’s not impossible.  With a bit of planning, you can be a meeting mode superstar.

 

As the organiser:

Meet your stakeholders where they are.  If people are uncomfortable with coming into an office space, forcing an in-person meeting will result in no-shows.  Save face-to-face for the times you truly need it and focus on providing a good experience online for everything else.  Be aware that attendees may decide to group up and attend online from the same room, so give specific instructions if your planned activities require each person to have separate access to a computer.  Design for online: take full advantage of the synchronous and asynchronous collaboration tools available through the applications at your disposal.  Get equipment warmed up in plenty of time, ready to get going when the meeting starts.  And whatever you do: don’t apologise or make excuses!  You’re about to lead a fantastic online session, after all.

 

As an attendee:

If you are attending in person, don’t forget to acknowledge and address any people attending remotely.  As a remote attendee, be mindful of your audio input.  Use a quality headset with a good microphone if you work in a shared office environment – and be prepared to mute yourself when you aren’t speaking to minimise disruption.  Nothing is worse than hearing background noise or someone thundering away at their keyboard.

 

What tips and tricks have you found to tackle the tyranny of terrible meetings?  I’d love to hear your thoughts!

Think “Re-use” When Writing Requirements

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.

 

Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page.  Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard?  This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world.  This is just one example.

 

Advertisement

 

High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow.  One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)

 

Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.

 

But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?

Constructive Conflict Is Better Than False Agreement

Over a decade ago, I was in a workshop with a range of different stakeholders.

 

Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule.  Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words.  They simply said:

“I disagree”

I remember being taken aback by the bluntness.  I live in the UK and our communication style is somewhat indirect most of the time.  It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”.  Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”.   I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable.  Someone was breaking the consensus; they were “creating conflict”.  Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead.  Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed.  What’s more, other attendees of the meeting started to question things, interject and show disagreement.   One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so.  And you know what? I am convinced that the output of that meeting was better as a result.

Advertisement

Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good.  I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement?  If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners.  Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction.  Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations.  We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion.  We can lay down an appropriate set of ground rules that allow for differences of opinions to surface.  I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion.  That’s to be expected.  With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial.  Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too.  Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”.  When someone says it they provide us with a gift, an opportunity to better understand them.

Best of BATimes: Deal Breaking Soft Skills – The Essential BA List

If you don’t have the right soft skills, you will struggle as a BA. Business domain knowledge and hard skills can be taught.

 

But finding a BA with the right set of soft skills can be a deal breaker for employers. And no, it’s not just the ability to read, write and converse. So which soft skills do you need?

Heads up

In this post I will be going over the soft skills which are essential for a BA.

Communication

  • Being a good listener, showing that you are patient and empathetic. Actually listening to the DEV team when they say a feature can’t be achieved. And being transparent with the business when explaining the same.
  • The ability to explain difficult (and sometimes simple) concepts/ideas/justifications (anything really) at all levels.

For example, walking through a business process with your DEV team. Clarifying business terms and ideas which they not be familiar with. Translating that into how the system works and explaining the value provided to the business.

  • Being able to articulate answers to questions clearly and clarify points on the spot. For example, not confusing the business with technical terms. Explaining concepts in a way that they will understand. Even if you don’t know the answer (rather than making something up) say that you will find out and get back to them later (and actually do that).

(Difficult) Stakeholder Management

  • Managing your emotions. Not all stakeholders play nice. You will always (always!) have one or more difficult stakeholders. You need to understand their motivations and why they are being difficult. The key is to maintain your professionalism and not let your emotions get the better of you.
  • Influencing. This also includes influencing without formal authority, persuasion and negotiating. Your reputation helps significantly here. If you are known to get things done and do what’s best for the company/client, your stakeholders will be more inclined to see things your way.

Managing Expectations

  • Showing you are in control. The business/stakeholders/your boss needs to know you have a handle on things. The worst thing you can do is pretend that everything is ok but in reality, it’s all falling apart. You must be clear about your workload and ability to deliver on time. If things are slipping, make sure you have evidence why. For example, maybe the business is not cooperating during requirement’s session. Possibly the vendor has screwed up somewhere. Maybe you have too much on your plate and you need to offload some work.

Diplomacy

  • The ability to understand office politics. For example, knowing who can get things done for and who always plays hardball.
  • Conflict resolution. Ideally conflict mitigation. Knowing when a situation can get out of hand and how to resolve it quickly.
  • Knowing what to say and to who. You will probably know certain people in your organization who you will want to avoid unless you really (really!) need to speak to them.
  • Having the ability to speak the truth and gain trust but also not “putting your foot in it”.
  • Learning how to tell people in power that they are wrong without them feeling like they are!
  • Not oversharing information to the wrong people and opening cans of worms which can impact you later.

 

Advertisement

 

Analytical Thinking

  • Being naturally good at working out problems. Being able to dig deep to find out the the root cause of an issue. (link to root cause)
  • Reading people/understanding people. The ability to sense when stakeholders are reserved and giving them the power to speak up and be heard.
  • When a stakeholder asks for something, being able to understand what they really want but are struggling to convey. Working out when people are masking the truth or too scared to speak up.

Adaptability

  • Handling pressure and stress. For example, working towards deadlines which might change at the last minute. And having to drop things and work on something else more urgent.
  • Dealing with WTF situations. For example, being dropped into a major production issue which is affecting the company’s revenue and the stakeholders are looking to you to get them out of it.

Relationship Building

  • More than just chit chat. You need to build effective working relationships by being known for:
    • Getting things done
    • Doing what you say you will do
    • Going the extra mile when needed
  • Being able to call in favors based on trust
  • Knowing who to ask when you need answers to difficult questions
  • Know who to ask (if they don’t know) to find out who else might have the answer to your questions

Leadership On Demand

  • Leading a group of BAs (e.g. in your managers absence), leading workshops and coaching junior staff

In this post I went over the soft skills which are essential for a BA. Effective soft skills are often taken for granted. I was guilty of this myself early in my career. Over time I have worked hard to develop my soft skills (and still continue to do so). Are there any surprises in my list? Anything you would like to add?