Tag: Communication

Critical Skills Needed for Project Success

Part 1 – Elicitation

This article is the first in a series I’ll be writing about critical skills that all project managers (PMs) and business analysts (BAs) need for success. We need these skills regardless of the type of project we’re on, the industry we’re in, the technology we use, or the methodology we follow. Each of these skills requires a combination of what are commonly called hard skills with those needed to work effectively with others.

This first article is about elicitation. It seems easy. After all, what’s so difficult about asking stakeholders questions? Elicitation, of course, is far more than the questions we ask. When all is said and done, it’s about learning. We learn what our stakeholders want, what they need, and hardest of all, what they expect by asking really good questions and listening to what they have to say with great attention. It’s tricky, though. We can’t do what I did early in my career when I tried to develop a list of requirements by introducing myself and asking what the stakeholders’ requirements were, what they really needed, and what they expected by the end of the project. Simply put, we won’t learn enough to create an end product that they’ll be happy with.[i]

What makes the elicitation process so hard? Here are several pitfalls.


Common Pitfalls

#1 – Missed expectations

Expectations are requirements, but they’ve never been stated. Therefore, we cannot get expectations by asking about them. Our stakeholders don’t think to mention them, and we don’t think to ask about them. I didn’t know about hidden requirements early in my career when I asked the questions like those noted above. Another problem– my focus was specifically on the future state solution. I asked for the features and functions, documented them, and got stakeholder approval. Then the development team built the final product according to the specifications with the inevitable result—a lot of stakeholder complaints.

#2 – People fear the future state.

This major pitfall is hard to overcome for many reasons. Some stakeholders are comfortable with their current state and don’t want to learn or train on the new processes and automation. Others are concerned for their jobs. Still others have a stake in the existing ways – perhaps they were part of its development or a known expert on its use. Whatever the reasons, the fear of the future state can make elicitation difficult.

#3 – The time trap

Many of us are often under so much pressure that we don’t have time to dig deep. We gather some high-level requirements, but we don’t have time to uncover the expectations. And even if we have time, which is rare, many of our stakeholders don’t. Many are available for an initial set of sessions, but interest wanes as the difficult detailed meetings drag on.

So, what can we do? Here are 3 tips for successful elicitation.

Tips for Successful Elicitation

Tip #1 – Use a variety of elicitation techniques

The first tip for uncovering expectations is to use a variety of elicitation techniques. That’s because each technique that we use uncovers a different aspect of the requirements. Here are some examples.

  • Process modeling. This has always been one of my favorite techniques. It documents how people get their jobs done. But as with all elicitation, it’s not easy. For example, one of the most difficult aspects about process requirements is that stakeholders argue over where to begin and where to end and how the processes fit together. Using different process models helps avoid this contention. SIPOCS (suppliers, inputs, process, outputs, customers) help narrow the scope of each model and swim lane diagrams help visualize how the processes fit together.
  • Data modeling. Process modeling is great, but people need information to get their work done. Data modeling helps us figure out what information supports each process step. It also provides business rules and is invaluable on our AI initiatives.
  • Use cases. These models help us understand how our stakeholders want to use the final product. They provide not only the scope, but all the functionality of the solution. And use cases, if completed thoroughly, turn into test cases.
  • Prototypes show what the final solution will look like.
  • Brainstorming yields the power of the group, while one-on-ones often reveal what stakeholders really think.

Tip #2 – Ask context questions

A context question is one that surrounds the solution that we’re building. While we do need to ask questions about the  solution’s features and functions, such questions do not provide the complete picture.

I like to group context questions into four categories of questions:

  1. These questions relate to what’s happening outside the organization and include questions like demographics, language, weather, technology, and compliance/regulatory. These may or may not apply to the project. If they do, we need to understand their effect on our work.
  2. These pertain to how ready the organization is to accept the final product. The bigger the change, the more issues there usually are. We need to know, for example, which stakeholders will be on board, which will resist the change, and what needs to be done to prepare the organization for the change.
  3. We need to ensure that the business problem we’re solving and the proposed solution align with the organization’s goals and objectives.
  4. These context questions are usually those about the current state.

Tip #3 – Know when to use open-ended, closed-ended, and leading questions

