Tag: Tips

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.

Certify or Not to Certify – That is the Question

Written by Stewart Mednick on April 6, 2017. Posted in Articles.

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):

Joe Lunchbucket CBAP, PMP, PMI-PBA, PMI-RMP, CSM, ITIL, CRM.

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.

Project Managers: 7 Things They Want Their Business Analysts to Excel At

Written by Brad Egeland on January 4, 2017. Posted in Articles. 1 Comment on Project Managers: 7 Things They Want Their Business Analysts to Excel At

I decided to perform a bit of a survey or experiment or whatever you want to call it.

I decided to ask several career project managers I’ve personally worked with and a few that I’ve connected with online as to their thoughts on what they wished, wanted or were grateful that their business analysts excelled at on the projects they managed with them. After rummaging through their wishful and rambling responses, I’ve come up with these 7 general themes…

Customer interaction.

The project manager is the key customer facing individual on the project. No question. The PM leads the initial project activities with the customer including kickoff, weekly status calls, and ongoing – potentially daily and sometimes hourly – communication with that project client. But having a business analyst who knows their way around the customer is a huge benefit to the project manager, the team and the project in general. When I’ve had business analysts who felt comfortable conducting meetings and requirements definition sessions with the client on their own, it’s freed up my time and mind to handle other activities on the project, charge less to the given project thus keeping the budget in good health for when issues need to be addressed (and there will be issues!), and perform other work on other projects.

Being technical.

This could also read “being familiar with whatever processes necessary given the industry the project pertains to.” I said “technical” because I’ve really only ever led technical projects. Having the right industry and technology knowledge will smooth the communication process with the project team that the BA really needs to have in order to be properly effective.

Tech documentation.

When the project manager has a business analyst who knows their way around a good project document deliverable, it is truly a great thing. I realize experienced PM’s and good BA’s probably take this skill for granted, but it is not a given. Nor is attention to detail which can lead to error-prone deliverable documents. I know, I’ve had it happen. It resulted in me and my team going to peer reviews on every deliverable going forward due to one business analyst producing three consecutive error-prone versions of the same documentation deliverable.

Being organized.

The organized business analyst contributes greatly to the project engagement without needing close supervision and oversight that a less experienced and less organized business analyst otherwise would. When the PM has confidence in the BA’s ability to just take the ball and run with it on decision-making, project team communication, and customer interaction, the freeing affect for both is incredibly productive.

Handling project budget issues.

I think most business analysts are pretty smart when it comes to expenses on the project. They think more like PM’s who are accountable for such things than tech team members who expend the hours that are in the budget and need to show 100% (or close to it) utilization. In other words, most business analysts – unless they are tech leads dually acting in the business analyst role – know they are considered more “management” than not. I’ve always said that keeping the project budget within 10% of target makes it much easier to stay on track in terms of dollars and budget. Staying in the 0-10% range means you’re always in the zone of “acceptability” and it isn’t likely to go crazy and leave you with a 50% budget overrun to try to fix…which you won’t likely ever be able to do. Having the business analyst who can understand that and help manage that budget and keep it on track is win-win.

Leading meetings.

This one is more than just customer interaction, of course. The business analyst, in many cases, is like the team lead. Interacting very, very closely with the tech lead on the technical projects in the requirements definition process and translation of those requirements into functional design documentation and a technical design document from which a viable project solution can be built. The BA must be, then, a trusted and accurate and effective project communicator. One who knows how to plan for, facilitate and followup on meetings with the team – and the customer, of course. Knowing how to run a status meeting, take notes, put together a meaningful agenda and project status meeting goal and how to follow up afterward with participants to ensure everyone has landed on the same page. Also, as important, is knowing how to put the right people in the seats at every meeting they conduct. It doesn’t do any good to call the right meeting to discuss the right topic if no one shows up. if you can run a good meeting that makes people want to attend and participate in rather than avoid, then you are golden. Someone who can get 100% attendance and participation is critical to project success.

Understanding PM processes, practices and tools.

Finally, yes…they may not be dually acting in the role of the project manager, but knowing how good project management executes and delivers is very helpful. That way they understand what the project manager is doing, is responsible for and probably will need help with. The more the PM and BA know about each other’s roles, the easier and more productive that relationship will be. And that’s a good thing. Think Batman and Robin. And the PM is not always Batman – it depends on what the responsibility is at the moment. They work well together and help each other out. Not quite like completing each other’s sentences…that would be weird. But close. BAM! POW!

Summary / call for input

The project manager and business analyst should work hand in hand together in a perfect world. Nothing is perfect, but my most successful projects have certainly been spent working with a business analyst who could take the ball and run with it. And most I’ve ever worked with have been able to do that – it seems to be in their nature and work ethic and it certainly makes the project run more smoothly and has always resulted in a more confident and satisfactory delivery team to project sponsor relationship.

Readers – what’s your take on this list? If you weren’t included in my small survey…and yes it was a very small pool…then now is your chance to share your thoughts and experiences. Do you agree with this list? What would you change about it? Please share and discuss.