Tag: Best Practices

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

Know When to Say When; How Not to Get In Over Your Head With Metrics

Written by Glenn R. Brule on May 18, 2010. Posted in Articles.

As business analysts we can agree that benchmarking is important, but from that point on we’re likely to find the conversation diverges. Differences abound in approaches of how and what to benchmark in order to prove value. Organizations become overzealous in what they want to benchmark and scorecard in their drive to create greater efficiencies. However, a key component for developing and monitoring successful metrics is ensuring that they are in alignment with the maturity of an organization. Knowing when to say when can enable less mature organizations to develop metrics that are both useful and appropriate at the developmental level.

Benchmark People and Process First

In a previous BA Times article on managing metrics, the author and my esteemed colleague, Keith Ellis, made the case for creating multiple point metrics for people, techniques, process, technology, organization and documentation standards. While creating multiple-point metrics may be the best possible scenario, it is an enormous undertaking and, given the maturity of an organization, the least likely possible scenario the organization can accomplish successfully. An organization that lacks BA maturity would do well to start with a simple approach to metrics that considers people, process and tools, with a greater emphasis on the first two.

I highly recommend forming a team of individuals to work together, ideally in a requirements workshop setting, to determine the metrics to be monitored. Select a maximum of five things to measure for a benchmark. Keep in mind that the metrics don’t have to be exact. A “swagged” or estimated number calculated with simple mathematics and a plus/minus degree of accuracy can be used when there are no specific data elements readily available and should be acceptable until a level of maturity is reached. As the organization begins to mature, so too can the details being measured, the formulas used to calculate those measurements and the accuracy of the metrics.

Processes are interdependent and complex, so restrict yourself to three to five processes. Basic measureable process-related activities could include such items as time to complete an iteration, number of change requests and total number of iterations. Also, look at the solution development lifecycle and pick one or two that are bleeding the most. Finally, schedule benchmarking on a monthly basis. One year out is too late for a remedy, and with fewer metrics to benchmark, you will find the task is quite manageable.

Tools really shouldn’t play a role in developing and monitoring metrics, but they invariably do when an organization begins to cloud and confuse what level of metrics should be assessed. It’s important when using this simple approach to remember that knowledgeable people and refined processes are needed before you can select a tool. A tool is only as good as the people and process using it. A simple SWOT (strengths, weaknesses, opportunities, threats) analysis will help a team to quickly ascertain appropriate people and process metrics.

Scorecarding Metrics

Scorecarding is very important for measuring how well activities are being executed and individuals are performing. It should be related to goals and objectives and show a demonstrated relationship with benchmarking to people and process (and tools, if they’ve somehow gotten into the mix). However, scorecards are often put in place and not used because they’re so complicated or they don’t relate back to benchmarks.

Even in singular projects, scorecarding should focus on one to three things. Take, for example, two or three benchmarks that would be measured for running a requirements workshop. One workshop iteration takes 40 hours of effort for planning, execution, validation, etc. The next workshop is conducted after training people and reduces the workshop effort to 20 hours. The scorecard would indicate a 50 percent increase in efficiency.

Project Comparison

Side-by-side paired project execution has the potential to be a valuable benchmarking tool, as long as it doesn’t become too burdensome or complex. Keep in mind that no two projects are identical so give yourself some leeway in finding comparable projects. For instance, a $100,000 project could be benchmarked against a $150,000 project. Then, follow two or three things from project to project and be prepared to evaluate five to ten projects that are similar in nature.

Ongoing Reviews

Peer reviews, contract reviews and structured walkthroughs can increase efficiencies more effectively than look-back reviews conducted after the fact. The reviews should be done through the entire process as iterative functions so that by the time you’ve gotten through a project, you should be confident in your scorecard data and benchmark comparison.

Toward Positive Financial Impact

As an organization matures, overall project costs, return on investment, internal rate of return and the time spent on validating output of interviews, requirements workshops and other BA functions will build toward performance improvement, not only for individual projects but also for project portfolios. This will enhance the value of business analysis and the positive financial impact that can be realized. An organization that lacks in BA maturity should take a simple approach to measure its performance. When it comes to requirements metrics, don’t try to run before you can walk.

Don’t forget to leave your comments below

Glenn R. Brûlé, CBAP, CSM, Executive Director of Client Solutions, ESI International brings more than two decades of focused business analysis experience to every ESI client engagement. As one of ESI’s subject matter experts, Glenn works directly with clients to build and mature their business analysis capabilities by drawing from the broad range of learning resources ESI offers. ESI, a subsidiary of Informa plc (LSE:INF), helps people around the world improve the way they manage projects, contracts, requirements and vendors through innovative learning. For more information, visit www.esi-intl.com.

Tips for Presenting Requirements and Deliverables

Written by Maria Horrigan on January 12, 2010. Posted in Articles.

In the past, my presentation of business level requirements has involved walking the business through the 80 pages of UML use cases and watching them glaze over after 10 minutes. I wanted them to understand what they were signing off on but this was not the right way to present the material to my audience. I was finishing up a project recently and was asked to present our teams’ findings, requirements specification and design to the director group.

