Skip to main content

Tag: Best Practices

The Top 10 Business Analysis Skills for 2012

Written by Angela Wick on . Posted in Articles. 1 Comment on The Top 10 Business Analysis Skills for 2012

I like to think of the BA role as a broker of information, getting big picture and details from many different people, groups, executives, subject matter experts, vendors, technical resources, etc . . .

what the BA does with all this information and how it gets communicated and repurposed for each audience is opportunity for a BA.

Today’s trends are pointing towards the following themes for BAs:
– Business Agility
– Innovation
– Engagement of stakeholders to drive agility and innovation

The needed skills to meet these trends in 2012:

1) Conceptual Modeling Skills
Engage your stakeholders with more meaningful dialog!  Conceptual Modeling of the business view of the solution has always been a critical tool to help bring business, technology, and delivery groups together in defining solution scope.  I have had many BAs tell me that they do this and show me their conceptual models.  What I find when reviewing the models is more of a technical architecture or data context diagrams.  Technical architecture and data context diagrams have their place, but the critical skill I am seeing as a gap in BA skill sets is the business view (vs. technical view) of the solution scope, this will be critical to engaging stakeholders and setting the stage for innovation

2) Communicating Details and Concepts
Similar to the conceptual modeling skills is communicating various levels of detail appropriate to the audience.  This can be especially difficult when you have various stakeholder needs on the team or in the meeting, and many times multiple views is needed to ensure the right message is communicated to all audience needs.  Where I see the gap today is details are not organized to be digestible and understandable to many audiences and there may be a lack of conceptual and context to accompany the details.  Without the concept and context information, the details – even when well organized – may not be understood or thought of in with the frame of mind that the BA needs from the stakeholders.  Rethink requirements packaging, does the same document need to go out to everyone?  Or, can each audience be given a guide as to which pages/sections are most pertinent to them?  Just a few ideas to help stakeholders consume what is important to them.

3) Curiosity
How curious are you as a BA?  This has always been a critical skill for BAs.   Ensuring curiosity in finding the root cause of the problem or opportunity, getting the  right audience, usage, context, purpose for requirements requires a strong level of curiosity in BA work.  Curiosity will go far in 2012 for BAs wanting to build competency and skills in the world of mobile apps, cloud computing, and continuing agile trends.  Curiosity will make some of the unknowns of today easier to work within, a curious mindset will take BAs into communicating the unknown and help organizations innovate.

4) Decomposing the Abstract into Details
I have to call this out separately from Conceptual Modeling and Communicating Details and Concepts.  The same themes are in play, but yet executed a bit differently and in different scenarios.  Decomposing the abstract into details is also referred to as “critical thinking” and sometimes “system thinking”; taking something large, ambiguous, and abstract and breaking into smaller pieces, patterns, and views.  It is about helping others see the details and big picture from different perspectives, helping stakeholders with varying points of view and priorities see where their details and others fit into the bigger picture.  It will also help BAs better estimate and work with PMs on the status and risk of requirements.

5) Mentoring and Coaching
As the BA role becomes increasingly more valued in organizations, two things will happen:  1) Organizations will need a career path for Sr. BAs, and 2) Organizations will need to develop internal strategies to develop more talent in the BA role and Sr. level skill set.  Mentoring and coaching skills are key for Sr. BAs in both of these strategies.  Mentoring and coaching done by Sr. BAs will develop leadership competencies in the Sr. BAs while developing BA competencies in new or more inexperienced BAs in the organization.  Sr. BAs who have the opportunity to mentor and coach will develop further leadership competencies needed to elevate the competencies of the BA team as a whole.

6) Communicating Risks
Project Managers focus on risks to the project budget, schedule and scope.  A BA needs to focus on risks to the business value of the solution and communicating the risk.  BAs are in a prime position to see the details and big picture view; this includes seeing the risks to the project, delivering a solution that does not maximize business value.  I find that BAs have an intuitive sense of this, but often struggle to communicate the risk in a way that gets leadership attention.  In order to get leadership attention to the business value at risk, BAs will need to develop skills in communicating the true business impact of the risk.  This means going beyond communicating in terms of the features and functionalities of the process or software, and going beyond that, there is not enough time for requirements to be done right. It means communicating the impact it will have on the business operation or strategy.  For example, when the functionality of a point of sale application has a requirements conflict in the process of accepting payment from customers, the focus needs to turn to the impact of the conflict on the customer service representative’s ability to serve the customers and the customer experience vs. the technical details at risk of the requirement.  In the heat of requirements and design details, we often let the details drive risk discussions and never get to the bottom line impacts that can really propel leaders to make the right decisions.

 

