Author: Elizabeth Larson

Elizabeth Larson, has been the CEO for Watermark Learning as well as a consultant and advisor for Educate 360. She has over 35 years of experience in project management and business analysis. Elizabeth has co-authored five books and chapters published in four additional books, as well as articles that appear regularly in BA Times and Project Times. Elizabeth was a lead author/expert reviewer on all editions of the BABOK® Guide, as well as the several of the PMI standards. Elizabeth enjoys traveling, hiking, reading, and spending time with her 6 grandsons and 1 granddaughter.

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.

2013 Trends in Business Analysis and Project Management

Written by Elizabeth Larson on January 29, 2013. Posted in Articles. 1 Comment on 2013 Trends in Business Analysis and Project Management

The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2013. This year we want to concentrate on trends for 2013 relating to an emphasis on competencies.

As people become skilled and certified, their base knowledge and abilities are in place. PM, BA, CSM, and BPM practitioners also need to apply their tangible skills to solving problems and helping our organizations achieve their objectives. For example, let’s say Jane knows how to model business processes and how to improve them. But, she may not always get time from stakeholders to understand their process, or establish trust with them to learn the root causes of process problems. She may also run into sharp disagreements about how a new process should be designed or conflicting priorities for what to improve first.

All of these common situations require various “competency” skills, which are often referred to as “soft skills.” We prefer the term “competencies” instead. The trend we’re seeing is that developing so-called “hard” skills isn’t enough. Organizations are now seeing the need to improve their workers’ behavioral-oriented competency skills at the same time.

So here are some competency trends that we see.

Project professionals need to provide advice, not pushback. Several years ago organizations told us that they wanted PMs and BAs to be able to push back when their stakeholders asked for new requirements. Some of these organizations are now seeing that pushing back is one way to avoid being an order-taker, but it is less effective than providing well-analyzed advice. Our prediction is that more organizations will want PMs and BAs to be trusted advisors (sometimes called trusted partners).
Organizations want scribes, not note-takers. Although highly valued in ancient societies, today’s scribes are not always held in high esteem. Many organizations view them as nothing more than note takers, and what’s worse, that’s exactly how many view themselves. The trend that we are starting to see is the recognition that effective scribing is important to the quality of the requirements as well as the project itself. To be an effective scribe, project professionals need to use competencies, such as critical thinking to separate the important from the trivial, the ability to absorb and synthesize a great deal of information and make sense of it, and the ability to present the results in a meaningful way. We are seeing more organizations requiring these skills, particularly of their BAs.
Organizations are beginning to recognize that agile projects require the ability to influence stakeholders.All roles on an Agile/scrum project, in particular the scrum master, the product owner, and the BA, need competencies related to being able to influence. We see some organizations beginning to recognize that each of these roles is distinct (e.g. rather than having the BA be either the product owner or one more member of the delivery team) and each needs to influence in different ways:
1. Scrum masters: need to influence a variety of organizational stakeholders, many of who will have more authority than they. Scrum masters need to remove project roadblocks, which requires influencing sponsors and other executives, financial analysts, vendors, etc.
2. Product owners need to influence other business stakeholders regarding the decisions they make as product owners. Whether prioritizing user stories or reviewing the product increment at the end of an iteration, product owners will need to be effective influencers. More organizations are starting to recognize that although product owners need to make business decisions about the product, they need to get buy-in from others affected by the product. Effective influencing is one of the best ways to achieve this buy-in.
3. Business analysts need to influence just about everyone on an agile project. We are seeing product owners starting to recognize and appreciate the BA’s advice on prioritizing requirements, including impacts, dependencies, risks, etc. Scrum masters are starting to appreciate the BA’s advice on the myriad of issues that relate to requirements, testers on testing the requirements, and vendors on implementing software, to name a few. Again we’re seeing the dawning of this recognition in some organizations.
Organizations are recognizing the cost of virtual teams
The communication overhead of working with offshore resources is getting acknowledged and accounted for more than in the past. Writing requirements for people onsite with whom there is the opportunity for face-to-face communication, as well as shared language and culture, is a leaner process than when writing requirements for people offsite. The cost savings of working with offsite/offshore resources has always been part of the equation for resourcing projects, but the cost overhead of working with offsite/offshore resources hasn’t always been as transparent. It can take many times longer to write requirements for offsite resources. Project professionals are becoming more diligent about identifying the costs incurred to deal with the time zone, language, and cultural differences.
Productivity and speed require the use of disparate and uncoordinated social media and collaboration tools
Until fairly recently, organizations wanted consistency. Consistency in their processes, consistency in their hardware, and consistency in the tools that were purchased to help productivity. The profusion of social media, collaboration, and communication tools continues. We are seeing that team members, particularly virtual, are making use of more and varied applications than ever and not always in a coordinated way. Do team members want a virtual bulletin board? Google it and myriad options come up – many free with few or no decisions required to install. It’s all very fluid. The integration of some of these things happens without even so much as a request. GoToMeeting just appears on a tab in GoogleTalk, for example. Nice. The continued pervasiveness of these apps in an increasingly distributed work environment is driving less standardized toolsets. You use what’s needed at the time, and if you need something you don’t have, click here. It’s free. It’s easy. Job done.
Consensus is giving way to “productive conflict.”
To the extent that the notion of consensus still implies (however erroneously) that everyone gets what they want, organizations are tiring of it. The idea of “productive conflict” holds more appeal. It’s not that organizations are losing interest in consensus, per se, but there is more emphasis on what comes out of the process than the process itself. And productive conflict may not run the risk of getting stuck, as so often happens when groups are trying to get consensus. Does this suggest that there may be some who aren’t in agreement? Maybe. But the trend we’re seeing is more organizations willing to pay that price in order to move forward.

