Tag: Business Analysis

Stop Calling Yourself the Bridge

Written by Kupe Kupersmith on February 11, 2014. Posted in Articles.

I just returned home for BA World Dallas and had some great conversations, including some during my presentations. During my Business Analysis is Dead, Long Live Business Analysis talk, which is based on my blog of the same name, I was discussing how I see the Business Analyst space changing. The old way of doing business analysis is dead, the new way is alive and well, just different. I asked the attendees how they see their role and a response I received was “We are the bridge between the business and IT.” With a booming voice, helped out by the microphone I had, I yelled “WRONG!” To the responder’s defense, I understood what he was saying…I just used it as an entry point to my make my case. And now, here is my case!

You can’t see yourself as the bridge anymore. Being a bridge is inefficient and less value add to the team. If you get a chance to see Jeffrey Davidson talk he does a great “skit” on being a bridge showing how long it takes to get information over the bridge and all the things that are lost in translation. It’s hilarious and makes the point! Think about a bridge in a major city. What happens when everyone is trying to get over the bridge at once…bottleneck. What happens when the bridge is closed for repairs…bottleneck. What happens when a New Jersey Governor’s office shuts down access to the bridge…let’s not go there! Do you get the point?!

You need to see your role as a facilitator, an analyzer, and an advisor. Listening to a radio talk show host explain the difference in media today vs. the past is a great analogy to how I view the present and past of business analysis. The talk show host said the role of media in the past was to provide information. That’s why everyone rushed home to hear the 6 O’clock news. Today, information is flying to our computers, tablets and phones as it is happening. So there is not much use for a radio talk show host, other than breaking news, to provide just the information. Now they have to analyze situations and provide opinions on what is happening. And if you don’t, the consumers will be looking to someone else.

This is exactly how I feel about you. You no longer have to focus as much on the information gathering and sharing or simply being called the bridge. You need to focus on the analyzing and being an advisor to your team and organization. If not, your consumers will be looking to someone else. Here are three things you can be doing instead of acting as the bridge and only bridge.

Allow others to play in the BA space. If others can elicit information, let them. Act as a coach for your team to help them determine what questions to ask, give them guidance on different elicitation techniques to use. If you are having an elicitation session, bring your developer and QA analyst along for the ride. They can hear things first hand, ask the questions they have, and see how you run a session.
Focus more time on analyzing. Let the information come in however it comes in and use your analytical skills to determine what the real needs are, what additional information may be needed to fill the holes, see how your project is impacting other projects, and think about the challenges of rolling out the new system or enhancements. You have plenty to do other than being the bridge carrying information.
Be an advisor. You need to be part of the discussion around the solution. Early in my career the view of the BA role was to just focus on the requirements, not the solution. There were BAs that would cringe when discussions of a solution were happening before the requirements were fully vetted. Discussing the solution should be part of your role. Your team and business partners are not looking for analysis, they need solutions. If you are not part of the solution the perception is you add less value. Do you want a financial analyst to just tell you there is no way you’ll have enough money to retire, or to tell you there won’t be enough money to retire and here is what you need to do to have enough money to retire? You want an advisor, not just an analyst. Your business partners want an advisor which includes analysis of the situation and designing solutions.

Once you adopt the mindset of not just being the bridge you can open your mind to focus on what is valuable. There was a time, the bridge was needed. That just is not the case anymore. There may be times you need to be the bridge. You just do not need to be the bridge full time. Be a facilitator, analyzer, and advisor.

All the best,
Kupe

Don’t forget to leave your comments below.

Where is the Business Analysis Profession Going?

Written by Aaron Whittenberger on February 4, 2014. Posted in Articles. 1 Comment on Where is the Business Analysis Profession Going?

It is customary that at the start of a new year people reflect upon the past and look into the future. I believe you will agree some people are better at both activities than others. In fact, recently Julian Sammy, Head of Research and Innovation at the IIBA® did both. In this recent article he takes a look at predictions that he and other members of the Senior Leadership Team of the IIBA® made in 2011 about what 2013 will look like. He then takes a look at what he thinks 2016 will look like for the business analysis profession.

