Skip to main content

Tag: Team

Short Quiz on Team Member Behavior – What Would You Do?

Team members are often in the dark on the behavior expected of them while working with others.

Here are 9 important but common situations that team members are likely to encounter throughout their project.

Choose the answer that best represents the behavior you expect from your team members or coworkers.

The answers are provided at the end of the quiz.

Quiz

1. What should a team member do if she believes that she cannot meet an already committed date?

  1. Work it out with the team leader and propose potential solutions
  2. Get help from her manager
  3. Work it out with the person with whom she has made the commitment
  4. Say nothing until she is 100% sure that the committed date will be missed
  5. Say nothing and do the best she can

2. Team member A repeatedly says that he is on schedule to deliver a critical-path item to member B who has a dependency on that item. But the item is delivered three days late. This puts the critical-path schedule three days behind. What should member B do?

  1. Maintain his original duration commitment which means that the schedule will remain three days late
  2. Notify his manager
  3. Escalate to member A’s manager
  4. Reasonably work with anyone and everyone to bring the team back on schedule
  5. Bad mouth member A at every opportunity

3. What should a team member do if he has bad news to share?

  1. Share it as soon as possible
  2. Share it discretely, as appropriate
  3. Share it in as few words as possible
  4. Delay as long as you can to buy time in case things improve
  5. a, b and c

4. A team member periodically does something helpful and noteworthy for the team leader, another team member or for the team itself. In terms of recognition, what should the team member do?

  1. Share the good deed with the team at the next available opportunity
  2. Inform his manager
  3. Remain humble and say and do nothing
  4. Request the benefitting party to inform his manager

Advertisement

5. When it comes to commitments and accountability, who within the team should be treated differently—a bit more special—than any other person or group? Who should be cut a bit more slack when problems arise?

  1. Client
  2. Contractor
  3. Vendor
  4. Company employees
  5. No one should be treated a bit more special

6. When a team member has made a noteworthy mistake, what should she do?

  1. Admit she made a mistake
  2. State what she plans to do to correct the mistake
  3. State what she will do to prevent the mistake from occurring again
  4. Do not allow the mistake to haunt her
  5. All of the above

7. What should a team member do to maintain a positive attitude when he works around some really negative people?

  1. Leave the organization
  2. Decide to maintain a positive attitude
  3. Confront the negative behavior at every opportunity
  4. Occasionally confront the negative behavior when the timing and conditions feel appropriate
  5. b and d

8. A team member should ask questions rather than assume. But doing so can cause that person to sense that others perceive them as stupid. What should the team member do?

  1. Let others ask the questions
  2. Make the best assumptions you can
  3. Test the waters with one question before asking more questions
  4. Ask the questions
  5. Obtain the person’s permission to ask questions

9. What can a team member do to discourage her meeting invitees from arriving late and leaving early?

  1. Yell at them
  2. Lock the meeting-room door
  3. Adopt the 10-minute rule
  4. Fine them $1 per minute they are late or leave early (money collected to be used on team snacks)
  5. All the above

Answers

