Tag: Techniques

Best of BATimes: 7 Warning Signs that You Are Too Soft

Written by Neal Whitten,PMP on May 17, 2023. Posted in Articles.

Simple question: Do you believe that you tend to be too soft at work?

What I mean by too soft is demonstrating behavior that results in being consistently less effective than what is otherwise possible—and needed—in performing responsibilities.

Whenever I ask this question at conferences, seminars or webinars, most people respond with a “yes.” From experience, I have found most project managers and business analysts, indeed, to be too soft—they are not willing to make the tough and unpopular project- or business analyst-related decisions, even though their instincts warn them that they are not taking the most effective action.

Being too soft harms your effectiveness, your career, the respect from others and your ability to make a difference and make things happen.

Examples of Too-Soft Behavior

Here are seven examples of too-soft behavior. Do you see yourself here? If so, this article may cause you to leave your comfort zone.

1. You behave as if you have the responsibility but without the authority

If you behave as if you have the responsibility but without the authority, then you’re too soft. I do face time with thousands of people each year. I frequently hear project managers and business analysts say that they have the responsibility but not the authority. This just isn’t true. You almost always have the authority; the problem is that you don’t take it.

Here’s an example. When was the last time you were called on the carpet—challenged—for exceeding your authority? Was it within the last week? The last month? The last year? Was it ever? My experience is that less than 15% of people in a large group—a statistically valid size group—have ever experienced being confronted for exceeding their authority. This is sad to me. But what is sadder is that, statistically, most people reading this article will never experience being called out on exceeding their authority across their entire career! My assertion is that you almost always have the authority—you just don’t seize it… you’re too soft.

2. You put off insisting on and driving good project management or business analyst practices

Whether I’m in a public setting or at a private company, it’s common for PMs or BAs to approach me for advice about their project problems. During the discussion, many times it’s relevant for me to ask about the project management or BA practices that they follow. I often hear them say that the practices they follow are weak and insufficient. They will state or imply that management in their organizations isn’t doing enough to provide and continuously improve the practices.

I’ll ask them what their role on the project is and they will tell me that they are the PM or a BA. If you are in either of these roles, then insisting on and driving good practices is your job. Not management’s. Not anybody else’s. It’s your domain of responsibility. You can seek help if you need to but the buck stops with you. If you do not insist on reasonable practices then you’re too soft.

3. You complain rather than constructively work issues to closure

I don’t believe that you should ever complain about anything—ever! Complaining is negative energy and adds no value to solving the issue at hand. People who complain are exhibiting too-soft behavior by averting truly getting the problem fixed. But make sure you understand what I mean by complaining. An example of complaining is when person A complains to person B about something that person C can fix. In this case, person A just wasted his time and person’s B’s time. However, if person A “complains” so-to-speak to person C—the person who can fix the problem—then this is not complaining to me. This is the first step of the solution by informing the person who can do something about it.

4. You evade taking a position on issues

If you evade taking a position on an issue, you’re too soft. A role of leaders is to help resolve conflict among team members. They take appropriate business-based positions on issues even if it doesn’t please all parties. Let’s look at an example.

I was mentoring Sarah who was a project manager of a sizeable project. We were walking through a hallway heading to a room where a meeting was soon to take place. We come upon two team leaders—Laura and Larry—discussing an issue in the hallway. Actually, discussing is too kind of description; they were angry at each other and loudly protesting the other’s views. Upon seeing this, Sarah leaned in to me and asked if I would mind if we join in on their discussion. Sarah said we have a few minutes before we must be in the meeting room. I said that that’s a good idea and we joined the two team leaders. After standing with the two team leaders and listening for a few minutes, Sarah turns to me and said we have to go; she did not want to be late for the meeting.

Once we were out of hearing range of the two team leaders, I asked Sarah why she didn’t say anything back there to help resolve the conflict. Sarah said if she had sided with one team leader then the other team leader would have been upset with her. I said that’s not how it works. Besides you now have both people upset with you because you did not assert your authority and help find an appropriate resolution. I went on to tell her if she sided with Laura and that left Larry upset with her, that’s not her problem—it’s Larry’s problem. I said never avoid taking a position because you fear that someone won’t like you. This is business, it’s not personal. Decisions are made based on what’s in the business’ best interest; not what’s in Larry’s best interest. Here again, Sarah was too soft in dealing with this situation which meant she was not as effective as she could be and should be.