So I will jump on the band wagon (because it is a popular thing to do and because I have something to say) and give you a look at what I think the business world will look like for business analysis professionals for the next couple years. Trends take time to develop and take hold so I will take a multi-year look into the future, and why I believe Julian looked three years into the future. You will see my analysis has a heavy tendency toward the tactical IT Business Analyst role because, well let’s face it, that is what I know best; and it is still the largest business analysis role in existence today. Maybe one of my trends should be a prediction of how that will change soon. Ok, I got my crystal ball out, are you ready?

Trend 1 – Agile is here to stay

There are those that still believe that agile is a fad, soon to pass. Sorry, anything that has been here for 10+ years is not a fad. Many fashions (remember bell bottom jeans) are a fad; agile is here to stay. Although acceptance of agile methodologies may stagnate a bit, many of the tools and techniques of agile will find their way into IT project work in many companies; further developing the hybrid project approach.

Resistance of agile acceptance will come from companies that “tried” agile and failed. Some will “try” again or for the first time, some will abstain; yet some will realize you don’t “try” agile, you decide to give it your “all” (all the organizational support it needs) or don’t bother. Further resistance will come from the idea of a 100% dedicated team to one project seems an unwise use of resources in today’s business environment; and agile professionals will struggle to answer that concern to the satisfaction of business management. Also, lack of truly effective Agile Coaches will hinder the willingness of companies to give it a go. This will become a valuable consulting role; if you’re looking to drive your career into a role of the future, consider this one.

Trend 2 – Business agility will demand greater collaboration on IT project teams

Greater demand for quicker IT project delivery times will continue to crunch project schedules and resources. The trend of doing more with less will continue. This will demand greater collaboration among the project team. The BA Team, QA Team and PM will give way to the IT project team; with the BA as the liaison to the business stakeholder. They will all merge into the “core” project team with the responsibility to deliver full functionality, on-time and on-budget. The “we vs. them” mentality will slightly diminish between business and IT, but it will drastically diminish among the IT team itself; gaining greater synergies for a more effective working environment.

Trend 3 – Resurgence of Strategic Enterprise Analysis

Continued dissatisfaction with dismal project success rates will bring about a resurgence of the strategic business analysis role. This role demands a whole different skill set than the traditional IT business analyst. Skills to do market research, capability gap analysis, SWOT analysis, benchmarking and feasibility studies will become in greater demand. The skill to create a bullet-proof business case describing the business value of IT projects will become paramount. This role will work with project approval committees to define for them the business value and risks of projects under review, thereby giving necessary support to project portfolio management.

Trend 4 – The Value of Product Vision gives rise to the Product Owner and Product Manager roles

Product Vision will gain wider acceptance as many will come to the realization that this means more than maintaining future enhancement and feature lists, and product roadmaps. System users will become greater source of future direction of product vision of systems development. Yes, these roles exist today, but primarily in large enterprises. We will see this role gain acceptance in Small to Medium Sized (SMB) companies. Even in large enterprises these roles will gain greater recognition with clear career paths. As these roles gain higher profile recognition, people in the role realize that their value comes in communicating that product vision to all business and IT stakeholders so that all have a shared vision of the future product. For business and IT professionals looking to drive their career, this is another good direction for the future.

Trend 5 – Requirements collaboration tools integrates social media and the desktop

With greater emphasis being put on business agility and greater collaboration on the IT project team, requirements management tools providers will jump on the opportunity, as these tools make the transition to requirements collaboration tools. Transparency of requirements during their development will become enhanced as other members of the project team, including business stakeholders will have that visibility. The requirements tool itself will become the accepted communication tool among the team, allowing them to interactively communicate about the requirements being developed. Yes, some tool providers have already integrated this capability, but organizations will integrate this capability into its business and IT processes, again due to gaining business agility.