I have promoted answers that my experience suggests represent the behaviors of the best teams—high performance teams. It’s possible, that for some scenarios, you don’t agree with my answer or you may not favor any of the options from which you can select. If your answer is different than my recommendation, it doesn’t necessarily mean that either of us is wrong. We may come from different company and country cultures that may influence our answer. We also may have had different experiences. But bear in mind that, if you and I don’t agree on the best answer, all the more reason that that scenario should be discussed within your team to ensure that everyone has a common understanding of what is expected of them.

  1. The answer is c. Work with the dependent party to resolve the issue without causing harm to other members of the team. If problems result, immediately include the team leader in the discussion and propose potential solutions to remedy, or at least minimize, the harm that may occur. The team member may also need to inform her manager and, if needed, secure the appropriate support from her manager.
  2. The answer is d. Member B is responsible for doing what is reasonable to work at restoring the critical-path schedule to its original commitment. Member B should be creative and open to ideas and obtain help if it is necessary and available. The first priority is not placing blame, but to resolve the problem so that the overall team does not suffer. To that end, the team leader should typically be informed of the situation and may be instrumental in working with all affected parties to repair the situation. If appropriate, member A, who originally caused the delivery to be late, can be included in the resolution.
  3. The answer is e. We all find ourselves having to deliver bad news from time to time. It’s never fun but it’s part of the job. Always deliver bad news as soon as reasonably possible, with the appropriate level of discretion and using as few words as possible. “As soon as reasonably possible” means that, in most cases, you attempt to resolve the problem before involving others—especially higher-ups. If you believe that the bad news must be shared, do so quickly. The sooner the problem is addressed, the less harm may be incurred. Make sure you do not blindside anyone when relaying bad news. No one wants to be surprised by hearing about a problem from a third party or at an inopportune time. As for using few words, if the person you are updating needs more information, she will ask.
  4. The answer is b. The team member should inform his manager about his noteworthy deed. It’s not only okay to toot your horn to your manager, it’s essential. If you don’t then your manager can never acknowledge and praise you for your admirable behavior, nor will you experience any appropriate benefit in your next performance review. However, do not run each time to notify your manager. Instead, use weekly or monthly status reports to your manager to include these types of items. Truly noteworthy and unique events can be communicated right away. Note, however, do not toot your horn to your coworkers—doing so can show you in a less than favorable light.
  5. The answer is e. All individuals and groups are needed to ensure that the team’s mission is completed successfully. If any of these stakeholders are having difficulty meeting their commitments, they must be appropriately worked with to ensure the issue is satisfactorily resolved. History shows that once one group or person is treated differently or so-called “special,” it’s typically that group that becomes the Achilles’ heel of the team.
  6. The answer is e. When you make a mistake—and we all do—it is recommended to admit that you made the mistake. Doing so can take the wind away from some people’s proverbial sails and allow people to focus on solving rather than the blame game. Now state what you plan to do to correct the mistake—this is called being accountable. Next state what you plan to do so the same problem does not reoccur—this is called being a professional. Lastly, do not carry guilt with you about the mistake. Learn from the experience and move on.
  7. The answer is e. Don’t allow others to define you. You choose your own attitude; nobody chooses it for you. A positive attitude can be contagious but so can a negative one. People will look forward to being around and working with you if you have a positive attitude. If others’ negative behavior is undermining your ability to achieve your commitments, then you must take action. However, if the person with the negative attitude has no influence within your domain of responsibility, then you can choose to do nothing. If you are around the person frequently, you may choose to encourage a change in her attitude or at least try to better understand what is behind it.
  8. The answer is d. Ask the questions. Better to have the misperception of looking stupid than proving stupid because you failed to ask the necessary questions. Do what you believe is the right thing to do. When you ask questions and listen to what people have to say, you learn things that you otherwise would not know. What other people think about you should never be more important than what you think about yourself.
  9. The answer is c. Schedule all meetings to begin at 10 minutes after the hour so that attendees can arrive on time from their last meeting. Allowing at least 10 minutes between meetings gives attendees time to travel, make calls or check email, and relax for a moment. Additionally, end all meetings 10 minutes before the hour, or earlier, so that attendees have time to get to their next meeting on time that will likely start on the hour.

This quiz and its answers, when openly discussed among the team leader and team members, provide a venue to ensuring that these expectations are clearly articulated across the team.

Agile Requirements Documentation – What’s Really Needed?

During agile training sessions, the most common question I get is, “Can you PLEASE just tell me what I need to document as an Agile BA?”

So, let’s clear up this up once and for all!

The answer is NOT simply user stories and acceptance criteria, or a traditional requirements document. Agile is just not that simple. This answer would focus on the wrong thing—output. Instead of focusing on output, it’s the outcome and the path you take to get to the outcome and outputs that’s important.

The reality is, your job as a BA isn’t to document, and it never has been! Seriously. Even when doing waterfall or traditional approaches for requirements, the BA role is about facilitating decision making and facilitating future state discovery. Documentation is the output of all of this. Yes, documenting is part of the job, but it’s not the goal of the business analyst role, no matter what approach the team is using.

Start with the why.

I am not a “no documentation” zealot, but I am passionate about ensuring that what we create is valuable. Let’s ask ourselves two questions about the documents we create: “What is the purpose of the document and why is the organization willing to pay for it to be created?”

Requirements-related documents cost organizations lots of money, so we need to be able to answer these questions to get the right content documented. We want to avoid wasteful documentation as well as avoid the endless spin created by team dynamics that need a memory of what was discussed already.

When teams transition to agile, they often try to make a concentrated effort to look at documenting less; and this is a good thing to evaluate in the spirit of cutting out waste and focusing on value. When teams are going through this I often see a lot of wasteful documentation teams say THEY MUST have.

