Skip to main content

Tag: Requirements

The Courage to Try Something Old – Part 2: Scribing

In the previous article I wrote about the importance of facilitating requirements meetings and why it can take courage to do so. In this article I’ll discuss another skill that has fallen in and out of favor over the years—scribing.

Many ancient societies valued scribes. Scribes typically were at the center of all activities and highly regarded in the areas of government, law, military, and religion. Today’s scribes are not so universally regarded, particularly in our world of PMs and BAs. Effective scribes should be at the center of requirements activities, but most often they are not. We’re often in the back of the room or off to the side. We’re not always introduced in virtual meetings. Many organizations view scribes simply as passive note-takers and unfortunately that’s how many scribes view themselves. But I have found that scribes are essential to the success of the project.

 

What is a scribe and what does a scribe do? A scribe is the role that provides documentation, either formal or informal, and anyone can play that role. PMs, BAs, facilitators, business owners, QA analysts, programmers—it doesn’t matter what the title is. Any time we’re documenting our PM or BA work we’re scribing.  Our output can include recaps of sponsor and other stakeholder meetings, requirements (models, textual, etc.), assessments, gap analyses, and business cases to cite just a few.

 

What skills does a scribe need? Like every effective PM and BA, the scribe has to create structure from chaos. That’s not easy so scribes need a variety of skills, such as listening, absorbing, clarifying, and writing. But perhaps most important is critical thinking, which comprises many skills including:

  • Conceptualizing – grasping what’s being discussed because we have enough context[i]
  • Applying – taking what we know from our experience and using it in new situations.
  • Synthesizing – absorbing lots of information, processing it, and making sense of it immediately.[ii]
  • Evaluating – knowing what’s important and what’s not, what works and what doesn’t.[iii]

 

Advertisement

 

Why do we need scribes? Documentation is important if for no other reason than because it saves time. We cannot possibly remember all the salient topics of our project and requirements meetings. Documentation helps prevent revisiting and revisiting again all the important decisions already made and who should complete which action items and by when.

 

How much courage does it take to scribe?  Why in the world would it take courage to scribe? Because the most common scribing pitfalls relate to courage. I am often asked questions such as these:

  1. What if the PM and/or team thinks it’s a waste of time to have a scribe?
  2. What should I do when the facilitator wants to “take notes,” but in the end, much of the meeting is lost because the notes are too sketchy?
  3. What should I do when I’ve been told to sit in the back and be silent when I take notes? Most of the time I have questions or want to clarify what’s been decided, but I’m told that asking questions will take too much time.
  4. What should I do when I’m asked to distribute the documentation in an unreasonable time frame?
  5. I know it’s important to recap the highlights of my scribing output at the end of the meeting, but we never seem to have time. Our discussions always run over.

 

If we are too timid to address these issues, we will be less useful not only to our project team, but the entire organization. But it takes courage to tackle them. We need to be effective at influencing, and courage is a main component of influence. We need to ensure that everyone understands the importance of both scribing and the scribe role, and it takes courage to point these out. It takes courage to speak up about the risks of not having scribes in organizations that don’t value them. And to link an unsatisfactory product delivered to stakeholders to effective scribing. And because it takes time to be an effective scribe, we need to advise including scribing tasks in project planning.

Finally, as scribes we need to be neutral and not have a vested interest in the outcome of the meeting. As we know, the person with the pen has the power and can rewrite the project’s history. Let’s not sneak in a couple of our or our sponsor’s favorite requirements, or conveniently forget any because it’s easier than seeking a scope change. And there’s no need to document every conversation– the key items like decisions and action items will do. When done well, scribing is a thing of beauty. When not, it might well be tossed out with other old but necessary techniques—definitely not in the interest of either the project or the organization.

[i] This often comes from past experience and is one of the reasons I’m not in favor of “neutral” scribes
[ii] This is one of my favorite scribe skills because it is essential in a requirements workshop where there’s so much happening at the same time.
[iii] louisville.edu/ideastoaction/about/criticalthinking/what for the 4 basic concepts

10 Common Problems Business Analysts Help Solve

Often Business Analysts are swept up by the hustle and bustle of project life and simply do what is needed to get to the end goal. Business Analysts focus on delivering a valuable solution to business stakeholders and they forget just how much value they add by help solving many problems along the way.

This short article outlines 10 of the common problems that Business Analysts help solve in the organization and especially when helping to deliver progressive change initiatives for the organization.

In no specific order of importance, find out more about these common problems that Business Analysts help solve and see if you can recognize some as familiar problems you often help solve too:

 