Don’t forget to leave your comments below.

Andrea Brockmeier, PMP is the Client Solutions Director for Project Management at Watermark Learning. She has 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 has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.

Elizabeth Larson, PMP, CBAP, CSM and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills. They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4th edition.

Five Lessons Learned from Harry Potter in the Room of Requirement

Written by Elizabeth Larson on October 9, 2012. Posted in Articles.

On a recent plane trip, when I saw Harry Potter and the Deathly Hallows 2 for a second time, I was struck by the scene in which Harry Potter enters the Room of Requirement. This magical room is one that “a person can only enter when they have real need of it [and…] is always equipped for the seeker’s needs.” It has a way of transforming itself as the need changes, so sometimes it is nearly empty and sometimes jam-packed with different objects from chamber pots to jeweled crowns. I sometimes imagine that our requirements workshops are held in similar rooms of requirements. Each time we elicit requirements from our subject matter experts (SMEs), the room is different. Each person entering the room, virtually or physically, has specific needs and each idea its own use. Sometimes there are an abundance of ideas generated and sometimes very few. And each requirements workshop can be filled with overwhelming challenges. In this final film, the ability of good to triumph over evil depends on finding a lost diadem, or crown, in the Room of Requirement. The intrepid business analyst (BA) faces similar challenges in their requirements rooms. Here are some that Harry and BAs both face:

Getting the high-level” what” is much easier than getting the necessary detail. Harry knows what he needs to find in the room of requirement– a diadem. So how hard can it be to find it once he’s in the room? Very hard, because although he has the high-level “what,” he has no idea what it looks like. He has no detail describing it, and he is frustrated as he looks around the very large room filled with objects from floor to very tall ceiling. He seems to have forgotten that to use the Room to maximum effect, those who enter are advised to be very specific about what they are looking for.” [1]After some minutes searching fruitlessly, however, Harry uses an effective technique to find the diadem. He listens.
As BAs, we are often given high-level requirements. The level is too high, however, to describe the need in enough detail to build the end product. For example, user stories describe high-level requirements, but need to be fleshed out. Use case models provide high-level processes, but without the narrative flow of events, the requirements remain incomplete. A business process with the primary path but no alternate paths is also a good start, but only a start. And one of the best ways to get that detail is active listening.
When we are under a great deal of pressure to find what we seek, we usually rush superficially through the business analysis work. Harry and his friends have almost no time to find the diadem. With no plan to guide them, they search frantically and chaotically. It isn’t until Harry takes the time to get additional information from an important stakeholder (the Ravenclaw ghost) that he can really focus on his goal.
As BAs we are often under pressure to complete our business analysis work quickly. When we give in to such pressure, we often misdirect our efforts and the result is rework, dissatisfied customers, and an effort that costs more in time and budget, to say nothing of team morale. Like Harry, we need a plan, we need to be focused, and we need to take the time to talk to stakeholders who can guide us to the correct and complete requirements.
Some people have a vested interest in throwing up roadblocks. Harry soon learns that he is not alone in the Room of Requirement and that others desperately want to prevent him from succeeding. In the battle of Good (represented by Harry and his cohorts) vs. Evil (represented by Draco Malfoy and his cohorts), Evil has a vested interest in preventing Harry from first entering the Room of Requirement and then finding the diadem.
Unfortunately, we sometimes encounter stakeholders who do not want to see the projects succeed. Those who resist change (sometimes for good reasons), who have to learn to use a new systems or follow a new process, who have to sell and support new products, who will no longer be domain experts, and/or those who might lose their jobs in cost-cutting effort, may use a variety of tactics to stall or stop the business analysis activities. We need to do what we can to build trust with them, to understand the root cause of their fears, to explain how the change benefits them, and to get their input—even when they are reluctant to give it.
It takes courage to enter the Room of Requirement. One of the few things we know as Harry enters the Room of Requirement is that success is critical and must be achieved, regardless of the certainty of danger and possibility of death. And indeed, among other things, Harry and his friends face the Fiendfire, a monster of fire that consumes everything in its path as it envelops the Room of Requirement.
As BAs we sometimes face our own Fiendfires. Uncooperative, unavailable, or unengaged SMEs, sponsors who don’t understand why it takes so long to elicit requirements, pet projects that do not align with business goals and objectives , and technical experts who are needed but are working on other projects, are just a few of the many “fiendfires” we face. Our tendency is to yield to time pressures and try to do everything ourselves, but that’s not usually the right thing for the organization. And it takes courage to take the time to understand the real business need, to recommend the right thing, and to refrain from moving forward ourselves without engaging the stakeholders. It takes courage to explain why requirements activities take time and why key stakeholders are needed. And it takes courage to point out the risks when they are not.
We cannot succeed by ourselves. Harry Potter needs the help of his close friends Ron and Hermione. They work as a team, each with different talents. Each is an important part of the team and if any were missing, they would not be successful. From time to time one of them goes missing, but success is only attained when the three of them work together.