The great enhancement in coming years in this area is that these tools will integrate to peoples’ desktop. Imagine being in conversation with a group and needing to schedule a meeting to continue the conversation. Imagine being able to scan everybody’s calendar and having a few suggested dates and times that everyone can make it to the meeting. Upon agreement of a good date and time, imagine everyone in the conversation receiving a calendar meeting invitation moments later; and all this happens right there in one tool. Now imagine that the conversation included vendor personnel who use Lotus Notes calendar while you use Microsoft Outlook; and some participants use Google calendar. Each recipient receives the proper invitation for their calendar.

Finally, the business analyst doesn’t rely on Microsoft Office as their primary requirements tool. Yes, some large, and SMBs, have been past this stage for a few years. However, this trend will become much more wide spread as more and more companies invest in these requirements tools; and those that have had them for a while will invest in the next generation of these tools to gain the benefits of the increased collaboration for their project teams.

Trend 6 – The Business Analyst as Proxy for the Business Stakeholder

In organizations where the Business Analyst reports to IT management and work on IT projects, the company will recognize the value of putting a Business Analyst on the business side to work as a proxy for key business stakeholder(s); this will be an additional BA role within the organization. This will free up the business stakeholder(s) to run the business while their proxy takes on the responsibility of working on IT projects to bring about the change that the key business stakeholder desires. This, of course, means that the business analyst has to not only share the product vision of the business stakeholder, but must understand the ‘what’ and the ‘why’ of all the business change requests with great clarity.

Trend 7 – Businesses increases its Investment in Training

Changes in the business analysis environment will increase at even greater velocity. That along with the increase need of collaboration with a lot of different roles within the business organization will cause business analysts to develop new skill sets. Businesses will continue to see the value in investing in the development of its people, but will look for greater bang for their buck when investing in training for business analysts and other project professionals. Training that take the people away from work for shorter time, allow more people to attend the training for lower cost will see increased utilization over the traditional classroom training class.

Education providers in the space will scramble to beef up their virtual classroom offerings with excellent content, while continuing to offer the traditional classroom training for those organizations that value the in-person interaction with the instructor and other students, and are willing to pay for it.

Local IIBA® chapter professional development days (PDD) will help fill this need as well. PDDs like WI BADD (Wisconsin), I-BADD (Iowa) and SO BARC (Cincinnati, OH) will continue to gain attendance over the next few years. Chapter’s that don’t yet offer this service will see the value and begin to provide this service to their business community. Likewise, local business education providers that have any capability in this space will beef up their business analysis offerings to leverage the opportunity of this trend.

Trend 8 – Business Analysis jobs will continue to be in abundance

With organizations putting focus on business analysis roles, additional roles will prop in those organizations. With the diverse skill set necessary to be effective, business analysis jobs will be in abundance. We will see an influx of people flowing into the business analysis profession from other professions including project management, quality assurance, business and operations. Now the flow will be both ways as people move from business analysis to project management and the other professions, but the flow into business analysis will be greater. Even with that inward flow it will not keep up with the demand for good business analysts, creating even greater demand for training.

Trend 9 – We will see a resurgence of Business Analysis Centers of Excellence

With all these changes in the business analysis space, organizations will also look inward for training for their business analysts and give them opportunities to learn from each other. Business Analysis Communities of Practice (BACoP) and Centers of Excellence (BACoE) showed rapid growth in 2011 and 2012, and stagnated a little in 2013. Organizations will see their value in training and incorporating best practices across lines of business. They will help ensure the same level of service across lines of business. We will see a slight uptake in BACoPs and

Trend 10 – Business Analyst and Project Manager roles will continue to Overlay

