Skip to main content

Tag: Tips

The Tyranny of the Algorithm

A while ago, I noticed that some people changed the way that they were writing LinkedIn posts. Rather than writing in sentences and paragraphs, everything would be written in this weird separated way with everything spaced out in a really unnatural way.  Then certain other common patterns appeared (e.g. using PDFs documents with multiple pages, or ‘carousels’ as some people call them).  Video was huge, then not huge, and so the trends fluctuated.  Some of the formats seemed really good and useful… others… not so much (we’ve probably all clicked on the occasional ‘click bait’ LinkedIn post…).

I gather one of the reasons that people post in particular ways is to get maximum exposure, and to do this you have to pander to the algorithm.  It is, after all, the algorithm that will decide how many people see your post…  and not all posts are created equal.  Those that get more ‘engagement’ will be seen by more people (and, very likely, get even more engagement).  Yet the algorithm decides what counts as ‘engagement’.

There’s nothing inherently wrong with this. LinkedIn is a private enterprise, it can (I suppose) run its operations however it chooses. But take a step back for a moment, and let’s make a hypothesis here:


The algorithm has changed the way people write content and interact with others on LinkedIn

I’m making no moral judgment here, and the way that people write and engage with each other has adapted over the years. But let’s follow this to its logical conclusion: social media algorithms have the ability to influence the style and formats in which people communicate. It decides what content gets seen (and doesn’t get seen). Again, as users we might be OK with that. But I hope that there is someone within those companies asking a whole set of ethical questions…


Avoiding Biases and Unintended Consequences

In particular, it’s important to consider whether algorithms might lead to bias, and might inadvertently disadvantage or affect particular groups or stakeholders, or whether they might have other types of unintended consequences. For example, I’d imagine that the LinkedIn algorithm probably aims to keep people on the site for as long as possible, and serve them up relevant adverts. But when people learn its nuances, they start to ‘game’ the algorithm, meaning that some folks are more likely to get their content seen than others. Presumably, LinkedIn eventually learns about this too, and adapts the algorithm, and the process repeats.


Yet unintended consequences like this aren’t limited to IT or algorithms. Nor are biases  (there are plenty of well-documented cognitive biases that affect people too). Crucially this is an area where BAs can help ask some of the difficult questions, and get beyond (or at least highlight) potential issues.


I have often thought it interesting that within most organizations, if you ask the question “who is responsible for regulatory compliance” you will get a clear cut answer. There is usually a legal or compliance team, and often a named individual who is responsible and accountable. Ask “who is responsible for the ethics of this product or project?” and (outside of some very specific domains) you’ll likely get a blank stare. Or, you’ll get a word-soup answer that boils down to “we’re all responsible”.  And when everyone is responsible, too often nobody steps up to ask the hard questions.




The Ethical Imperative

This is a space where BAs can add significant value. As BAs we’ll be used to conducting stakeholder analysis, thinking in terms of the different stakeholders or personas who will be impacted by a particular proposal. We can extend this thinking by asking “who isn’t here around the table, who is missing from these conversations, and how can we ensure they are represented?”.

We can ask the difficult, but important ethical questions, and ensure that the projects and products that are progressed by the organization are in line not only with its strategy but also its values. If there’s a strategy-execution divide in many organizations, that’s nothing compared to the values-execution divide! (We’ve probably all had experiences with organizations that say they ‘put the customer at the heart of what they do’ that… definitely don’t actually do that!).


Often, as BAs, we are able to take a step and ask “what is the impact of this”, and “what does success look like for X stakeholder group?” and “how does that vary from what the Y stakeholder group thinks?”.  By taking a holistic view, balancing different viewpoints and putting an ethical lens on things, we can hopefully reduce the risk of inadvertently introducing bias or unintended consequences.

This involves us having the courage to ask bold questions and keep ethics firmly in mind. If we don’t, there’s a real danger that the ethical dimension will get missed. A situation that I’m sure we’re all keen to avoid!

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?

5 Project communication mistakes.

Business analysts can get so lost in the details of the projects that we forget to tell the people who are most affected.

Or, we try to tell them but they don’t quite understand. Or we just talk to senior stakeholders and ignore the rest. 

