Tag: Facilitation

BATimes_Nov10_2022

Best of BATimes: 99 Tips To Be A Fantastic Business Analyst

Published on August 29, 2019

1. BA yourself

This is one thing that only some professions can do. An Actuary can’t actuary himself, a developer can’t code herself, a mechanic can’t mechanic himself. We can analyze ourselves. Use your skills. Decide what a fantastic BA is; research, interview, question and then review yourself. Do some gap analysis and then formulate an action plan.

2. Be nice

No one wants to work with a jerk. No one wants to help and supply information to a jerk so engender support. Thank people, go out of your way to be personable, establish friendships and mutually positive working relationships.

3. Understand project lifecycles

Get to know all the steps in project lifecycles, not just your own and especially the intricacies and peculiarities of the adaptation used by your organization.

4. Be a mentee

There is much to be learned from Analysts further along the road than you.

5. Present well

Don’t dress like a scruff, smell nice, clean your teeth. These are surely basics but I have met people in business who have overlooked these things and they are avoided. You can’t be avoided and be successful. 

6. Prep prep prep

When you go to meet a stakeholder, especially for the first time, prepare. Understand who they are in the business and project context. Ask them for any pertinent information to be sent for your review in advance. Maximize the time with them to appear (or be) effective and efficient and they will happily give you more.

7. Be on time

Your prompt arrival in the office and at meetings will give you more poise than if you rush in late. It is the fruitage of an organized and self-correcting individual.

8. Work on your confidence

We’re not all naturally confident but by reassuring ourselves of our abilities in our BA skills or in our industry knowledge we can instill the needed confidence and trust from our business stakeholders that we can understand their world view and needs.

9. Don’t reject difficult things

They help you grow. Be the BA that accepts unusual assignments and see your career enriched and flourishing.

10. Get good at cost benefit analysis

Don’t leave this to the PM. At project inception, or for minor changes, be able to determine with appropriate certainty whether to accept or reject activity. Maintain a project which can stand-up on its own merits.

11. Be optimistic

Pointing out the bad may be necessary but if you find yourself always the nay-sayer then fix it. Problems are our business. Our optimism can make for a gentler change process.

12. Get your desk in order

Give your workspace a make-over. Keeping it clean and orderly can help you be organized and looks a lot more respectful.

13. Go to a conference or two

Hear some new stuff. Mingle with your peers. Feel proud to be part of a greater something.

14. Help others

You have a project deadline, sure, there’s always one looming but give your fellow BAs your assistance. It will broaden your knowledge and strengthen your team.

15. Be strict about your change management

Keep a record of changing requirements and details about them. It will save you the red face when, inevitably, someone will ask you later for paperwork.

16. Do your actions

If the PM has to continually chase you for your actions they will resent it.

17. Don’t be offended by the red pen

Your work will be reviewed, heavily. Welcome critique and correction. Never be upset about any proposed edits. The individual has spent time immersing themselves in your work and for that you can be grateful. It will make your work better, or at least more acceptable to your audience.

18. Volunteer to share your knowledge

Blog, post, present at lunch-and-learns, write-up how-to guides. There are always people who don’t know what you know so share.

19. Model

Use models a lot. Business people invariably find models easier to verify than paragraphs of information and it brings the potential delivery to life. Architects, Developers and Data Analysts thrive on a well-produced model.

20. Learn, learn and learn some more

If you have the means then don’t stop learning. There is so much training available in BA skills, industry knowledge, peripheral project skills, business knowledge, techniques and soft skills.

21. Offer plentiful walk-throughs

By walking-through your outputs with developers, testers and business representatives you reduce the risk of misinterpretations.

22. Finish your projects

This is especially true if you are a contractor. It’s not good practice to leave a project part-way through if you can help it.

23. Develop strategies for juggling

You will have to work on many things at once. Find what works for you to avoid loss of productivity. If you have yet to nail this there are plenty of productivity tips and hacks on the internet.

24. Clear paths for people

Be someone who anticipates down-stream problems and blockers for yourself and others and intervene.