As the Project Management Institute (PMI®) continues to expand its teachings into areas like stakeholder management and collecting requirements they will lose focus on their core purpose and core audience. Businesses will realize that requirements, and stakeholders, need more than just management or documentation. They will realize the different skill set and focus (business focus, not project focus) needed to effectively develop requirements from the business and project management will give way to a project leadership mentality. Businesses will see that dual project leadership roles, one focused on the project and one focused on the solution, has greater probability to lead to increased project success rates.
The practitioners that perform these roles, through their professionalism, will find ways to work together for the benefit of the organization no matter the teachings of the PMI® or IIBA®. As for the IIBA® and PMI®; just like David and Goliath, David will

So that’s how I see the next couple of years for business analysis, and related, professionals. Now let’s see how I stack up to the ESI International’s predictions for the

So which do you agree with? What would you add or subtract from the list?

Don’t forget to leave your comments below.

The Top 8 Mistakes in Requirements Elicitation

Written by Aaron Whittenberger on January 21, 2014. Posted in Articles. 1 Comment on The Top 8 Mistakes in Requirements Elicitation

Whether you are an Enterprise Business Analyst, Enterprise/Business Architect, Business Intelligence Analyst, Data Analyst, Process Improvement Analyst, Agile BA Team Member or IT Business Analyst, you work to bring about change within the organization. Sometimes these are small incremental changes, and sometimes these are big changes that require an organizational shift or cultural change. Whether small or large, most of those business analysis roles deal with gathering requirements. One of the key activities of a Business Analyst is to draw out and document business change requirements from stakeholders throughout the organization. As the International Institute of Business Analysis (IIBA®) celebrates their 10th anniversary this year, we are reminded that business analysis as a profession is still maturing, as is the practice of business analysis in many organizations around the world.

As organizations struggle with maturing their business analysis approaches, let’s take a look at some common mistakes that practitioners commit when eliciting requirements from stakeholders.

1. Improper Stakeholder Analysis

Often times resource managers or the Project Management Office (PMO) assigns resources to projects almost as early as the Project Manager (PM) and Business Analyst (BA) are assigned. With these resources the project marches on and the Business Analyst never does a proper and complete Stakeholder Analysis. Stakeholders can be missed because that early in the project all the lines of business within the organization that are affected may not be known. Perhaps as the project moves on, it takes a turn into a new business line; and if the Business Analyst doesn’t recommend that a representative of that business unit be assigned to the project team, then they are not doing their job. If you have stakeholders from one line of business answering for another line of business, you may not have all the business or functional stakeholders engaged in the project that should be.

One of the first activities that the Business Analyst should complete upon being assigned to a project is a Stakeholder Analysis. This helps ensure that the proper stakeholders are engaged in the project. However, a Stakeholder Analysis is not a one-and-you’re-done thing. It is an activity that should be considered throughout the project’s timeframe, especially when elicitation discussions take a turn into a new business area and there isn’t a representative from that business unit on the project team. This is the time for the Business Analyst to raise the red flag, complete a new Stakeholder Analysis, and recommend new resource(s) be engaged on the project.

2. Improper language in the requirements

Business Analysts that work in very large organizations or with very structured teams, especially Quality Assurance teams, have heard that your requirements have to be well structured and testable. Many Business Analysts have been told that requirements have to be SMART: Specific, Measureable, Attainable, Realizable and Time-bound. I worked in one place that advocated that requirements had to be SMART-CC, adding Complete and Concise to the SMART acronym.

Quality Assurance Teams advocate the SMART test for requirements as they want requirements that they can test. Even though, most of the time, QA teams test the solution against the solution (functional and non-functional) requirements, most Business Analysts will attempt to make their business and stakeholder requirements SMART. A lot of times the BA will fall into the trap of expressing the requirement from the technical viewpoint and in technical terms. So they have taken a requirement for/from the business and applied technical terms or changed the viewpoint of the requirement, which adds ambiguity and confusion for the business stakeholders.

Remember the business requirements and stakeholder requirements are primarily from and for the business stakeholders. Even though the technical team will use those requirements, the business is the main consumer of those requirements. Therefore, they should be expressed in business terms and from the business standpoint. Likewise, the solution requirements have to be SMART for testing purposes. The technical teams are the main consumer of those requirements, so they should be expressed in technical terms.