7) Leveraging the “parking lot”
Are you running your meetings or are meetings and stakeholders running you?  Many BAs get into tough situations in requirements meetings and feel that other agendas and personalities are driving their meetings astray.  Using a “parking lot” (simple visual list of items that do not fit into the meeting agenda to be followed up on or scheduled into another meeting) to manage and control the meeting agenda, content, level of detail and difficult personalities is a key strategy.  Most importantly, make sure that the parking lot is visible to everyone in the meeting.  Having the parking lot in your notebook or on your laptop does not show others that you have their ideas and concerns captured to discuss at a later time.  Be empowered to take control of your meetings!

 

8) Change Management
Embracing the BA role as an agent of change will continue to show the value the organization the value the BA role brings to the organization. Projects are about business change; the BA role is about bringing the most value possible in a solution to address the business change.  The role of a change agent in the BA is critical to ensuring all impacted parties are ready for the changes needed to accept the solution.  Understanding how changes and solutions impact the stakeholders operations, processes, attitudes and behaviors is a key skill in maximizing the success of the new solution and the business value it brings.

9) Asking WHY?
I love the word “Why”, but hate to use it.  My challenge to readers of this blog is to help one another find ways to ask “Why”.  Many times using the word “Why” can come across wrong to the other person, it can seem defensive and the other may wonder why (no pun intended) you are asking.  Finding different ways to ask “why” can alleviate this dilemma.  My favorite ways to ask “Why?”:  Tell me more about what is behind the need for abc?  What does success look like?  What would happen if this project does not get implemented? What are yours?

10) Impromptu Whiteboard Drawing
In 2012 when innovation, agility, and engagement are the trends, being able to spontaneously draw will lead to stakeholders to a deeper level of engagement.  Getting up to draw shakes up the flow of boring meetings, engages others to focus back in on the discussion, and brings out humor – let humor be a friend. You don’t have to be an artist to draw concepts on whiteboards that generate great dialog, discussion, creativity and innovation.  It also does not have to be you that does the drawing; ask someone else to draw what they are thinking and your meeting will benefit in many of the same ways.  When the drawing yields powerful and meaningful discussion, be sure someone takes a picture with their phone.

No matter that type of BA, no matter what the industry, these skills in 2012 will set your projects up for deeper engagement, innovation and agility.

Don’t forget to leave your comments below

 

The Great Facilitator Part 4: What Great Facilitators Know About Estimating

Written by Bob Zimmerman on . Posted in Articles.

Bob_Z_mar_27_28309844_XSIn my previous article, I shared an exercise that helps teams understand how to develop a plan that is manageable and achievable. I call this “Commitment-Based Estimation.” Now I will show how great facilitators can play a role in making their teams super confident about their estimates.

Who Should Facilitate an Estimation Session?

Before we talk about how to do a great job in facilitating estimation sessions, I’m going to discuss how to select the best person to facilitate these sessions.
I typically find that the Team Lead drives estimation sessions. Project Managers and Architects are also fairly popular in this role. The key, however, is to find a person who will allow the team to own the estimate.
When a Project Manager leads the estimation, they usually drive a team to develop estimates that reflect the project plan. Once the Project Manager starts imposing schedules, or challenges the team to optimize an estimate constantly, then the team won’t feel ownership. This is not how to get a Commitment-Based Estimate.

Similarly, when an Architect drives the estimate, they typically assume a technical frame of reference and try to help the team understand the mechanics of the estimation. If they impose their vision for the complexity of certain tasks, once again, the team won’t feel ownership.

So who makes the best facilitator for estimation sessions? I’d say look for a person who is:

  • Part of the team and has skin in the game
  • Already a respected leader and trusted by the team not to impose their personal views
  • Is experienced in helping teams balance risks, contingencies and dependencies