5. You avoid or excessively delay making key decisions

Decision making is a critical action in any team, project or organization. We all have experienced instances where we felt decisions were being made far too slow. Make sure that you aren’t the problem. If you avoid or excessively delay making key decisions then this is another example of demonstrating too-soft behavior.

If you wait to make a decision until all data is known to ensure that you are making the very best decision, then you will lose all competitiveness. Better to make a decision and occasionally be wrong, then make no decision or excessively delay in making the decision.

6. You fail to perform your assignment as if you own the business

When you look around you for the people who you respect the most, they are likely folks who come to work each day with the mindset that they perform their duties as if they owned the business—and the business is defined by their domain of responsibility. If you have ever owned your own company, you will know exactly what I mean. You cannot put food in your belly or pay your bills unless you are successful. It’s this passion that helps people achieve their best. These are people who make things happen.

They believe—and their actions demonstrate—that the buck stops here and that they are fully accountable for the project or their assigned domain. Your boss and your senior management want you to take charge over your domain of responsibility with the passion that comes about when you behave as if you owned the business. If you hesitate or routinely pull back then, again, you are demonstrating too-soft behavior.

7. You require the personal approval of others to function

You are too soft if you personally require the approval of those around you to function from day-to-day—and without it you feel inadequate—then you will likely find their behavior to have an immobilizing effect on you; it can stop you in your tracks. Don’t ever give that kind of power to another person. What other people think of you should never be more important than what you think of yourself.

In Closing…

I have revealed seven examples of too-soft behavior. If you routinely exhibit these too-soft behaviors, then you’re clearly too soft—you tend to take the easy way out rather than do the right thing by demonstrating the most effective behavior. If you only occasionally slip into this behavior, then that may not be a serious cause for alarm.

If you fear that not being too soft will cause you to be “too hard” and therefore you will be seen as being rude, insensitive, abrasive, arrogant or a bully… don’t go there. You are a good and decent person and will not give way to these behaviors.

You might be asking yourself if an upside of demonstrating too-soft behavior is that you might win friends and respect? After all, if you are consistently too soft, those you work with will see you as very easy to get along with and passive—you’re always rolling over and abdicating to others. The problem is that if you’re a leader and are consistently demonstrating too-soft behavior, you will lose respect from those you lead, and from your peers and from your superiors. Being too soft will also have a negative effect on your project’s outcome because the best business decisions are not always made or made in a timely manner. All this can lead to your career becoming stagnant or even shortened.

Now, go become your imagined self!

Published on February 28, 2017.

Back To Basics: Excellent Elicitation

Written by Adrian Reed on May 11, 2023. Posted in Articles.

Elicitation is a core business analysis skill, and one that BAs typically utilize daily. It is easy to fall into the trap of thinking that elicitation is so basic that it doesn’t warrant talking about. Yet, just because it is a core skill doesn’t mean it’s easy, and it certainly doesn’t mean it’s unimportant. Not only this, but elicitation usually involves working with stakeholders, and whenever people are involved there can be inadvertent conflict and contradiction. Achieving clarity is rarely easy! In this article, I’ll address three perspectives of elicitation that you might find useful.

Elicitation As A “Trawling” Activity

In their book Mastering the Requirements Process, James and Suzanne Robertson use the metaphor of trawling to describe elicitation. The idea is, much like a fishing boat with a net trawls for fish, an analyst ‘trawls’ a business area for relevant pieces of information.

Ever since I first heard this metaphor I’ve liked it. Building on the Robertsons’ work and extending the metaphor, we might also say:

