Skip to main content

Tag: Business Analysis

Get Fit: Lose the Business Analysis Weight

Many of us started 2014 with a stack of goals and resolutions. Did you resolve to take a few pounds off by eating healthier, hitting the gym, or running a 5K?

What about your professional health and fitness? Do you have a few extra professional pounds dragging you down?

Some BAs are lugging a spare tire around their middle—outdated techniques or broken relationships hold them back from becoming their best professional selves.

So, let’s lose some BA weight and build strength, increase flexibility and improve efficiency. Here are a few ways to work smarter not harder in 2014.

1. Strengthen or Rebuild your PM relationship

BAs have many important relationships to manage, but the relationship with the PM might be the most important. The best BA/PM combos are true partnerships.

Sit down with your PM and discuss requirement process goals and improvements for 2014. Tell the PM what s/he can expect from you that is different, new, and improved. Explain what you need from the PM to support these goals.

Foster this partnership throughout the year:

  • Establish consistent communication channels: set up a weekly status meeting, touch base over coffee or lunch, create brief summaries of key meetings and share them, and/or create a visual, one-page BA dashboard that gives up-to-date status of your deliverables.
  • Find common goals and work together to achieve them. Figure out how to make each project successful and how to add value to your organization.
  • Solve problems together. When complex project issues arise consult the PM. Share information, strategize and collaborate.
  • Understand ALL potential project risks—not just BA tasks—so you can look out for your PM’s interests. Be the eyes and ears of the project team.

2. Trim the details

Scale back on details that are of minimal value. For every document, every presentation, every e-mail—ask yourself why each detail is important. In many cases, excess details blur the big picture. Stakeholders with a blurry big picture are a major risk to a project. This lack of context will cause way more pain than missing details.

  • When peers ask for feedback, clarify the type of feedback they want. Don’t focus on grammar details and typos when they ask for content and contextual feedback.
  • Review emails before sending. Is the length appropriate? Do you use bullet points and white space effectively? Are you asking for too many things from a really busy person in an email? Is e-mail the appropriate tool for the information you have to share? Would a call or meeting be more effective?
  • Review your documents before distributing. Are you creating documents full of details and sending all the details to everyone to review? Consider your audience. Does everyone need all that detail? Are there ways to effectively summarize the information? Can you add visual elements that provide context for your stakeholders? Can you decompose the information so it is easy to follow for everyone?

3. Kick your meetings up a notch!

Evaluate your facilitation toolbox. Toss those old tools and find a few new ones. You’ll see huge benefits in efficiency when you learn how to make meetings fun, collaborative, and valuable for everyone. Here are a few tips:

  • Determine what each stakeholder will learn or get from your meeting.
  • Keep the invite list as small as possible. Meaningful collaboration happens in small groups.
  • For workshops—plan activities elicit information strategically rather than just asking, “What are your issues?” or “What are the requirements for this feature?” or “What is the best way to fix this?” It’s highly unlikely these canned questions will produce creative or complete responses.
  • Make meetings engaging. Don’t sit around a conference room table for an hour. Get moving. Use whiteboards and Post Its. Find creative ways to elicit ideas or prioritize requirements.
  • Virtual Meetings-Multitasking is bad enough in person, but it’s usually worse on conference calls. (You’ve heard dogs barking and kids crying and toilets flushing right?) You have to encourage active participation, beyond just listening. Engage the eyes and the hands. There are so many tools out there, many of them free, that help BAs create interactive virtual meetings. Try virtual whiteboarding, virtual Post Its, virtual breakout sessions or virtual facilitation games.
  • Make them fun, collaborative, and with value for everyone. What will they learn or get from your meeting?

So, take a risk in 2014. Drop the dead weight and try a new technique, build stronger relationships and question the details. Assess your best practices and find efficiencies. Flex your BA muscles!

Don’t forget to leave your comments below.

Requirements vs. Design – Does it Really Matter?

Much has been written recently about design in the business analysis field. Some writers have even suggested that since most or all of what we do is about design, then requirements don’t matter anymore. It is popular – even exciting perhaps – for BAs to think of ourselves as designers, since much of the work we do results in solutions. We don’t disagree with the trend and the main concern prompting us to write this article is to point out the importance of including the “as is” state as part of any requirements – or should we say design – effort.

In thinking about the topic it is our opinion that a) perhaps people lack some perspective on where and how business analysis has evolved and b) the debate about requirements vs. design may be mostly one of semantics. Over the years, Elizabeth and I along with many others, have worked hard to help the BA profession carve out its place in the business world.This effort has involved moving from the extremes of having either a technical, systems analyst role or an administrative business “super user” role do the business analysis work. 