Open-ended questions allow the respondents to expand their thoughts. We ask open-ended questions any time we want to learn more. For example, we ask these questions when we’re just beginning an effort, during brainstorming, and when we need to get all the issues out on the table, etc.

Closed-ended questions are forced-choice questions. They have the answers embedded in the question itself, sometimes explicitly as in a survey question, or implicitly. I like to ask closed-ended questions when stakeholders are all over the board and we need them to focus. For example, given all these issues we’ve identified, if you had to choose 10, which would they be?

Leading questions are not questions at all. They sound like questions, but they’re really our opinions stated in the form of a question. “This is a pretty cool feature, isn’t it?” My least favorite leading question is one we often hear: “Have you ever thought about…solution.” Again, it’s not a question. It’s us presenting our opinion rather than asking what our stakeholders think. What’s wrong with that? Remember we’re in the middle of elicitation, which is about learning. Presenting our solutions during elicitation cuts off exploration because we’re telling rather than learning. Later, after we’ve completed elicitation and analysis, whether it’s for the whole project or a smaller part, we can make a thoughtful recommendation.

To summarize, effective elicitation is critical to the development of a final product that our stakeholders are happy with. Elicitation is not easy. There are several pitfalls which are difficult to overcome. But if we follow the tips provided in this article, we will deliver a product that our stakeholders actually like and want to use.

[i] I use the terms solution, final product, and end product synonymously. It’s the solution to the business problem we’re solving. It’s also the product or product increment being produced at the end of the project, project phase, or iteration.

M_SSING Context

Have you ever had a conversation where the context was missing? Have you considered going the extra mile so that everyone has the same viewpoint?

Let us look at the scenario below:

*Person A and B are looking for the same flour brand at a grocery store.

At a grocery store:

Person A: Hello! Would you know in which aisle can I find ABC brand flour?

Store employee: I am sorry, we are out of that brand.

Person A: Thank you!



At a grocery store:

Person B: Hello! Would you know in which aisle can I find ABC brand flour?

Store employee: I am sorry, we are out of that brand.

Person B: Thank you! Would you know if there are other brands of flour? I need the flour for a craft project.

Store employee: Aisle 15 is where you can find all the brands of flour. Any brand would work since you need it for a craft activity. If you would like, feel free to check aisle 20 for craft supplies.

Person B: Thank you so much!


One requirement yet different experience. For a fruitful conversation, all the participants must have the same understanding. The team must work based on the same set of assumptions. How can you ensure the team is on the same page? Start by asking questions. It is second nature for a business analyst (BA) to ask questions. Asking questions merely to extract information does NOT help uncover the detailed requirements. As a result, lack of details could often lead to misinterpretation and miscommunication.

Here are a few ideas that can get everyone on the same page and their benefits:

1. Provide a brief background about why you are asking the questions.

E.g., Instead of asking the stakeholder what is the current billing process? You can ask, “I would like to understand how is billing done? What are the pain points? What are the components of the process that would need to stay in the new application? Comprehending the as-is state will help understand the gaps and offer solutions.

2. A Business analyst (BA) can ask contextual questions to stakeholders. Stakeholders must reveal details without holding information.

Tip: Share these questions ahead of a conversation with a stakeholder. The stakeholders can organize their thoughts and come up with a list of questions if needed.

Bonus:  A BA can offer alternative solutions if they have the same background as the stakeholders.

3. Providing context paves the way for sharing real-world examples by stakeholders. These use cases aid, everyone, on the team in visualizing the user’s world. Based on the second conversation above, it is evident that there are more use cases to flour than cooking.

4. Let us change gears from the stakeholders and talk about the team. When team members have the same context, they can ask questions amongst themselves to strengthen their understanding.


Next time around, be it any conversation, make a conscious attempt to explain why you need what you need? That helps the other person understand your perspective and intent. After all, one term can have multiple meanings depending on the context used. The context can change the entire landscape of the conversation.

“For me, context is the key – from that comes the understanding of everything.” – Kenneth Noland.

Meeting Expectations When It Comes to Meetings