Here are the arguments I frequently hear for excessive documenting on agile teams:

  • My developers won’t start until its documented in this detail.
  • The QA/Testing team requires this much documentation.
  • We send the document offshore, so it must be a detailed document.
  • We are working with vendors so contractually we need to send them a document of detailed requirements for the whole project.
  • We are doing the development in an agile way, but not requirements too.
  • We need the requirements documented for training purposes.
  • We need the document to remember what we are working on.
  • We need the document for compliance.

I will provide my perspective on these arguments, but first we need to cover three important pieces of a healthy agile mindset and environment.

Apply agile principles and working memory concepts.

An agile approach enables teams to document less and increase speed while reducing costs. Here are the three agile principles that help teams reduce documentation:

  1. Limited WIP (work in progress)
  2. Small cross-functional teams, where hand offs are minimized to complete the work
  3. Co-located teams (It’s possible to be agile with distributed teams, if teams leverage the facilitation skills, techniques and tools needed to make this work.)

It all comes down to “working memory” and leveraging the working memory of the team to reduce the dependence on documentation.

When a team has Limited WIP, they only work on one or a few things at once. There is less to remember because there aren’t days or weeks between discussions while you work through dozens of topics. With this intense focus, a small cross-functional, co-located agile team has enough working memory capacity to track details with minimal documentation. When a team is leveraging these principles, it feels strange and wasteful to stop and document unless the team agrees it is needed to help them move forward.

Working memory is a key to the puzzle and working memory is maximized when there is limited WIP, small teams and co-located teams. If your organization compromises on any of these, then the working memory of everyone is compromised. Work slows down while teams document to help them remember as they switch between too much work in progress.

What should be documented?

Documentation in agile is “living” and should be updated as the team need to update it. Think of it as a living asset the team uses that grows, gets pruned, gets trimmed and grows some more.

A small, cross-functional team with limited WIP, should document the following:

  • Product Vision: The team needs a shared understanding and reminders of the direction they are going. It should be visible too all so that it is pointed to and discussed daily as the details emerge.
  • Product Roadmap: The team needs a visual representation of the direction they are headed to achieve the vision and desired outcomes. And, it gets updated regularly!
  • User Story Map: The team needs to see the big picture of the user stories from a user journey perspective—to see the forest through the trees of the user stories of a product. And, it gets updated regularly!
  • Placeholder for the Conversation: The team needs a way to capture past conversations or hold a place for future conversations. This usually includes user stories and some acceptance criteria.
  • Analysis Assets: The team needs to SEE conceptual and analytical models. These visuals help the team remember the big picture of the process, people, technology, rules and data pieces of the project. These are things like: story maps, scope diagrams, decision tables, ecosystem maps, data flow diagrams, etc. These are visual—hung on the wall so teams can quickly jump up and huddle to discuss how a user story relates to all of them, and they are updated as often as needed.

Advertisement

Remember to keep documentation as simple as possible. Choose a format and level of detail that allows change and delivers just enough value to keep the team moving forward in the right direction.

What about compliance, QA, vendors, offshore teams, training, etc.?

OK, back to all those arguments teams use to rationalize excessive documentation. When you focus on limited WIP and small, cross-functional, co-located teams, these are the agile-minded responses.

  • My developers won’t start until its documented.
    • They should be part of the team, not a hand off
    • The entire team needs a shared, limited and focused WIP
    • The Product Owner and team need to see working product quick to give feedback to the developers, the more feedback loops, the better the product will be.
    • A quality conversation about a small piece of work is enough to get started, if not, then the conversation may not be on track.
  • The QA/Testing team requires the document.
    • They should be part of the team, not a hand off
    • The entire team needs a shared, limited and focused WIP
    • A quality conversation about a small piece of work is enough to get started, if not, then the conversation may not be on track
  • We send the document offshore, so it must be a detailed document.
    • They should be part of the team, not a hand off
    • The entire team needs a shared, limited and focused WIP
    • A quality conversation about a small piece of work is enough to get started, if not, then the conversation may not be on track
  • We are working with vendors so contractually we need to send them a document.
    • They should be part of the team, as needed to account for a more collaborative work style rather than hand offs
    • Limit the WIP you give them, force them to work on just a little at a time and allow you to provide frequent feedback.
  • We are doing the development in an agile way, but not requirements.
    • If requirements are not agile too, then how to we know we are building the right thing?
    • Requirements not being agile compromises actual agility to change priorities quickly and take in requirements change for strategic advantage.
    • Just in time requirements for the most important pieces with a limited WIP maximizes the ability for the organization to learn and change quickly without leaving work mid-progress or waiting for a large piece of work to complete to get to the hottest priority.
  • We need the requirements documented for Training purposes.
    • The solution design is flawed if you need to train your users on how to use the application. Technology of today and tomorrow will no longer support this type of design.
    • There are faster ways to create training documentation than using spec documents. Work as a team with a limited WIP to get the inputs to the trainers that they need.
  • • We need the document to remember what we are working on.
    • Too much WIP! Limit WIP and see less documenting needed.
    • Focus on finishing one or few pieces at a time, not on starting more work.
  • We need the document for compliance.
    • Most teams are documenting too much for compliance compared to what compliance actually requires.
    • If you really dig into what compliance requires, lightweight documentation usually works just fine
    • Also consider documenting what was built rather than before it is built so that the team does not have to do rework when things change.