Where you trawl matters: If you trawl in an area with no fish, you’ll end up with an empty net. The same is true of requirements—ask the ‘wrong’ people and you’ll get very little.
The type of net matters: I’d imagine that the type and size of fish you are trying to catch will affect the type of net used. There’s a comparison here with elicitation—the techniques need to vary depending on the context and the types of requirements that you’re looking for. Detailed observation might yield very in-depth requirements, so might be considered a ‘small net’. A high-level conversation with an executive might yield high level outcomes and be considered a ‘big net’. Both are important, but it’s important to know which you are looking for.
There will always be stuff to throw back: Sometimes, it’s tempting to plan elicitation activity in a straightforward, linear way. As if you’ll be able to speak to person A, person B, do some observation and then everything is done. Of course, it never works exactly like that, as people will throw in curve-balls, there’ll be discussions which take you in unknown directions and so forth. I suppose this is a bit like trawling for fish: there will always be some fish to throw back if they are too small, too big, or the wrong type. In requirements terms, this shows that elicitation and analysis go hand in hand. As soon as elicitation starts, there will be filtering and prioritization happening.
Ethics should be built in to the process: I gather that fishing boats may throw back fish that are endangered, or are below a certain size. In terms of requirements, there is perhaps a lesson for us as analysts: If we come across a requirement that we believe is unethical, we should question it. This might sound like an odd thing to say, after all, who would raise an unethical requirement? Yet, with proposed technological transformation there might be an underrepresented group that is disproportionately affected, and perhaps this hadn’t been considered. It might be that the requirement owner had never considered the ethical consequences, and is very happy to amend or remove it once they think about the broader unintended consequences.

Elicitation Relies On Stakeholder Analysis

Much as elicitation and analysis are inextricably connected, there is a clear dependency on stakeholder analysis. Sometimes we might be led to believe that stakeholder analysis is a frivolous activity, after all, who has time to sit down and create stakeholder lists and models? Yet, the reality is that it’s one of those activities that will likely save time in the future.

I can still vividly remember a time, very early in my business analysis career, when I was assured that a particular project I was working on didn’t require compliance sign-off. I took this at face value, didn’t do any further stakeholder analysis and went ahead. Cutting a long story short, we got to testing and found that we absolutely did need compliance sign off. That was a scary revelation, but luckily our compliance colleagues were friendly and pragmatic. With some late nights and minor changes we got the project over the line. But for me, it was a lesson learned: Proper stakeholder analysis could have avoided it entirely.

I’m a particular fan of the stakeholder rainbow, and the stakeholder interest intensity index. I discussed a number of stakeholder techniques in a presentation that’s available on YouTube, feel free to check that out if you’d like to know more!

Context And Scope Matter

Finally, it’s worth noting that elicitation which doesn’t consider context and scope is really just a Santa’s wishlist. Imagine asking everyone in an organization “what is it you want?” or “what could save you time?”. You’ll get lots of ideas, many of them actionable, but you won’t get a coherent set of ideas.

This probably sounds so obvious, but it’s an easy trap to fall into. As analysts, it’s easy to be so familiar with the scope and context of a project that we assume everyone knows it. Yet that’s rarely the case, so spending a few moments to outline the core objectives and outcomes can really help.

This also highlights another key point: It’s absolutely crucial to understand the business objectives and outcomes being sought. Trying to elicit and prioritize without knowing the outcomes is virtually impossible. How can anyone say requirement A is in scope (or not), and whether it’s more important than requirement B if there’s no clear agreement over the ultimate outcomes being sought?

Conclusion: Shine The Light On Elicitation

It’s easy, particularly as an experienced practitioner, to let elicitation become second nature. That is completely natural. But perhaps it is worth spending time now and again reflecting on how we elicit and whether it is still effective. Although it might not be a headline-grabbing topic, elicitation is absolutely crucial to what we all do!

Best of BATimes: Six Effective Elicitation Questions to Ask Your Stakeholders

Written by Angela Wick on April 27, 2023. Posted in Articles.

Asking questions during interviews or as part of a structured requirements workshop is commonplace. However, the most important question is one you should be asking yourself:

Am I asking the RIGHT questions?

Here are a few of my favorite elicitation questions and what they might reveal about your project.

1. What are the biggest challenges in your role?

A key part of any BAs role is to understand the context of the project: where does this project “sit” within the larger organization.
Having stakeholders describe the challenges in their role prompts both leaders and doers to share information that moves “outside the box” of the project.

