Tag: Tips

How a Business Analyst Should Prioritize Knowledge Transfer

Written by Kupe Kupersmith on February 1, 2011. Posted in Articles. 1 Comment on How a Business Analyst Should Prioritize Knowledge Transfer

My friend and fellow author on BA Times, the Bad Ass BA, just wrote an article, The Bad Ass BA Observes the Hunt for the Right Business Analyst. In the article she discusses different types of business analysis job requisitions that are currently on all the job boards. One type that she highlighted got me thinking about an issue which companies deal with every day. The type of job requisition she touched on was the “clone the 25-year veteran who just retired” job opening. This is where a hiring manager wants to have someone with the exact experience and knowledge of someone that has been working on the same application and with the same customers for years.

Why do some hiring managers need that? They have relied on that one person to work on that application and with the customer base far too long. Why do they do that? A big reason is that the customer gets comfortable with a particular individual and they do not like change. So as long as the person they love does not want to pursue other opportunities they will stay there until they leave the company due to a staff reduction or reach retirement age.

This particular post will not address the ways a BA manager can help spread the knowledge to avoid this situation. An earlier blog post, The Sadness of the Silo’d BA, touched on this subject. This post will focus on what the new BA who is replacing the long established BA should focus on to be most effective. Until organizations start pairing BAs, BAs will be in silos and will continue to be the only ones with certain knowledge. Coming onto a new project team, a Business Analyst needs to obtain as much information from the departing BA as possible. If you are the incoming BA there is so much information you need that it often feels like you are drinking from a fire hose. You have limited time with the outgoing BA, so you have to prioritize the topics you cover.

Conventional wisdom may lead you to believe the main priority should be the application(s). That in fact should be the lowest priority. Yes, you need to learn the features of the application and as much about the application as possible, especially if you are also responsible for production support. But there are other team members that often have knowledge about the application. QA Analysts and developers have in-depth knowledge of the application, so use them for support until you have had time to get caught up on the application.

Your top priority should be focusing on the stakeholder(s) who may be most upset about a new BA coming onto the project. Have the departing BA schedule time with those stakeholders to personally introduce you one-on-one. It is in your best interest to make these stakeholders feel comfortable. Ask them what you can do to make the transition easiest on them. The reality is that the departing BA is departing. The stakeholder may be upset, but if you ask for their input on making the transition smooth you are taking the first step in winning them over.

Next, get the departing BA to give you a brain dump on how all the stakeholders like to communicate. Which ones like formal meetings and which ones prefer hallway conversations? Get a list of those that like formal documentation and those that do not require formality. Understand what communication medium the stakeholders prefer; email, text, phone, face to face, etc. What stakeholders are usually positive on projects, which ones bring conflict? Are there stakeholders that don’t get along? Are there stakeholders that dominate meetings? I think you get the gist of where I am going.

The BA who is departing understands and subconsciously considers all these factors when interacting with each individual stakeholder. That’s why they love him/her. Since it has become second nature for the departing BA, it may not be easy for them to think of the answers to your questions.

The easier thing for the departing BA is to give you a demo of the application. Fight the urge to allow that to happen unless you have the time – after the analysis of the stakeholder(s) has been completed.

My one warning on the subject is to validate what you have been told. We all have biases and the departing BA may bring theirs when answering these questions. Take into consideration what you have been told – but make your own final judgment as you interact with these individuals.

All the best,

Kupe

Don’t forget to leave your comments below.

How to Handle Tight Deadlines as a Business Analyst

Written by Sergey Korban on November 30, 2010. Posted in Articles.

When you are assigned a complex project that has a short timeframe (as often happens), it can be nerve wracking – I know this from experience. It’s like driving a racing car – you have to push close to the limits but any error can throw you completely off the track.

The first thing that I do when I get a project like that is considering the reasons for the deadline. You can end up with a tight deadline for a variety of reasons. The deadline may be mandated by the management. It can be determined by interdependencies between projects. It can be defined by market compliance rules. In other cases it’s estimated using the work breakdown structure for the project but ends up being too short because of wrong assumptions.