Meetings. The conglomerated work effort to bring about the grouping of individuals to converse and discuss topics of relatable interest at a given point of time. In mere words, meetings are one of the several crutches of work in business analysis that endeavors to accomplishing our goals. Whether you relish them or dread them, meetings are compulsory. Open your calendars and assuredly you will see on a daily or weekly basis that you have a concentrated number of meetings spanning numerous projects. Or, if you are one of the lucky ones, your meetings can be far and few in between. My personal record in the marathon of meetings has been eight meetings in a workday, all different, varying projects and spanning four hours of the day. When I converse with people outside of work and inform them of my longwinded hours of speaking or listening in on meetings, they give me an incredulous look and with care: “How do you get any work done?”

Some of us may admit that we have faced this question and own to some self-truth: we may not be wholly paying attention to the meeting. Answering emails, preparing for the next meeting; perhaps, you stepped out for a quick cup of coffee, with the camera off as a preventive measure. In the virtual world that we found ourselves transitioned to by the public health pandemic that is COVID-19, it has allowed ourselves to grant meeting liberties we would not possess if we were meeting in the office. However, authentically, we should be setting our expectations and meeting them when it comes to these meetings to effectively achieve our objectives. So, when I was posed with this question, I took some time to reflect, and born was this article. How do we meet our expectations when it comes to meetings to make them effective and to get “work done”? For myself, it has become a set of principles to follow as a guideline when it comes to these sessions. These fall into timing, focusing, documenting, and communicating.


There are only so many hours in the working week that we can accomplish what we want to, and it never feels like there is enough time. Meetings can be an impairment to our limited time in the week, miring our stacked to-do list. However, it does not always have to be this way! The first tenet to the meetings is to appropriately time them. Timing with effectiveness is everything when it comes to the foundation of a meeting. Consider, when scheduling one, an honest effort of how much time the meeting should take. If you know it will take an hour, schedule an hour, persist to keeping to an hour, and be pleasantly surprised if your meeting is shorter than anticipated! Timing effectively is not a skill learned overnight; nevertheless, it is one that can be continually improved upon through best practice.

Additionally, focus on meetings comes in two forms: preparation and execution. I have found that being prepared for meetings can strike chords in the efforts of delivering an effective meeting. Rudimentary in nature, necessary by necessity. Know your subject, what your objective is and how you are going to achieve said objective. Execution will then follow shortly thereafter; and keeping your meeting attendees focused is baked into this. Too often, “meeting creep” can set in and suddenly your hand is forced to reschedule or schedule more meetings to impair your effective timing. Avoid the divergence by preparation and keeping on track, for both yourself and attendees.

When it comes to documenting, a wise person in the IT realm when I had been in my secondary education, once told me to “document everything.” At the time, it made no sense. Now, it means truly that: responsibly document everything when it comes to meetings. Whether it be sharing your screen with a running document or the old-fashioned pen and paper, meeting minutes and notes are the core aspect to documenting the action items and deliverables in projects. It serves it’s purpose to be able to say who, when, where, what, why and how someone was able to do something in a project when it was documented during a meeting of said project. One does not, nor must not, transcribe every word; yet glean a holistic enough perspective to highlight the key points with enough information for reference.

The tried-and-true adage that “communication is key,” is not just for relationships in our personal and professional lives. It is true for meetings. The ability to communicate with transparency and effectually is the last rounded effort of the lexicon that promotes a synergized meeting. Go back to your preparation and execution from the “focus” principle and translate that into the communication you are delivering. Instead of meager words forming together sentences that might satisfactorily achieve the objective, aim for the exceeding and deliver on what your best work is each time, and your meetings will thank you.

Meetings. The word may forever be ingrained into our brains as a hallowed term in the business analysis field or ring us full of trepidation. Yet, if we remind ourselves of the tenets homed in on this article, we may find that meetings are not as tripe and dismaying as they are. They are a major source of our work and should be treated no differently than any of our other aspects of efforts. We hold ourselves accountable for the work we deliver as business analysts and the work outputs of meetings are equivalent. Spend the little amount of time it takes to accomplish these items, in no order, and experiment with how much more you can further your meetings. You may find that your work is completed in a timely, or even early, fashion.

Analyse Your Stakeholders

As a business analyst, aren’t you a bit like a translator? Your job is not just to interpret data, but to interpret it from the perspective of a businessperson and for the good of a specific business project. You are the middleman between sets of data and stakeholders in a business, and no matter what their educational backgrounds may be, those stakeholders are relying on you to deliver information that they can use to inform their next move. It’s up to you to communicate what might be rather abstract information in a meaningful, relevant way. Remember that word — communication — because as a business analyst, you are a professional communicator.

