Tag: Skills

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

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.

The BA and PM Role; a Deeper Dive

Written by Elizabeth Larson on February 23, 2010. Posted in Articles.

In November I wrote about whether or not the roles of PM and BA could be combined into one. I received wonderful responses, all of which broadened my perspective. Although I remain convinced that in most circumstances both roles are preferable, I understand that certain conditions, such as project size and corporate culture, may dictate whether or not one person plays both these roles on the same project. Another factor is that from a high-level view the skills seem similar. However, once we dive deeper into the business analysis and processes, the overlap lessons.

Today I’d like to explore the amount overlap between the two roles somewhat more deeply. Because of the need to use a common set of terms, I’m going to base my discussion on the Knowledge Areas (KAs) found in both the BABOK® Guide 2.0 and occasionally refer to the PMBOK® Guide Fourth Edition. Let’s start with the BABOK® Guide’s KAs. A mnemonic to help remember the KAs is PEACEUS. Think of all the “pieces” in the BABOK® Guide. PEACEUS stands for:

	Knowledge Area	Knowledge Area Highlights
P	Business Analysis Planning and Monitoring	Just for the business analysis phase(s): determine if the project will be waterfall or agile, identify stakeholders, estimate activities, decide which processes to use, determine metrics, monitor business analysis work.
E	Elicitation	Prepare for elicitation event, hold the event, document and confirm the results.
A	Requirements Analysis	Organize, prioritize, specify, verify, and validate requirements, including modeling requirements.
C	Requirements Management and Communication	Baseline requirements, manage changes, trace requirements, document requirements, present requirements for approval, manage re-use.
E	Enterprise Analysis	Define business need, assess gap between “as-is” and business need, determine how to approach the solution (“to-be”), define the scope of the solution, and develop a business case for undertaking a project to meet the business need..
U	Underlying Competencies	Qualities, knowledge, and skills that business analysts need to have to be successful, such as trustworthiness, systems thinking, ability to negotiate and communicate, and business knowledge to list a few.
S	Solution Assessment and Validation	Determine if the organization is ready for the change, figuring out how to implement the change, and allocate requirements to different projects, phases, releases, or iterations.

On the surface it appears that there are significant overlaps. For example, collecting requirements appears to be an area where there is confusion over roles and the potential for conflict. Another area is that of procurement, particularly relating to the Request for Proposal (RFP) processes. Another area for role overlap and conflict is scope management. Enterprise analysis is about defining the solution (product) scope. The PMBOK® Guide describes the need to detail out the scope of the product and the criteria needed to accept the product.

It seems to me that although there are areas of potential overlap, there are some significant areas that require unique skills. The table below shows some of the areas of overlap and uniqueness.

	Knowledge Area	Areas of Overlapping Skills	Requiring Specific BA Skills
P	Business Analysis Planning and Monitoring	Identifying stakeholders, defining activities, estimating activities, developing metrics, monitoring the work.	Determining if the project or phase should be waterfall or agile, planning the processes needed to complete business analysis.
E	Elicitation	All these areas potentially overlap. Many of the skills are required by both the PM and the BA.	Skills for eliciting some requirements activities require a different skill set. For example, if the elicitation event is to prototype a new set of web pages, create use cases, or elicit data requirements, specific business analysis skills are useful.
A	Requirements Analysis	Not too much overlap. This area does include defining assumptions and constraints, but it’s a stretch to say there is much overlap here.	Organizing project work is very different from organizing and prioritizing requirements. Specifying requirements, which is where the modeling happens, for example, requires a specialized skill set that doesn’t overlap with those of the PM.
C	Requirements Management and Communication	There are many overlapping communications and presentation skills.	Although baselining, documenting, and tracing requirements are discussed in the PMBOK® Guide, I believe that it takes unique business analyst skills to effectively complete these activities. Also, managing re-use is a unique skill.
E	Enterprise Analysis	Defining the solution scope requires similar skills to decomposing deliverables into a work breakdown structure (WBS).	After much agonizing about this one, because this was work I did as a PM, I can be convinced. Except for defining the solution scope, all the processes in this KA, can be more effectively handled by the BA,
U	Underlying Competencies	All project professionals, both PMs and BAs, need these competencies.
S	Solution Assessment and Validation	Assess organizational change.	With the possible exception of assessing organizational change, this KA requires a unique set of skills to determine if “the solution meets the business need and facilitate its implementation” Babok® Guide introduction to Chapter 7.

I believe that if we were to take these processes within each KA down to the tasks within each process, we would see even more uniqueness. So for now, I continue to think it best to separate the two roles where possible.

Don’t forget to leave your comments below

Will the Real BA Foundational Skills Please Stand-up

Written by Kupe Kupersmith on February 16, 2010. Posted in Articles. 1 Comment on Will the Real BA Foundational Skills Please Stand-up

An interesting discussion was started on a LinkedIn group a few weeks ago posing the question, “What would you think is the single factor that determines project success?” This sparked a healthy debate and made me think on a more micro level for business analysis. I asked myself what are the foundational skills needed by a business analysis professional? It did not take me long to answer my own question. Let’s see if you agree.

Let me start with what I think they are not. In our profession it has been discussed that at a minimum, BAs had to know the accepted techniques used in the role. Examples include use cases, workflow diagrams, context level data flow diagrams, etc. These are critical pieces to making an excellent BA, but not the foundation. They are interchangeable and new ones can pop up at any time. Did people not analyze before use cases became a standard format for analyzing and documenting requirements? Sure they did. These techniques are not a constant.