The One Rule You Should Never Break

There is one rule the facilitator must never break: Allow the team to come up with estimates they believe in. Unless the team is very junior or new to estimating, every team needs the freedom to come up with their own estimates. If the team asks for two weeks, never impose a shorter schedule and tell them to get the job done in one week.
Now you may be thinking: Does this mean I can never challenge a team? It does not. What it does mean is that as a good facilitator, you ask the right questions and help them share and test their assumptions.
For example, ask the team: “What would you need to get this done in a week?” or “How much can you get done in a week?” By asking the right questions, the scope may get reduced. Now you get the deliverable within a week because the estimation was not imposed on them. Again, the facilitator does not want to undermine the ability of the team to own the estimate.

Other Things Great Facilitators Do:

Some of the other approaches that have helped me personally manage some very strong groups include:

  • Make sure the team does not give an estimate that is simply unrealistic. I talked about this recently on my blog, in a post called “Attitude of Estimation.” As a facilitator, you want to encourage the team to come up with an estimate that is workable.
  • Ask questions and create assumptions to make the team think of scenarios that might happen. This helps the team create more accurate estimates.
  • Make sure everyone has a voice. Business Analysts need to be able to articulate the business needs and clarify what is being delivered. Project Managers can offer perspective on dependencies and resource availability. The QA team needs to test not only to see if something works, but also to see if the product is in compliance with business needs. Developers, Architects and the database team also need to weigh in. Too many times an estimate does not include a full set of voices and results in inaccurate estimates and mediocre functionality.

In my opinion, too many people take the facilitator role for granted. I think there are some jobs that are too important to perform any less than perfectly. Facilitation is one of them. A poor facilitator can break the spirit of a super talented team while a great facilitator can lead a good team to surprise itself on what it is capable of.

Get the whole picture by checking out the other 3 parts of this series –

Part 1 –  Part Business Analyst. Part Orchestra Conductor. Part Psychologist – Do you think of yourself as an effective facilitator but unsure how others perceive you? Maybe you’ve been at a meeting recently where the facilitator is doing a fantastic job but you just can’t figure out exactly she is doing differently. The differences are subtle.  This series is about those subtleties that separate the great facilitators from the mediocre ones.

Part 2 – Check in and the Chair:  Why can some facilitators effortlessly lead their team to achieve brilliant clarity and enthusiastic alignment? This article includes some basic practices great facilitators use to manage a room and deliver impressive results.

Part 3 – Commitment Based Estimation: In order for an estimate to have teeth, the team must feel ownership of the process and genuinely believe the estimates are achievable. This article includes exercises to facilitate estimates that are realistic and manageable. 

Don’t forget to leave your comments below.

Bob Zimmerman’s career in custom software development spans more than two decades and has been largely dedicated to the process of leveraging technology to drive innovation and growth. As Geneca’s CTO, Bob Zimmerman continues to build on his work as the driving force behind Getting PredictableS.M., the requirements definition and project best practices that are the foundation of Geneca’s mission to make software development predictable. He continues to extend these best practices to leverage more value for clients and new growth opportunities for Geneca.

Requirements for the App – Tips and Tricks for the iPad World

Written by Remzil Kulkarni on . Posted in Articles.

Tablets are omnipotent these days. They have revolutionized the way we do a lot of things. App developers are in high demand and businesses with a product are jumping over themselves trying to get ahead in the game by establishing a presence through offering an app. The recent slew of customers that approached us for requirements related to an app offering got me thinking of how doing requirements engineering for an app is different from a regular product and what key things you should bear in mind as you develop your app.

It’s all about the look

What makes an app on a table device cool is that the graphics are slick and somehow makes the person using the app feel tech-savvy in the process. Like it or not, the “cool” factor for a user interface is one of the things any app is rated on. My advice is to not take this area lightly, but rather to invest in user design experts whose work you have access to and appreciate. Ensure the process is creative and collaborative.

Tip: In order to contribute as a BA, explore various leading apps in the same domain or targeted at a similar audience in order to find out what you like, what’s popular and what suits your app perfectly.

The sense of touch