BAs can be successful only when we work together with the other stakeholders. Collaboration is one of the key success factors to navigating through the Room of Requirement.

Don’t forget to leave your comments below.

[1] Wikia, Harry Potter Wiki, http://harrypotter.wikia.com/wiki/Room_of_Requirement, viewed on January 5, 2012.

10 Ways to Succeed in Busting Trust

Written by Elizabeth Larson on June 4, 2012. Posted in Articles.

With so much written on trust these days, I thought it might be interesting to provide ten things that you can do that are almost guaranteed to destroy the trust of your project team, peers, and business stakeholders. Busting trust is pretty easy. As Sophocles said, “Trust dies, but mistrust blossoms.” There are lots of ways to destroy trust. For example, we might think of all the ways to build trust and then do the opposite, like being dishonest, or lacking authenticity, or if we are unwilling to communicate bad news. What follows are ten additional ways to bust trust. There are, of course, many more. These are just a few of my favorites.

Gossip. Gossiping’s fun, right? It’s great to be in the center of who knows what about everything and everyone. Some people use gossip as a currency. Feed me a juicy tidbit and I’ll give you two in return. So why does gossiping bust trust? If I tell you a piece of gossip about someone, do you really think I wouldn’t tell others about you?
Use humor inappropriately. Have you ever joked around during a meeting or requirements workshop, making wise cracks or being sarcastic? Have you ever told the facilitator who was trying to enforce ground rules, “What’s the matter? Don’t you have a sense of humor?” We may pride ourselves on our cleverness, but others in the meeting might feel dismissed or that their ideas are being trivialized. It’s a great way to ensure that the agenda stalls and that the meeting objectives are not reached. If you are the constant joker, join the club of trust busters.
Be competitive. When we are collaborative, value others’ input, and are interested in a solution that meets the organizational goals and project objectives, we will probably not succeed in busting trust. But when we put our self-interest ahead of the team, when we don’t listen to others’ ideas, when darn it, our way is the right way and we argue our position rather than listening actively to others, we have a good shot at busting trust.
Withhold information. Ah, those poker players. We all know them. They’re the ones who hold their proverbial cards close to the vest. When we withhold information or feed it to the project stakeholders on a “need to know” basis, we are not being transparent and others might well question our agenda. Have you ever known people who were master poker players in all their communications? The ones who feed you one item at a time? When we hold onto information because we know that information is power, rather than sharing information because we know that sharing information not only is power but also a key to getting projects done quickly, we are sure to win a trust-busting award.
Share confidential information. Sometimes, however, there really is a need to withhold information. When we have accepted the responsibility of hearing or reading confidential information, we cannot share it and leave our integrity intact. Some people have a need to “be in the loop.” Such people ask, “Can you keep a secret?” or “If I tell you something, do you promise not to repeat it?” or “I really shouldn’t mention this but…” We need to be careful before listening to the confidential information. We want to avoid the conundrum of whether to share vital information if it means breaking our promise and therefore being out of integrity. If we’re comfortable with this dilemma, share and listen to confidential information and you will certainly bust trust.
Don’t make or meet commitments. I once had a boss who never had to meet his commitments because he never would make any. Making commitments means taking a stand. However, making commitments without meeting them is a great way to lose credibility. When we stall, put off work, or simply don’t get the job done, others lose confidence in us. And we open ourselves up to micromanagement. People who are dependent on our results and have made commitments to others understandably get real nervous when the results are delayed. They’re on the hook because of their own commitments. And when nervous, they tend to hover. One of our best defenses against micromanagement is to meet our commitments—and communicate if we can’t.
Be unprepared. When we don’t do our homework, we lose credibility. When we’re asked a question and have to admit that we don’t have an answer and are forced to say “I’ll get back to you on that one,” we lose credibility. Sure, saying that you’ll get an answer is better than making up an answer, but it’s no substitute for being prepared. So if we don’t anticipate questions we’re likely to be asked, and if we don’t prepare answers in advance, we will lose credibility, which is a great way to bust trust.
Act inconsistently. Acting consistently is a cornerstone of building trust, so when we don’t, we can be pretty certain that people won’t trust us. Consistency is having values and matching our behavior to our values. It’s about “walking the talk.” It’s about behavior that people can count on. It’s about reliability. So when we react inconsistently, such as when we react emotionally to unexpected bad news and shoot the proverbial messenger in the process, we will be effective at busting trust.
Be closed to other cultures/ethnocentric. In a nutshell ethnocentrism is the belief that my culture is better than yours. The culture in question might be organizational culture, national culture, regional culture, age, gender, religion, or a host of other cultures. When we close ourselves off to input from people who are different from us, we let them know that neither they nor their ideas are important. Not only will we bust their trust, but we will lose credibility with other team members as well.
Believe that results rule. When we put results ahead of relationships, we pretty much guarantee that we’ll get those results at the expense of trust and without the collaboration and cooperation that we’ll need for long-lasting success. Getting results is fine. But getting them at the expense of others means they’ll be short-term results at best. Failure to collaborate is a great way to bust trust.