#1 Unclear or conflicting stakeholder expectations

Stakeholders may have unclear or conflicting expectations of what a project will deliver which hampers progress and can lead to disappointment.

Business analysts can help mitigate this problem is to ensure that all stakeholders have a shared understanding of what is achievable and what the project will deliver.

A Business Analyst helps to solve this problem by facilitating workshops with stakeholders to reach agreement on project outcomes, and by creating clear documentation of requirements that can be referred to throughout the project.

 

#2 Inadequate resources

Many projects also suffer from inadequate resources these days, which can lead to delays and frustration. Experienced Business Analysts can help identify which skillsets are needed to help deliver a project during the planning stages of the project to ensure resources are request early during the project set up stages.

Some more ways that a Business Analyst helps to solve this problem is by monitoring project progress and highlighting to the Project Manager where risks of resource shortages may occur. Where possible Business Analysts also help to create mitigating actions to avoid potential project delays due to resource constraints.

 

#3 Poor communication

Poor communication is often a root cause of many problems that occur during a project. Miscommunication can lead to misunderstandings, errors, and delays.

A Business Analyst can help to improve communication by facilitating communication between stakeholders, creating clear and concise documentation, and holding regular meetings to update everyone on the project status.

 

#4 Unclear or changing requirements

Unclear or changing requirements are one of the most common problems faced by Business Analysts. This can cause confusion amongst team members, as well as delays in completing the project.

One way that a business analyst can help solve or minimize this problem within a project is to ensure that requirements are well-defined and agreed upon by all stakeholders before work begins, whether they are working in Waterfall projects or Agile based iterations. This can be done through creating a requirements document which outlines all the requirements for the project and getting sign-off from relevant stakeholders.

In an Agile environment, the Business Analyst can help manage this issue by ensuring that user stories are well-defined and understood by all team members before work begins on them.

 

#5 Lack of engagement from stakeholder

Another common problem faced by Business Analysts is lack of engagement from stakeholders. This can be due to several reasons, such as stakeholders being too busy, or not feeling invested in the project or even mistrust of the business analyst.

The Business Analyst can solve this by ensuring a clear stakeholder engagement plan is a key activity within the project. The Business Analyst can also work to build relationships with stakeholders and ensure that they are kept updated on the project status and progress.

 

Advertisement

 

#6 Ineffective or missing processes

Ineffective or missing processes can lead to a number of problems within a project, such as errors, delays and duplication of work. This is often due to a lack of understanding of current processes being followed within the area the project is trying to solve for.

A way that the Business Analyst can help to solve this problem is by conducting a business process analysis to understand the current processes in place and identify areas for improvement. The Business Analyst can also work with the relevant stakeholders to develop new or improved processes where needed.

 

#7 Lack of understanding of user needs

A very common problem that a Business Analyst face is a lack of understanding of user needs. This is not because the Business Analyst is ineffective when engaging stakeholders necessarily, it can be due to several reasons including unavailability of key stakeholders and time or resource constraints that exist within the organization.

If there is a lack of understanding of user needs, it can lead to the development of a solution that does not meet the needs of the users, and ultimately will not be successful.

The Business Analyst can help to solve this problem by conducting user research and requirements elicitation to understand the needs of the users that will be using the solution. This can be done through a few methods such as interviews, focus groups, workshops or surveys.

 

#8 Lack of understanding of business goals

Many business analysts also find that there is a lack of understanding of business goals within an organization. This can make it difficult to align projects with organizational objectives and ensure that the right solutions are delivered. Often a Business Analyst will be assigned the task of developing a business case for a potential solution without having clear alignment of business objectives.

A way the Business Analyst can help to establish a clear understanding of the business goals is to work with stakeholders to document the business goals and objectives for the project. This can be done through workshops or interviews to understand the pain points that the organization is experiencing, and what they are looking to achieve by undertaking the project.

 

#9 Change fatigue

Another common yet less tangible problem faced in organizations is change fatigue. This is when staff members become resistant to change because change happens so frequently within the organizational area. This situation can make it difficult for Business Analysts who has to introduce new changes to business stakeholders and it becomes hard for Business Analysts to achieve their requirement outcomes.

One strategy a Business Analyst can follow to help manage the change fatigue of their stakeholders is to ensure that they keep them updated and engaged at the appropriate level throughout the project. They should at the same time aim to champion the benefits of the change to stakeholders and try to avoid asking stakeholders to repeat requirements or information that may have been articulated in the recent past by other Business Analysts. This is where it is very useful if Business Analysts can research similar project information to avoid rehashing the same content with fatigued stakeholders.

 