Tablets are typically devices with touch screens, so your app will have to respond to touch events well. This can open up an entirely new dimension of engaging with the user. The level of satisfaction a user derives from a well-performed task in response to an intuitive action can be very high and almost addictive, and can encourage usage of the device and app frequently. Innovation can be key in this area as well – the iPad started a revolution simply by tapping the potential of this aspect of interaction with the user.

Tip: Mimic the actions you would perform where applicable. For example, flipping a whiteboard to get to the next page, or for a charting tool, pulling a pie slice out to see what the rest of the chart looks like without it. Then, ensure your user interface responds to such motions.

Give something back quickly

While we are using tablets more and more for certain tasks, not everything has changed. Recent surveys of tablet usage [1] show that while we use tablets more for tasks such as listening to music, downloading, maps and information when we’re on the go, we continue to prefer our desktops for activities that require extended periods of attention. A lot of work therefore continues to happen on desktops and laptops. Given this nature of usage, a good principle to follow is to give something back to the user quickly.

Trick: If your app is helping someone plan their finances, make realistic assumptions based on some key data to show them projections quickly in order to demonstrate the capability and value of your app. Then give them the opportunity to fine-tune the accuracy of projections by entering their data for better results. Once users can see what your app can do, they will take the time to enter data as they know what they will get in return.

Scope

Organizations are rushing frantically to put an app version of their product “out there” and establish a presence in the mobile space. But the problem is that when you have an existing product or solution, you can’t really take it in its entirety and “app it.” You typically should consider reusing components and bear in mind the overall goal of the solution, but feel free to make the app different where it needs to be in order to fall in the category of a well-thought of and useful app.

Tip: A good exercise to carry out is to study the scope of the existing solution that’s available and prioritize what is necessary and what can be forfeited. Your app should have functionality that’s absolutely vital but can leave out the bits and bobs that are incidental.

Keep your app light

Keep your app light. Reuse components from an existing app by making them available as online services. Avoid unnecessary data capture. However, if your app needs to function as a standalone app, balance the need to keep it light with its need to be functional in a disconnected mode.

Tip: Explore non-functional requirements related to app development to ensure all aspects of the app are covered.

Be aware of app guidelines

Lastly, be aware of the limitations and guidelines for your app. While most leading target operating systems (Android, Blackberry, Nokia’s Symbian operating system) don’t proactively publish guidelines before putting an app on their store, Apple has stringent guideline [2] and your app will have to go through a two-week approval process before it is made available on the App Store. However, even for apps targeted at operating systems other than iOS, the guidelines on Apple’s website are a great read to help you develop a good app.

Trick: Go through the guidelines on the Apple website for pointers on your app.

Conclusion

With all of that said, requirements for apps are exciting and a brilliant learning opportunity. The aspects I’ve put forward in this article are an excellent starting point but there’s lots to discover along the way. I wish you all the very best for putting together your app – happy discovering!

Don’t forget to leave your comments below. 

[1] BusinessInsider.com, TechRadar.com 
[2] Apple app guidelines can be found at https://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html 

Remzil Kulkarni has over 15 years of experience in technology enabled business transformation focused on Insurance, Telecom and Finance. She has a Masters degree in Engineering Management from Southern Methodist University, Dallas TX and is President of the IIBA Pune Chapter. She is a certified Prince2TM Practitioner and a Fellow of LOMA (FLMI). She currently heads the Business Analysis Centre of Excellence at Mastek Ltd., where she has worked for the last 6 years. 

Meet Your Business Analysis Influencer

Written by Kupe Kupersmith on . Posted in Articles. 1 Comment on Meet Your Business Analysis Influencer

Kupe_Mar_6_2012_32083524_XSMy goal in life is to meet everyone in the world.  I know that goal is not SMART (specific, realistic, etc.). It is not reaching the goal that is important; it is the effort I go through to try and meet the goal that counts. The goal goes deeper than just “meeting” people. I try to meet everyone I can and establish a relationship. Building strong relationships is a constant, consistent goal of mine. Some grow deeper than others, but I don’t discriminate. I meet and engage with people sometimes without knowing how I will add value to that person or how they will add value to me. For some this is a hard concept to grasp. Some feel so busy and can’t fathom spending time getting to know someone new without knowing why you should get to know them.
 We work in a highly collaborative work environment. You don’t have to do everything on your own. If you build strong relationship people are more willing to help you. So if you are too busy to build relationships it is because you are not building relationships.

