Tag: Best Practices


Bad Bosses for BA’s

Our relationship with our manager has a massive impact on our work, health and happiness. What makes a good leader for BAs and what can we learn from bad bosses?


Project Managers

PMs are often attracted to their role because they are skilled at delivery. It is very difficult to balance the competing demands of meeting delivery milestones with nurturing and developing individual team members. Having the combined roles of line-manager and delivery-manager puts project managers in an unenviable position, and if the performance evaluation of the PM is primarily concerned with project delivery, it is clear which role will take precedence.

Some of the worst examples of PMs managing BAs include:

  • Treating the BA as deputy PM
  • Assuming the BA wants to become a PM
  • ‘Hoarding’ the BA on their project, despite requests to expand horizons and develop
  • Vetoing analysis tools and techniques the BA wants to apply
  • Preventing the BA from speaking/presenting to senior stakeholders, reducing the visibility of the BA and unintentionally (or intentionally) taking credit.


If the person doing these things is also your line manager – how can you address the behaviours or find appropriate support?


Learning points

Where a BA is line managed by their PM, there needs to be recognition that there are two different relationships at play. The ‘best’ outcome for the project (BA assigned 100% of the time, forever) is unlikely to be the best outcome for the individual BA. PMs will sometimes have to put the needs of the individual above the project, or risk losing them from the organization entirely.

BAs may want to partition meetings or request separate ‘line management catch-ups’ which have more emphasis on personal development and wellbeing and less on project delivery.

The PM/BA relationship works best when they are a professional partnership. The roles have different skills and approaches, but are working towards the same delivery goals. This can be severely compromised if the PM is the only ‘boss’ for the BA.


Product Specialists

Product managers and product owners sometimes find themselves managing BAs. They may also want to ‘hold on to’ their BA indefinitely. They often value product knowledge over the BA skillset and expect BAs to become subject matter experts. If the only training and development opportunities they can imagine for the BA is ‘more product knowledge’, then BAs are not getting the support and encouragement they need from their boss. They may not understand the breadth of the BA role and skill set, and subsequently only allow the BA to operate in a very narrow role with a constrained set of tools, techniques and relationships.


Learning points

Refer to job descriptions to keep both BA and boss focused on the wide remit of the role, not narrow product knowledge. The BA should build strong relationships with business stakeholders and relevant teams, so they have easy access to business knowledge, but don’t become the keeper of this knowledge. Encouraging regular discussion of succession planning and rotation and re-assignment normalises the idea that a BA will not stay with a particular product for the long term, and what we are providing is a business analysis skills-based service, not a product knowledge-based service.


The Absent Executive

Whilst it may be appealing on paper for a BA to report directly into a CIO or other senior executive, it comes at a price. It can be very difficult to get their time, leading to an inattentive and shallow line management relationship. The BA is often faced with the choice of a distant relationship, with irregular catch-ups and never knowing if something more important may overwrite one-to-one time OR attempting to become the right-hand-man of the exec, picking up a range of problems and projects, but is subject to rapidly changing priorities. Neither of these are particularly appealing situations and neither provides considerate and consistent line management support for the BA.




Learning Points

Reporting into a senior executive requires a high level of autonomy and independence. Some BAs enjoy working in this way so this can work well. However, everyone deserves to have a positive and supportive relationship with their boss and not see themselves as the lowest priority item on a very long to-do list. Investing in other meaningful relationships with more accessible colleagues may help to address the gap if a management void occurs. This could include a mentor, coach or trusted and supportive peer. Developing the community of business analysts helps to provide support and direction if there is an absence of management.


General Manager

There has been a rise in the belief that ‘a good manager can manage anything’. The problem is, this is not actually true and multiple studies spanning many sectors find that:

  • A manager who has skills and experience of a function leads to a higher performing function
  • People whose boss has skills in their discipline are happier and are better at their jobs!


A manager who does not understand or value business analysis is the worst possible boss for a BA.


Learning Points