Essentially, I’m asking you to adopt an agile mindset and advocate for limited WIP and smaller teams that reduce the need for documentation, reduce costs and accelerate product/solution delivery.

If your organization has compromised these principles, then working memory challenges are likely driving your teams to document more. That is okay, as long as the team and organization realizes the value of the document and is consciously choosing to slow down outcomes and results due to the choice of compromising the agile values.

Remember that your role as an agile business analyst is not about documentation. It’s about facilitating good and timely decisions, and guiding stakeholders to discover a future state that delights the end user.

What’s this nonsense about emotional intelligence, anyway?

There’s been a lot of talk in the last several years about the importance of emotional intelligence in the workplace.

In fact, many organizations are starting to recognize that soft skills are more important than the traditional analytic or trade skills that they used to specifically target in their search campaigns. Old hiring methods that focused on job output have given way to 360-degree “full person” profiling techniques such as the behavoural job interview and social media scans. Of course, human emotions aren’t new. Why then, does it seem we’re suddenly changing our workplace around to accommodate them?

To understand that, I think it’s important to look over the last hundred years or so of Western work evolution. In the 1920s, robber barons were bilking most of the world’s wealth. Our immature economy couldn’t sustain this and so it collapsed. To rebuild from the rubble, a generation of people said “never again” and collectivist values formed, resulting in dramatic wage compression, social services, collective bargaining, and a general “coming together” for universal survivability (which makes the simultaneous McCarthyism in the States rather ironic). Decade on decade, in various ways, unity was the prevailing attitude that our culture embraced. It’s under these very conditions that the traditional, stable, benevolent organization we’ve come to know was created.

OPEC and double digit inflation wrought economic havoc in the 1970s, priming us for the Reagan years. This seems to have been an important turning point. Unity stopped becoming the driving force behind innovation – suddenly every man (and woman) was in the rat race for themselves (remember The Secret of My Success?). Individual achievement became the norm. It didn’t happen immediately, but I believe this paradigm shift began the unraveling of decades worth of organizational fabric. The pace of innovation exploded, bringing with it incredible technology costs. “Superfluous” employee-related costs, like training and development, had to go out the window to feed the upgrade monster. This meant that to find someone capable of performing a specific job, you had to find a candidate who was already doing that specific job somewhere else. This, of course, pushed recruitment costs up, but retention costs necessarily had to come down. Simultaneously, the nature of Western work shifted into a project-based rhythm as operational work was either outsourced or eliminated. (As an aside, I believe that under these conditions, moving recruitment onto the web was the worst possible idea ever, but that’s another story.)


Advertisement

So where does this leave us? I believe we’re left with a world where individual talent is the working world’s most sought after currency – but (for the most part) that talent is transactional. There will always be people like Jonathan Ive whom companies protect like treasure but for most of us, contract work is becoming the norm. This means that the protective cocoon of an organization’s pensions, benefits, water cooler friends, paid professional development opportunities and after-work parties are gone.