Don’t forget to leave your comments below.

7 Trends in Business Analysis and Project Management to Watch for in 2012

Written by Elizabeth Larson on January 10, 2012. Posted in Articles.

The close of one year tends to make one reflect on what has occurred in the past year related to and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.

Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:
1. Business analysis is maturing as a profession. As the IIBA has gained traction, more organizations have become aware of the BA role and its importance. From 2010 to 2011 the number of IIBA members increased about 50%.
2. Organizations have found that even with successful project management, many projects fail because of dissatisfaction with the end product. Having business analysts helps ensure that the product is a solution that works and is one the organization needs.
3. PMI has recognized the importance of the business analyst role. In 2010 they undertook a study to determine areas of overlap, handoffs, and how the two roles could collaborate.

Combined Agile methods. We predict that Agile methods will continue to change and merge as organizations take advantage of the benefits of Agile. In our 2009 Trends blog we stated that “Integrating Agile methods into project management and business analysis is a trend that will continue in 2009. Currently, the industry has a wide, varied, and inconsistent use of Agile techniques. This trend is likely to continue.”

In the two years since we wrote that article, Agile methods have continued to evolve. Although organizations have widely adopted Scrum as the predominant Agile method, they still struggle with its implementation. We think that organizations will continue to adopt Agile methods, but that these methods will continue to evolve. Combined techniques, such as Scrum-ban (which combines Scrum with the Lean technique Kanban) or Scrumerfall (a combination of Scrum and Waterfall) will be adopted for different kinds of projects.

PM and BA on Agile projects. We predict that the role of the BA and PM on Agile projects will solidify. When Agile started to be adopted, some organizations thought that the roles of PM and BA were obsolete. However, more and more organizations have recognized that the need for both roles, even if the titles are new. The Scrum Master role is best filled by someone with the expertise to coordinate the initiating, planning, executing, monitoring, & controlling, and closing each iteration and release. In other words, the work typically done by a PM. The designations of Certified Scrum Master (CSM) from the Scrum Alliance and Agile Certified Professional (ACP) from PMI have solidified this role.
The role of the BA on an Agile project has not solidified. BAs are used in a variety of ways or not at all on Agile projects. There have been heated discussions on LinkedIn discussion groups and at conferences about this role. While many organizations use BAs in the product owner role, the fundamental issue of the product owner having to make business decisions makes this problematic. Going against most of the current thinking, we predict that organizations will realize in the next few years that business analysis is essential to Agile projects. Agile projects still have requirements, and there is a need to go from high-level user stories to the detail needed to develop the needed functionality. Organizations will realize that this in-depth analysis cannot be completed during an iteration, that it has to happen just prior to development. This is called grooming the product backlog and is the perfect role for the business analyst.