Part of the impetus for the new design focus has been a strong aversion by some in the Agile community to business analysts or business analysis. Those who feel strongly tend to concentrate on the design aspects of a new product and don’t see the need for much if any actual analysis of the business or business need. (See Tony Heap’s blog for an example. ) If business analysts are now just designers and we need little analysis, we are moving back to the earlier systems analyst role. Although that might be a satisfying career move for some, it does not usually serve the organization well. To say that we don’t need to worry about requirements is missing the essence of what a business analyst can and should be.

Early in Rich’s career he worked as a programmer-analyst doing COBOOL programming with a variety of databases. That was a euphemism for a role that was 90% design/programming and 10% analysis as we know it today. In thinking back, our jobs then were to implement decisions made at higher levels in the organization, both from the CIO and business management levels. Although we met occasionally with business stakeholders, we generally worked to adapt the business to available technology. While today’s “design” does not imply that we have to ignore business needs, it does suggest that we will focus on solutions without truly understanding the needs.

Haven’t we moved beyond that approach over the last few decades?

Let’s walk through some reasons why the emphasis on design over analysis is an issue. Being only or mostly interested in “design” implies that we don’t care about the “as is” state anymore, as is suggested in recent articles, blogs, and discussion groups. (See David Morris’ article, We Are All Designers Now. ) Without understanding the current situation, we cannot hope to understand:

  • How end users’ jobs will change with the implementation of the new product or product increment. If we do not know the extent of the change we cannot help workers adapt to the change, which increases the risk of lack of buy-in, unhappiness, and even possible sabotage.
  • Which of the issues with the “as-is” need to be addressed. If we implement new processes and systems without curing existing ills, we will lose credibility.
  • No new product or solution is devoid of the current state. Even when we create a brand new product or service, it must fit into the current environment and infrastructure. That means we will have requirements that must be met – not designs – to ensure the new solution contains existing functionality that works and without which the new product cannot perform adequately.
  • In addition, most of us work on projects that are not entirely new products, but replacements and enhancements of existing systems or processes. These efforts need plenty of analysis of the “as is” state and its corresponding requirements to make sure the changes we bring will fit into the rest of the business operation.
  • Even for brand new products, there are many business rules and decisions that apply across projects and should be taken into account for the project at hand. For example, the new Training Management System we built for our web site was contracted to a development company. The “specification” the development company used represented our decisions (i.e., business requirements) about what was to be built. The specification was clearly not a design – that was done by the developers – but represented our needs and requirements for the new system.
  • The BABOK® Guide version 3 talks about requirements being the representation of a need and design as a representation of a solution. That is a workable distinction, although it is a bit awkward to talk about “designs” at the same level as requirements. To understand the distinction better, it helps to substitute the words for the process instead of the outputs:
    • Analysis is understanding the needs and requirements and communicating them to the builders of a solution.
    • Design is how new features and functions will be incorporated into a solution, plus maintaining existing requirements that should be kept in the new solution.

The last point is perhaps our biggest concern with the new thinking. The business analysis community has fought for years to keep analysis distinct from technical design. In the end, we don’t care that fashioning a solution is called design. After all, what is now being called design is nothing different from calling the output of the process “To-be” requirements.

To illustrate our point, consider Figure 1. The example might be a typical enhancement to an existing system or process. In the traditional business analysis approach, the “as-Is” state is analyzed as a starting point to capture processes, data, and interactions that must be kept for any new solution. Those are “as-is” requirements.

The “current state to be retained” in the “Design” box below are also requirements. They could be processes, data, or user and system interfaces. The design process comes into play when determining how to integrate them with the new features being added. Those new features could equally be called “To Be” requirements as well as design. This is not technical or physical design, but the “logical” design mentioned earlier.

larson feb18

Examples of “To Be” requirements (or design if you prefer) include many traditional BA outputs including:

  • Process models showing an “As Is” as well as a new business process.
  • Data models showing “To Be” data requirements and business rules relating to the relationships between entities.
  • Use Case models with interaction requirements and corresponding business rules.
  • Prototypes and mock-ups indicating interface requirements. These models tend to cause the most “overlap angst” with other staff such as UX experts. Data models come in a close second in the “don’t step on my turf” confrontations.
  • Interfaces with other systems.


In the end as long as we are talking about “logical” design and not technical or physical design, the authors agree with the current trend calling BAs designers. In actuality, BAs have always been designers because we help people conceptualize and visualize solutions that will help businesses meet goals and objectives through solutions. As long as we don’t forget the importance of “As Is” and “To Be” requirements and the part they both play in any solution, then emphasizing design over requirements becomes to us an academic argument.