Especially in an interview setting, this question allows the collection of “stories” that will elaborate and cement the value of the project and its required capabilities. These “stories” are concrete examples of the business need that will communicate the value of the project to sponsors, vendors, testers, developers, etc. throughout the project lifecycle.

Though you want to be cautious to avoid scope creep, briefly stepping outside the confines of the project can also help you identify:

Organizational risks
Missing stakeholders
Requirement gaps

2. What does success look like?

As I noted in my May article, “The Top 5 Mistakes in Requirements Practices and Documentation”, many project teams spend too much time focusing on the as-is current state.

Asking stakeholders to define success is a perfect way to move workshop or brainstorming discussions from the current state into the future state.

In the initial stages of elicitation, this question will help gather a clear overview of what capabilities are required for the project. The output of this question to can be used to create high-level conceptual models of the future state.

This question can also be used in beginning to elicit requirements for very specific features and capabilities. The challenge will be keeping stakeholders focused on the “what”: users, processes, rules, events and data. The discussion migrating to technology, systems and solution may risk that the true needs go undiscovered.

Perhaps most importantly, focusing on success frames the discussion in a positive light, emphasizes benefits, and gets stakeholders excited about the value the project will provide to their organization.

3. Who do you think is impacted (positive and negative) by the project and how?

We have all seen that even small projects can create a ripple effect that touches many parts of an organization. All of the people touched by the project’s ripples are potential stakeholders. Identifying and categorizing the roles of various stakeholders is key to successful elicitation.

In the initial phases of business analysis, understanding who is affected by the project will help you refine the scope of the solution and build your core team of stakeholders.

Asking this question throughout the project lifecycle will also help you:

Identify new stakeholders
Identify and mitigate risks/constraints
Redefine needs or identify new needs
Elaborate requirements
Prioritize requirements

4. What would happen if we don’t change the way things are done today?

Use this question as an alternative to: “Why are we doing this project?” or “Why is this project important?”

As you may know, I love the question “Why?” but I hate to use it. “Why” questions tend to put people in a defensive position and can inhibit open and honest communication.

Also, framing the discussion in terms of “no changes”, is essentially asking stakeholders to define the current state. However, this phrasing will limit the “as-is” discussion to the processes and events that need to change.

Stakeholders will help you understand the key opportunities, risks of dormancy, the benefits of change — all-important inputs for successful elicitation.

5. What other changes are happening within the organization that may impact this project?

Most organizations function in a state of constant change. To avoid being blindsided, find stakeholders that understand how new strategies, policies, regulations, processes, and technology, might impact our projects.

Many project teams tend to isolate themselves within the silo of their business unit—often in an effort to stay focused. However, too much isolation can lead to missed opportunities for:

Collaboration
Integration
Sharing of best practices

Keeping attuned to organizational changes can help to:

Mitigate risks
Estimate project deliverable dates
Manage scope
Identify constraints
Understand interdependencies

6. How would you describe the process?

This is really a technique, with multiple questions, that I use frequently with SMEs in one-on-one interviews or in small groups. This technique is most effective when delving into the details of specific processes or events. Here’s what I do:

I ask the SME/s to describe the process for me.
Then, I draw the process out with them—on notebook paper, presentation paper, whiteboard, or using software.
As they explain the process I ask, “What parts of the process would you improve and why?”
I also ask, “What ideas do you and your teammates talk about as ways to improve the process?”

At the end of this exercise, I leave the room with a validated visual of the current state of the process and a list of opportunities to add value to the organization.

Let me know if these questions will help you or share your favorite elicitation questions below.

Agile Requirements Management Part 3 – A Collaborative Data Model

Written by Steve Farrall on April 19, 2023. Posted in Articles.

In this article I want to explore how to integrate data requirements with product features and user stories; the result is some very useful traceability to where a particular data entity or attribute is being used across a product.

A conceptual data model is an integral part of the analysis process, it allows the analyst to better understand the overall requirement and how the various elements are related to each other. This enables the correct features to be identified to support the requirement and may well identify some gaps in the requirement where data is not being setup ready for the next process to collect and consume.