3. Jumping to design before getting the requirements

I have been in many stakeholder requirements elicitation activities where the stakeholders start talking about design and in which system this solution will be implemented. If the BA doesn’t squash those discussions immediately when they start too early, then they tend to multiply and consume the actual elicitation of requirements. Soon you have a design for a solution before you truly understand the business problem you are trying to solve—before you understand the business need.

This tends to put blinders on the entire project team, and everyone marches down the same path toward a solution because that is the only thing the team can see. Once the solution discussions begin, and are not halted by the BA, it tends to give everybody hearing the discussions a single focus, even though they don’t fully understand the business need. Quite often this leads to alternatives to the“initial solution never getting considered. This also leads into my next two mistakes BAs make during elicitation activities.

4. Not guiding the conversation during elicitation with a group of stakeholders

Even with a small group of stakeholders, even in a one-on-one stakeholder interview, discussions can go off course onto tangents that are not relevant to business needs. Sometimes the conversation can be so far off course that it is not even relevant to the present project. These conversations tend to distract from the task at hand and waste time during requirements discussions. It can cause stakeholders to become frustrated with the process and become disengaged with the project, as they find better use of their time than to continually hear a couple of people dominate the conversation with what they did over the weekend or other irrelevant topics. Another distraction is when there are two or three conversations going on in the room. Of course, all these issues compound as the number of stakeholders in the conversation increases.

Part of the task of the facilitator is to keep the discussion on topic. When the conversation goes off on a tangent, it can be difficult to find the proper time to rope it back in. The sooner the facilitator brings the conversation back on topic, the less likely further discussions will stray off, the less time is lost, and the more engaged your stakeholders stay in the project.

5. Getting approval for the requirements without a shared understanding of them

With today’s tight project schedules, often times the requirements approval process is rushed so much that ensuring that all stakeholders, business and technical, understand the requirements in the same way is difficult. With stakeholders coming from different viewpoints, ensuring that they all understand the requirements is a task in itself. A structured requirements walk-through will go a long way in accomplishing this task. As everyone in the walk-through hears comments from other stakeholders, a common understanding begins to take form. The stakeholders learn how others view the requirements.

6. Feeling requirements must be 100% complete and accurate before sharing with the stakeholders

Novice Business Analysts can fall into the trap of feeling that the requirements that they are documenting must be 100% correct before they share them with anyone. They feel that any corrections or changes to the requirements mean that they did not do their job correctly. So in an effort to make sure they are correct, they go talk to more stakeholders. They make sure to elicit from everybody in the organization. Then before you know it, the project is in analysis paralysis.

BA Managers have to ensure that there are no performance measures on the BA’s evaluation that measure changes to requirements. It is not a good measure of how well the BA did the job of elicitation. The BA themselves have to remember that they are one person and they cannot know everything. Changes to requirements are not any indication of how well the task of elicitation was done. Using a more collaborative approach to requirements elicitation, where the requirements are more visible throughout the process, is a better approach to ensuring the requirements represent what the business actually needs.

7. Not building trust with stakeholders

Often times BAs move from one project to the next, have four projects going on at once, and don’t take the time to get to know new stakeholders that they had not previously worked with. Getting to know the new people who you are working helps you understand their viewpoint and agenda. This will certainly help if conflict arises during elicitation. Understanding each person’s viewpoint will help the BA resolve the conflict by helping each person to understand the other viewpoints in the conversation. The BA cannot accomplish this if they do not understand the viewpoints in question. Taking the time to get to know someone shows them that you value their input and participation in the project.

8. Blindly using a template

