Skip to main content

Tag: Team

Don’t. Step. Back.

‘We need to take a step back’ is a common phrase amongst BAs, and while the intention is understandable, this entreaty simply isn’t helping.

You know the feeling.

  • The project is already running away with itself.
  • Stakeholders have identified a solution before articulating the problem.
  • This great new idea does not align to strategy or objectives.
  • The CEO wants to implement a system they’ve seen work elsewhere without understanding our context and challenges.

 

You know we need to calm down, think logically, act rationally. In every meeting, you want to say things like:

  • We need to slow down
  • What about the bigger picture?
  • Let’s go back a step.

But no one wants to hear that.

The start of initiatives are about energy, motivation and enthusiasm. BAs can be seen as blockers. What we think is pragmatism can be interpreted as negativity.

 

Restraining Language

When BAs are constantly using language which is perceived as holding back progress, stakeholders begin to avoid us, work around us, and don’t include us in discussions where we could offer a valuable perspective. BAs then become increasingly worried and frustrated, and our warnings become more dire and more persistent.

It can look like our input is focused on restraining the initiative and identifying additional work.

Is it possible deliver the same information in a more impactful way?

Advertisement


Examine Our Role

BAs often feel we are the conscience of a project, and our job is to protect stakeholders and the organization from poor decisions. Is that a reasonable expectation to set for ourselves?

Trying to reign-in a project which has senior backing, forward momentum and is moving at pace is perhaps not the best way to expend our energy. It’s OK to be on board with an idea and to be enthusiastic. We don’t have to ensure every ‘lesson is learned’. It’s more important that the project benefits from an engaged BA that is consulted at the appropriate time and is seen as someone who is contributing to moving the initiative forward.

 

Enabling Language

Swapping our restraining language for forward-focused language may not be as difficult as we think.

Instead of “We need to take a step back” we can say “We need to be clear on the best next step”.

Instead of using “Yes, but….” to list off all the problems, we can use “Yes, and…” to keep our contribution constructive.

We can use language that says I’m onboard with this project, I want to see it progress and my contribution helps move us forward.

BAs can sometimes see positivity as naivety. It is possible to be positive and well informed. We can use our experience to help projects avoid potential pitfalls, without insisting on a backwards step.

 

Conclusion

BA don’t need to single-handedly restrain projects. In fact the best way to influence projects and products in the right direction is to demonstrate that we are invested and enthusiastic about the outcome.

Language matters. Swapping restraining language for enabling language shows our stakeholders we care, we understand and want a positive outcome. There may still be difficult messages to deliver, but  we can frame these as future-facing hurdles to overcome rather than backwards-facing steps to make.

Designing Case Study Interviews for Hiring Awesome BAs – A Hiring Manager’s Perspective

When I first started hiring business analysts, there was a while there where I was great at hiring BAs that didn’t quite fit what I was hiring for. As a BA myself, I recognized the need to pivot beyond a verbal interview to get a real-time look at a candidate’s skillset. I needed to see what a candidate could do and evaluate that against what was needed for the role I was hiring for.

Enter the Case Study.

Designing the perfect case study is a lesson in trial and error, with each candidate revealing ways to make it better. More than ten years later, I’m still running case study interviews (and have hired some of the absolute best BAs I’ve ever worked with) and have a few tips for hiring managers that want to design their own.

  • Keep it simple. It’s a high-pressure situation, do not give your candidate a page of text. You will miss your mark due to misinterpretations, assumptions, over-analysis, time-crunch. A simple picture, a simple task. It’s enough.
  • Pick a couple key skills to evaluate. You’re only going to get so much out of the case study without making it overly complex. What are the two or three key things you’re looking for and design to see those skills in action.
  • Do not send the case study out ahead of time. You’re just asking for someone to show up with a ten foot long, professionally printed flow chart. Yes. This happened.
  • Be VERY VERY clear. Be specific about what you’re asking the candidate to do or produce. Are you expecting them to interview you, draw a diagram, write a requirement? No matter how clear you think it is, someone will misinterpret it. Repeat your ask multiple times.
  • Make it relevant to you. Use simple scenarios from real life; industry or domain relevant, something your candidate may face on the job. This will give make it real for both you and the candidate.
  • Be flexible. Everyone will interpret your case study differently based on past experiences. Don’t look for your perfect answer, and don’t design with right or wrong in mind. Instead look for skills being used, the questions being asked, the way ideas are communicated; capabilities are the key.
  • Make it fun. If you’re stressed, they’re stressed. Keep it casual, make a joke, lighten up. Turn down the pressure to allow your candidates to battle their nerves and show their skills off better.