Analogy time! Let’s consider a house. The foundation is solid (hopefully). It supports the living space of the home. The living space is filled with appliances, furniture, art, rooms with doors, closets, windows, etc. Depending on what you are doing in your home at any time, you use some rooms, some furniture, and maybe an appliance. At the same time rooms, furniture, and appliances are not being used. Then there is the bread maker you were given for a house warming gift. That baby only comes out during special occasions. The rooms, furniture, and appliances are the equivalent to the techniques I mentioned earlier. The techniques are used when necessary. Every project does not require the use of every technique you have available. So then, what are the real foundational skills you need?

When I think of a foundation, I think of something that is constant, always there. Your foundation needs to be built with trust, analytical and problem solving skills, mixed with ethics, personal organization, business knowledge, and communication and interaction skills. These are often referred to as soft-skills, but these are nothing close to being soft. This is your foundation. From here everything is possible.

In the IIBA BABOK these skills are called underlying competencies. The writers of the BABOK define these as “the skills, knowledge, and personal characteristics that support the effective performance of business analysis.” The writers got it right by using the words “underlying” and “support”. Without these skills BAs cannot perform at their peak, just like a beautiful front door that won’t open or close properly because of a settling foundation.

Knowing the technical aspects of the techniques available to you is not enough. Even if you know the when to use an Activity diagram and all the symbol definitions, it is useless if your foundation is not secure. What good is that technique if you don’t have the interaction skills to elicit the requirements, or the communication skills to ensure you understood the requirements, and the ability to ensure the solution team clearly understands the need.

Take a few minutes and inspect your foundation. Is it secure?

Foundationly yours,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

What Every Executive Needs to Know About Hiring Business Analysts

Written by Keith Ellis on February 9, 2010. Posted in Articles. 1 Comment on What Every Executive Needs to Know About Hiring Business Analysts

The ability to hire great people is one of those skills that differentiate hugely productive managers from the mediocre. When dealing with a specific project, it gets even tougher with the number of distractions, time sensitivities and need to fill head-count numbers on a project plan. It’s very easy to get sucked into short term thinking, and sometimes HR management practices get short-sighted as well. No, the probationary period of a new hire is not a generic safety net.

Here’s some fast thinking you can do in under 30 minutes to help you hire better:

Get away from hiring generalists

Rather than trying to hire people that are generally great at all things, focus on the areas of greatest value to the organization. Take a few minutes to jot down the services this person is going to offer the organization. Figure out where in the project cycle and which requirements definition and management processes will really impact your organization’s performance. Be brutal in your focus to get it down to one or two areas where this person needs to shine.

By getting ‘service focused’ (verb/noun pairs like ‘Facilitate Requirements Meetings’) you’re being blunt about the competency that is essential for success on the project.

List the Skills Needed

Most companies have defined templates used in their requirements definition and management approach. How many hiring managers look at that document and simply extract use cases, cross-functional swim lane diagram, etc from the template to get a list of techniques the analyst would need to know to be successful. How many people look at the services and say, what techniques would need to be known here to be successful? If you’re looking for requirements definition capability and “Facilitate Requirements Meetings” then you probably want someone who knows the techniques for facilitating a cross functional team.

Want a good technique for listing soft skills? Just list the things that annoy you as a manager.

Test Required Skills

I’m a huge believer in testing skills, before the interview and after the interview. It reduces your reliance on your first impression. It is way too easy to get caught up in thinking the first 30 seconds is the make/break part of hiring. I always end up reminding myself, I’m not hiring a politician. Put more weight on getting the person to do a pre-interview task, get them to do a post interview task and look at the judgment, work quality, and skills used in doing those tasks. Give a documentation focused person a requirements document and say, is it done? Have a facilitator run a simulated facilitation session. Nothing elaborate, just focused on the skills that are essential to success. You could even look to outside organizations that do skills testing (Inquestra, etc) if you’re not feeling particularly creative or need to hire dozens of people and don’t have time to administer the tests.

Get Away from Trying to Hire Industry Experts; Focus on Analyst Skill

Here’s a basic rule of thumb: your line of business managers are the subject experts that know the business. Analysts, need to know analysis. If the analysts are competent, they will function really well, regardless of the industry or position. Granted, if you want a systems analyst for SAP, you need to focus here a little more, but definitely not for business analysts. Let’s face it, the pool of candidates can get really small, really quickly. And chances are, if someone is emphasizing being an industry expert, I’ll bet they are not overly strong in pure analyst skills.

Be Happier

There is nothing worse than dealing with a bad hire. Well… I hate it! Not just the HR stuff, but also what it does to your good performers and the overall project. If your company doesn’t already have great role descriptions in place, try some of these techniques. Having a great team is just a happier place to be.

A Few Thoughts for Those of You Looking for a Job

Lots of folks are out looking for positions today. Here are a few thoughts on positioning yourself for something else:

Consider positioning yourself as a specialist. You do a few things really, really well.
Try putting more active tense “services” you provided to the organization in your resume. Hiring managers (and google) scan for keywords.
List proof of your skills as your accomplishments. (How about: ‘Lead analyst principally responsible for facilitating requirements meetings on over 50 projects’)
Make your expertise as an expert analyst come out

Trying these ideas means deliberately writing a resume that does not fit every opportunity for a contract BA. The idea is to position yourself for certain types of opportunities, and to be successful in landing a spot when one of those types appears. As an interesting side benefit, employers tend to pay more for someone they perceive to be a specialist than they would someone they see as a generalist.

I wish you all great success.

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.