#10 Lack of governance

Finally, another common problem faced by Business Analysts is a lack of governance around requirements management. This can lead to several issues such as scope creep, requirements changes being made without consent or approval, and a general lack of control over the requirements. This can be a particular problem on larger projects where there are many stakeholders involved and the Business Analyst is not the only person working on gathering and documenting requirements.

A way to help solve this problem is for the Business Analyst to put in place a requirements management governance framework. This should include processes and procedures for how requirements will be managed, approved, and changed throughout the project. It is also important to ensure that all stakeholders are aware of and agree to the governance framework prior to the start of the project.

 

Conclusion

These are some of the top problems I could think of that Business Analysts often face and help solve. Some projects have multiple of these challenges happening at the same time which makes the role of the Business analyst very valuable as problem solver.

Best of BATimes: How To Level Up Your Business Analyst Career

As a forward-thinking Business Analyst, this question is probably crossing your mind frequently.

 

You’ve established yourself in your career, but you may feel stagnant, eager for a change of scenery or simply ready to learn something new. In a competitive job market, Business Analysts need career know-how to navigate their next steps to keep their work fulfilling. Read on for simple steps you can take to take your Business Analyst career to the next level.

Understand Which Career Path You Want

To get an edge on advancing your career, you need to know where you want to end up. Business Analysts can take their careers in any one of a variety of directions. It all depends on your interests, strengths and opportunities.

As you move through your career, you’ll see that job titles and descriptions become more specialized and specific based on industry and skills. If you’re interested in the tech industry and you’re good at bridging technical work with communicating specialized ideas, a role as an IT Business Analyst could be a great fit. If you’d prefer to work in a variety of industries doing C-level consulting, you may consider a path into a Management Analyst position.

These are just a couple of examples of advanced and in-demand career paths for Business Analysts. Collabera and New Horizons Computer Learning Centers have detailed descriptions of directions that Business Analysts may take as they move throughout their careers.

Find A Mentor

A mentor is a great industry-specific resource for everything from day-to-day questions to giving insight into career decisions. Mentor-mentee relationships can begin organically, like with a trusted superior at work, or you can seek one out with a networking program. The International Institute of Business Analysts (IIBA) hosts local chapters where you can meet other analysts at different points in their careers, and they are forming a mentorship program for members.

A mentor should be someone you can see regularly, perhaps daily or weekly, and who can get to know you and your work habits well. Ideally your mentor is someone at your company, but a former colleague or even a professor can make a great mentor too. With a mentor, you’ll form an ongoing bond that will evolve as your career goals change.

 

Advertisement

 

Get A Career Coach

While mentors are typically fellow Business Analysts, career coaches are professionals who operate from a higher level as they help you seek out new opportunities. They may not be Business Analysts themselves, like a mentor would be, but they have plentiful resources for networking, optimizing your soft skills, and helping with resumes and cover letters.

Career coaches often focus on a local region where they have expertise on the job market. They meet with their clients for sessions lasting up to a couple of hours for a flat fee. Virtual and nationwide services are also available through organizations like TheMuse. If you plan on meeting with a career coach, make sure you have an idea of what you want to accomplish during your session and have documents like your resume and work history handy.

Take Classes

Your experience as a Business Analyst doesn’t have to come solely from formal education or on-the-job projects. Taking classes allows you to improve existing skills or add new skills to your resume through cheap and accessible means.

Business Analyst networking groups, like the IIBA, hold specialized workshops to help you hone your skills and learn from other Business Analysts. If you prefer self-directed learning, there are free online resources with high-quality trainings for Business Analysts, like LinkedIn Learning, where you can earn certificates to display on your profile. Coursera also has a free curriculum that specializes in business analytics with courses designed by The Wharton School of the University of Pennsylvania. These courses are great if you have a specialty field in mind where you may be lacking competencies.

Volunteer For Challenging Projects

If you feel stagnated in your current role, be on the lookout for opportunities to challenge yourself. Offer your input in projects that may be out of your usual comfort zone so that you can learn with skilled colleagues or step forward to tackle an issue you found in day-to-day processes. No matter the project, be sure to ask for help when you need it—that’s one of the best ways to grasp new concepts and skills. By taking on challenging projects, you’ll not only gain experience, but you’ll also establish yourself as someone who takes initiative.

Invest In Soft Skills