I was recently handed a Business Requirements Document (BRD) template that had several categories of requirements including documentation, reliability, scalability and training, among others. All of these categories are non-functional, or solution, requirements—and as I said this was in the BRD template. Recognize the fact that these are solution requirements and do not have any place in the BRD. If you receive a BRD like this, remove these categories or mark “N/A” or “Will be defined during design and included in the Functional Requirements” in each category. If you do the latter, check the Functional Requirements document template to ensure that the category is in that template as well. If not, add it. Don’t blindly use a template just because that is what the organization uses. Don’t try to define solution requirements during business requirements. How do you know what your training needs are if you don’t know what the solution is? BAs are agents of change. Challenge the template and help the decision makers in the organization see the value of a correct template.

Conclusion

To do an effective job at requirements elicitation, avoid these traps that can get your activities off track. Be sure you have everyone in the conversation that should be, define the business need before designing the solution, ensure that there is a shared vision of the requirements, and document the requirements in a collaborative approach with the project team. This will help ensure that you do an effective job at eliciting the requirements for your organization.
So there is my list, what is yours?

Don’t forget to leave your comments below.

2014 Trends in Business Analysis and Project Management

Written by Elizabeth Larson on January 21, 2014. Posted in Articles.

The close of one year tends to encourage us to reflect on what has occurred in business analysis and project management during the past year and think about future trends. To summarize the trends we saw in 2013, the need for project managers and business analysts to be trusted advisors and to influence stakeholders, whether on an Agile or more traditional project, has not disappeared. The same can be said for the demands to balance distributed teams’ needs for efficient and effective communication tools with organizations’ needs for consistency and security.

Below are the seven new trends we see in the Project Management and Business Analysis fields for 2014.

1. Continued frothing-at-the-mouth enthusiasm for anything “Agile.”

The “Agile” bandwagon hardly seems to be abating. Whether organizations have really adopted agile, or they have stuck their toe into the shallow end of the “Scrum-but” pool, appetites for big, waterfall-type projects have diminished all around. This concept is further reinforced in the PMBOK® Guide – 5th Edition, released a year ago, which identifies phase-to-phase relationship and project life cycle options that account for waterfall, agile, and everything in between. So even for the PMs who haven’t had exposure to a real agile environment, there is more comfort with the idea that many of the tools and techniques that have served them well in the past can be applied on all types of projects.

PMs will increasingly find it an easy sell to break projects into subprojects or smaller projects, whatever the project life cycle and approach. They know too well the cost of trying to define and control many large projects, and they know their stakeholders would rather see smaller deliverables sooner. It’s not agile, per se, but more, smaller projects will resonate strongly with stakeholders as they define what project success really means to them.

The BA world is equally rabid about Agile, seeing the release in 2013 of the Agile Extension to the BABOK® Guide, ver. 2. Version 3.0 of the BABOK due out in 2014 will have an Agile Perspective, and we won’t be surprised if IIBA produces an “Agile Practitioner” sub-certification akin to the PMI-ACP certification from PMI.

2. Use cases will enjoy a resurgence, particularly on Agile projects.

Five years ago we wrote that we expected “Slightly less reliance on use cases and more movement towards user stories.” While many traditional projects have favored the use case technique these past five years, it is only recently that we have noticed an upsurge in the interest in and questions about use cases on Agile projects. And no wonder use cases are gaining traction. User stories, the most common format for writing Agile requirements, are usually created at a high-level of detail. In order for the delivery team to estimate the story during sprint planning and then build the story, it often has to be elaborated in more detail. This elaboration, called grooming the product backlog, provides enough detail about the story so the team can move forward. This is not an attempt to elicit all the requirements up front, but rather to minimize delays caused by poorly defined requirements.

Many Agile teams are beginning to realize that an effective tool for this grooming is the use case, which provides critical information, such as when the user story begins, when “done is done,” and what criteria have to be met to be accepted by the product owner. They are also seeing the importance of the use case narrative in describing decisions and paths that ultimately lead to the navigation, edits, and messages required for software user interfaces. Sure, teams can obtain this information by impromptu conversations with the product owner, but many Agile teams are starting to realize that the use case structure is ideal for getting the user story done more quickly and completely.

3. Business Analysis Focus on Design.