Advertisement

There are innumerable ways to go about evaluating for a particular skill through a case study. Here are a few examples:

  • Facilitation and/or Elicitation Skills. Give the candidate a basic scenario – even something as familiar as ordering a pizza online. Ask them to gather requirements from their client (you) for a new feature. You should predefine your feature with a couple alternate scenarios or edge cases. See how well your candidate elicits your requirements. Did they catch those alternate scenarios?
  • Modeling. After gathering the requirements during the facilitation portion of the case study, ask your candidate to create a simple flow chart, use case diagram, context diagram – whatever you’re looking for. Did they accurately model the requirements? Do they know how to communicate using models?
  • Working with ambiguity. Include very little detail in your scenario. Throw them into the project with a paragraph and a pat on the back (totally unrealistic, right?). Ask – how would you start? What would you do? Look for how the candidate thinks and how they plan to work knowing very little. Did they talk about identifying stakeholders? Understanding the objectives, benefits or KPIs? Making a requirements management plan? Did they approach the unknown in a way that made you confident they could work through it?
  • Strategic thinking, risk analysis, problem solving. Throw a couple blockers into the scenario. The clients are swamped and rarely answer emails. Technical stakeholders are distributed across multiple departments and have competing priorities. The vendor hasn’t provided a data spec for the extract you need to document. The timeline for the project has been moved up and you’re being asked to compress requirements timelines. Don’t be afraid to throw in real scenarios you deal with regularly. I’ve gotten good ideas on problems I was dealing with myself!

In all the above case study scenarios, you can design the challenge and evaluate the output differently depending on the skill level of the role being hired for. For a junior practitioner, I would evaluate a flow chart with a different lens than someone with 10 years of experience. I would expect a senior BA to identify more subtle risks and have tighter mitigation strategies than someone two years on the job.

The case study can be adapted for anything!

As you continue your case study journey, you will continuously tweak, adapt, and perfect. I’ve gotten it so close to where I want it that I enjoy seeing how else a candidate can trip me up and force me to adapt yet again.

My latest tweak: virtual case studies during pandemic times means you must send your candidates a copy of the case study. A digital copy can be forward to recruiters who then give it to other candidates. Candidates then magically produce a ten-page requirements document in half an hour. It took me a couple interviews to figure out that magic. Tweak time! Now there are variations of the case study used at random.

However, you integrate case studies into your process, above everything else, keep it simple and don’t take yourself too seriously. You’d probably find a case study interview stressful too! For those of you on the receiving end of a case study interview – don’t panic. Have some fun with it and show what you can do knowing that the hiring manager’s expectations will be more closely aligned to your skill set upon hiring and you’ve set yourself up to be more successful in the role in the long run.

Approaches for Being a Lead BA

You’ve worked your way up the BA ladder – started as a Junior BA, then a BA, then a Sr. BA, and now you’re a Lead BA on a project working with other BAs. What do you do? This article focuses on some of the Do’s and Don’ts of being a Lead BA. Some of it is science and some of it is art.

Requirements Governance:

1. Who do you take direction from your PM or your BA Manager:

The first place to start as a Lead BA is establishing your own personal Requirements Governance. Who do you provide status updates to and who do you take direction on requirements from – PM or your BA Manager? The scenarios I’ve encountered are:

  1. You as the Lead BA take your BA requirements direction from the PM and provide status updates to your BA Manager.
  2. You as the Lead BA take your BA requirements directly from your BA Manager and provide status updates to your PM.
  3. The third and most often scenario is where both the PM and your BA Manager are of the opinion that you take requirements direction from them and provide status updates to the other.

Tip: Right at the beginning of the project start the conversation with your BA Manager and clearly establish the relationship you’ll have with him or her and with the PM (in my experience coaching BAs too many Lead BAs don’t have the conversation upfront and then find themselves in a bind when scenario C) above becomes an issue during the project itself). If the answer is taking your requirements direction from them, set up a short meeting with your BA Manager and the PM to establish this relationship as PMs generally don’t like that arrangement, and it’s best to get them to discuss it face to face. If the answer is taking your requirements direction from the PM, then simply follow-up the meeting with a confirmation email to your BA Manager and just let your PM know that you’re effectively going to report to them and take, where appropriate, BA approach direction from them.

Advertisement

2. Establish your role as Lead BA on the BA team:

