Tag: Tips

The Pitfalls Of Efficiency: Process Improvement Is A Balancing Act

Written by Adrian Reed on April 24, 2024. Posted in Articles.

Business analysis work often involves improving processes. This might include simplification of a process, reengineering or automation. When used well, IT can be used to enhance (or even completely rethink) a process. The ideal outcome is to design a process that is quicker, more convenient and more cost-effective than what it replaces.

When aiming for efficiency, it’s important to ask “for whom are we optimizing this process?”. This might sound like an odd question to ask, but often there’s a fine balancing act. A process that appears very efficient for a company might actually be very inefficient and inconvenient for its customers. Standardizing a procurement process might create internal efficiencies for the company involved, but might place additional work on the company’s suppliers.

An Example: “No Reply” Secure Email

I was recently a customer of a company that would send correspondence via secure email. I’d receive a notification via regular email, and I’d then need to log in to the company’s secure email portal to read what they had sent me. This was fine, except the emails they sent were all from a ‘no reply’ address. While the secure email system they had implemented literally had a ‘reply’ button, there was a disclaimer on every email they sent which said “don’t reply, as we won’t read what you send us” (OK, it wasn’t that blunt, but you get the idea!).

This led to the crazy situation where the only way of replying to their secure emails was to either call via phone (and queue for 45 minutes), or put a reply in the mail.

This is an example of a situation where convenience and savings are predominantly biased towards the company, with some minor benefit for the customer. Prior to sending secure email, they would put correspondence in the regular mail. Moving this to an electronic platform presumably saves in printing, postage and stamps. It’s of marginal benefit to customers too, as they receive correspondence quicker (providing they look at their email regularly).

But the real customer benefit would have been to be able to correspond and reply with the company via secure email. Ironically, by implementing the solution the way that they did I suspect their ‘no reply’ mailbox is actually full of replies from customers who didn’t read their disclaimer!

There is no “right”, it’s a balance

As a customer, I found the situation frustrating, but there is no inherent or universal ‘right’ answer here. It might be that the company in question had deliberately chosen not to accept incoming secure email for compliance reasons, or perhaps they feared they’d be flooded with lots of customer inquiries as they are now ‘too easy’ to contact (although I’d argue that if this is the case then there’s probably a bigger root cause they ought to be contending with!).

The point here is that it should be a conscious balancing act. It is all too easy to create a situation that is more efficient for one group of stakeholders, but actually worse for another. An employer who decides to streamline their process for employees who need to claim travel expenses might decide that they can save time if they ask their employees to input more data at the time they submit their claim. If they get the employee to select where the expense was incurred, the amount of sales tax that was included in the expense, the category of cost and so forth, then this saves time later. Yet an employee who isn’t a tax expert might find this frustrating (“Is train travel exempt, or zero-rated for sales tax?”). Of course, in reality this will likely affect the quality of data too, as people try their best (but don’t know which of the different tax code options to choose).

This is a specific example, but it highlights a wider point: it’s important to consider process improvements from the perspectives of the stakeholders impacted. This involves considering what efficiency as well as effectiveness looks like for each key group.

As with so much in business analysis, stakeholder identification, engagement and empathy is key!

The Tyranny of the Algorithm

Written by Adrian Reed on August 16, 2023. Posted in Articles.

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

Written by LN Mishra on August 4, 2022. Posted in Articles.

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.

Written by Matthew Pountney on June 28, 2018. Posted in Articles. 3 Comments on 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

Written by Markanthony Akem Bsc Economics, MBA on January 23, 2018. Posted in Articles. 2 Comments on 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;

Evangelist,
An agile champions
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;

Leadership approval.
Plan to communicate transparency.
Purpose in Message.
Train and Coach.
Set designated meeting location.
Use radiators.
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.