So how can you as a business analyst make sure that circumstances don’t control you and your team, and you deliver your project successfully? Keep in mind that sometimes you can be successful even if you don’t meet the original deadline!

Here is a visual summary of deadline causes and ways of handling them:

Let’s look into the ways of handling deadlines in more detail.

Manage the Manager

Management sometimes sets up deadlines with a good “buffer” to allow themselves time for decision making at the end of the project, or because they don’t expect to get results on time and want to push things along by moving the deadline forward. This can be best mitigated by having good communication with the management.

However, what can you do if your manager does set an unreasonably short deadline? Find the tolerance level of your project sponsor (management) and of the key stakeholders who can influence the sponsor. Talk to end users to understand the severity of not delivering on time. There can be scope for negotiation.

Shuffle Dependencies

If your deadline is constrained by dependencies, you can talk to project managers of the upstream and downstream projects to get a better understanding of the interconnections. You might be able to find a way to reorganise things and either get what your project needs delivered earlier, or move the deadline for your own project.

Be Smart About Compliance Deadlines

If you’re working on a compliance project, it may have a firm deadline established by the market bodies. In this case find out if there is a transition period. It is usually provided because market participants have differing levels of compliance and don’t have the same resources available to make the transition. You can also evaluate the impact of breaching the deadline (such as fines for non-compliance), and prioritise the parts of the project which would have the highest financial impact if they are overdue.

Double Check Estimates

When it comes to deadlines defined by estimation, it’s a good idea to double check the estimates. Ask what facts and assumptions were taken into account when the task was initially estimated.

Watch Out For Changes

Once the project starts, you have to watch out for changes in the project environment. Changes will affect project completion time, so work with the team and stakeholders to update the WBS and the schedule.

Organising Work On Projects with Fixed Deadlines

After you’ve applied the practices above and you are sure that you’ve done everything you can to negotiate a reasonable deadline for your project, the next phase is organising your work in the best possible way to meet the deadline.

I’ve found that the following practices help me complete projects on time:

Determine the business context which will be affected by the change to status quo
Define the scope of the solution required to satisfy the identified business need
Plan short iterations to verify the project direction
Align the solution with the existing business processes and IT infrastructure

Each of these practices is discussed in more detail below.

Determine Business Context

Completing this step successfully often determines the success or failure of the project.

Many organizations that operate in a competitive environment have well defined and standardized processes. Many others don’t however, so be prepared to discover them. Explore the business processes which may be affected by the new solution. Learn which systems are used by the business within these processes. Embedding new solutions into these business landscapes should be considered thoroughly to reduce resistance to changes and exclude redundancy in project management, solution delivery and transition to the new state. If done right, it also gives a business analyst an opportunity to find ways to add value to the business.

The rationale for the project should be identified by the project manager, while the business analyst should identify business drivers and actual business needs.

Define Solution Scope

This is the exciting part of the project, but defining solution scope has never been an easy task. Short timeframes and technological changes which may occur during your project make it even more challenging.

In general, to cope with this task the project team needs a solid foundation to build on – well documented processes and good infrastructure. Knowing and using best industry practices can often point you towards defining a sustainable solution and save exploration and research time.

When it comes to defining solution scope, my approach is to use only the “must” requirements for the “initial” solution, and prioritise the remaining “should” requirements into subsequent phased releases (“final” solution).

You must work closely with the solution architect and play an active role in exploring available options. Often the overlap between business analysis and system architecture saves a lot of time – I have saved up to a third of project time by ensuring that the architect could use my documents as a useful starting point in producing a detailed design of the solution.

Plan Short Iterations

I’m still on the fence with regards to the Agile method. Its value is clear in software development (at least for certain kinds of projects) but when it comes to business analysis, I’m not so sure. However, short iterations are one useful technique in Agile which can reduce project time. Use them to get a summary of the completed and outstanding tasks, evaluate changes to the project scope, and identify feasible shortcuts.