Make sure it’s clear to the BAs you’ll be leading that you are the Lead BA, and they will work with you in that capacity. A couple of ways to communicate this:

  • Ensure you’re called out on the project governance as the Lead BA and ensure the BAs you’ll be leading review the project governance
  • Where you’re taking your Requirements direction from your BA Manager have them send out an email to the BAs you’ll be leading that you’re the lead and that you’ll be guiding the approach etc. to the Requirements deliverables

3. Start by learning about your BAs:

At the beginning you’ll need to establish how experienced the BAs are with eliciting, documenting, and analyzing requirements, how familiar they are with the project subject matter, etc./ by scheduling quick little chats with the BAs you’ll be working with

  1. If you’re dealing with Sr. BAs with lots of experience, then your focus with them will be on making sure things are going smoothly and that they working to the timelines for their requirements work packages; You can give them fairly large and complex requirements work packages
  2. If you’re dealing with more Jr. BAs then you will be in a more guidance/ mentoring mode – periodically reviewing their requirements and providing feedback, mentoring on approach to different types of requirements such as documenting process flows and business rules, etc.; Initially limiting the scope of their work packages to small well-defined pieces of requirements; have little chats with them about how things are going

4. Develop a view of the requirements work packages:

Typically, a group of BAs is assigned to a project because the project is complex and there are multiple “groups/ categories” of requirements that need to be created to deliver the scope of the project. At the outset understand the drivers and objectives of the project and establish a view of the requirements work packages. Some examples of this are:

a. Achieving compliance with regulations or another compliance-related purpose:

    1. You may need to look at work packages focused on complying with different sections of the regulations
    2. If the compliance covers multiple departments or Lines of Business (LOB) you may need to focus on requirements for each department/ LOB to comply with the regulations

b. Developing and implementing a large technology system or platform:

      1. You may need to look at requirements work packages focused around different groups of users with the system – for example if it’s a workflow system you likely have work packages for customer-facing components, back-office-facing components, etc.
      2. You may need to look at requirements work packages focused on different functional features. For example, a customer-facing platform for a direct investing platform may consist of trading-related features, viewing account holdings, researching different securities, etc.

5. Managing the requirements work packages:

a. Establish a view of the project timelines with respect to the requirements work packages based on their complexity etc. I prefer a matrix like this to do so (using the direct investing platform as an example) based on the requirements lifecycle – plan, elicit, analyze, document, get sign-off (note do this in Excel or Project to track progress, etc.)

Plan Elicit Analyze Document Sign-Off
Trading requirements 01/01/22 to 10/01/22 10/01/22 to 25/01/22 25/01/22 to 02/02/22 02/02/22 to 16/02/22 16/02/22 to 28/02/22
Security Research requirements 01/01/22 to 10/01/22 10/01/22 to 25/01/22 25/01/22 to 02/02/22 02/02/22 to 16/02/22 16/02/22 to 28/02/22
View account holdings requirements 01/01/22 to 10/01/22 10/01/22 to 25/01/22 25/01/22 to 02/02/22 02/02/22 to 16/02/22 16/02/22 to 28/02/22

b. Based on what you learned about the BAs you’re leading assign them to different work packages – and monitor their progress on their work packages against the. I’ve found the best way to keep track of this is using a matrix like this that I update on a weekly basis:

Legend:

P – Plan, E- Elicit, A- Analyze, D- Document, S- Signoff

BA1 BA2 BA3
Trading requirements P – Jan. 1/22
Security Research requirements P – Jan. 1/22
View account holdings requirements P – Jan. 1/22

 

With these 2 matrices, you can keep track of who’s doing what and how they are doing against the target dates so you can provide status reports to the project team as required.

6. Monitoring progress and connecting the BAs as a team:

The most effective approach that I’ve found to monitor the progress of my BAs is to hold weekly meetings – with a twist. Most people just do a status check-in during their weekly meetings – how are you progressing against your timelines. I believe that weekly meetings are a good chance for the BAs to inform and help one another. I encourage them to talk about challenges they are having – someone else in the team may have encountered this and have a solution/ approach to tackling it. I encourage them to talk about effective approaches that they’ve found to doing things that may be helpful to other members of the team. Finally, I ask each BA to give a brief overview of the requirements they are working on. As most projects with a BA team have a common goal – by talking about requirements it will quite often identify synergies or conflicts between requirements/ work packages that will help move the project forward more efficiently.

Conclusion:

Hopefully, these approaches will help you become a more effective BA Lead. There are lots more approaches and in future articles, I may expand on them.

Who is in, and Who is Out

Imagine attending a meeting, and all the participants but you, are contributing ideas to a discussion. You are clueless. Maybe you missed a conversation, or you did not read an email? There could be numerous reasons why you could not contribute during the meeting. One instance could be that you were not included in an email chain or not invited to a meeting.