A trend that will continue into 2014 is the notion that business analysis work involves design. Much of the BA’s work includes fashioning solutions, so it is natural to think of this as design work. To some extent the discussion is semantic, in that business analysis has long included design work but using different terms, like “to-be requirements” and “logical design.”

In developing the 3rd edition of the BABOK® Guide, due to be released in 2014, The IIBA® has given “Design” an equal place at the business analysis table. It describes design as “a usable representation of a solution.” (See the article on the IIBA web site.) The technical community may take issue with business analysts doing “design” work, but one thing is clear: the BA community is laying claim to part of the design space and we’re not looking back. Look for an article from us on this topic soon.

4. Increased use of the “cloud” and the need for business analysis in choosing cloud solutions.

Cloud computing will continue to have an allure of the promise to reduce investment in infrastructure and operations. However, it’s been a tense year for those monitoring data security and privacy. Organizations may be increasingly “angsty” about organizational and project information being stored “out there,” but the reality of needing to make information easily available to distributed team members is going to continue to trump those concerns for the coming year as project managers and teams increase use of the cloud for storing and sharing project data.

However, we believe that because of security concerns, organizations’ willingness to analyze their security requirements and to align those requirements to the potential cloud solution’s security features will grow, translating into the need for more analysis of overall requirements prior to investing in new cloud solutions. The growth of cloud technology has created a plethora of options for organizations, so in order to maximize the investment and achieve the greatest value, organizations will use business analysis to evaluate prospective cloud solutions.

5. Less email, more connecting.

The lack of employee engagement is a hot topic these days, and the costs are as significant for the projects in those organizations as they are for the organizations at large. Furthermore, many, if not most, projects use geographically distributed team members, making the obstacles to engagement considerable. We expect that project managers and business analysts are going to spend more planned time in the coming year making an effort to connect with stakeholders, including team members. Fortunately, the number of synchronous communication tools (audio and video) continues to grow, which will increasingly render email a less desirable medium. For those without access to new tools, this may be the year that picking up the phone finds new favor among team members. Overall, those who can let go of the perceived need to document every conversation will reawaken to the intrinsic benefits of communicating with higher-context media other than email which uses only the asynchronous exchange of written words.

6. Business analysis will focus on communicating first and documenting second.

More organizations are realizing that the business analyst brings more value to the organization when they have exceptional skills to listen, observe, question, and probe for the real needs rather than simply producing documentation. As we noted last year, these skills must also include the ability to influence stakeholders in order to get the participation needed for understanding and acceptance of the recommended solution. Further, they must be able to communicate the results of the analysis back to the stakeholders in a way that promotes understanding and gains acceptances and buy-in. We predict that more organizations will jump on the need for “just enough” documentation, realizing that great communication targeted to the group or individual will go much farther than a 500-page requirements document.

7. Project managers will focus on requirements management.

In 2009 we predicted: “There will be a greater emphasis on requirements in Project Management.” This focus has mushroomed during these past five years, in part because PMI has shown a greater interest in requirements activities. The continued expansion of the Collect Requirements section in the PMBOK Guide®– 5th edition, as well as the creation of the PMI Requirements Community of Practice with its numerous webinars and articles on requirements management, has encouraged project managers to become immersed in requirements activities. We anticipate that we will see a new Requirements Management certification from PMI. After all, since PMI has completed a role delineation study, can a related exam be far behind?