25. Categorize people but know your exceptions

Use personality and character traits to help you understand the motivations and reactions of your team but note that exceptions exist. Tailor your interactions to fit.

26. Don’t jump to solutions

Have problem-formulating conversations to focus your mind away from solution-mode.

27. Form collaborative relationships

When you collaborate you are more likely to get early and continuous buy-in, nothing will come as a surprise to your end client and you get immediate feedback on your work. It’s worth the extra effort.

28. Find your key SME voices

The quality of Subject Matter Experts is not equal. I have seen business users hide information for a variety of reasons (most understandably) making elicitation more than the usual effort and I have had System Testers guess answers and present information as fact. Hunt for good sources of information and verify what is said.

29. Play requirements back

Saying things like: “So if I understand this right, what you needs is…” saves misunderstanding.

30. Work to uncover implicit requirements

What assumptions have you or your customers made that they haven’t vocalized. Set aside some time and thought to uncovering these.

31. Know your audience

The level of detail that you go to should reflect your audience, know this before you start your elicitation. Get it wrong and you either waste time or have to re-work.

32. Recognize that accuracy is important

Particularly in your written English. If you can’t get that right, what else might get called into question.

33. Start with context

Ask: “Why the project exists?”, “What will be the end results?”, “What benefits are sought?” Then work from there.

34. Document what you won’t build..

..and get it agreed. It doesn’t mean it can’t be changed but it will at least be recognized as a change rather than something that you missed.

35. Get creative

With care not to promise an outcome, suggest ideas and alternatives to users during elicitation. Possible options can be used as a sort of model to tease out other requirements.

36. Read widely

The IT industry is constantly changing and working practices follow hot on the heels. Our understanding of business practice, psychology, methods for collaboration and effecting change progresses. Manuals, how-to guides and handbooks to support our work are plentiful.

37. Don’t forget your non-functionals

If you don’t include these in your document template as standard, add a section for each non-functional as a reminder to consider it.

38. Don’t gild the lily

It may not be scope creep as such but it’s easy to gold-plate our requirements with unnecessary items. Admirably this is usually in response to wanting to deliver the best but these types of extras add up. Work out what your Minimum Viable Product is and then be sure to note any additions as just that.

39. Revisit your prioritizations often

Work with your group of SMEs to get your product features delivered in the right order but remember that things change so schedule re-prioritizations throughout delivery.

40. Evaluate your own skills

Choose a couple of areas for improvement, write them down and formulate some actions that will help you improve them.

41. Look for “free”/cheap benefits

By knowing what’s off-the-shelf or can be achieved with relative ease you can maximize the product and minimize the cost.

42. Ask for feedback

At suitable points during and at the end of projects get personal feedback. Asking people who will give you constructive critique is valuable. Keep it. In years to come you can see how this helped you to change and grow.

43. Find balance

Don’t neglect your personal life. Finding a good work-life balance helps you cope with the ups and downs of projects.

44. Connect with others

Associate with other Business Analysts. Everyone knows different things and that diversity is valuable. Learn, share, help and be helped.

45. Know when to shut up

You’ve raised a risk or an issue but no action has been taken, so you raise it again or differently. It’s good practice to be assertive but there comes a point when you have sufficiently noted it and taking it further causes consternation. Learn where that point is and stop before you reach it.

46. Be a mentor

You know more than you think you know. Give back to the profession by sharing that with someone following in your footsteps.

47. Work as a team

When you work with other BAs, even if you’re tasked on different items, work together. Peer review, support, offer and ask for opinion and share experience.

48. Make your research visible

If you do background reading, conduct surveys, read manuals, hold workshops then put your findings as links or appendices to your documents. Don’t make someone who may need to pick up your work at some later point have to start from scratch.

49. Expand your comfort zone

Do something a little bit uncomfortable, just a little. It will make you capable of more in the future.

(See www.batimes.com/articles/personal-growth-through-discomfort.html)

50. Be agnostic to the solution