BAs can help managers to understand the role and remit of business analysts and can champion the application of repeatable, rigorous analysis to aid decision making, understand customers, avoid risks, identify opportunities and improve services. It is always worth investing the effort to raise the profile and highlight the impact of good business analysis.


Organizations with sufficient numbers of BAs (5+) should be investing in a BA leadership role such as:

  • Head of Business Analysis
  • BA Manager
  • BA Team leader
  • BA Chapter lead
  • Head of profession for business analysis


Having individual BAs reporting to a range of roles and scattered throughout the organization does not allow the consistent application of business analysis, the opportunity to continuously improve or appropriate development and support of BAs.

Successful BA leaders are skilled and experienced in business analysis. They understand how to recruit and develop BAs and enable appropriate utilization and retention of BAs, saving the organization time, effort and money.



While there will be many examples of successful line management relationships from all of these roles, it is important to recognise the potential pitfalls and how they can be addressed. Not everyone is cut out to be a manager of people. Having a boss who cares about us as an individual, is interested in providing support and offering development and values the contribution we make should be the minimum we expect from our line managers.

Having a bad boss is bad for your health and career, so if you can’t change you manager, change your manager.


Further reading
Are you Losing BAs? C Lovelock, February 2022

Best of BATimes: Does Networking Hurt Your Hands? The Power Of A Glossary

A few weeks ago I was working away from home, and I was able to attend an IIBA UK event in the evening.


It was a really enjoyable event, and after meeting a whole bunch of new people and chatting about all things BA related, I went and checked in to my hotel. As I was checking in, the receptionist asked me how my day had gone. I explained that it had been busy, and I’d spent a few hours networking late into the evening. As much as I enjoy networking (I love meeting new people and sharing/learning), I do find it exhausting. As he handed me my key, the receptionist said something that really surprised me:

“Ah, I used to do a lot of networking. Kills the hands, doesn’t it? All that terminating. I used to work for a communication company so I did a lot of networking”.

Perhaps it was because I was tired, but I did the typically British thing and just smiled and accepted the statement that he’d made without questioning it–but on my way to my room I was puzzling over what he’d said. Why would networking hurt his hands? Too many handshakes maybe? And why would you terminate something at a networking event… that sounds pretty serious! And why is the fact he worked for a communication company important…

Then the penny dropped. Networking has different meanings, and I suspect he was referring to laying physical networking cables in a data center or communication room, where cables have to be crimped and (presumably) ‘terminated’. Perhaps using some of the tools is uncomfortable after a while. “An evening networking” to me means meeting other BAs and having a coffee. To him it meant navigating cables in a comms room ‘out of hours’ getting everything ready before people arrive the next day.




The Illusion Of Communication

As William H. Wyte once wrote “The great enemy of communication, we find, is the illusion of it.”. This is often the case inside organizations and between organizations too. With our plethora of acronyms and words with ‘special meanings’, it is easy to appear that we are agreeing on a particular issue, idea or requirement, only to find out that each person at the table has a subtly different understanding of what is being discussed.

Even words that appear, on the surface, to be obvious can have different meanings depending on who you ask. The word ‘customer’ might seem clear and obvious, but it is quite possible that different people attribute different meanings to it. Who is the ‘customer’ of a training course? The delegate who attends it? The company that employs the delegate (assuming they are paying)? Probably both–although both will have subtly different needs and requirements, only some of which overlap. This is made even more complicated in intermediated industries where there might be an end customer, and one (or many) intermediaries. If a financial service company sells products via brokers, some might refer to the broker as a ‘customer’, others might refer to the end investor as the ‘customer’. Again, they’ll have very different needs and requirements.

This can lead to all sorts of crossed-communication throughout the business change lifecycle, not least when it comes to requirements. Whether we’re writing user stories, use cases or even a heavy-weight requirements catalogue, it pays to think about terminology. This is where the good, old, trustworthy glossary comes in.