Leaving recipients off unintentionally (or intentionally) from any form of communication can lead to confusion and misunderstanding between the team members. A little bit of proactive questioning can help avoid hits and misses. Ask these questions first:

  1. Who should and should not be on a meeting invitation?
  2. Who should and should not be on an email chain?

The obvious answer is: It depends

Next, ask these additional questions to finalize the list of recipients. Evaluate the responses before hitting the send button:

  1. What is the email or meeting topic?
  2. Would skipping a team member in an email or meeting lead to miscommunication?
  3. Will including all the team members make a few of them feel that the meeting was irrelevant to them?

Advertisement

You can answer the above questions by leveraging these options:

  • RACI (Responsible, Accountable, Consulted, and Informed) matrix: RACI matrix can be a great source of stakeholder information for global projects.

For example: List the Responsible parties under the To list or Required Attendees. List the Informed parties under the Cc list or Optional Attendees.

  • Working Agreement: No RACI matrix? An Agile team working agreement can come to the rescue. Define who are the core team members. Refer to this list when sending out any email communications or meeting invites.

Tip: Core team can be cross-functional with stakeholders across the organization.

  • Email distribution list: Say the team size is small (4 to 6 members) and there is no RACI matrix or working agreement, then create a distribution list that includes the email IDs of all the team members. It is less effort and error-proof when selecting a list instead of individual email IDs for sending any form of communication.
  • Instant messaging group chats: Most instant messaging tools allow the setup of groups. Create one for your team and post a message in the team chat. Plus, there are options for the recipients to acknowledge the chat message (emojis such as like, happy, celebrate, and such).

In conclusion, despite the ideas mentioned above, there are chances that someone is still left off an email chain or a meeting. Be a team player, reach out, and get them caught up. The crucial element is that the entire team is on the same page.

“We need to be on the same page and not play the blame game” – Nate Heying.

Developing a “Sense of Purpose” for a Business Analysis Initiative

Βusiness analysts can contribute in delivering the sense of purpose and worth concerning a business analysis initiative. This sense of purpose will contribute to the better effectiveness of the work that is performed between the BA team and the different stakeholders. As the business analysts are continuously communicating with different stakeholders and deal directly with their needs, they are the best source to contribute to the capturing and the diffusion of a common purpose that may also serve as a success criterion for the initiative.

The capacity to effectively lead a business analysis initiative is directly related to the pursuit of a worthy purpose. The purpose may be the most powerful link to join people and processes in a common effort. General/ Organizational purpose can be transformed and decomposed into more specific and detailed initiative purposes. The degree to which we pursue an ennobling purpose is the degree to which we attract others.

Advertisement

Purpose attracts and therefore serves as a unifying force. There is unity of effort and energy to the degree of shared purpose. Our level of satisfaction and our level of energy is directly related not only to our understanding of our own purpose but also to whether the organization and specific project to which we contribute, share that same purpose.

Below you can find four considerations for effectively managing the sense of purpose as a business analyst:

  1. Big Picture

Being able to see the things holistically and the long-term value and effects of any task can help you embrace a worthy purpose that will give you energy and motivation but also distribute this sense of purpose to the other stakeholders

  1. Respond to “Why”

In order to successfully spread a sense of purpose, you need to instill a sense of worthy purpose. It is to answer the why question, why should work overtime for this project? Why should I sacrifice? Why should I dedicate my time to achieving high-quality deliverables? The answer has to be something that is worthy, something that is ennobling.

  1. Focus on the Perception

You may feel you have communicated effectively the purpose to the other stakeholders but do the others perceive the purpose as something worthy and important? Perception is reality. What people think they hear is the truth according to them.  So, we have to think through our communications in a very deliberate manner, in a planned manner, thinking through how it’s going to be received on the other end and making sure that people are receiving the message that we want them to receive.

  1. Align with the Organization Purpose

The organization’s purpose and the core values of your organization should be aligned with the project-specific purpose. Projects or initiative specific purpose may be derived and be a more detailed and case-specific purpose of your general organization purpose.

Effective execution of business analysis tasks requires convincing key stakeholders (both internal and external) that your analysis and your conclusions are valid so that you can transition from your analysis to implementation. As such, you must be able to summarize your findings in a message that makes a persuasive argument that aligns with the sense of purpose. An argument that mirrors progress towards the realization of this purpose. Therefore, defusing a sense of purpose and then communicating results towards achieving this purpose is an integral part of your effort in any business analysis task you are engaged with. One that is worthy of careful consideration.