If you want to be a great communicator, it’s of paramount importance that you understand your audience. Forget the numbers for a second. Think about your stakeholders. If your job is to communicate with them, then for you to perform your job properly, they’ve got to be able to communicate right back, and be comfortable doing so. That means you need to be able to share bad news and be capable of disappointing people gracefully. It also means they need to be able to take that bad news and that disappointment, so they can work with it and mold it into success. Without honesty and transparency, your title isn’t Business Analyst. It’s Yes Man. There’s a time and place for Yes Men, but this isn’t it.

Speaking of titles, let’s set those aside. Your stakeholders may be your employers, but they’re also people. Shocking, right? Just like you, they will feel much more confident communicating with someone they feel a connection to. So to prime yourself for a successful project cycle, be sure to know your stakeholders. Or, if you prefer, analyse them.


Qualities of a Stakeholder

Think about the ground-level qualities of your stakeholder. Where do they live? This is important because you may need to account for time zone differences. Which medium do they prefer for communication — email, phone, video conference, in-person, or even text? What’s their experience like? Get a feel for your stakeholder’s level of experience, both generally and in relation to the specifics of your assignment. Have they been involved in similar projects in the past, and, if so, are they keen to offer their own insights? Don’t assume every suit is a novice with money; they may very well be just as knowledgeable as you, but, for reasons you’re not paid to understand, they’d rather not do what you’re doing. All the better.

Then comes the business side of things. How formal is your stakeholder? Not everyone is into casual communication in the workplace, especially when it comes to inter-hierarchical communication. Yet some will be put off by a rigid presentation. You have to get a grip on the amount of formality expected from you, if for no other reason than the need for you to be taken seriously and be understood as a communicator. While you’re at it, try and pinpoint exactly what level of authority a stakeholder possesses. While you must always be respectful to your employer (and they should be the same), you have to have some understanding of which decisions can be made by whom, otherwise you might find yourself unsure of who to turn to when project-halting issues rear their heads.

There’s always a shot-caller. Don’t shy away from a quasi-Machiavellian approach. Recognize that, in any profit-seeking organization, some parties are less dispensable than others, whether it’s due to their social standing within a group, aggression and energy, or sheer ability as a money maker. Identify the shot-caller and determine how their requirements of you may differ from their peers.

Peripheral Qualities

With the formality and infrastructural concerns out of the way, try a little bit to get to know your stakeholders’ personalities. Think of these as qualities you wouldn’t talk openly about in a work email, but that would still help you in how you decide to deal with your stakeholders.

Sometimes, your job might shift from translator to mediator. It’s not really in the job description, but, at the end of the day, you might be the only one in the room who can bridge the gap not only between information and business decisions, but between all the different arbiters of those business decisions. Stakeholders don’t always get along with each other or see eye to eye, and even those with deep, time-honed business relationships will bicker — sometimes childishly. Don’t be afraid to step in and resolve some differences, appropriately of course, if it means consensus can be reached and the project can pick up and keep moving. Of course, to do this the right way, listen to the room and note the relationships you see. Just like you analyse individual stakeholders, try to analyse the group.

You’ll find, after some time working together, that you can identify if a stakeholder is able to act on their feet confidently or if they are the type to ruminate before making big decisions. Keep in mind which one you’re speaking to, because it will have no small effect on how you proceed. Plan ahead for situations where you might get a committed decision later, or even sooner, than you had hoped.

And finally, this one’s important in today’s global, interconnected business world: culture. You will likely find yourself dealing with people from all backgrounds. People from different countries, different religions, and different upbringings. If you’re working abroad and you’re the odd one out, get a feel for the customs and norms of the native culture. That’s Traveling 101, isn’t it? If your stakeholders can see you’ve made even a slight effort to participate in their culture, it will be much easier to develop mutual trust and willingness to understand and work with one another. At the very least, you may avoid saying something embarrassing.

Do We Need A Skills Matrix?

The answer to this question is almost always no. Here’s why…


The stated objectives for creating a person-level skills matrix are usually something like:

  1. “We want to match staff to appropriate work by understanding their skills.”
  2. “We need to identify skills gaps and shortages across the team/organisation and prioritise areas for individual and general improvement.”