The data model will then naturally provide the start point for the database design and will ensure that all the features and associated user stories are all be singing from the same hymn sheet. The sprint teams will benefit from a shared understanding of the data that they are being tasked to manage.

The Tool

Initially my thoughts were that a true data modelling tool with a built-in dictionary were needed, having used these kinds of tools in previous projects.

As the choice of tool was limited, we explored whether Confluence might provide a useful stand in solution; we were already using Confluence to manage the requirements and user stories, so this looked like a natural plug-in to our existing Confluence wiki.

Develop the Model

For convenience, a separate data modelling space was setup to hold all the diagrams and page content for the data model which could then be referenced across the Wiki pages to add understanding to the requirements.

The Confluence service we were using came with the Gliffy diagramming tool; this allowed us to create entity relationship diagrams (class models). As the model was quite large, it was split into distinct data domains, this is easily managed by creating a view (diagram) for each domain.

Create Data Entities

In order to make the Confluence data model more like a true tool-based model, hyperlinks were included in the diagrams attached to drawing objects like an entity or domain; click on a high-level domain in the diagram view and the attached URL will then launch the associated domain view diagram, allowing a drill down to the detailed entity level.

Once down at the entity level, the next step is to setup each entity as a separate Confluence page; the last click at the entity level will arrive on a page that can be enriched with content for collaboration with the team.

Each data entity is loaded as a separate Confluence page; this approach also means that you can link to individual features and user stories using the page URL but also provides a ready-made folder to hold related content like data attributes.

Tip – Setup Data Domains

Setup a domain hierarchy in Confluence to file the entities appropriately, this will facilitate creating views of subsets of the model using the ancestor filter option in the reporting macro.

Trace Data Requirements

Now we have the model available in Confluence with each entity loaded as a separate page the data requirement can be integrated into the requirements wiki traced to the product features and included in user stories as a URL link to the relevant pages.

Tip – Identify Data Usage

The more comprehensive the application of this approach the greater value will be realised; if you go down to attribute pages then it will be possible to drill down to where data items are being processed.

Setup Data Attributes

Defining the data attributes is a useful activity to ensure that the system will include all the required data and manage it in a consistent manner.

Data attributes can be simple and self-explanatory items, the name alone can be enough to understand the purpose intended; however, it is often the case that the meaning can be very subtle and having an attribute page available to record an explanation is very useful.

Data attributes are setup as child pages to the parent data entity page to provide a natural filing plan but they can be referenced anywhere and shared in conversations with team members to clarify their purpose and ensure consistent data usage.

Tip – Attribute Names

Page names must be unique within a Confluence space, so it is a good idea to fully qualify the page name with the entity name as a prefix to avoid any duplication issues across different entities.

Integrate Data Requirements

This is where the data model becomes integrated and collaborative, a big advantage over separate modelling tools.

Whenever a user story is referencing a data requirement then the URL to the entity page can be plugged into the story as part of the narrative. For example, the narrative “Create a Customer record for the order received” can replace the plain text “customer” with a URL to the customer entity page instead. Once this approach is adopted the data usage can easily be discovered; starting from the entity page under the page information details all the incoming and outgoing links to the page will be shown, revealing where the data is used and with a single click the reader can jump straight to the story page.

Tip – Business Rules

Including attribute links in business rules will ensure the sprint teams are looking in the right place when implementing the user stories. For example, check the “order delivery date” has not be missed; otherwise, an alert must be triggered to follow-up on the delay with the customer.

Conclusion

Confluence may not appear to be the obvious tool to consider for managing data requirements; however, the fact that it can be integrated with the product features and user stories is quite powerful. The ability to see where individual data attributes are being used facilitates impact analysis and support; the business rules can be expressed precisely and facilitate the development of an integrated system.

It will require careful management to ensure changes can flow through the process and can easily be identified but this is true of all these kinds of tools.

Last but not least is a the record of feedback and comments added to the pages in Confluence, explaining why certain decisions were made and how data attributes introduced are being used by the system. This record will be invaluable for assurance and support queries to understand the how and why a piece of data is being used by the system.

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?