Project manager and business analyst need to present a unified front in dealing with business stakeholders. Face to face communication is essential to make short iterations work for analysing the current situation, required changes and making decisions on the next steps. Informal communication style helps too – really, there’s just no time for strict formalities if you want to get things done. It’s very important for the project manager to arrange a “green corridor” for access to authorities and clear the way for the team to focus on delivering rather than struggling with bureaucracy.

As a business analyst, you also have to do your share to deliver results quickly by being professional and active in all your activities (industry research, compliance requirements and so on). Make sure that communication is well maintained between everyone involved in the project.

Align Business and IT Infrastructure

Most of the time new solutions are embedded into the existing environment. It’s a good idea to make maximum use of the existing components and processes to make the introduction of the new solution less intrusive and to minimise the number of temporary patches and business interruptions.

I try to present the solution in terms of interacting services to achieve this. I transform business references to applications and systems into services and show how they could interact. This approach allows me to show the business users how all pieces of the business, including external parties and outsourced services, come together and how the new solution will improve overall efficiency.

Conclusion

Whenever you get a project with a short deadline, don’t forget that there are two major considerations: what can be done to change the deadline, and what is the best way to organise your work to meet the deadline.

The practices presented in this article should help you address each of these considerations.

Don’t Forget to Leave Your Comments Below

Sergey Korban is the Business Analysis Expert at Aotea Studios, publisher of innovative visual learning resources for business analysts. We think business analysis should be easy to learn! We deliver practical knowledge visually, with a minimum of text, because that’s an efficient way to learn. Find out more at http://aoteastudios.com

How a Business Analyst Becomes an Advocate

Written by Kupe Kupersmith on September 27, 2010. Posted in Articles.

If you know me, you know I make it clear that building relationships is one of the most important skills of a business analyst. By building strong relationships with your stakeholders you become an advocate for the business and your project team. But, how do you build these relationships? How do you become an advocate?

In April of this year I started doing an improvisation workshop for business analysts called “Business Analysis through Improvisation”. If you read my earlier post, “Improv Comedian Turns Business Analyst“, you know I regularly performed with an improv troupe for many years in Atlanta. In the workshop, I discuss and demonstrate improvisation rules and guidelines that I feel help the attendees be better BAs.

Here are two rules that I cover in the workshop that I want to highlight here. These rules will help you build strong relationships so you’ll be viewed as an advocate.

Keep Conversations Moving Forward

I covered this in my earlier post, but I felt it was important to bring this up again. In improv, as you probably know, there are no scripts. The same is true for business analysis. I can bet you never have a word for word script ready that you use in your conversations and interviews with stakeholders. Because there are no scripts, in improv you can never “deny” the other actor. If an actor says something to you, you have to accept what they say and add to the conversation. You never outright say no. If someone walks into a scene and exclaims “Wow, I love that you colored your hair yellow,” you never say “it’s not yellow.” That denial instantly puts the burden back on the other actor to come up with something else. It kills the scene and ends the conversation.

In business analysis, for example, our business stakeholders come to us with changes in scope. If you always say “No, sorry that was not in scope”, you are out right denying. You end the conversation with the stakeholder. You may think you are ending the discussion about new scope all together, but all you did was make the stakeholder mad. He’ll just escalate and talk to your PM or manager to try and get the new items in scope. Does this mean you should say yes? To be an advocate and build a strong relationship, you don’t have to say yes, but you need to go with the conversation. In a situation like this, after clarifying the need I’ll say something like “we can definitely add that feature, let me work with the team to see what the impact on the cost and schedule will be. Then we can discuss if you still want to include it in this release.” Doesn’t that sound so much better? You keep the dialogue moving forward. You come across as a team player, as an advocate. By not denying you help everyone make an informed decision on how to move forward.

Another example, when you can deny is when a stakeholder comes to you with a solution. In business analysis we are taught to understand the root problem or opportunity before jumping to a solution. Often, the business stakeholder comes to our team with a solution. A denial type response would be something like, “Let’s not talk about the solution before we have had time to understand the true business need.” Should you discount their solution option? Do you assume they have not done the business requirements for the project? Instead you can respond by saying something like, “Great, tell my why you need that solution.” By starting the conversation that way you’ll get the answers you need and be able to help the business address the problem or opportunity with the right solution.