If you still need some convincing regarding building relationships, here is one big reason you should bother. Build relationships to ensure your message is delivered. This thought popped into my head after seeing an interview with Bono, lead singer of U2. He is a huge advocate to reduce or eliminate the AIDS virus. He has helped raise money and awareness that is dramatically helping the cause. But Bono is not a doctor. He does not work for the Center of Disease Control.  He is not trained to do the research, administer tests or provide medicine to patients. What he does do is use his influence to help raise money to support the cause. He uses his influence to convince lawmakers they should allocate funds and resources to support the cause.  He delivers the message.

I speak with many BA professionals that get frustrated when they can’t convince their management that they need more focus on the BA practice. I speak with many BA professionals that realize projects are not going well, but are not sure how to get their message to the right person. Sometimes you don’t have the influence necessary to get your message across. Does that mean you should stop? Of course not.  You need to detach the message from the delivery of the message. The point is not who delivers the message; the point is that the message gets delivered. 

Most likely Bono won’t be stopping by your office anytime soon trying to convince your management that they need to fund your effort to start a Business Analysis Community of Practice. Go out and meet some new people in your company at all levels.  Who knows, maybe they’ll be delivering a message for you.

Don’t forget to leave your comments below.

 

The Business Analyst: When Not Knowing the Answer is OK

Written by Josh Jones on . Posted in Articles. 1 Comment on The Business Analyst: When Not Knowing the Answer is OK

A new project has spun up and you’ve been assigned as the Business Analyst (the same scenario outlined below could happen if you are added to a project that was already in flight). You’ve done your diligence preparing; you’ve read the scope, reviewed the charter document and called your first requirements gathering meeting with the business partners and IT representatives. Your meeting is underway and while you’re attentively listening to the business SME explain the detailed process for transferring a policy from one agency to another, you find yourself feverishly jotting down notes as the nuggets of information being thrown out are too juicy not to capture. Then it hits you: you have no idea what the business SME is talking about!

                Though your notes are word-for-word with what the business SME is saying, they might as well be a foreign language that you don’t speak. The fear of looking foolish or not wanting to lose creditability in the eyes of the project team, you do your best to keep writing while desperately trying to grasp the concepts that the SME is laying out in front of you. When first assigned to a project, this is where most BAs get tripped up.

                In my experience (ten years in the BA and PM space), I’ve been there many times. And it wasn’t until a few years ago that I finally figured out how to handle the situation described above successfully. No matter how seasoned of a Business Analyst you are, a situation like the one above will happen. It’s inevitable. It’s very rare for a BA — no matter how much experience they have — to start every project with knowledge that will allow them to know what’s going on at all times for all scenarios.

                The hardest parts of when you don’t know the answer is 1) trying not to look dumb in the eyes of fellow project team members 2) knowing how to make sense of what is being said and 3) being able to take the information given to you — at a time when it makes no sense whatsoever — and produce relevant (and accurate!) requirements.

                There are four simple tricks you can use to get you out of the jam of not knowing the subject matter yet still get something out of the meeting.

·         First, use your “Veil of Unfamiliarity.” As a contracting BA, I have many clients. And most of the time, when I work with a client, I know very little about the interworkings of their internal process, knowledge workflow and system-to-system linkage. But that doesn’t stop me from quickly picking up the things I don’t know. When I find myself new to a client, I often stand behind my “veil of unfamiliarity.” What I mean is even though you have all the best analysis skillsets in your toolbox, they are useless unless you know how to use them on a project. When I find myself on a brand new project that I know very little about, I will often say (out loud), “Since I’m new to this subject matter, I’m going to step behind my veil of unfamiliarity for a moment, could you explain that in more detail?” This is similar to asking the client, “Would you mind putting what you just said into easier-to-understand terms/language?” The reason you want to use your veil is so you can understand the unfamiliar topic at a higher level (less detail) before later diving into the weeds of that particular process flow or UI functionality or whatever it is that you’re trying to understand. In other words, you are openly admitting that you aren’t familiar with the details of the subject matter…yet. Being open and honest by asking the client to make the topic easier for you to understand will further strengthen that trust relationship with the project team and business partners. Using your “Veil of Unfamiliarity” is another way of saying, “I don’t know what you’re talking about yet, but I will soon,” all the while saving face (protecting your integrity) with the project team.  