If you begin with a pre-determined solution or have a particular software package in mind you won’t be working on behalf of your client.

 

Advertisement

 

51. Be flexible to software development lifecycles

Learn to work waterfall, agile, fragile, whatever your client wants. Help them build on what they have.

52. Work with positive people

When you get a choice, pick to spend your work hours with optimists. Lift your chin up and thrive with them.

53. Don’t plagiarize

It’s fine to get inspiration from other text but word them in your own way. The process of breaking something and re-working it allows you to assimilate it properly.

54. Create your own templates, improve others

If templates don’t exist within your organization start to build a repository as you work. Have one eye on how a future project may use the template. If your organization does have templates, seek ways to improve them.

55. Hone your toolkit

Rich pictures, sequence diagrams, business model canvas, running workshops.. and the other scores of tools and techniques in the BA toolkit. Practice them and then get them into your workplace. The more the merrier.

56. Encourage newbies

We were all new once. The profession is constantly refreshed with new and trainee BAs. Welcome people. Help them.

57. Don’t get stereotyped

Take on projects in areas that you haven’t done before so that you have experience and confidence in delivery in as wide a range of topics and disciplines as possible.

58. Avoid too much future-proofing

While it’s a very useful consideration some attempts at future proofing just don’t fit with the future when you get there. Unless it has wide application and has relatively no cost or impact to the project don’t overengineer it.

59. The devil is in the detail

Ask for detail and then spend time understanding complexities. If you don’t, annoying requirements will rear their ugly heads later, when you’re further down the road than is desirable.

60. Order your own tasks

It’s in our nature to do enjoyable things or things which are easy or small first and then rush others. Avoid this by monitoring deadlines and dependencies taking into account impacts from other people and their availability.

61. Decide what your goals are

Ask yourself where you want to be in 5 years and put a plan into place. It may be various certifications, it may be working on certain types of projects, with technologies or in specific locations. Work out the steps you need to get there.

62. Ask for help

No man is an island. There is no shame in asking for help whether about your career, with techniques or technical aspects.

63. Archive and catalogue

Don’t leave files, part finished documents, reference material and other artefacts as collateral damage of your work. Archive your documents, catalogue your information and generally make it easy for people to work out what are the most recent versions and what supports them.

64. Have a to-do list

Don’t risk forgetting important tasks for something as simple as keeping a list. Be organised.

65. Its ok to make mistakes

We are human and mistakes are inevitable. Know that you will make them and decide that dealing with them diligently and humbly will be appreciated and respected.

66. Estimate using metrics

If you’re asked to estimate for a piece of work, use quantitative methods as much as possible and share the information on which it is based.

67. Add a glossary

I have not seen a BA deliverable yet that hasn’t benefitted or would benefit from a glossary (either within the document or at project level). To determine what goes into it, consider your audience. You may need to add business terminology to give framework from IT readers and IT and project terminology for the business.

68. Vanilla is not the only flavor

Don’t forget about alternative flows. The abnormal activities are generally the pain points for most businesses. Overlook them at your peril.

69. Get your must-haves right

The MoSCoW rating is incredibly useful and the priority of requirements must be stated explicitly but it is only useful if you have ratified that a must-have requirement is absolutely necessary. Double check.

70. Chunk up your work and take breaks

By creating a series of much smaller tasks you maintain motivation as you complete activities and as a result have natural break points to re-energize you ready for the next task.

71. Speak up

If you see a possible method of improvement have the courage to vocalize it, respectfully and professionally.

72. Flesh out a plan but be flexible

Plan your assignments in a work-breakdown structure, so you can keep an eye on your own progress but don’t be too rigidly stuck to it that you can’t make the most of stakeholder time when they are available.

73. Do it now

If you get the choice between doing it now and doing it tomorrow; do it now. Procrastinating individual items adds up to lost time and missed deadlines.

74. Be motivated and committed

Volunteer enthusiastically, actively pursue end goals, deliver on your deadlines.

75. Find your USP