Here are five ways communications can go wrong.

1. Treating communications like a luxury

The change manager – or dedicated communications officer on big programmes – is often the first to be cut, if indeed the investment has been made in hiring one to start with. The logic here is that running a good communications operation is secondary to delivery activities and, in one memorable case, I’ve heard clients refer to such roles as ‘walking headcount’, meaning their days are numbered.
However, as many teams quickly find out, there is very little on a project that does not fall within a communications officer’s remit: obvious work such as keeping end users informed of a project’s progress and probable impact but also vital but more subtle work like managing different types of stakeholder, creating alignment in messaging, getting buy-in and support. Without this, most BAs managers quickly find themselves sinking and having to dedicate much of their time to this work – taking it away from ‘delivery’. 

2. Failing to manage tricky customers effectively

As every contractor, consultant or internal BA knows, stakeholders can be a difficult crowd. Personalities vary, irrespective of seniority: one likes detail and weekly updates, one just wants the headlines and a quarterly steer co; another refuses to read emails but claims to have not been informed; others vie for political advantage over their colleagues at the expense of all other agendas.
Ineffective strategies for dealing with these situations include ignoring difference, trying to pander to everyone or taking the situation personally rather than seeing it as a communications challenge. Through this lens, all inter-personal friction can be mitigated and every stakeholder can be managed; indeed, the only failure is to give up and stop trying new approaches.


3. Creating an information vacuum, allowing gossip 

Many projects become their own worlds, often seeing the multitudes of stakeholders who will ultimately be affected by the project’s outcome as an afterthought. Well, people talk and a lack of information will be addressed through gossip. Before you know it, stakeholders will believe your project has nefarious goals or – perhaps worse – that you are going to make all of the organisation’s problems go away.
Clear communications are the only way to manage this, ideally presented by a client stakeholder with good rapport with the affected groups. 

4. Being boring

We go to work and – for whatever reason – we think everyone else suddenly wants to be bored out of their minds. So we fill our emails with tired jargon or we inflict long PowerPoint presentations on our colleagues or we feign enthusiasm in the hope our project team will feel motivated. But, our brains in the office are the same as they are outside the office: same attention span, same interests, same intelligence. Not using this fact and communicating in a similar way to how we are accustomed outside the office is a mistake that is sure to see your message being lost or ignored.
Business analysts are particularly culpable. Sometimes, we manage to be both dull and over-bearing to our stakeholders – or try to inject ‘fun’ that numbs the mind of on-lookers. The best approach here tends to be to deliver simple messages, ideally with no more than one or two slides in support. With so many free third party tools available, many of us could also consider playing with well-formatted html emails, infographics, video presentations; but it is rare such media replace the strength of a solid and impactful presentation. 

5. Being slow

Many projects that do have a dedicated change officer responsible for communications spend a long time devising a strategy, defining which communications go to which people at which times. This is useful in principle but often they are encumbered by having to get approval for the plan – or individual communications – from unavailable stakeholders or of over-ambitious and costly strategies that end up either never being implemented or rushed at the last minute. Communications are, by their nature, newsworthy – and news must be delivered while it is still new.
Business analysts on projects of all sizes need fixes for these issues to allow them to focus more on the day-to-day running of their projects. If you want to explore ways to address these issues and manage your communications allowing more time for higher-value project activities, please feel free to reach out to the writer of this article.

Agile Evangelization – 7 Must Haves For Evangelization

The use of waterfall methodology has typically been the standard for project development and management.

Nonetheless, the spread of agile as a concept began at a time not too long ago as a result of rapidly growing productivity needs and faster product to market delivery requirements. With agile being a framework that reflects on change in mindset, implementing it as a practice requires well-crafted initiatives such as evangelization to derive required result(s).

Agile evangelization as defined by Guy Kawasaki is the act of leading people towards better ways of developing software. He went further to state that evangelism is firmly rooted in what is good for us individuals and organizations alike. But contrary to Guy’s reference to software development, agile evangelization can defined as the process of structuring and positioning of self-organized team activities to drive better process development, product delivery and people management through effective leadership and respect for people. In other words, certain components of teams that are self-organized and performing defined activities are required to drive specific results. Such teams require specialized roles of;

  1. Evangelist,
  2. An agile champions
  3. An extended team.