Don’t forget to leave your comments below.

The Best Reason to call BAs Designers?

Perhaps the biggest reason to call our work design has nothing to do with the BABOK or Agile. It is financial. Yes, the accountants are reluctant to capitalize analysis work, but they do allow capitalizing design work. This makes a huge difference for funding of projects since capitalized costs can be spread out over the useful life of the product being built.

Elizabeth and I have a friend who runs a consulting firm in Minneapolis. He tells us his clients won’t typically pay for “analysis” or “requirements” work. But, he also understands the value of business analysis for the success of his company’s projects. So if he couches the same work as “design,” the clients are more willing to pay for it.

About the Authors

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.

It all Happens from the Get Go – 7 Planning Steps to Achieve Measurable Results

Business leaders need to ensure that planning and implementation is focused. A well thought-out planning and implementation approach considers linking strategy, tactics and operational needs. It includes considerations for key business impact zones (productivity, tools, people and culture) and the outcomes required for solutions to business problems.

Consider the business objectives, the process and the work approach that must be used to successfully achieve results in an organization. Results should be resource-driven beginning with shared thinking and consideration of the challenges that need to be addressed. Call them points of pain. All businesses have them and every business leader knows it.

A checklist would be handy at this point. Consider common business challenges such as issues with focus and direction, trust, communications and collaboration, productivity, effectiveness and efficiency, process and work procedures, outdated equipment and tools, people experience, skills, beliefs, values or even blame-storming. No matter the issue, they all add up to one thing – a negative impact, something a business leader seeks to avoid.

Here are 7 steps to consider when planning for measurable results:

Step 1. Understand your business priorities

What five things are on the strategic agenda of the organization? Why are they so important to the business? In what way can your team make those items happen? If you can answer these questions you are on the path to good business leadership thinking.

Step 2. Identify the challenges

What are the points of pain? What are the key challenges? How are these challenges impacting the business? Can we qualify and quantify the problem? Have we considered the impact to productivity, our tools, people and culture? What are the overall impacts and ripple effects to the organization? Write a clear and concise business problem statement that everyone understands. Share that statement and engage in shared thinking and creative solutions with your people.

Step 3. Determine key solutions

Throughout the process, encourage teams to assist you in solving the business problems. Be careful here, as coming up with ideas on how to solve business problems does not mean implementing solutions. Provide support and insight to people whose natural approach is to roll up their sleeves and jump right in. At this point, as a business leader, you should be seeking thinking and solutions. Only after the ideas have been put forth do you seek to prove their viability.

Step 4. Choose a solution that makes sense

This is where viability comes in. It really comes down to what, why, who, how, when, where, how much and what’s in it for the organization, the benefit, risk and return factor; all the things we learned in grade school and on the playground only with more risk. The best thing is to review situations and possible impacts. Pick three solutions: the do nothing solution, the do something solution or the do something else solution. Think through the issues and make a decision.

Step 5. Implement the solution

It’s not always easy, but it must be done. As the business leader, make sure you have your team together. Establish your approach to deal with people and team dynamics across the organization. Change means push back so be prepared. Be honest about your resource abilities. Invest in their success through investing in your own development. Use a good business coach to avoid future issues. Make it part of the process so your people will embrace it. This is a preemptive approach for solution implementation. Remember, as the leader you do not need to be the sage on stage but be the guide on the side.

Step 6. Measure the results

Ensure that you have put the right items in place to measure the results. This could be at many levels. Answer the simple question: does it work? The answer needs to be a yes or no, not maybe or sort of, eh! Did you get what you expected? How long did it take? Is it over or under budget? Will you see the expected return on investment? If so, over how many years?

Do we have the right people? Have you considered the impact zones and the impact? Does the solution (process, tools, people, etc) align with what is important to the business? The list of questions here is long and depends on what was set as the measurement needs earlier in the planning process.

Step 7. Capture lessons learned

This is an area that business leaders rarely engage in. Yet, it is extremely valuable at all levels in the business. A feedback loop should always exist and the business leader should explore what was learned internally and externally. This is your intellectual property that can be used for future planning and continuous improvement.

In the end, it comes down to following a planning and implementation approach that ties strategy and tactical solutions together. As the business leader your success depends on following a proven approach, engaging your people in the process and building key business skills. Planning for measurable results happens from the ‘get go’.

Don’t forget to leave your comments below.

Stop Calling Yourself the Bridge

kupe Feb11I 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.

  1. 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.
  2. 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.
  3. 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,

Don’t forget to leave your comments below.

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.