·         Second, look for action items — even if they aren’t for the BA — and insert yourself into them (when it makes sense, of course). Another trick I’ve found to work well is to associate myself to follow-up action items that come out of a meeting even if they don’t directly involve me. Take the opportunity early in a new project to absorb and learn as much as you possibly can. It doesn’t matter where the source is either; just immerse yourself in anything topical to the project. Of course, it goes without saying that you should take care of your BA responsibilities first, but if you have the chance to sit in on a meeting with IT as they review a design document or sit with the business partners as they figure out how they want to incorporate their needs into deliverables, do it. Even though some of the action items aren’t directly tied to your BA work on the project, you’ll be building that background knowledge that will come in handy later on in the project.

·         Next, create a partnership with the Business SME (or wherever the knowledge is). While it’s always important for the BA to have a healthy partnership with the Project Manager, it’s just as important to have a healthy, open partnership with the Business SME. After all, they are the ones whose needs must be met by the project. More often than not, this relationship is overlooked, not in place or undervalued, and can lead to limited — or in worst cases broken communication — between you (the BA) and them (the owner’s for the needs/business requirements). If you want to be successful in the BA space, you must value the partnership with the business SME. It will be so much easier to get vital information quickly when the partnership with the Business SME is healthy, strong and open.

·         Lastly, and probably the hardest trick of all, is to be humble and ask. This is the simplest trick to grasp, but also the hardest to actually do. If you are like me at the start of a new project, you’re cautious of exposing your proverbial underbelly to a new project team. By that, I mean you’re hesitant to let your colleagues know that you have a vulnerability around fully understanding the subject at hand right out of the gate. However, if you don’t speak up now (at the beginning of when you start a project), it’s too late. Because the role of the BA is so vital to the overall success of a project, you should never pass up the opportunity in the beginning to ask the business SME — or anyone else on the project team for that matter — to clarify their comments if you do not understand them. It could be comments about scope, business needs, requirements, functional specs or anything project related. The point is, it doesn’t matter what the topic is: if you aren’t crystal clear with your (the BA’s) understanding, ask them to clarify their statement(s). More often than not, the requirements phase of a project moves at light speeds, so it’s important to level-set expectations of understanding the subject matter early and often in order to avoid getting left in the dust. And if you’re worried about losing creditability in the beginning of a project for not knowing the subject in detail, just imagine how much creditability you’ll lose when you get three weeks into requirements gathering sessions and you still don’t know what’s going on. Trust me, I’ve seen it happen and it’s not pretty! In the end, the business SME — or whoever is providing the clarity — would rather provide more clarity on a topic that you asked about than find out you (the BA) did not fully understand it.

Too often, I’ve seen good business analysts lose credibility with a project team because they aren’t willing to admit that they don’t know something. Fearing they will be ridiculed, the BA will play along like they know the subject matter, but when it comes down to crunch time on a project and they aren’t as well versed in something they’ve said they are, then that is when the requirements are at risk of being incomplete, or worse, incorrect. It doesn’t have to be that way! The next time you find yourself sitting in a project meeting or requirements gathering session and you don’t know the answer to a question or don’t know how a business process works, try using one of the tips in this article to assist you with gaining a better, clearer understanding of the subject. In the end, you will thank yourself for being bold enough to put aside your fear of losing credibility and doing what it takes to have a clear, concise understanding of the topic at hand. By doing that, you will have put yourself in the position to produce solid, real and most importantly, accurate requirements.

Don’t forget to leave your comments below.

Josh Jones is a seasoned BA with over 9 years of experience in the BA and PM space.  Josh has successfully applied project and analysis leadership expertise to deliver project initiatives in a wide variety of industries (including product fulfillment and distribution, insurance, broker dealer management, Life and Annuities products, information technology, network services, financial services, investment/retirement products, and agriculture). 

As a mentor and BA coach, Josh’s hands-on, “create a solid partnership” approach blends his desire to share his business analysis expertise with his passion for helping others improve.