While it makes sense to devote your time to expanding your technical skills, don’t let soft skills fall by the wayside. Soft skills are qualities and interpersonal skills that are less “trainable” than hard skills, but translate to every role in every industry. Soft skills include conflict resolution, negotiation, communication skills and more. Usman Haq details important soft skills for Business Analysts in his article in BATimes. These skills are acquired and practiced daily, so be mindful of opportunities to hone them. LinkedIn Learning also has courses on soft skills so you can study at your leisure.

Are You Ready To Take Your Career To The Next Level?

Being a business analyst entails wearing a lot of hats. Conquer your career path by understanding your long term career goals, find a mentor and a career coach to help you reach those goals, take classes for both hard and soft skills and don’t be afraid to raise your hand for big projects.  As you take these small steps, your future in Business Analytics will unfold.

The Strawman: When a Wrong Makes a Right

Sometimes, the easiest way to find out what someone really wants is to show them what they don’t want.

The strawman approach is frequently used by business analysts – sometimes knowingly, and sometimes not. Actively inviting stakeholders to engage with and criticize an inaccurate reflection of requirements can provide insights that greatly speed up the requirements elicitation process. However, it can also be a risky approach.

This article describes that strawman approach, its potential pitfalls, and tips for using the approach to support productive requirements elicitation.

What is the Strawman Approach?

You may have heard of a strawman argument – an argument that distorts an opposing stance to make it easier to attack [1].

In business analysis, a strawman can be created by presenting knowingly incorrect, incomplete or distorted requirements to stakeholders in order to provoke a response. This is usually done in the form of a model or prototype solution, providing a visual representation that stakeholders can engage with and refute. The idea is that the way stakeholders respond to the inaccurate strawman will inform more complete, coherent and representative stakeholder requirements.

Stakeholders often find it difficult to articulate their requirements. They can be vague when it comes to specifying their wants (I want a bright color…), yet very specific when it comes to specifying what they don’t want (…but not pink!) This is because people often find it easier to specify their wants and needs in opposition to something. In such cases, presenting an inaccurate or incomplete model/prototype representation of requirements as a strawman can provoke a strong response from stakeholders, creating a better understanding of what they don’t want, and providing a starting point for conversations about what they do want.

 

Advertisement

 

The Pitfalls of the Strawman Approach

While the strawman approach can be a powerful requirements elicitation technique, the approach should be used with caution. Some of the potential pitfalls associated with using a strawman include:

  1. Impact on your credibility: When done right, presenting a strawman to stakeholders can make a business analyst appear open, co-operative, and responsive to stakeholder needs. However, presenting something that is clearly wrong can also impact a business analysts’ credibility, leading some stakeholders to question the analyst’s abilities.
  2. The strawman becomes the answer: The point of the strawman is that it isn’t accurate! You want stakeholders to refute it and provide information that will allow you to change and/or improve it. However, in cases where stakeholders really do not know what they want, they may not challenge the strawman. This could lead to the strawman (either in part or whole) becoming the answer.
  3. The business analyst can feel exposed: Presenting a strawman is not an easy thing to do. It takes a degree of professional courage to produce a piece of work and present it, only to have it criticized – even if that was the intention.
  4. Some stakeholders are too nice: Some people find criticism difficult and may be unwilling to say what they really think about a strawman, particularly when they are being asked to criticize it in a group setting.

Tips for using the Strawman Approach

The following are a few tips to consider when using a strawman to elicit requirements:

  • Do you research. Make the ‘strawman’ as accurate as possible. Differentiate between elements of the strawman that are based on known, more accurate requirements, and those that are ‘best guesses.’
  • Know your stakeholders. Think about how your stakeholders might react to the strawman. Think about how you present the strawman to different stakeholder groups. Consider presenting the strawman to ‘friendly’ stakeholders 1-on-1 to get feedback to improve it, prior to exposing it to more influential stakeholders and/or a larger group.
  • Acknowledge it is a strawman. Sometimes acknowledging what you are presenting is a ‘strawman’ will give stakeholders the permission they need to constructively criticize it.
  • Don’t rely on it. The strawman approach should not be used as a primary requirements elicitation approach, but rather a tool that may be deployed to elicit those more subjective requirements, engage a particular stakeholder group, or as a check for validating what you know and what you don’t.
  • Clearly label your strawmen. Once in the wild, the strawman can obtain a life of its own, being reproduced and/or discussed in unintended places. Therefore, it is important to clearly label, store and/or otherwise indicate the strawman is a draft, prototype or experiment.
  • Don’t take is personally. Remember, the stakeholders are reacting to and criticizing what is presented to them – not you personally!

 