Be in the Moment

Since there are no scripts in improve, you need to be completely focused on what is happening on stage. You have to be a true active listener. If you are not in the moment, you’ll miss words and signals from other actors on the direction of the scene. It becomes apparent real quick if you are not in the moment. You’ll say and do something that makes no sense.

There is plenty of talk that we need to be active listeners and be in the moment. Business analysts are communicators, we are great listeners. But, how many of us are really great active listeners? It is not all our fault, society is against us! Things like instant message, email, a smart phone at your hip, back-to-back-to-back meetings, and a full plate at work and in your life make it easy for us to be distracted. What happens is we are always multi-tasking. Women, historically, are the best multi-taskers. This goes back to the hunter-gatherer theories where men were the hunters and had to be singly focused on the animal they were going to kill that day. Women were the gatherers, collecting fruits and vegetables, taking care of the kids, and the home. There is a great one man play called Defending the Caveman that explains this theory in a very funny way.

One of the biggest relationship killers is not being in the moment. How do you feel when you are having a meeting with your manager about an issue you’re having and he is multi-tasking; checking his email or asking you to hold on while he takes a call? I know I would feel like he doesn’t really care much about helping me with my issue. This is what your stakeholder will feel like if you do the same during an elicitation session. If you felt it was important enough to schedule the meeting, then focus on that meeting. Act like a hunter and focus only on that meeting. If other important activities need to be addressed, it is better to reschedule the meeting then keep interrupting it.

Keeping conversations moving forward and being in the moment are two ways to build strong relationships and be viewed as an advocate. Continue to work on these areas.

To your relationships!

Kupe

Don’t forget to leave your comments below

Managing Up; Tips and Tricks for the Project-Challenged

Written by Fred on August 31, 2010. Posted in Articles.

Managing Up is Vital

If you are a busy business analyst or project manager or even if you combine both roles by necessity, you already know from experience that “managing up” is a big deal. Failure to influence your boss’s boss, sponsors, and anyone else more senior to you to pay attention to important project details and give you their buy-in and commitment can have very serious consequences. You, your team, your organization, and your customers risk lost time and money, scope creep, poor quality results, lower innovation, reduced productivity, and higher levels of stress and burnout causing delays and mistakes due to high turnover and absenteeism. The following six tips and tricks will to help the project-challenged who know that “managing up” is important and would like to be proactive in doing more of it better.

Managing Up is a Mindset: You are the Pilot
Imagine you are in the pilot seat in an airplane and you see a view of your project approximately 10,000 feet beneath you. Keep this “big picture” view in mind when you attempt to influence upwards.
You Have About 20 Seconds
All it takes if the first 20 seconds of a conversation with a boss, sponsor, or other individual more senior to you for him or her to gain or lose attention and interest. So use your time wisely by focusing on the most important things first, such as the outcome, risk, benefit, or issue. Leave the details for later.
Train Them to Say “Yes”
Ask questions that are easy for them to say “yes” to, such as: “Do you agree that we must meet our targets?” or “It is important that our internal customers have their requirements met, right?” When they say “yes” to questions about the big picture, you are actually training them to say “yes” later when you ask them to commit to more specific things. Gaining their attention and interest first is necessary if you want their commitment and action later.
Plan Your Message to Start at the End First
Start at the end first. State your recommendation or the results expected and identify related risks, options, or changes next. Remember that the other person is also a pilot and is looking at the project from afar. It is up to you to focus him/her on exactly what you need and want and once this is understood, you have done the ground work to address more specifics.
Train for the Marathon
If you were planning to run a marathon, you would probably not expect to reach the finish line without sufficient training and participation in shorter races. It is the same with managing up. You also need to train ahead of time to build stamina and experience. Prepare for the marathon experience of managing up by creating a managing up marathon training program consisting of short spurts of conversations that give you experience and help build confidence. Choose topics for these conversations that are not high-risk, such as asking for commitment to change a small part of a project or recommending a project change that has a positive impact on productivity or the bottom-line. Your goal is to prepare for bigger, more complex marathons requiring more stamina and confidence.
Practice, Practice, Practice!
Don’t restrict your training to actual projects. Find ways to practice “managing up” in your personal life as well. Create a list of people you can practice with, including: colleagues; friends; professionals outside of work. Try asking them for something, assuming they are senior to you. If you are a member of a professional association, club, or group, seek opportunities to influence others with more authority or seniority than you and then ask for their feedback.