The BA as management consultant. We predict that in 2012 BAs will actually function as described in the BABOK® Guide, version 2.0. That is, more BAs will “recommend solutions that help the organization achieve its goals.” They will do that in a variety of ways:
1. Business cases. More organizations will recognize that the BA is in the best position to develop business cases. Although often performed by PMs, this function happens prior to the initiation of a project and is input to project initiation (PMBOK® Guide – Fourth Edition). The PMBOK recognizes that the performing organization (business owner) is accountable for the business case, but it is the BA who is in the best position of developing it.
2. Ability to Influence without Authority. We are seeing more organizations tell us that they want their BAs to move away from taking customer orders and start using their expertise to recommend solutions. This need correlates to the enthusiasm we have seen around the need to influence without authority.
3. In her keynote at the BBC conference in Ft. Lauderdale last year, Kathleen Barrett, CEO of IIBA mentioned that one of the key competencies of the enterprise BA is management consulting.

BAs as change agents.We think that BAs will be more involved in change management. At the BBC conference in Ft. Lauderdale last year Kathleen Barret announced a new tag line for IIBA—that business analysis was about changing how organizations change. In other words, BAs will be more involved in change management. Changes might include changes in business processes, job descriptions, reporting structures, software, and more. Here are some of the ways we see this happening:
1. Enterprise analysis. Before projects are initiated, BAs determine the business need across the enterprise and recommend solutions, which need to include the ways in which organizations will need to change when these solutions are implemented.
2. Project work. While the identified at the enterprise level are by necessity high-level, the changes resulting from each project will be specific in nature. We predict that BAs will develop better tools for assessing whether or not the organization is ready for the change. We think that they will act as management consultants once the project has been defined to ease the pain associated with implementing the changes associated as with implementing the solution.
3. Post-project follow-up. We believe that BAs will be called on to monitor the post-implementation changes and continue to consult with the organization on the best way to make the solution work, even when there is some organizational resistance to it.

The virtual environment.Now that it is here, the virtual environment will continue to flourish, even if the economy improves. There are a variety of reasons why organizations will continue to rely on the virtual environment for completing projects, for training, and for webinars to replace live conferences.
1. Travel budgets. Spurred by a sluggish world economy, many organizations have reduced travel budgets for team meetings, training, and international conferences, relying instead on the virtual environment. Although colocation of teams is ideal and preferred, it is not always possible. More teams communicate and collaborate virtually, more virtual training will occur, and more webinars will take the place of live conferences.
2. Globalization has made travel impractical. Although face-to-face time, particularly during project initiation, is helpful in building trust, respect, and relationships, it is not possible to be together for all project meetings and/or requirements elicitation interviews and workshops when the team is located across the county or world.
3. Collaboration tools have made the virtual environment not only possible, but practical. Net meetings, as well as more robust training and webinar tools have supported virtual teams, so that real work can be accomplished. In addition, teams have learned how to build relationships and trust in the virtual environment. Building relationships and trust in a virtual environment is easier and quicker once people accept and feel comfortable with the virtual tools available.

“The economy, stupid,” a past political slogan said. During a slumping economy, organizations look of ways to maximize efficiencies. Focus turns to business processes and how to improve and manage them. During more prosperous times, interest in business process management tends to wane. We predict that business process management, with an emphasis on eliminating waste in organizations, will continue throughout 2012, even as the economy (hopefully) shows signs of improvement. We also predict that there will be no dominant tools for managing processes and recommend that project professionals doing business process work focus on core concepts and skills and be flexible when it comes to using BPM tools.

Don’t forget to leave your comments below.

Elizabeth Larson and Richard Larson are Co-Principals of Watermark Learning, a project management and business analysis training company. They have over 30 years of industry experience each, and have helped thousands of PM and BA practitioners develop new skills.

They have published numerous articles and papers and have co-written two books together on Requirements Management and CBAP Preparation. Both Rich and Elizabeth are CBAP and PMP certified through IIBA and PMI, and are contributors to the BABOK® Guide, Version 2.0 and the PMBOK® Guide – 4^th edition.