Reference
[1] Strawman Arguments: What They Are and How to Counter Them – Effectiviology, www.effectiviology.com/straw-man-arguments-recognize-counter-use/

Techniques for prioritizing requirements

One of the major challenges that Business Analysts face is getting stakeholders to prioritize requirements. Everyone is used to high syndrome – where the stakeholders say everything is a high priority.

The key to dealing with this problem is for BAs to understand the drivers of the project and then create priority evaluation criteria to assess each requirement. This is a key step that is often overlooked when starting the business analysis deliverables of the project.

Let’s say the objective of a project is to optimize a business process for an operations group. As a BA it’s important to understand what constitutes an optimized process. It’s a simple upfront question that will surface criteria that the BA can use to help the business prioritize the requirements. For example, the stakeholders may indicate that the optimal process would be one in which the To-Be process has fewer manual hand-offs, reducing the amount of paper that flows through the process, reducing the number of steps requiring manual entry of data, etc.

Advertisement

These criteria can then be used to develop a framework with which to evaluate and prioritize requirements. My preferred approach is what I call the scale approach. With the scale approach, you get the stakeholders to call out how well each requirement aligns with the assessment criteria on a scale of 1,3 and 5 (where 1 means the requirement is poorly aligned with the criteria, 3 somewhat aligned, and 5 highly aligned). This gives a numeric priority assessment of the requirement and a quantitative method of comparing requirements. This helps to get stakeholders out of the “high” trap mode.

Scale Approach:

Here is an example of the scale approach. The scaling approach uses a 1,3,5 scale where 1 is poor alignment, 3 is some alignment (in the middle) and 5 is highly aligned. The max score for any requirement is 15 and the minimum is 3. I’ve tried more granular approaches like 1 to 10…but it just causes a lot more sitting on the fence when you have that many values to apply to a criterion…and it’s not as “distinct” an outcome as the 1,3,5 scale. I specifically avoid using numbers instead of High, Medium, and Low because I find that a numeric approach makes things more subjective than a High, Medium Low evaluation approach.

# Requirement Evaluation Criteria 1 (Reduce Manual steps) Evaluation Criteria 2 (Reduce paper through the process) Evaluation Criteria 3 (Reduce number of manual steps) Total Criteria Score
1 Requirement 1 3 5 1

9

2 Requirement 2 5 5 3

13

3 Requirement 3 1 3 1

5

4 Requirement 4 3 3 3

9

 

Typically, with the above scoring system I would then map it to the more traditional High, Medium, and Low using the following ranges:

Low – score equal to 5 or lower

Medium – score of 6 to 10

High – score of equal to 11 or higher

Based on the above you would then prioritize the requirements as follows:

# Requirement

Priority

1

Requirement 1

Medium

2

Requirement 2

High

3

Requirement 3

Low

4 Requirement 4

Medium

Heat Map Variation:

Most stakeholders are very visual. So sometimes I’ll combine this with a heat map approach. With the heat map approach, each score on the scale is associated with a color.

Score of 1 – shade the cell red

Score of 3 – shade the cell yellow

Score of 5 – shade the cell green

So, if we take the above example and add colors, it will look like:

#

Requirement Evaluation Criteria 1 (Reduce Manual steps) Evaluation Criteria 2 (Reduce paper through the process) Evaluation Criteria 3 (Reduce number of manual steps) Total Criteria Score

1

Requirement 1 3 5 1

9

2 Requirement 2 5 5 3

13

3 Requirement 3 1 3 1

5

4 Requirement 4 3 3 3

9

As you can see above – it really jumps out at you that there is a “strong” fit with requirement 2 and a poor fit with requirement 3. I find the heat map approach helpful when there are a lot of requirements because it’s a lot easier to gauge and compare requirements based on colors than numbers. Also, a lot of times with a heat map you don’t need a total criterion score at the end. It just jumps out at you.

You can further simplify things by just using the colors instead of the numbers.

Does it take more time?

The simple answer is no it doesn’t take more time. All it takes is a little bit of prep, a prioritization meeting and then you have prioritized requirements. When you compare that to having numerous emails, meetings, and discussions about what the requirements priorities are you’ll see it’s a much simpler and effective approach. It also forces stakeholders to really think about the requirements and how they want to achieve their objectives – so less second-guessing of requirements in the future.

One final note:

When I use this approach, I put the actual scoring matrix into the appendix of the requirements document and not in the main body to enable a wider audience to more easily read the requirements document.