Summary

Managing up is a skill as well as a mindset. It requires the perspective of a pilot, the ability to plan and deliver your key message efficiently, training yourself and others, and ongoing practice for success. Like anything else that is worthwhile, if you make the right choices about how to spend your time and energy to prepare properly, you have greater chances to achieve better results.

Don’t forget to leave your comments below

Dr. Gail Levitt is President of Levitt Communications Inc., a global organization in Mississauga, Ontario with affiliates in Vancouver, Ottawa, Montreal, and Boston. Gail is an accomplished author, facilitator, and coach, specializing in leadership communications, critical thinking, and problem solving. She has over eighteen years of success, leading and advising diverse teams in managing people and projects. Some of Gail’s customers include: RIM; Bell Canada; HSBC; Telus; ACETECH; Project World; ESI International; Sauder School of Business, UBC; ACETECH; Transport Canada; Canada Post; Toyota; Starwood Resorts International. Dr. Levitt is currently writing a book on team leadership for business analysts and project managers.

We Don’t Need BAs!

Written by Kupe Kupersmith on May 25, 2010. Posted in Articles.

Since you are reading this post I assume you are most likely a business analyst, want to be a BA, or have BAs working for you. At the end of this post I think you’ll all agree that we do not need BAs. I think it is also safe to say there is nothing positive about a BA.

Let me first define what I mean by “BA”. I do not mean a Business Analyst. I am referring to a Bad Attitude. I am a firm believer that we need business analysis, but we do not need business analysts with bad attitudes. Our profession is still young, and bad attitudes will seriously impede our ability to positively impact organizations around the world.

I recently went to a store to make a purchase. When I was next in line the cashier said, “Can I help the next person?” Her words were fine, but the tone was terrible. Her body language and lack of enthusiasm said “I don’t really want to help the next person in line, but that is what I get paid to say.” I knew this was going to be a bad experience, but I tried to approach it with an open mind. Unfortunately it only got worse. Here is an example of how I was treated. I had two items to pay for so I handed the cashier both. I quickly learned she was not happy about that move. She yelled, “One thing at a time!” I really like the store, but I had a really bad experience because of one person’s bad attitude.

In situations like this I normally don’t complain. I will just never spend my money at that establishment in the future. There are too many options out there. I don’t feel like trying to give feedback and help resolve the issue when I can just go down the street to the competition.

As a business analyst do you have a bad attitude? Let’s find out with this short quiz.

Answer the three questions below by choosing the answer that you most closely can relate.

When you are eliciting requirements for a specific process and your stakeholder starts talking about another process do you respond by saying something like:
a. “One thing at a time!”
or
b. “This is a great conversation, but we have time scheduled to discuss that process tomorrow. Can this wait until then or should do we need to explore this process before continuing?”
When your project manager asks for your status do you respond by saying something like:
a. “I’m working on it. I would be done if you didn’t keep asking me my status.”
or
b. “Things are looking good. I have a few more meetings this week. I’ll give you an update Friday.”
When your QA Analyst asks about a requirement for the third time do you respond by saying something like:
a. “I already explained this to you twice; I doubt a third time will help.”
or
b. “Let me see if I can explain this better…”

If you answered “B” to all of these most likely you have a positive attitude and are viewed as a team player and contributor. If you answered “A” to any of the above you may have a bad attitude. Think about why you answered “A” and you may want to make some adjustments.

Similar to my response at the store, the people you work with may not give you critical feedback about the impact of your attitude. They may choose to not work with you and decide to work with another BA without a BA (bad attitude).

Positively yours,

Kupe