We have used the phrase agile evangelization quite a bit as well as pointed out its roles but what does it really mean? In my understanding, agile evangelization can be defined as a stakeholder buy in initiative(s) that is aimed at familiarizinga non-agile team, group or individual with the core principles and practices of agile.

In my studies, I identified the following as being the core items needed for a successful agile evangelization;

  1. Leadership approval.
  2. Plan to communicate transparency.
  3. Purpose in Message.
  4. Train and Coach.
  5. Set designated meeting location.
  6. Use radiators.
  7. Create group for champions.

Leadership approval: Leaders carry influence and as such their approvals hold water. Employees tend to take serious what their leaders support or voice concerns on. Leadership guidance shields evangelization and introduction of net new initiative(s) into an environment. So, for effective and meaningful evangelization, leadership engagement is critical to success of such initiative. Also if there is a leader, people follow as against work for such person. Leaders sell and deliver on well thought out vision and can earn trust and confidence of people they lead.

Plan to communicate transparency: People respond better to change and transformation, when there is an understanding of the obvious. In other words, change should be transparent and communicated in lieu of its commencement. As a leader, it is a sole responsibility to ensure all employees understand and are willing to align with an agile evangelization initiative put forward.


Purpose in message: Common sense rules require purpose clarity in message delivery and so does agile evangelization. Part of communicating an agile evangelization is that, supposed adopters of the framework require understanding, as to how the overall change vision aligns with their existing process. People want to know their place in the change, what does the change means for their role and where obviously they fit in. Clarifying this would advance any agile evangelization initiatives that are brought forward for adoption.

Train and Coach: Train your people and expose them to the concept of agile. In light of the training, there should be reinforcement with coaching as a way of maintaining continuous knowledge transfer. In transitioning from waterfall to agile, evangelization is most crucial as people are usually not fully aware of the agile concept and its practices. As such, training and coaching to reinforce knowledge, plays key role in maturing people in that environment with the concept.

Designated meeting location: When kicking off an evangelization initiative, ensure there is a designated location for meetings. All participating groups should know of the designated meeting location. An accessible location not too far but centrally positioned, will drive participation during knowledge sessions.

Use radiators: Use of information radiators is the best way to keep knowledge flow constantly streaming to agile adopters. Information radiators server as visual aid and constantly reiterate learning for people who have no prior knowledge of the concept. Designated locations for agile evangelization meetings can always have radiators posted on the walls to visually remind people of the initiative goal.

Create a group for champions: The fifth principle of agile encourages building a team around motivated people. As such, an experienced evangelist would identify, select, train and coach a group of motivated individuals to be champions. Who is an agile champion? What does an agile champion do? After a close review, I came to the conclusion that while an evangelist provides and interprets the concept of agile core values and principles, champions reinforce the already defined concept and sell it to non-motivated members on their immediate teams. The point is that people relate to change better when it is from a trusted source.

In summary, agile evangelization is a best practice for introducing agile in non-agile environments. Delineation of roles further breaks down the responsibilities and thus, makes evangelization efforts far more reaching and entrenched in the process DNA of an organization.

Certify or Not to Certify – That is the Question

I do not have a certification. I do not have a string of capitalized initials after my name.

I do not need to have the affirmation that I am knowledgeable, skilled, or experienced by having extra ink printed on my business cards.

However, perhaps you do have a certification; a string of initials after your name, and a deserved sense of pride that goes along with that accomplishment. After all, to be able even to submit a CBAP application you must have 7500 hours of BA experience that is verifiable. Yes, I can see how that certification can entice many toward that elusive “pot of gold” career game-changer.

A certification can be worth the pursuit as much as it cannot be. The variables to determine a value-added proposition to your career are many; are parabolic, and are personal. Many times, a certification is pursued under the guise of the qualification for employment. I will tell you this: if an employer states a CBAP as a requisite qualification for a job, then perhaps that company does not understand what they even want and why! I say this because it is all about the numbers:

  • There are approximately 6700 CBAPs worldwide.
  • There are approximately 2500 CBAPs in the United States.
  • There are approximately 120 CBAPs in Minnesota; 70 in the Minneapolis/Saint Paul metropolitan area (where I live).