A glossary perhaps isn’t the first thing that springs to our minds as business analysts. It’s something we know we probably should do, but with the pressures of a project it can be easy to let it slide. This simple experience, with a misunderstanding over the word ‘networking’, reminded me how important they are. After all, with a clear glossary, writing just about any type of requirement artifact becomes easier. If there is a clear and agreed meaning of “Investor” and “Broker”, for example (rather than using a term like “Customer” that might mean either, or both) we can be concise and precise in our requirements writing.

This potential for misunderstanding also highlights the need for techniques that don’t rely on the written word. Visual techniques, including formal modeling, can help explore the problem space and requirement scope too. All of these activities help us cultivate conversations and help us ask “what exactly do you mean by ‘x’?”. Not only this, but a well-defined glossary can help inform the production of other artefacts such as a concept model (these are clearly different things, but defining terms up front helps a great deal).

In Summary

A glossary might take some time to create and maintain, but it’ll help avoid ambiguity and ensure we can create concise and precise requirements. It is an investment in time worth making.


Best of: 8 Tips for a Successful Requirement Elicitation

The key to a successful requirement elicitation session for a business analyst starts with asking the right questions.


This is not a natural skill for many but something that needs to be perfected over time. For starters, keeping a checklist of questions can be an effective measure. So here are few tips to help you get started.



  1. A Business Analyst’s involvement in a project usually starts with the kick off meeting. When you do your introduction to the client, face to face or over a con- call, make sure to explain who you are, your role in the project and what you would like to achieve through this meeting.
  2. While addressing the client, please address them by their first names; especially those from a different country/culture. For e.g. please do not second guess if Robert is Rob or Bob and end up annoying the client. The best you can do is ask them.
  3. Be an active listener. Do not interrupt the client unnecessarily. Towards the end of the meeting, paraphrasing what you have heard will make sure you both are on the same page. For the elicitation to work well, you need to understand what people are saying and also try to read between the lines to understand what they might be hesitant to say.
  4. You need to gather aspects based on the Who/What/Why/When/Where model. Always ask the right questions. While talking to stakeholders, what robs the BA of her credibility is the use of fillers such as, “umm, ahh, like, so, you know…” between sentences that communicate uncertainty and can be quite distracting. If you tend to use these, try to replace them with thoughtful pauses between your sentences. It’s best to avoid hedgers such as, “kind of, sort of, I feel, I gather” and “I suppose”. Instead replace them with strong words, facts, statements of “I know” or “In my research I found that”.
  5. The questions should be framed based on the current state of the system in question, the goals and objectives, pain points, the desired future state, users, success criteria and assumptions.
  6. Some of the clients might ask you to hand over the questions in advance so that they can be well prepared for the call. There is no harm in doing so.
  7. Please do not follow templates blindly that are being used by your organization. Do not try to fit into a model. Rather try to create one based on BA best/good practices.
  8. Do not use technical jargons while dealing with business stakeholders. A BA should be able to speak the language of the audience she is talking to.



To do an effective job while eliciting the requirements, it is necessary that all the stakeholders involved share a common vision regarding the requirements. Be aware of the above mentioned loop holes that can lead you off track. For a successful requirement elicitation, the BA needs to understand the overall business picture/product vision and should be able to relate how the individual project objectives support this big picture.


‘Twas the Night before Implementation

‘Twas the night before implementation and all through the warehouse

not a program was working, not even a browse.

The programmers hung by their screens in such despair,

with hopes that soon, a miracle would be there.

The users were nestled all snug in their beds,
while visions of working systems danced in their heads.

When out in the snow there arose such a clatter,

I sprang from my desk to see what was the matter.

Away to the window I flew in a flash,

tore open the shutter, and threw up the sash.

And what to my wondering eyes would appear,

but a Senior Business Analyst with a six-pack of beer.

His resume glowed with experience so dear,

I knew in a moment; the miracle was here!




More rapid than the programmers could consume, his requirements they came,

and he shouted and clamored and called them all by name:

“Now Update! Now Inquiry!

Now, Create and Delete!

On Batch Job! On Interface!

On, Closing and Functions Complete!

To this programmer! and to that programmer!