Who will thrive under these conditions? It will likely be people with a very distinct set of skills:

  1. To keep their head above water through the constant sea change associated with project environments, successful workers will need to highly adaptable. This means they will need to retain a cool head under pressure and be able to use logic and reason to carry them through inevitable challenges without succumbing to strong emotions.
  2. To be able to lead others in times of crisis, successful individuals will need strong interpersonal skills, empathy and the ability to form mutually satisfying relationships with other people. They will need to be able to effectively balance their own needs against the needs of others and ensure socially responsible outcomes that map against the greater good.
  3. To be able to stay in the game for the long term, successful workers will need exceptional stress management abilities. This means they will be able to regulate their body’s stress responses, never allowing themselves to become too keyed up for too long. They will take care of themselves mentally and physically, independently of work.
  4. To be able to perform the above, a successful worker today will need high levels of self-awareness. Empathy requires a solid understanding of one’s own feelings while adaptability and stress management both require one to have an intimate knowledge of their own boundaries. This is both so they can protect themselves against too much uncertainty, but also expand those boundaries under controlled conditions.

Together, these four abilities comprise the basis of what has come to be known as the trait model of emotional intelligence. Given the challenges that today’s workers must face, I think it’s no accident that employers are starting to look beyond analytic and technical skill sets in their hires. These “soft skills” have become every bit as important to career longevity as the tangible work results we have traditionally valued.

How can workers hone these abilities? That is a question for another day.

7 Crucial Behaviors to Master When Dealing with Your Leaders

Your leaders want you to know—need you to know—the behaviors they consistently expect from you.

Just because you have a leadership role doesn’t mean you are living up to the expectations of your leaders.

The more you understand what is expected of you, the more you will likely focus on honing those skills, improving your performance and, in the process, helping your leaders look good which helps you look good. Talk about a win-win! So, if you have an interest in enhancing your image, effectiveness and career—and who doesn’t—let’s get to the first important behavior.

1. Don’t Dump and Run

When you have an idea for an improvement, don’t transfer that idea to your leader and then wash your hands of it. Be willing to be its champion and become part of the solution. Your leaders have neither the duty nor the bandwidth to personally take on and work every good idea to closure.

Your leaders want and need your ideas but they also expect for your hands to get dirty from time to time. Words don’t make companies successful; actions do.

2. Make It Brief

When you’re speaking with your peers you can speak in paragraphs. When you’re speaking with your immediate boss, reduce the paragraphs to long sentences. But the higher up the food chain you communicate, learn to shorten the sentences—even approaching sound bites. Your leaders don’t have the time for the unabridged version. If they need to know more, they will ask you. They respect you more when you can net your messages so they can obtain the necessary information in the minimal amount of time.

3. Don’t Complain

People who habitually complain are a bore and a waste of time and energy to those around them. If you’re complaining, you’re not solving; you’re part of the problem. For example, if you complain to Person A about something that Person B can fix, then you just wasted your time and that of Person A’s. But if you “complain” directly to Person B who can fix the problem, this is not complaining; it’s the first step of moving toward a solution. By the way, if you get a reputation as a complainer, people may stop listening.


Advertisement

4. Bring Solutions with Problems

When you are faced with a problem and need help, articulate both the solution and the specific help required. Tell your leaders exactly what you need from them, such as funding, letter of support, escalation support, lifting the freeze on hiring, or approval of a new tool. You are far more likely to obtain their support when you have a solution in hand and they know precisely what is expected from them to help you carry out the solution.

5. Meet Commitments

Do what you say you will when you say you will do it. Manage your commitments well. If, at times, commitments may need to be reset, then work with the required parties as soon as possible so that any collateral damage will be minimal. But do not create a pattern of missed commitments where there appears to be no end in sight. No one can meet every commitment that they have made but they should be able to meet most of their commitments. The commitments that slip should be carefully replanned and rarely should they slip again. The respect you develop across your organization or company will, in large part, be affected by your ability to successfully and maturely manage your commitments.

6. Promote Dialogue

Don’t be a “yes” employee—or more specifically, a silent employee. Don’t just take notes, nod, and leave your boss’ office. Listen thoughtfully, ask good questions, and raise concerns— if any. Your leaders need your response, your ideas and your participation.

7. Keep Your Leaders Informed

Keep your leaders informed of important news. Don’t work in a vacuum. Avoid surprises. However, this doesn’t mean you should tell your boss about every problem that comes your way. In fact, don’t reveal most problems to your boss. If you did, your boss would cringe every time he or she sees it’s you on the phone or at their office door or in an email that just arrived. You are paid to solve problems. Your boss gains no value in knowing all the problems that you face each day and how each was solved. Therefore, be selective and only share those problems that you feel your boss should know about or that you want your boss to know about. And be discreet in how you share bad news with your boss.