There are no hardcore statistics, but there are estimated 1.5 million analysts in the US. There are an estimated 5,000 BAs in Minnesota. 120 CBAP certifications are 2.4 percent of the BA population. If an employer requires CBAP certification to be considered for a job, then their population sample to choose from will be very slim. The good news is if you have a CBAP, then you are a shoe-in for the job!

Does it matter to your career if you are certified? In the above example, it certainly could. But what about a break out of the ‘value-added variables’ I eluded to above:

  • How long have you been in this career path?
  • Do you have formal training?
  • Have you been mentored?
  • Is your experience industry specific?
  • Are you a member or an officer of a professional organization?
  • Have you been published, a speaker at an industry event, or provided training in your field?

I feel the above list of variables could certainly trump a certification. I say this based on the premise of the resume; what is the first section of a resume (excluding a summary)? It is work history/experience. The second section is education. The last section, typically, is professional certifications, awards, accomplishments. Personally, I have over 25 years’ experience in various industries. The pursuit of a certification would not be prudent since it will render me no value. I am at the top of my field in title, experience, and compensation. Should I choose to focus on a different industry, then perhaps a certification can add value, especially if that industry is in high demand of filling job vacancies, like in the field of security. If an individual with 5 years’ experience and that many years out of college ask me about certification, the conversation will be very different and very PRO-certification as well.

I have focused mostly on a CBAP so far. There are other certifications that can enhance one’s career if a BA is looking to diversify. Many BAs also pursue a Project Management Professional (PMP). Some look to Agile and pursue Certified Scrum Master (CSM). There are security certifications, business process certifications, change management certifications, IT specific type analyst certifications, and on and on and on.

To determine if a certification will help you or is worth the investment in time and money, you must perform a career assessment and lay out your future goals. Do you want to follow a career path of the technician or the manager? Is your current job title a stepping stone for a bigger goal or is this job title going to be prefixed with “Senior” or “Lead”?

One thing that may be a bit tricky is to acquire a certification as a means of entry into an industry. If I am a Senior Business Analyst and pursue a certification in security, a Certified Information Systems Security Professional (CISSP), will I be guaranteed a job in the security field? Considering that I have been in the healthcare industry my whole career, perhaps not. However, as stated above, this is a high-demand industry, so perhaps that will be the golden ticket for securing a job. These are all things to consider.

Some industries do require a certification as a requirement for entry; law, medicine, financial planner, for example. Until there is regulation, a certification will not be a mandatory requirement for entry into whatever that industry job world could be from project management, business analysis, or scrum. Regulation of business analysis will probably never happen, which means that the ones who are certified, may stand out as unique, and perceived as experienced, but certainly do not corner the market unless the certification process is abused, that is. I have seen the following in a LinkedIn profile (the name is changed to protect the guilty):


If you were an employer, would you be impressed or not?

As an employer, I feel if you are going to spend all your time certifying, how can I trust you actually know anything on an expert level of any of those fields? Some people may be impressed with quantity; I say err on the side of quality. I would say pick one, two, perhaps three certifications and just do those well. It just looks like some people are really good at taking tests.

In every job, technology focused or not; there is a distinct path of the flow of information. When you start a job at a company, understand what the information being used is. Where is the information generated; the source? How does it pass to the users? How is it stored and where? How is it loaded into the storage?

Is it manipulated/transformed in any way? How do the users of the information use it to perform their jobs?

From my experience, a certification for a job in a company is not necessary because in some cases knowledge and experience trump a certification. Conversely, a certification at that point in your career where you have significant experience can be what it takes for you to propel to the next level in your career. A certification is not the silver-bullet remedy to acquiring the job you want.

Certification is a badge of honor to wear proudly. Regardless of the reason or motivation to certify, the bottom line is simple. Perform your job well, and you honor your certification initials at the end of your name. Perform your job poorly, and you tarnish your certification and your peer’s certifications. Once you certify, you are an ambassador for certified professionals.

To choose certification or not to choose certification – that is the question.