Skip to main content

Tag: Business Analysis

Where is the Business Analysis Profession Going?

awhittenberger feb4It 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.

awhittenberger feb4 2

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.

awhittenberger feb4 3.jpg

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

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.


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

anderson FeatureArticle June19The 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

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. wick Jan14 14 2

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:

  1. 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.
  2. 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?
  3. 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?
  4. 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.
  5. 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.
  6. “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.
  7. 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.

The BA Practice Lead Handbook 13 – Taking your Business Analysis Team from Good to Great

As we look ahead into the next century, leaders will be those who empower others.
Bill Gates

In article 6 of this series, we discussed an approach to building a capable BA workforce able to manage the complexity of your team’s project assignments. In this article, we discuss the need for the BA Practice Lead, as well as the BA, to become effective leaders of teams. Your job is all about building and sustaining high-performing teams.

What’s the big deal about teams?

Complex projects are challenged today because of people failing to come together with a common vision, an understanding of complexity, and the right expertise. Virtually all work today is accomplished by teams of people. Sometimes teams of teams consisting of groups around the globe. Team leadership is different from traditional management, and teams are different from operational work groups. When leading high-performing, creative teams, it is no longer about command and control; it is rather about collaboration, consensus, empowerment, confidence, and leadership.

What do high-performing teams look like?

When you think of great teams you have observed, what teams come to mind? Perhaps your local professional sports team is the first mental image that emerges. Whatever the sport, high performance is the name of the game. Sometimes, high individual performance is a detriment to the team. Success in the world of professional sports is about team performance.

So, outside of sports, what high performing teams have been a wonder to your eyes? Let’s just begin to identify some of them and the nature of their sustained high-performance. We will name just a few. I am certain you could add to this list.

Paramedic Teams

Paramedic teams mean the difference between surviving and succumbing to an overwhelming force. Paramedics provide medical care at an advanced life support level in the pre-hospital environment, usually in an emergency, at the point of illness or injury. This includes an initial assessment, a diagnosis and a treatment plan to manage the patient’s particular health crisis. Treatment can also be continued en route to a hospital if more definitive care for the patient is required. Paramedics almost always work in teams of two to four specialists, each fully understanding his role, and how it integrates into the whole approach to assess the degrees of urgency to wounds or illnesses and provide life-saving interventions. It is about the importance of the mission and the team resolve. 

Firefighting teams

I once met a New York City firefighter who had been with his squad for decades. I asked him how he handled such a pressure-filled job. His answer: “I would pay them to let me be a fire fighter.” He was talking about the camaraderie, the spirit, the brotherhood, the importance of the mission. Think 911 or Hurricane Katrina.

Non-Governmental Organizations (NGOs)

I have a sister who is heading up an NGO at the United Nations. She mentors interns and high-school age young women and men to become involved in global solutions to problems such as the trafficking of women, the poverty and environmental health issues of communities that are adjacent to coal mines, the basic right of all to have access to clean drinking water. She says she had her dream job. It is about the importance of the mission and collaboration with other world-changing NGOs.

Symphony Orchestras

Today the Boston Symphony Orchestra, Inc., (BSO) presents more than 250 concerts annually. It is an ensemble that has richly fulfilled their vision of a great and permanent orchestra in Boston. BSO has been the scene of almost two hundred American premieres over the last century. From Wilhelm Gericke to James Levine, each conductor of the BSO has created a legacy of new works introduced to BSO audiences. The BSO Archives houses printed programs, press clippings, posters, photographs, administrative files, an extensive collection of radio broadcast tapes of concerts and commercial recordings. It’s about musical expertise, cultural and historical contributions, and first-rate performances. 

Heart Transplant/Operating Room Teams

Transplant patients who come to University of Colorado Hospital are often very, very sick. Their survival depends on well-orchestrated care delivered by the transplant team. There have been many historic transplant stories at University of Colorado

Hospital and by the physicians and researchers of the University of Colorado Denver School of Medicine. Among them:

  • First-ever liver transplant in the world. (1963)
  • First successful double lung transplant on a cystic fibrosis patient in Colorado.
  • Colorado’s first solitary pancreas transplant to eliminate diabetes in a patient.
  • First in utero stem cell transplant to save a fetus with a rare blood disorder.
  • Opened a liver cell bank – one of the first in the country – to further research into new liver transplant procedures.
  • First living-related liver transplant in Colorado.
  • First living-related liver transplant on an adult with fulminant liver failure.
  • Region’s first liver transplant from a non-related donor.
  • One of the first in the nation to perform living-donor transplant surgery.

It’s about top-of-their-game medical professionals, superior medicine, a highly-skilled, interdisciplinary team, and progressive, innovative change. 

Navy Seals

And then there are the Navy Seals. Well, they are the Navy Seals, probably the most famous of all great teams.

Navy SEALs are a unique breed of warrior who conduct special operations in any environment, but who are uniquely trained and equipped to operate from, around and in maritime areas. SEALs take their name from the environments in which they are trained to operate: sea, air and land. Their small highly trained teams usually work quietly at night conducting some of the nation’s most important missions. SEALs are constantly deployed throughout the world to protect national interests. 

Think Seal Team Six, sometimes referred to as the Special Mission Unit. ST6 is a multi-functional special operations unit with several roles that include high-risk specialized missions. Required entrance skills include combat experience; language skills; and the ability to blend in as civilians during an operation. Members of ST6 are selected in part because of the diversity of skills of each team member. The ST6 training schedule is without comparison in its intensity. Though highly classified, they are renowned for their barely credible, almost fiction-like accomplishments. 

