Skip to main content

Tag: Other

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]




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] for the 4 basic concepts

50 Most Dangerous Words for Business Analysts

As business analysts, it’s our primary responsibility to bring clarity to requirements communication. Unfortunately, many words spoken by our stakeholders can be ambiguous. Not understanding these words in their proper context or without adequate information can lead to situations where different stakeholders can have a different understanding of the same word.

One of my very favorite words is Manage. Manage can mean anything under the sun to anyone. For example, managing a schedule to me means creating a schedule, viewing schedule, updating schedule, deleting schedule, importing schedule, exporting schedule, reporting on schedule, and alerting schedule delays. For the developer in my team, managing a schedule could simply mean creating a schedule, viewing the schedule, updating the schedule, and deleting the schedule (The four fundamental operations on data).

Discussing the ambiguous terms with stakeholders will give them the idea that something is also missing from their end. They can do some more research to find how exactly they want the system to behave rather than giving information that is at a higher level. In this blog, I am writing down the top 50 ambiguous words I came across as a business analyst. I want all my business analyst friends to contribute to this list so that we can comprehensively list the ambiguous words.

Any time any of our stakeholders use these words, we would know that there is some ambiguity involved. It’s not that the ambiguity is always bad, but it must be clarified before something goes for designing and development. So till the time we are far away from that, it’s ok, but as we come closer to the design and development phase, we must find the real concrete information so that the development team can design the solution as per the stakeholder requirements.




Rank The word What makes it dangerous
50 Most appropriate Who decides what’s most appropriate?
49 As soon as possible In the next 5 seconds?
48 In future By EoD Tomorrow?
47 ETC Missing details
46 TBD When?
45 Usually Where is the unusual stuff?
44 Generally Non-precise
43 Normally Non-precise
42 To the greatest extent Who decides the extent?
41 Properly Non-precise
40 Where practicable Conditions not specified
39 Supported Passive voice, Actor unknown
38 Handled Passive voice, Actor unknown
37 Processed Passive voice, Actor unknown
36 Rejected Passive voice, Actor unknown
35 Always Assumed certainty which does not exist
34 Never Assumed certainty which does not exist
33 All Assumed certainty which does not exist
32 None Assumed certainty which does not exist
31 Every Assumed certainty which does not exist
30 Earliest Non-precise
29 Latest Non-precise
28 Highest Non-precise
27 Fastest Non-precise
26 Flexible Non-precise
25 Modular Non-precise
24 Efficient Non-precise
23 Adequate Non-precise
22 Minimum required Minimum shall be achieved
21 Minimum acceptable Minimum shall be achieved
20 Better Non-precise
19 Higher Non-precise
18 Faster Non-precise
17 Less Non-precise
16 Slower Non-precise
15 Infrequent Non-precise
14 To the extent specified Non-precise
13 To the extent required Non-precise
12 Very high Non-precise
11 Very low Non-precise
10 Fantastic What is Fantastic?
9 Multiple currencies Which currencies?
8 Multiple languages Which languages?
7 Multiple browsers Which browsers? Even for the same browser, which versions?
6 Robust Non-precise
5 Sturdy Non-precise
4 User-friendly Non-precise
3 Great performance How do you determine that?
2 User All users or specific types of users?
1 Manage Possibly the most dangerous verb – Can mean anything under the sun

What other words would you like to add to the above list?

3 Career Stories Where IIBA Certifications Truly Helped

The International Institute of Business Analysis (IIBA) is a professional association formed in October 2003 with the stated goal of supporting and promoting the discipline of business analysis. In another word, IIBA is the professional body for business analysts.

IIBA is providing many types of certifications and they all have their own benefits. In the past 10 years, I have experienced various occasions where, either myself or people I know, have achieved great and tangible career results thanks to certain IIBA certifications.

Here are 3 stories with 3 IIBA certifications, which apparently do not represent all the useful certifications that IIBA provides. However, I believe you will get a strong message why you may want to become a certified business analyst.


Story 1: A university graduate

A promising young talent was about to graduate from university. She had equipped her resume well with IT & BA courses, project-based-learning initiatives, internships and workplace experiences. However, based on her job seeking experiences, she had an impression that sometimes she was perceived by potential employers as “indifferent” to other university graduates.

She was determined to make a difference in job applications. The action she had done was to have obtained the ECBA (Entry Certificate in Business Analysis) certification, which was then added as a highlight to her resume and used in job applications.


In a final round interview, she successfully stood out by saying “I have been certified in the same (IIBA) framework as experienced BA’s use”, while other candidates claiming, “I am a quick learner”.


I’m sure you will also be empowered by the story if you are currently looking to transition your career towards a business analyst role.


Story 2: A 2nd year Junior BA

A young IT professional completed her 2nd year of work anniversary in an IT consulting firm as a junior business analyst. Although she progressed a lot in BA competencies and demonstrated consistent work performance, it was frustrating that a lot of people in the company, including her manager, still saw her as “that Junior BA”.

She decided to remind her manager in a polite yet effective way. Weeks before the annual performance review (a.k.a., salary review), she had completed her CCBA (Certification of Capability in Business Analysis).


In the performance review meeting, she showcased the details her outperformance, coupled with her CCBA certification and the techniques she had acquired from the study of CCBA. At the end of the meeting, she asked for a promotion to Intermediate BA. She got the good news soon after.


Story 3: A Senior BA who wants to change industry

A senior BA got 10 years’ BA experience. He was always in the telecommunications industry but now wants to pursue a career in the financial service industry. He had a few interviews, but all ended up not well. The typical feedback he had received was “solid BA but lack of domain experience”. He took the advice from others to study towards CBAP (Certified Business Analysis Professional).


After being CBAP certified, he was invited to an interview with a local bank. He made a point to the interview panel that “BA skills are transferable across industries” and outlined his BA expertise that had been certified via CBAP and that would add value to the bank immediately. After a week he got a phone call from the hiring manager asking for referees.



Summary: ECBA/CCBA/CBAP Comparison Table




  1. IIBA Certifications,