Don`t forget to leave your comments below.

About the Authors

Andrea Brockmeier is the Director of Training Services at Watermark Learning. She has over 20 years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She is actively involved with the PMI® chapter in Minnesota where she has been a member of the certification team for many years. She has a master’s degree in cultural anthropology and is particularly interested in the dynamics of global, virtual teams.

Vicki James is the Director of Business Analysis for Watermark Learning. She is responsible for developing and maintaining Watermark Learning’s Business Analysis Training programs and serving as an instructor for both live in-person and virtual online classes. Vicki has more than 15 years’ experience in the public and private sectors as a project manager, business analyst, author, and independent industry consultant and trainer.

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

Empathy At Work: The Secret of Business Analysis Success

Written by Angela Wick on January 14, 2014. Posted in Articles. 1 Comment on Empathy At Work: The Secret of Business Analysis Success

For many people, empathy is a tool for personal or spiritual relationships. We save our empathy skills for people who are struggling with poverty, illness or grief. We don’t apply empathy to those who are happy or content and when it comes to our professional lives, most feelings, including empathy, remain tightly bundled under our business casual façade.

In some professions, like nursing or social work, empathy is an obvious asset. Marketing and advertising professionals rely on empathy as well. But what about project management, business analysis and software development? How can we apply empathy to our professional lives? How can empathy help us bring value to our stakeholders?

Empathy and Business Analysis

Your mother used to say something about walking a mile in other people’s shoes, seeing through someone else’s eyes, put yourself in their position… When it comes to our professional life, applying empathy mantras to our stakeholders can lead to amazing discoveries about our projects.

Take a look at this drawing. It’s a simple representation of an empathy map.

If you understand what your stakeholders are thinking, seeing, saying, hearing and feeling you can:

Proactively and effectively manage issues and risks
Evaluate politics, priorities and motivations
Uncover hidden requirements and bridge requirement gaps
Locate constraints and dependencies

Implementing Empathy

Gathering information for the empathy map can be a bit tricky. We can’t just schedule an “Empathy Map Meeting” and ask everyone what they are thinking and feeling, right?

No! Please don’t schedule an empathy map meeting. Tone and timing are very important. Here are few ideas:

Gather insight before meetings. You can meet with key stakeholders one-on-one before important meetings. You can prep them for the meeting and ask a few questions that would offer insight into their thoughts and feelings.
During a series of meetings, ask the empathy map questions in different ways to gather current versus future state. What are you hearing? What do you need to hear? What are you seeing? What do you need to see?
Watch body language during meetings. What is your project sponsor feeling when she rolls her eyes every time the SME speaks? What is your tech lead thinking if he is shaking his head during an issue resolution meeting?
Don’t be the scribe during meetings. You need to be able to observe and listen to the interactions between stakeholders. You won’t see the eye rolls, frowns, smiles and head nods if you are too busy taking notes.
Follow up after meetings. Take time to personally reflect on stakeholder interactions during meetings and if necessary follow up with stakeholders one-on-one or in small groups.
“What’s in it for me?” aka WIIFM is a question you should ask yourself on behalf of every stakeholder at the beginning of each project, before each meeting and as you design each deliverable. Your communication will be more efficient and you will get faster buy-in and better engagement from your stakeholders.
Write it down. Create a spreadsheet with each stakeholder and empathy map sections. Add to it regularly as your project moves forward. You may never show your empathy map to others, but it will be a great reference tool. When you encounter issues throughout the lifecycle, your empathy map will offer great insight to help your project stay on track.

Empathy and Innovation

Applying empathy to a project will help BAs successfully navigate their basic tasks, but can BAs inspire innovation with their empathetic approach?

Definitely! Empathy and innovation are related:

Approaching all requirements and project tasks with empathy will yield meaningful collaboration. BAs will know the right questions to ask to engage stakeholders and draw out key information. Meaningful collaboration yields innovation.
Innovation often relies on finding connections between two seemingly unrelated ideas or processes. BAs who understand the empathy map for each stakeholder see connections that others don’t. Maybe two stakeholders from different organizations are hearing the same complaints from their team. The BA might be able to bring the stakeholders together to help each other solve the problem.
Innovation requires the full participation of all stakeholders. If an empathetic BA knows that a SME has a great idea, but probably won’t share it because he feels intimidated by the project sponsor, the BA can facilitate a process that draws the ideas out anonymously.

Do you use empathy as a technique? If not, give it a try. Share your experience in the comments below.

Don’t forget to leave your comments below.