Technology Innovation Teams

At the top of nearly everyone’s list when it comes to innovation, – Apple, Inc. Their products are at the top of nearly everyone’s gift list. For them it’s about innovation, creating things we don’t even know we want or need. From 




We could go on and on. There are great teams in every walk of life. So, our challenge is to find out what makes some teams good and others great.

What do all great teams have in common?

Let’s examine what all of the great teams have in common. To a fault, they all include these elements:

  • Small but mighty – if the team is too big, members lose their sense of camaraderie and purpose.
  • Core full-time, co-located leaders – they follow the shared-leadership model, each taking the lead when their knowledge, skills and expertise are needed.
  • Highly trained and highly practiced – practice, practice, practice!
  • Diverse, multi-skilled – a high performing team needs a variety of skills, capabilities, talents, cleverness, and the dexterity to understand all of the perspectives of complex situations.
  • Experienced – there is simply no substitute for experience
  • Personally accountable – each member holds himself personally responsible and accountable for the success of the mission.
  • Expertly coached – behind all great teams is an inspiring, loyal, coach who removes all barrier’s to the team’s success.
  • Holistic, systems thinkers – great teams see the whole picture and understand how complex teams need to adapt as the environment changes or more is learned.

In addition, great teams understand strategic criticality of the effort, the mission, and the value of their work products. They all have a common set of values and guiding principles. They are passionate about the mission, the work, the results. They keep score and constantly improve their methods, approaches, quality, training, communications, and therefore, results.

What’s the big deal about teams?

So how do you take your team of BAs from a good team to a great team?

It’s about Capabilities

hass Dec17

First and foremost, it’s about capability. We once again present the capability model below to demonstrate that as project complexity increases, the capability level of the project leadership team must also increase. The model describes how capabilities evolve from technical prowess to leadership, strategy and innovation fortes.

It’s About Understanding Complexity

And it’s about using complexity thinking to make decisions about building, leading and sustaining high-performing teams. Again, as project become more complex, more sophisticated leadership abilities are required. Studies show that companies can’t find the employees they need – critical thinkers with the ability to:

  • Adapt, invent, re-invent,
  • Collaborate, create, innovate, and
  • Leverage complexity to bring about innovation.

Traditional project jobs are changing:

  • Typical tasks are being automated and commoditized.
  • The critical Business Analysis focus is now on strategy, innovation, value to the customer and wealth to the bottom line vs. requirements management.
  • The critical Project Manager focus is now on complexity management vs. project management.

So, use complexity thinking when making critical project leadership assignments, as depicted in the diagram below.

Use Complexity Thinking to Make Project Leadership Assignments.

hass 2 Dec17

It’s About Filling the Gaps in Capabilities

The graph below demonstrates the typical gap in capabilities when dealing with complexity. We re-introduce the diagram below to depict the findings from the ground breaking research study, The Bottom Line on Project Complexity, the results of which were presented at the PMI Global Congress 2010 North America. The study correlated the current state of BA practice maturity with project complexity and project outcomes.

The industries represented in the study were Insurance (Ins), Financial Services (FS), Information Technology (IS/IT), Government and Non Profit (NP), Health Care (HC), and Transportation (Trans). The diamonds represent the typical complexity level of projects within the industry. The research findings indicate that the average BA maturity level for these industries is 1.68 as represented by the black horizontal line in the diagram. But the complexity of projects mostly fell at level 3, highly complex projects. Therefore, there is a gap between the complexity level of most projects and capability levels of BA practitioners working on the projects. The BAs were also asked to predict the probable outcome of their projects in terms of budget, schedule, and scope (BSS in lower right). The diamonds are color coded to represent the degree of challenge the BAs predicted will be evident at the end of the projects.

Assuming that these research findings are relevant to your current BA team, it is imperative that you take action to close the gap in your BA team capabilities. If you are unable to do so, it is likely that two thirds of your current highly-complex projects will fail or be challenged for meeting BSS (CHAOS Report 2011, The Standish Group).

It’s About Filling the Gap between Project Complexity and our Capabilities

hass 3 Dec17

Putting it all Together

So what does this mean for the Business Analyst?

For BAs, continually learn about great teams and effective team leadership. Strive collaborate with the other project leaders (the PM, the architect, the lead developer, the business visionary) to take your current project team from a good, capable group to a great, high-performing team.

So what does this mean for the BA Practice Lead?

For both the BA and the BA Practice Lead, reference Chapter 5: Fostering Team Creativity – the Business Analyst’s Sweet Spot of the book entitled The Enterprise Business Analyst by this author. If you do not have the book on your shelf, you can access it through the IIBA e-library if you are an IIBA member. It provides a more in-depth discussion of building and sustaining high-performing teams. Topics include:

  • Effective Teams
  • The Power of Teams
  • Team Development Through Stages
  • Team Leadership Styles Through Stages
  • Best Team Practices for the Business Analyst
  • Creativity – A Right Brain Pursuit
  • Everyone is Creative
  • Getting There – From ad hoc Group to Working Group to Creative Team
  • The Business Analyst as Innovator
  • Becoming a Creative Force
  • The Innovation Imperative
  • Innovation is a Team 
  • Putting it All Together: What Does This Mean to the Business Analyst

Don’t forget to leave your comments below.