Maybe you’re a people person, good with data, can see the bigger picture, are an influencer, have specific technical expertise or domain knowledge, run killer workshops, are highly accurate….everyone has a unique selling point. Whatever it is, find it and use it.

76. Be an observer

Keep an eye on what your peers are doing. Look for cross-over and gaps between their work and yours.

77. Don’t cut corners

Guessing, not completing research fully, ignoring the quiet opposing viewpoint, not determining the full stakeholder group, failing to verify background information, removing valid approval stages are all ways to store up later problems. Don’t cut corners.

78. Run your own project

Is it possible to start a little business of your own? Doing this lets you really test your BA skills.

79. Display kindness and patience

When projects get pressurized this will make you stand out and be someone others want to have around.

80. Understand your Subject Matter Experts

Put yourself in their shoes. You’ve invited them to sit in a long meeting? Make it interesting, schedule breaks and bring biscuits.

81. Get your unfinished specs reviewed

Reduce your own risk of large rework by shipping parts of your document early and get feedback.

82. Take the initiative

Make suggestions. Improve your own team’s processes. Create bodies of knowledge. Organize socials Involve yourself.

83. Keep your requirements updated to the end

A change has been made at the eleventh hour, everyone knows about it, is there any need to take time-out to correct the documentation, especially when the pressure is on?….Yes. If you don’t, no-one will be sure of any of it in the future.

84. Take a step back

During meetings and workshops, take time to observe; interactions between people, gauge motivations. There is a lot more to be learned than comes in through the ears.

85. Control/Challenge scope

Consider scope constantly. It is the bread and butter of getting the optimal solution for the composite group of stakeholders.

86. Mock stuff up

User interfaces, documents, reports. Let your end users see and play with the final product at the design stage.

87. Minute your meetings

It doesn’t have to be War and Peace but make notes. Dictate, doodle or mind map if it’s a more effective or efficient method for you.

88. Give people a “starter for 10”

People provide what you want more quickly if they’re not starting from scratch. If you have a template, provide it. If you want data, provide the table to be populated. If you want a quote, propose a sentence.

89. Learn standards

If there is a UML or ISO way of doing something then try to use it. It’s less ambiguous.

90. Use data analysis tools

Many Business Analyst roles include research in data. You can be more self-reliant if you are capable at manipulating it.

91. Use requirement ‘numbering’ for more than a unique reference

Use prefix letter, suffix letters and sub-numbering to store information about the source (stakeholder or actor), expected delivery method (various IT systems, manual processes, teams, department or companies) and dependencies on other requirements.

Eg, CS75-S.1 (CS = Customer Services, S = SQL, .1 = 1st child requirement)

92. Don’t be vague

Make requirements specific. Eg the phrase “needs to be run regularly” should be “needs to be run twice a day, usually at 12pm and 5pm” and the phrase “other systems use it” should be “three Access databases, listed in Appendix C, link directly to the data”

93. Find your best packages

Find and get proficient with tools and application supporting BA work. Eg, for producing and tracking requirements, for producing diagrams, flows and other models, collaborating and conducting meetings, managing work, etc.

94. Change control your documents

Applying version control saves your readers’ time. Be specific about what’s changed in your version history and use function for highlighting changes.

95. Understand development basics

Gain some knowledge in the basics of development; processes, data and events, components and re-use, integration with other applications, design principles and constraints. Learning to write in a pseudo code style can help with that mentality.

96. Understand test basics

Gain some knowledge in the basics of testing; test condition design, what a tester needs from your documentation.

97. Conduct Stakeholder Analysis

Don’t leave this to your project manager, do your own. Know who your influencers are, your VIPs and any potential “troublemakers”.

98. Ask effective questions

Questions are the keys that unlock treasure troves of information. Closed questions are useful when you need to be specific and open questions are needed to allow free-flow of knowledge transfer. Learn how to make them effective and unbiased.

99. Get qualified

There are a number of qualifications tracks available in various jurisdictions. International Institute of Business Analysis, British Computer Society and International Requirements Engineering Board. For gaining knowledge in the fundamentals as well as sharpening practitioner skills it is invaluable and a résumé necessity.