Now code away! Code away!

Code away all!”

He was dressed in a tux, from his head to his foot,

and his clothes were bright, all glowing and afoot.

His eyes—how they shined! Fingers nimble and lean,

from weeks and weeks in front of the screen.

His cute little mouth was drawn up in a smile,

and his hair, every strand in place as he worked a mile.

He stopped only to take a swig of his beer,

as the work ahead circled in the atmosphere.

He worked so fast, and smiled aware of his self,

and I looked upon his work with dismay, in spite of myself.

A wink of his eye and a twitch of his head,

soon gave me to know I had nothing to dread.

He spoke not a word, but went straight to work in great affair,

turning out specs and models with such flair!

And laying his finger upon the “Enter” key,

and giving a wink, the system came to life to a tee!

The updates updated, the deletes deleted,

the inquires inquired and the functions completed!

The testers tested each whistle, and tested each bell

with nary an abend, all had gone well!

The system was finished, the tests were concluded,

the users’ last changes were even included.

And the client exclaimed with a snarl and taunted,

“That’s not what I asked for, but exactly what I wanted!”

                                                         –Aaron Whittenberger


Behavior for Internal vs. External Customers

Mentoring my first BA apprentice this year has been challenging and extremely rewarding. It’s provided me with a great sense of achievement but also a renewed love of the craft, I highly recommend it for ‘old hats’ like myself.


Some of the questions an apprentice asks are eye-opening since they are coming from an ‘education first’ posture, and as a mentor, you get to help them put what they’ve learned into practice. As I’m primarily self-taught and only certified four years ago, I’m sometimes taken aback that I’d never asked these questions myself but thinking through the questions I’m thrilled to find I usually know the answer.


For most BA-related questions though, the answer usually starts with, IT DEPENDS.

Also, the BA craft is an art, not a science, and an important trait a BA builds is FLEXIBILITY. Their behavior should change based on whom they are dealing with, and the stage the project is in.

As an IT BA, everyone is a customer, but we need to treat internal and external customers differently, based on the relationships we’ve built with them. If you’ve repeatedly worked with an internal business partner from IT or another part of the organization, your interactions with them can be informal and somewhat friendly, while remaining professional. Interactions with ‘new’ internal business partners should be professional first, and friendly but formal until you’ve proven you can deliver. Trust is earned, not given, playground rules apply.




Turning this idea around for external customers, in my company’s case product vendors, an IT BA should expect to be treated like a customer, as they help ‘guard the gate’ for their internal business partner during product justification, selection, and sometimes implementation project phases. They need to be the product manager in order to evaluate solutions against requirements, arrange for vendor demos, and justify the purchase of new solutions. This can also mean assisting in the delivery of functionality, standing in the business partners’ shoes initially, and ensuring quality and acceptance of the solution.

In essence, IT and business partners ‘subcontract’ product evaluation and selection to the IT BA, who must always act in everyone’s best interest, within existing IT constraints. It’s a complicated dance, while the IT BA needs to be the main vendor point of contact throughout product selection and possibly delivery, they often also need to assist with negotiations for all stakeholders to reach a consensus. This is doubly true if they are also involved in testing. I like to call this zone Switzerland.


I recently helped select a solution provider based on a solid match to our requirements, however, once the contract was signed, we found that there were slight changes to the product that made it a less desirable choice. Partnering with the internal business customer, we successfully negotiated with the vendor to use the original version of the product for delivery, understanding that while they would continue to support this version, future functionality enhancements would only be applied to the new version of the tool. This vendor had tried to take control of delivery early on, attempting to require us to submit to their implementation script, but slowly understood that we needed to be in charge due to extreme resource constraints. As a result, our initial communications were short and sweet, this was how it needed to happen, and they grudgingly complied. By the time we started testing the new application with live data, however, we’d become a team.


Seasoned BA’s can pull this off effortlessly, while a newer BA, especially an apprentice, needs guidance and practice to build the confidence they need to be successful. I think this is true for both waterfall and agile methodologies, I hope this helps.