These seem sensible enough. They sound efficient, future focussed and suggest it will help individual team members to engage in appropriate work and increase their skills as needed.


The skills matrix appears on the surface to help with these aims. Unfortunately, they rarely meet the intended outcomes.

Here is a typical process:

  1. Drivers 1 and/or 2 exist, and eventually someone says “skills matrix”.
  2. Key skills to include are discussed and agreed. (This takes much longer than planned; technical skills are over-represented, core skills [1] are under-represented and undervalued by this process).
  3. Realisation that we want knowledge areas not just skills. A very long list is produced…
  4. After much questioning and resistance (most) staff rate themselves against the skills and knowledge areas.
  5. This is on the whole unsuccessful due to the Dunning-Kruger effect [2] on the one hand and Impostor Syndrome [3] on the other. (Plus, the fact that most of us think we are self-aware and only 10-15% of people actually are [4]).
  6. Many difficult conversations are then required explain why Person A is not actually an expert in everything and Person B is better than they think.
  7. The people who would be “best” for a piece of work based on the output of the matrix are not available.
  8. Managers and team members are all quite bruised by the process.
  9. Matrix is not updated. It goes slowly out of date.
  10. Abandoned.



Alternative Reality

The skills an individual has is one of many factors which need to be considered when assigning appropriate work. The factors include:

  • What motivates them?
  • Who do they work well with?
  • Who can build relationships quickly?
  • What kind of support/environment allows them to do their best work?
  • Where do their interests lie?
  • Who has these skills/who needs to develop these skills?
  • Is there an appropriate senior person/role model?
  • Who has earned an exciting opportunity?
  • Who needs to stick to the basics?
  • Who can juggle multiple assignments?
  • Who prefers to concentrate on one area?

It is not possible to model all these factors in a spreadsheet. This level of understanding comes from managers having good relationships with team members, being able to honestly discuss personal style, preferences and professional development needs. Managers also need good visibility of upcoming work and assignments to be able to plan appropriately and engage with team members about future work.

Training Needs And Skills Gaps

Good managers know this information without a skills matrix. Given a list of skills needed by an organisation, managers should be able to identify and quantify capacity and competency gaps. A skills matrix is a lazy substitute for good quality management and a distraction that creates the illusion of control.

Individual personal development plans which align to organisational objectives are a more motivating and effective way of establishing and then aggregating team-member level data.

How Can BAs Help?

Business Analysts may be asked to create or contribute to the development of a skills matrix or record our own skills. We can use our analytical skills to establish the drivers and intended business outcomes and suggest alternative methods of achieving those.

Is A Skills Matrix Ever Relevant?

If the answer to the question “Do we need a skills matrix?” is almost always no, then there must be exceptions. Very large, typically global organisations which operate across a number of sectors (such as retail, aviation, construction etc.) that need to quickly mobilise specialist teams need a way of “searching and filtering” on staff. This is more effective as searchable information, with some structured data (e.g., job title, location, knowledge domains) and bio information maintained by the individual (experience, preferences, etc.) to allow the right people to be identified. Implementing this type of system requires appropriate investment in technology and business change. The business case for the ‘spreadsheet matrix’ never stacks up.


The skills matrix is typically a misguided attempt to automate something which needs to be a human discussion. How they are implemented often demotivates staff, serves as a distraction from real work and genuine issues and fails to meet the intended outcomes.  Organisations that want the capability to understand the skills and experience of their staff need to encourage the right behaviours from managers, make appropriate investment in robust decision support tools and engage with staff to capture information which is accurate, proportional and timely.

[1] Core Skills: C Lovelock, BA Times, 2019 https://www.batimes.com/articles/stop-saying-soft-skills/
[2] Dunning-Kruger Effect : J KrugerD Dunning, 1999  https://pubmed.ncbi.nlm.nih.gov/10626367/
[3] Impostor Syndrome: C Lovelock, BA Times, 2020 https://www.batimes.com/articles/impostor-syndrome-business-analysis-is-not-just-common-sense/
[4] Self-Awareness: T Eurich, Harvard Business Review, 2018 https://hbr.org/2018/01/what-self-awareness-really-is-and-how-to-cultivate-it