BATimes_NOV2_2022

Encouraging Collaboration and Resolving Conflicts with Mockups

All business analysts have (or will) attend the same meeting with stakeholders so disagreeable that if you put an orange between them, they would immediately disagree on its color. If these stakeholders cannot bridge their disagreement, a great approach is to collaborate with the stakeholders to create lo-fi visual mockups.

When done correctly, BAs can use mockups to engage stakeholders in a collaborative learning exercise that includes the following elements:

  • Visual elements to depict subjects such as roles, actions, and relationships.
  • Auditory elements when discussing these topics.
  • Reading and writing elements when documenting discoveries and agreements.
  • Kinesthetic elements when modifying the placement and relationships of visual elements.

These are the styles identified in the VARK model of learning. Using this multi-sensory approach in a collaborative learning exercise can be bring together stakeholders, even if they have different learning styles.

 

Advertisement

 

Mockups can depict anything related to the business change – software screens, tables and fields in a database, or process flow diagrams. By collaboratively creating these items, BAs can engage stakeholders in a shared journey of discovery. During this journey, BAs can introduce new data points and information to gently transition stakeholders from entrenched “I-know-best” positions to the more neutral territory of shared learning. This additional territory can yield discoveries in terms of requirements and solution approaches. And sometimes, it can identify previously unknown common ground for adversarial stakeholders.

I participated in a real-world example of using mockups in this manner. During an elicitation session, two stakeholders adopted opposing views that involved a simple workflow. Each stakeholder had something of a point – stakeholder #1 argued that the solution should require completing a specific task before continuing; stakeholder #2 argued that finalizing that task later allowed for more flexibility.

 

I had mockups depicting a workflow for a related and similar process. These mockups were simple slides with screenshots and text boxes calling out the user workflow. I quickly made copies of those mockups to depict each stakeholder’s approach. Each stakeholder was able to instruct me on tweaking their mockup as needed; then, using the mockup as a visual aid, the stakeholder could articulate their approach more effectively. By comparing them side-by-side, it was easier for both stakeholders to see the validity and shortcomings of each. During our discussions, a third approach emerged, which we were quickly able to mockup. The stakeholders negotiated from their combined shared learning experience and agreed that this third approach would satisfy their requirements.

This real-world example of resolving stakeholder conflict with mockups reinforces the importance of the visual:

  • Stakeholders could more easily understand the relationship between their disparate requirements when mocked up.
  • Stakeholders could better appreciate alternative user workflows as the mockups clarified it.
  • Stakeholders could envision and agree upon a compromise solution when mocked up.

The mockups clarified the merits and obstacles of each approach and made the third (compromise) choice obvious. Even if the stakeholders had not agreed on the compromise solution, the depictions provided by the interim mockups would have clarified their point of disagreement and made their conflicting priorities clear.

Even in requirements, a picture is worth a thousand words.

BATimes_OCT26_2022

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!

BATimes_Aug10_2022

The Courage to Try Something Old – Part 2: Scribing

In the previous article I wrote about the importance of facilitating requirements meetings and why it can take courage to do so. In this article I’ll discuss another skill that has fallen in and out of favor over the years—scribing.

Many ancient societies valued scribes. Scribes typically were at the center of all activities and highly regarded in the areas of government, law, military, and religion. Today’s scribes are not so universally regarded, particularly in our world of PMs and BAs. Effective scribes should be at the center of requirements activities, but most often they are not. We’re often in the back of the room or off to the side. We’re not always introduced in virtual meetings. Many organizations view scribes simply as passive note-takers and unfortunately that’s how many scribes view themselves. But I have found that scribes are essential to the success of the project.

 

What is a scribe and what does a scribe do? A scribe is the role that provides documentation, either formal or informal, and anyone can play that role. PMs, BAs, facilitators, business owners, QA analysts, programmers—it doesn’t matter what the title is. Any time we’re documenting our PM or BA work we’re scribing.  Our output can include recaps of sponsor and other stakeholder meetings, requirements (models, textual, etc.), assessments, gap analyses, and business cases to cite just a few.

 