My project was to develop a consolidated reporting tool that would bring together six different program data sets. So I took a user centered design approach to developing the business requirements and incorporated a lot of the information architecture tools and techniques I had learned on projects over the least three years.

I started with face-to-face consultations and workshopped the needs and wants of the service users who were required to supply reports. I also talked to internal users who would analyze and summarize the reports for the branch’s policy decision makers. We decided to use user stories and personas, want maps and process maps to present our findings about what the users really wanted and then used the site map and a prototype to show how the system would look and feel.

The presentation went extremely well as the directors were taken through the process and had the visual clues to show them what the user experience would be. So why was this presentation approach successful? I think it was because my BA documentation tends to be very visual, as I find that my audience likes to see how the design and the system will work, and need to be brought along the journey. In a recent presentation I told the story through the eyes of the users and found this was a very effective way to present my deliverables.

Here are my top five tips for presenting requirements and deliverables:

1. Establish and Communicate the Purpose. On my project, the service users clearly wanted a system that would help them manage and plan their day-to-day service business, not just a tool to use for reporting back to the funding branch. I presented our findings from the stakeholder consultations and then presented the six personas to demonstrate our understanding of these six key user groups. I told their story by presenting user scenarios and explained why they wanted what they wanted from the system. My key message was that the system users wanted a management tool, not a reporting tool. By clearly presenting this purpose and demonstrating through personas and user stories, the directors understood that this change would mean a win/win at implementation time as the burden of data entry for services would be lessened if there was something in it for them – namely useful management reports.

2. Use Visual Artifacts to Display Requirements and Design. The personas were a very powerful tool to show what the archetypal users of the system wanted and how the groups differed in what they required. We displayed the primary, secondary and tertiary user needs in a want map and this helped to show the key differences and commonalities of wants across the varied stakeholders. The process maps showed how the different groups would interact with the system and how we would help them through the process, streamline the process and reduce duplication of information. The prototype helped to show how automation and integration of data would decrease data entry burden and also capture information that could be used to aid their management and planning.

By presenting deliverables as user scenarios and showing the findings through use of personas and want maps, the directors were able to see the value in responding to the needs of the services as this would, in the long run, gain acceptance and quick wins for the system implementation. Walking this audience through use case after use case would have missed the mark with this group, as it would have been too detailed and technical and would not have given them the same feel for the concept of what the users wanted.

3. Understand your Audience. My presentation was aimed at the business users, and I needed to understand their needs so I could tailor my presentation to meet their needs. I needed to understand who the key players were? Who were the influencers and decision makers? What did they want from this system? What were the relationships between the different stakeholders? This was difficult as it was a short project (only 10 weeks) and I had little direct contact with some of the key players. Therefore, I worked closely with my business product owner to ensure he saw the deliverables in progress and had a chance to comment prior to their being presented to the directors and executives. I sought his guidance on how to handle the meeting; the dynamics of the stakeholders involved, and walked him through the key messages. This preparation meant that I could frame the deliverables in a way that would hit the mark for this audience.

4. Understand the Business Context. Presenting to an audience when you don’t understand their business does not end well for the presenter. In conveying understanding of requirements for the business and users, I believe it is important to know the business context. I did my research and preparation before the meeting and asked myself:

What are the key drivers for this change?
What processes are involved?
What are the internal or external environmental constraints or opportunities out there for this group?

Once you know the context, demonstrate that you understand the business needs and vision. Then demonstrate how your solution will meet that need.

5. No Surprises. In the past I have been reluctant to show my work in progress, as I wanted it near completion before sharing it (as the “Virgo” perfectionist in me wanted to make sure it was right!). In working on Agile projects in recent times, I have embraced this skinny solution concept and am now comfortable starting with a skinny version, and fleshing it out as the work progresses. When I had finished a piece of thinking about users, processes or design, I would share these artifacts with the core project team, the key business product owner and then refine. This iterative approach helped my target audience to get a feel for what the deliverable would look like and meant that, when it was being presented, it was not a new concept, just a more refined and validated version of what they had seen earlier. Remember that you are presenting your requirements design solution, not telling a joke, so sending material out beforehand as pre reading will not “spoil the punch line”. If you feel people may miss the point of your deliverable without you there to narrate, then allow for their questions at the end rather than taking questions throughout the presentation.

Don’t forget to leave your comments below

Maria Horrigan is an experienced business manager, IT strategic planner and information and communications specialist. She has over 10 years senior management experience within the pharmaceutical industry, not-for-profit and Government. As a principal consultant, Maria is an experienced information architect, senior business analyst and IT strategic analyst and provides advice on developing system requirements with a focus on information architecture and user-centred design, to ensure appropriate IT systems are intuitive and usable. She is a senior practitioner and a well-known Australian speaker on communication, user-centred design, and business analysis. She has experience managing large federal government contracts and project management of large scale business system implementation, systems planning, and analysis and change management. She has a reputation for innovation, managing change, driving strategy implementation and successfully delivering programs. Maria is a Board member and Vice President of Women in Information and Communication (WIC).