The success you achieve with your career has a lot to do with your behaviors in dealing with your leaders. Your career-clock is ticking. Now, become your imagined self!

Succeeding as a Virtual Business Analyst

The past decade has seen virtual teams become a more accepted mode of working together, yet for years I thought that, as a business analyst, contributing as a virtual team member was out of the question.

However, for the past year I have been a virtual business analyst on a software implementation project, where I am in New Zealand and the rest of the project team is in Australia. My experience has taught me that there are a few unique challenges associated with such a role, but that success is achievable.

Here are some of my key learnings:

Building Credibility and Trust

Despite all the great technology and tools that empower us to work as virtual business analysts, there is no substitute for face-to-face contact with stakeholders to establish credibility and trust with them.

On my most recent project I spent two weeks at the company’s head office in a project kick-off phase. As well as using the BABOK® Guide knowledge areas to direct my activities during that time, I put considerable effort into building relationships with the stakeholders. If I was to complete the bulk of my work from a remote location, I would need a clear understanding of who fitted where in the stakeholder matrix – how important or influential each was to my success. I was looking for people who were:

  • Business domain experts
  • Existing system experts
  • Decision makers
  • Able to resolve bottlenecks and bring pressure to bear

Yes, this is the same approach any business analyst would take on a project, but I put extra effort into getting to know them professionally and personally. By meeting for coffee or lunch I was able to get to know them and to win their trust, and I could only do that when we shared the same location. This was foundational to the following months working from a different country.

Early Understanding of Strategy

On the project in question, I learned in the first few days that one of the top strategic needs was to drive change in sales behaviour, from number of deals signed (regardless whether they made money or not) to profitability of deals signed. From a requirements analysis and design perspective, this was relatively straightforward.

However, the impact of this change on sales team motivation and remuneration could easily have jeopardized the success of the project. Since I had done the strategic analysis early in the kick-off period, I was able to engage the sales managers to establish a change management plan for the sales team. As a result we ran a whiteboard session with the sales team to introduce that change and address their concerns.

Time Zone Challenges

Over the years I have worked on teams with members located in very different time zones, such as Australia and India (4 hours) or Australia and Germany (10 hours). The result is that there are a number of hours where I am working and part of my team is not. I cannot pick up the phone and call them, which necessitates adjusting my work habits:

  • If my workday finishes before theirs, ensure they are clear on what I’d like them to have completed by the beginning of my next workday (no leaving that email until tomorrow morning)
  • Be willing to stay late to ensure I can talk directly to someone on an urgent matter
  • Agree to set times for regular videoconference calls in lieu of dropping by their desk

Advertisement

Competing with Organizational Priorities

This is a challenge common to all projects, but when working as a virtual business analyst and a consultant as well, as was the case in my recent project, it is compounded. Since I was not on the corporate email distribution list, I typically discovered that a higher priority task had taken resources only when stakeholders failed to deliver as expected. When asked about the delay, I would be told something like, “My manager told me ‘X’ is my top priority this week.”

To succeed, it is important for the business analyst to request that stakeholders advise priority changes that impact their project work. However, requesting does not guarantee instant success. In situations like this the virtual BA must have the good grace to roll with the punches, give a gentle reminder and be ready to re-plan at a moment’s notice.

Lack of Physical Presence

This is a challenge for all virtual team members, as it can be a case of “out of sight out of mind.” Walking past someone’s desk can remind him or her they have a project task to complete. As a business analyst, I place high value on less formal, “water cooler” conversations, which are hard to replace.

How can the virtual business analyst make up for a lack of physical presence?

  • Don’t assume people will remember to complete their project tasks so ensure you follow up regularly
  • Use your knowledge of the person to add a personal enquiry to the conversation (this is where the time spent face-to-face at the start of the project really pays dividends)
  • Use videoconferencing where possible as this adds some non-verbal communication elements to your interactions

“Sudden” Stakeholder Changes

Similar to the problem of competing with organizational priorities, there can be times when a key stakeholder leaves the organization. On my project I discovered this to be the case the day before one person left. No one had thought to tell me! There was no time to get those uncompleted deliverables finished.

Fortunately, another staff member stepped in quickly and I was able to leverage their enthusiasm at being allowed to determine the final outcome of the project, as it impacted their area.

Working as a virtual business analyst is definitely more challenging, but at the same time I found that success is possible and in some ways more rewarding than in a traditional team environment.

Do other business analysts have insights from their experiences? Please share in the comments section.