What skills does a scribe need? Like every effective PM and BA, the scribe has to create structure from chaos. That’s not easy so scribes need a variety of skills, such as listening, absorbing, clarifying, and writing. But perhaps most important is critical thinking, which comprises many skills including:

  • Conceptualizing – grasping what’s being discussed because we have enough context[i]
  • Applying – taking what we know from our experience and using it in new situations.
  • Synthesizing – absorbing lots of information, processing it, and making sense of it immediately.[ii]
  • Evaluating – knowing what’s important and what’s not, what works and what doesn’t.[iii]

 

Advertisement

 

Why do we need scribes? Documentation is important if for no other reason than because it saves time. We cannot possibly remember all the salient topics of our project and requirements meetings. Documentation helps prevent revisiting and revisiting again all the important decisions already made and who should complete which action items and by when.

 

How much courage does it take to scribe?  Why in the world would it take courage to scribe? Because the most common scribing pitfalls relate to courage. I am often asked questions such as these:

  1. What if the PM and/or team thinks it’s a waste of time to have a scribe?
  2. What should I do when the facilitator wants to “take notes,” but in the end, much of the meeting is lost because the notes are too sketchy?
  3. What should I do when I’ve been told to sit in the back and be silent when I take notes? Most of the time I have questions or want to clarify what’s been decided, but I’m told that asking questions will take too much time.
  4. What should I do when I’m asked to distribute the documentation in an unreasonable time frame?
  5. I know it’s important to recap the highlights of my scribing output at the end of the meeting, but we never seem to have time. Our discussions always run over.

 

If we are too timid to address these issues, we will be less useful not only to our project team, but the entire organization. But it takes courage to tackle them. We need to be effective at influencing, and courage is a main component of influence. We need to ensure that everyone understands the importance of both scribing and the scribe role, and it takes courage to point these out. It takes courage to speak up about the risks of not having scribes in organizations that don’t value them. And to link an unsatisfactory product delivered to stakeholders to effective scribing. And because it takes time to be an effective scribe, we need to advise including scribing tasks in project planning.

Finally, as scribes we need to be neutral and not have a vested interest in the outcome of the meeting. As we know, the person with the pen has the power and can rewrite the project’s history. Let’s not sneak in a couple of our or our sponsor’s favorite requirements, or conveniently forget any because it’s easier than seeking a scope change. And there’s no need to document every conversation– the key items like decisions and action items will do. When done well, scribing is a thing of beauty. When not, it might well be tossed out with other old but necessary techniques—definitely not in the interest of either the project or the organization.

[i] This often comes from past experience and is one of the reasons I’m not in favor of “neutral” scribes
[ii] This is one of my favorite scribe skills because it is essential in a requirements workshop where there’s so much happening at the same time.
[iii] louisville.edu/ideastoaction/about/criticalthinking/what for the 4 basic concepts
BATimes_Aug3_2022

Just because you are in the minority doesn’t mean you are wrong!

Speak to any group of BAs, and they will empathize with the frustrations of a familiar experience: you have spotted a potential problem on the horizon, but you’re struggling to convince teammates and stakeholders that it needs addressing (or even that it exists at all).  Argh!  So why don’t people believe us, and how can we help them see what we see?

 

The unique BA perspective

Even if you work collaboratively with a range of stakeholders, the nature of the BA role makes you something of a solo operator.  You are often the only one of your kind assigned to a multi-disciplinary project team, and – while you will be consulting widely with others – the analysis input of your role comes from you alone.  Working at the interface of many sources of information puts you in a unique position to see things others can’t.  It is both a blessing and a curse: while you can add value by making inferences and drawing conclusions that aren’t obvious to the folks on the ground, your insights are not always readily received when those folks are preoccupied with other lines of endeavor.  You want to share your findings to help improve outcomes; they want to get on with their work without the BA derailing it.  You may not be a specialist in their area, so why should they believe you?

 

The best of times

If you have good working relationships with your team or stakeholders, a carefully timed question or constructive conversation is all you need.  Project professionals are often keen problem-solvers like you.  If you need to spend more time unpacking each other’s points of view, you can resolve most queries amicably with a chat around a whiteboard.  Be mindful that specialists won’t necessarily welcome direct challenge from a non-specialist: in these situations, you may find it beneficial to cast yourself in the ‘apprentice’ role.  Ask your specialists to help you, the interested non-specialist, understand the matter at hand by walking you through an explanation; you can then cannily insert your leading questions at the appropriate point.  You may, of course, have misinterpreted something and be flat-out wrong – so be prepared for that eventuality!

 

The worst of times

Sometimes, however, that initial conversation doesn’t cut it.  You’re still sure that you’re on to something – the discussions haven’t disproven your theories – but you cannot get others to consider, let alone understand, your way of thinking.  You feel like the prophetess Cassandra of Troy from Greek mythology: fated to see the future and obliged to speak the truth, yet never to be believed.  So what’s a BA to do – why isn’t the message getting through?

 

Advertisement

 

Understand the problem

As with any analysis, the key is to identify the root cause of the issue.  It’s easy to take it personally when your concerns are dismissed without consideration but don’t automatically assume malice.  There are lots of reasons why people may not be responding as expected:

  • You might not have communicated your ideas as clearly as you thought.
  • You communicated clearly but caught them on a bad day.
  • People with other viewpoints outrank or outnumber you – people tend to be swayed by power or a majority.
  • They might not feel secure in what they are doing and don’t want to be challenged by any ideas that could throw things off balance.
  • They may lack the contextual knowledge or technical aptitude to understand your ideas.
  • They have different priorities (or different agendas!).
  • You might not be their ‘preferred sender’.

The last point can be incredibly frustrating.  Sometimes, despite you doing absolutely everything else right, you are just not the person to whom your audience is willing to listen.

 

Formulate your plan

Once you’ve figured out what’s going on, it’s time to get a communication action plan together.

  1. Identify your target person or people.

To achieve your desired outcomes, who do you need to persuade to consider your point of view?  Sometimes, this isn’t the person you think of first.  Is there another individual whose voice is more likely to carry weight with your ultimate target?  If so, it may be better to channel your energy into helping this individual understand your concerns and letting the message travel forward via them instead.

  1. Curate your materials and your messaging.

Cut the waffle: what are the key points you need to communicate?  And how are you positioning your message?  If the presentation format you’ve used so far hasn’t worked, try something new: can you package things up differently?  People often respond favorably to visual material if it helps them get to grips with something less familiar.  Sometimes a diagram can make all the difference.

  1. Build your coalition.

Are there others who understand your perspective and could help influence the conversation with your target person or people?  More people saying the same thing can add credibility to your message through endorsement and weight of numbers.

  1. Pick your moment.
    Timing is everything. Your message is unlikely to land well if you try to share your thoughts in the middle of an unrelated but all-consuming disaster, for example!  Aim to create appropriate time and space for a calm, focused discussion.
  1. Be prepared to play the long game.

It may take several attempts to land your ideas, particularly if you have had to involve other people to help deliver your message.  Consider the overall impact of your interventions on your target person or people.  How will the sequence of interactions be experienced from their point of view?

Once you have the above in place, you can initiate your plan.  Good luck!

 

Know when to hold and when to fold

One of the more difficult things to accept as a BA is that things don’t always go how you think they should, even if you have the truth on your side.  It’s a great feeling when your suggestions are recognized, valued, and help shape the work to come, but it’s equally likely that you will hear: ‘Yes, I understand what you are saying, but we have to do it X way because of Y.’  Don’t feel disheartened if this happens to you.  If you have managed to get people to understand your point, no matter the eventual outcome, you have done your job.  You have identified a potential issue, surfaced it for consideration by the appropriate stakeholders, and enabled an informed decision to be made in consequence.  There is one less unknown in the project landscape; it’s time to let that point rest.  Onward to the next challenge!