Tag: BABOK

Why the Scrum Product Owner IS a Project Manager, part-2

Written by Robert Galen on August 4, 2015. Posted in Articles.

In the first part of this post we began to explore the Project Management quadrant of my 4-Quadrants of Product Ownership model. When I introduced the 4-Quadrants in this post or blog post, I introduced four areas where I thought a skilled and well-balanced Scrum Product Owner had to have skill and focus:

1. Product Management
2. Project Management
3. Leadership
4. Business Analysis

The one that seemed to get the most pushback from folks was the Project Manager area. I think because many had a view to traditional project managers they’d worked with in the past, and they were having trouble mapping these skills into the role of Product Owner.

Next I’ll continue the deep- dive exploration of aspects of that quadrant, with three more areas:

5) End-to-End Project Release Planning

One of the central activities of SAFe is conducting a 2-day PSI (Potentially Shippable Increment or Release Train) planning session as a team. The event is focused on mapping work (Epics & Themes) or the “ask” from a business perspective to each teams’ ability to commit to User Stories that meet the ask.

The planning takes an end-to-end view, so from:

Requirements and visualization
Architecture – system, UX, DevOps
Through construction
Testing (functional, non-functional, automation development)
Covering operational readiness (DevOps deployment, documentation, training, customer readiness, etc.)
Deployment to Production

In other words, it takes a “Concept-to-Cash” view to ALL of the work required to deliver on the goals, themes, and features for the release. And keep in mind that the PSI is planned in a series of sprint-level increments, so it is an iterative plan.

In SAFe, there is a role entitled Release Train Engineer or RTE. They are largely responsible for facilitating and orchestrating an effective PSI-planning event.

Even if you’re not implementing the SAFe framework, many Agile organizations and teams leverage some sort of release-level planning activity—particularly in at-scale Agile. It just makes sense to have a view to a larger picture before letting loose multiple Agile teams towards an unplanned goal.

I would argue that the individual Product Owners and the Chief Product Owner are incredibly important to effective release planning. Not only to “set the stage” with the “ask”, but to be there during the planning to answer questions and to help the teams make appropriate scope tradeoffs as they try and deliver on your goals.

I would even say that Product Owners should become “students of” release planning techniques, approaches, and models. Even with an RTE or similar role, you’ll want to partner with them to ensure you and your teams have a solid plan. Here’s a link to a PDF article that explore various forms of release planning in much more detail.

6) Stakeholder Management

I remember distinctly in traditional projects where our C-level team would “call in” the project managers for portfolio level tracking. Often they would never see or interact with the individual teams. Instead, the project managers were the sole lenses for each project.

This placed a tremendous burden on the project managers to effectively “manage” stakeholder information sharing, expectations, and their reactions. Some were good at it and others were not. Some had more trust with stakeholders, which mattered a great deal too.

Often you could draw a direct correlation between projects that were going well versus not, by the maturity and skill of their project managers stakeholder management.

As we move to Agile contexts, this sort of stakeholder management is still largely relevant, but now it falls to Product Ownership to handle expectations management. Often it focuses on reinforcing the importance of your Stakeholders and Senior Leadership to “fully engage” with your/their Agile practices.

For example, getting them to regularly attend sprint demo’s, release planning, Scrum of Scrums meetings, and even circulating around daily Scrums will give them a strong sense for progress, challenges, and where they might help.

But you’ll still need to provide a “buffer” between your teams and your stakeholders, so that they effectively understand and react well to the transparency and the adjustments being made.

Note: this crosses into the Leadership Quadrant of the 4-Quadrants to some degree. This is one of those nuanced areas that really make a difference in your overall success. I often challenge the Chief Product Owner (or other Product leaders) to think about who and how they’ll be thoughtfully and actively managing their stakeholders.

7) Project Retrospective

Clearly you’re involved in each sprint retrospective that your teams conduct. And I want to encourage you to fully engage in each one of them. But that being said, I also think you need to take your feedback acquisition “up a level”.

Your Sprint Reviews are a wonderful ceremony to gather feedback from your Stakeholders and Leaders. Please don’t miss that opportunity to gather their feedback as you deliver each increment. And don’t always assume that you’re getting it either. I’ll share a story to make that point.

I was talkin Software Devg to the EVP ofelopment at a conference not that long ago. He was describing the interaction in a recent Sprint Review or Demo. He said:

Bob, I threw a 5 to represent my reaction to the demo, but I wanted to throw a 2. In truth, the demo was terrible and I believe the team failed to meet customer needs in their development efforts. I just felt very uncomfortable giving that sort of negative feedback in front of a large audience. I pulled aside the Director of that team later, and I gave her my feedback.

I actually challenged him to speak the truth” in future reviews. I tried to make the point that it was important to be transparent with feedback as well. Sure, craft it carefully, but if a demo sucked and you said it was great, that is setting a very bad precedent. He responded:

You’re right Bob, but we are located in the South and have a culture of thoughtfulness and care when giving bad news. It will take me (and us) time to get over this cultural barrier. But I can’t imagine “telling truth” for quite some time.

Clearly you need to work incredibly hard to get all forms and types of feedback out from your stakeholders. Be aware of your cultural norms and figure out creative ways to get the truth on the table so you and your teams can address any deficiencies or misses.

SAFe has a release-level retrospective at the end of each PSI. It’s a cross-team, ALL stakeholder meeting where issues are discussed and improvement action-plans are formed. So there are multiple “layers” to the feedback and reflection opportunities.

I’ve written several other posts that explore the power of Sprint Reviews beyond simply showing software:

• http://www.projecttimes.com/robert-galen/the-agile-project-manager%E2%80%94voila-the-great-reveal.html
• http://www.batimes.com/robert-galen/sprint-reviews-learnings-from-the-movies.html

I wanted to remind you of one of the reasons I developed the 4-Quadrants in the first place. It’s because of how hard the Product Owner role is to perform well. It’s an incredibly deep and broad role that requires tremendous effort and skill. It also requires quite a bit of time.

I often joke, and it’s not really a joke, that I’ve only met 4-5 Product Owners who could perform all aspects of the 4-Quadrants by themselves. Ever! What this implies is that it’s OK to ask for help. In fact, you’ll most probably need to get help in your role.

If you have Project Management strengths and skills, then take some of this on yourself. If you don’t, then look for someone else in the organization with these skills and strengths to help you out. For example, in SAFe environments, you might want to make the RTE a partner or best friend.

But the KEY is to find or ask for help if you need it in the quadrants where you are weakest.

Wrapping Up

I know, I’ve just added a tremendous amount of additional work to every Product Owner reading this article. I’m sorry. But whether you like the 4-Quadrants model or not, this work is there for you regardless. The key is to be aware of it, get someone covering it, and to do it very well.

All of the 4-Quadrants are important to the role of Product Ownership, but I hope I’ve shown you how crucial the Project Management quadrant is to you, your team, and your organization.

Stay agile my friends,
Bob.

Leadership Lessons – When Were you Last Engaged?

Written by Peter de Jager on July 31, 2015. Posted in Articles.

No. That isn’t a question about your personal life, it’s a question about your work life. Are you still engaged? Or has the passion for your work worn off? More to the point? Are our staff still engaged? Do they look forward to arriving at the office, or are they regularly having to buy new alarm clocks because the old ones don’t hold up to the Monday morning mauling to shut them up?

The issue of ’employee engagement’ has become a bit of a trend lately. Head to Google Trends (www.google.com/trends) and type in ‘Employee Engagement’ for a visual representation of that trend based on Google searches. (Compare it to how my specialty of ‘Change Management’ is trending. Oops. Do I need to change my topic?)

The first thing we need to do is define what we’re talking about. What is ‘Employee Engagement’ and then, why should we care about it.

Here’s a definition I use that’s in synch with what I’ve seen as common usage;
“ an employee who is engaged with their job feels a certain amount of ownership in the outcome of their actions, they care about their work, they show initiative when something needs doing, rather than waiting for someone to point them in the right direction”.

Why is it important? Consider yours truly, the writer of this column as an absurd example. I’m a one man company. I must be engaged in what I do, not necessarily all of what I do, but at the very least with the core of what I do, otherwise there are ugly consequences.

I could not care less about ‘accounting’, yet it must be done – so I outsource that administrivia, and several others, to someone else. Problem solved.
But, the core of what I do is ‘take the stage’. The instant that becomes a chore, something I do on autopilot because I have to? Then I am on the fast path to being an ex-speaker.

In a typical office, the consequences of lack of engagement are similar, but they are easier to hide, or at least to ignore. A single unengaged employee out of a staff of 5 or 10 might be regarded as not much of a problem, but if 50% of staff are unengaged, then productivity and quality begin a precipitous drop.
If all of our staff are disengaged from what they do, then who owns all that which needs doing? Who cares about the deliverable? Who takes the initiative? If ownership, caring, and initiative is all falling to a handful or even a single individual? Then we have a serious problem. Especially when increased ownership, caring and initiative without recognition and/or reward is a very good reason to stop caring… anyone for a good game of domino effects?

When employees become disengaged, then even day-to-day operations require conscious effort to drive them forward, an effort that might be better used thinking about tomorrow.
So why do we disengage? Here are five possible reasons – there are others.

Not enough feedback.

We’re simple creatures. We like to know how we’re doing. Without feedback? We have no clue if we’re going in the right direction. Feedback is food that feeds our motivation.

Lack of opportunity to grow

We also don’t like standing in the same place, at the very least most of us find that boring. Even if there are no new positions to move into, are there at least new things we could be doing?

Lack of recognition

This boils down to a simple question? Do you care that I care? Not everyone is ‘self-motivated’, many us, make that nearly all of us, appreciate being appreciated.

Here’s a challenge. I dare you to do this. One Friday afternoon. Order in a few pizzas, some cans of pop, some dessert. Call everyone into your office and tell them, “I know you’ve all been working hard. I just wanted to say. “Thanks!” You don’t have to say anything else. Just ‘Thanks!’ This works even better if you’ve never done such a wild and crazy thing, especially if your organization has banned office celebrations. (This must be the case, because office parties have become a rare beastie.)

Let me know what happened. My e-mail is at the end of this collection of articles.

Lack of Trust

I don’t think anyone needs to spend much time elaborating on this. Nobody cares to put extra effort into an organization they no longer Trust. On a scale of 1-10… how much Trust is there in your organization?

Stress-Burnout.

Things are tough all over and getting tougher. If you want to muse something over on your own? Go back to Google Trends and do a search on ‘Recession’…. compare that chart to the one you got when you searched on ‘Employee Engagement’.

Not all of the above are solved easily, some are, others are way beyond our scope and powers. The problem of employee disengagement is a real one. If allowed to grow (or encouraged to grow!) then sooner or later the organization is coasting (grinding?) to a halt. The first step in solving it is accepting that it is a problem… and with that? Here’s the closer;

Here’s a personal question.. What do you do on autopilot at work? What have you disengaged from? What have your staff disengaged from? What’s that costing your organization? Do you know? Do you care? (Careful with that last answer… it’s a doozie)

BABOK Version 3 vs. Version 2 – Taming the new Guide – Part 3: BA CORE CONCEPT MODEL (BACCM) and Perspectives

Written by Elizabeth Larson on July 6, 2015. Posted in Articles.

In our continuing series on BABOK version 3 vs. version 2, we conclude with the two major additions made by IIBA: the BA Core Concept Model™ (BACCM) and an all-new section containing five perspectives on Business Analysis. This article provides a summary of the new BACCM, a practical definition of the six core concepts, and an example of each. This article also describes the new Perspectives and provides examples of the common elements in all the Perspectives.

BA CORE CONCEPT MODEL (BACCM)

One of the key changes in the BABOK® Guide version 3.0 is the introduction of the Business Analysis Core Concept Model (BACCM). This model defines the framework for all business analysis work, and can be applied across industries, methodologies, projects, and organizational cultures. It shows the interrelationships among six core concepts: Needs, Solutions, Changes, Stakeholders, Value, and Contexts. There is no order to these six concepts that can be read in a variety of different patterns. Let’s look at each of these six concepts and then some of the ways each relates to the others.

Figure 1 below, published by IIBA in the BABOK® Guide version 3.0, shows the BACCM.

Needs refer to business problems that require solving or opportunities that can be seized. Needs are satisfied by Solutions.

Solutions are the products and services that provide ways to take advantage of opportunities and solve business problems. Solutions are developed through Changes consisting of one or several projects, programs, or initiatives. Examples include installation of commercial software and changes to the current processes, development of a new medical device, creation of a marketing campaign, or implementation of new regulations.

Figure 1: Business Analysis Core Concept Model

Changes are the steps involved in transforming Needs into Solutions. Note that the word “Change” is used in the BABOK® Guide in lieu of the terms “Project” and “Program.”

Stakeholders are individuals or groups that have Needs, an interest in the Solution, and/or are affected by the Changes.

Value. Solutions need to provide Value to the organizations and Stakeholders. If Solutions do not provide Value, they have not met the Need. Business analysis is really all about delivering Value to the organization.

Contexts are all those things that affect and are relevant to the Changes. This is the environment in which the Solution will be developed and includes such things as organizational culture, as well as the culture of the various countries that might be involved, languages, organizational process assets and environmental factors, constraints like weather, seasons, or other things happening at an organization or within a division or department.

Let’s look at an example of these interrelationships.

Need. A sponsor is concerned about losing market share to a competitor. One of the problems that contributes to this loss is the limited information provided by the set of Order reports she currently receives. Her Need, then, is the limited Order information inhibiting her ability to make good buying decisions.

Solution. After some analysis and a business case, the business analyst has recommended commercial business analytics software as a Solution. This is a complex Solution that will involve multiple projects addressing such things as processes, software, and new technology to name a few.

Changes. The Changes to the organization will be significant. The analysis of the current state and definition of the future state done during Strategy Analysis will need to be refined and expanded. Some of the Changes include designing new processes, purchasing new software, modifying data structures in existing interfacing applications, capturing new data, building technical ways to transition to the new software, and more.

Stakeholders. Stakeholders including buyers, merchandisers, advertising staff, distribution centers, retail store personnel, customer service specialists, several vendors, and many areas in IT will be affected globally.

Value. This Solution will provide Value to the sponsor, many Stakeholders, and the organization. The business case included a cost/benefit analysis which showed that although the costs were high, the organization would start seeing a benefit within a year. Several solution performance measures were identified during Solution Evaluation to help measure the realized value.

Contexts. Since this is a complex project with globally distributed Stakeholders, there are many Contexts that need to be considered. Each country’s laws and regulations, the various national cultures, as well as the different departmental cultures will affect the development of the Solution. For example and speaking generally, the distribution staff tends to be casual, the buyers more goal-driven and direct, and the advertisers more expressive. In addition, one of the facilities is in central Europe, which has recently experienced massive flooding. Finally, monsoon season is approaching India, where some of the technical and support staff are located.

Understandably not all Solutions and Changes are as complex as this one. This example was meant to provide an understanding of each of these six core concepts and how they fit together.

Perspectives

The BABOK® Guide Perspectives are focused areas that need to be addressed depending on the nature of the project. Each Perspective provides how business analysis work is completed and its unique characteristics on projects with these Perspectives:

Agile
Business Intelligence
Information Technology
Business Architecture
Business Process Management (BPM)

Some projects will have multiple perspectives. A business analytics application, for example, might have elements from all five perspectives.

Each perspective is organized into five sections:

Change scope (think project scope) includes such things as which areas of the organization are impacted and will be affected by the approach taken. For example, the Agile perspective alludes to a constantly changing scope. The BPM perspective contains four typical lifecycle stages and several methods to outline the scope.
Business analysis scope includes the scope of the business analysis work, including which artifacts or work products will be produced and which stakeholders will be involved in the change. For example, the Agile perspective notes that the amount of rigor applied to documentation, a business analysis work product, is dependent on the nature of the project.
Methodologies, approaches, and techniques. Each Perspectives might have some specific methodologies or approaches that are unique to that Perspective. Scrum, for example, is an Agile Methodology. Information Technology has its own development life cycles. As an example of a technique, Prioritization is listed as a general technique, but in the Agile perspective MoSCoW prioritization is listed as an Agile-specific type of prioritization.
Underlying competencies include those that are most relevant to each perspective. They do not have to be unique and might be relevant to other Perspectives as well. For example, the Communications and Collaboration technique is listed as an underlying competency in the Agile perspective. Collaboration Games is listed as a general technique. Communications Skills is listed as a general underlying competency.
Impact on Knowledge Areas shows a mapping of specific activities relevant to the Perspective to the BABOK® Guide tasks. For example, the Agile Perspective discusses the relationship to the Requirements Life Cycle Knowledge Area, stating that requirements are defined with increasing detail and that validation of requirements is done at the end of each iteration. The BI Perspective mentions overcoming barriers to utilizing new analytic tools and techniques in Solution Evaluation.

This article has provided a summary of the new BACCM and Perspectives with some examples to help decipher these new concepts. The overall series of articles gives an in-depth look at the new BABOK version 3. The new Guide represents a major increase in content and improvement over version 2. Our goal was to explain the major changes and additions, and to structure and simplify it. Please respond with your comments, questions, and any disagreements.

Don’t forget to leave your comments below.

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.

BABOK Version 3 vs. Version 2 – Taming the Guide – Part 2: Techniques

Written by Richard Larson on June 23, 2015. Posted in Articles.

In Part 1 we started our comparison of BABOK version 3 and its predecessor, version 2. We outlined the Knowledge Area and Tasks that are changing with the new release and showed where the major changes are occurring. Our view is there were substantive, but not necessarily shocking changes in the versions pertaining to the KAs and Tasks. Now we turn our attention to the updates of the General Techniques in the latest BABOK version.

BABOK VERSION 3 TECHNIQUES

General BABOK techniques are another major area of change in BABOK v3, which we cover second for similar reasons as we did for the KAs. Namely, the amount of familiarity people have for the v2 techniques will help make understanding the changes in v3 a bit easier.

Version 2 of the BABOK included 34 general techniques and 15 task-specific techniques. Version 3 has added 16 additional general techniques, a whopping 47% increase. We could debate whether such an increase was needed, but one thing is certain: there are several new techniques to master if you plan to pass the CBAP or CCBA exam. And, for those using the BABOK as a general reference, Business Analysis has more techniques than ever that are regarded as generally accepted in the industry.

See Table 1 below for a summary of both the stability and changes to general techniques from BABOK version 2 to 3.

Technique	Same	Rename	New	Notes
10.1 Acceptance and Evaluation Criteria	X
10.2 Backlog Management			X
10.3 Balanced Scorecard			X
10.4 Benchmarking and Market Analysis		X		Added “Market Analysis”
10.5 Brainstorming	X
10.6 Business Capability Analysis			X
10.7 Business Cases			X	Was a task in v2
10.8 Business Model Canvas			X
10.9 Business Rules Analysis	X
10.10 Collaborative Games			X
10.11 Concept Modelling			X
10.12 Data Dictionary		X		Dropped “Glossary”
10.13 Data Flow Diagrams	X
10.14 Data Mining			X	Most applicable to BI Perspective
10.15 Data Modelling	X
10.16 Decision Analysis	X
10.17 Decision Modelling			X	Includes Decision Tables and Decision Trees, both part of “Decision Analysis” in v2
10.18 Document Analysis	X
10.19 Estimation	X
10.20 Financial Analysis			X	Moved from Enterprise Analysis in v2
10.21 Focus Groups	X
10.22 Functional Decomposition	X
10.23 Glossary			X	Split off from v2 Data Dictionary & Glossary
10.24 Interface Analysis	X
10.25 Interviews	X
10.26 Item Tracking		X		In v2 were part of “Problem Tracking” and an Element in “Manage Solution Scope & Requirements”
10.27 Lessons Learned	X			Dropped “Process” from title
10.28 Metrics and Key Performance Indicators (KPIs)	X
10.29 Mind Mapping			X
10.30 Non-Functional Requirements Analysis	X
10.31 Observation	X
10.32 Organizational Modelling	X
10.33 Prioritization			X	Previously were techniques in “Prioritize Requirements” in v2
10.34 Process Analysis			X	Includes SIPOC and Value Stream Mapping, arguably part of process modeling
10.35 Process Modelling	X
10.36 Prototyping	X
10.37 Reviews		X		Formerly “Structured Walkthrough” in v2
10.38 Risk Analysis and Management		X		Formerly “Risk Analysis” in v2
10.39 Roles and Permissions Matrix			X	Previously techniques in “Conduct Stakeholder Analysis” in v2
10.40 Root Cause Analysis	X
10.41 Scope Modelling	X
10.42 Sequence Diagrams	X
10.43 Stakeholder List, Map, or Personas			X	Previously techniques in “Conduct Stakeholder Analysis” in v2
10.44 State Modelling		X		Called “State Diagrams” in v2
10.45 Survey or Questionnaire	X			“Survey/Questionnaire” in v2
10.46 SWOT Analysis	X
10.47 Use Cases and Scenarios	X			Formerly “Scenarios and Use Cases” in v2
10.48 User Stories	X
10.49 Vendor Assessment	X
10.50 Workshops		X		Called “Requirements Workshops” in v2

Table 1: BABOK v2 vs. v3 General Technique Differences

BABOK VERSION 3 TECHNIQUE SUMMARY

As you can see in the table above, all 34 general techniques from BABOK version 2 remained intact or were renamed. Again, we could argue the wisdom of keeping all the techniques or the appropriateness of adding some of the narrower techniques. Like any Body of Knowledge, there will be tasks and techniques in BABOK® Guide v3 that will never apply to a particular person’s job or career situation. The challenge becomes that of a) mastering the content enough to pass the CBAP or CCBA exam and/or b) deciding whether to use the particular techniques on the job.

Of the 16 “new” techniques, half of them are not actually new. Some have been moved out of task-specific techniques, such as Business Cases. Some are divisions of other techniques such as Process Analysis, which has many similarities to Process Modeling. Table 2 below is our list of the truly new techniques added to BABOK version 3.

NEW TECHNIQUE	BABOK DESCRIPTION	RELATES TO
10.2 Backlog Management	Used to record, track, and prioritize remaining work items.	Agile Perspective
10.3 Balanced Scorecard	Used to manage performance in any business model, organizational structure, or business process.	BPM Perspective and Process Analysis
10.6 Business Capability Analysis	Provides a framework for scoping and planning by generating a shared understanding of outcomes, identifying alignment with strategy, and providing a scope and prioritization filter.	BPM Perspective and Process Analysis
10.8 Business Model Canvas	Describes how an enterprise creates, delivers, and captures value for and from its customers.	BPM Perspective and Strategy
10.10 Collaborative Games	Encourage participants in an elicitation activity to collaborate in building a joint understanding of a problem or a solution.	Facilitation and Workshops
10.11 Concept Modelling	Organize the business vocabulary needed to consistently and thoroughly communicate the knowledge of a domain.	Glossary
10.14 Data Mining	Used to improve decision making by finding useful patterns and insights from data.	BI Perspective
10.29 Mind Mapping	Used to articulate and capture thoughts, ideas, and information.	Conduct Elicitation

Table 2: Truly New Techniques in BABOK Version 3

In the next part of this article, we examine the two major additions to BABOK version 3: the BA Core Concept Model and Business Analysis Perspectives.

Don’t forget to leave your comments below.

BABOK Version 3 vs. Version 2 – Taming the New – Guide Part 1: Knowledge Areas and Tasks

Written by Richard Larson on June 4, 2015. Posted in Articles.

Most people in the BA field know that the IIBA® has produced an important update to its definitive Business Analysis Body of Knowledge, the BABOK® Guide. Released in April 2015, the BABOK® Guide includes major upgrades, ranging from the BA Core Concept Model™ (BACCM), to changes to most Knowledge Areas, the addition of 16 new techniques, and the addition of an all-new section containing five perspectives on Business Analysis.

By IIBA’s estimation, the BABOK has grown 50% from version 2 to version 3 and now has more than 500 pages. It has a richer and more complete set of information about the practice of Business Analysis. It also means the CCBA will have a greater amount of knowledge on which to test aspiring CBAP and CCBA candidates. Both points are good for the profession in our opinion.

Most comparisons of the two versions cover the major changes and ours is no different. However, we begin with the familiar aspects of version 2 and how they change in version 3. Part 1 features changes to Knowledge Areas and Tasks. Part 2 covers the expansion of Techniques, and Part 3 presents the two major BABOK additions: the BACCM and the Perspectives.

BABOK VERSION 3 KNOWLEDGE AREAS AND TASKS

We are starting the BABOK differences with the Knowledge Areas (KAs) and tasks instead of the Core Concept Model for two main reasons. First, most people are familiar with the KAs and their tasks, so it makes the jump to v3 a little less of a leap. Second, the BACCM surrounds the KAs and for each KA the BABOK Guide version 3 shows how the BACCM applies to it. Our view is that v3 is not as big a change as one might think when doing a KA to KA comparison.

Below is a table we compiled to show the differences in tasks. After finishing a draft we then consulted with the BABOK Guide’s table of differences and the result is shown in Table 1.

Some tasks have not changed much or at all, such as “Plan Business Analysis Approach” or “Verify Requirements. “ The task names of some 10-11 tasks have remained the same, which means roughly 21 tasks have been changed, added or deleted. There are now only 30 tasks compared with 32 in v2.

BABOK® Guide Version 2 Knowledge Area and Task Names	BABOK® Guide Version 3 Knowledge Area and Task Names (additions/changes in v3)
2.0 BA Planning and Monitoring – v2.0 tasks	3.0 BA Planning and Monitoring – v3.0 tasks
2.1 Plan Business Analysis Approach (content for prioritization and change management moved to Plan BA Governance) 2.3 Plan Business Analysis Activities	3.1 Plan Business Analysis Approach 3.3 Plan Business Analysis Governance
2.2 Conduct Stakeholder Analysis 2.4 Plan Business Analysis Communication	3.2 Plan Stakeholder Engagement
2.5 Plan Requirements Management Process (see note for Plan BA Approach)	3.4 Plan Business Analysis Information Management
New Task:	3.4 Plan Business Analysis Information Management
2.6 Manage Business Analysis Performance	3.5 Identify Business Analysis Performance Improvements
3.0 Elicitation – v2.0 tasks	4.0 Elicitation and Collaboration – v3.0 tasks
3.1 Prepare for Elicitation	4.1 Prepare for Elicitation
3.2 Conduct Elicitation Activity	4.2 Conduct Elicitation
3.3 Document Elicitation Results 4.4 Prepare Requirements Package 3.5 Communicate Requirements (Note: ours is more complete than the BABOK comparison)	4.4 Communicate Business Analysis Information
3.4 Confirm Elicitation Results	4.3 Confirm Elicitation Results
New Task:	4.5 Manage Stakeholder Collaboration
4.0 Requirements Management and Communication – v2.0 tasks	5.0 Requirements Life Cycle Management – v.3.0 tasks
4.1 Manage Solution Scope and Requirements	5.1 Trace Requirements (Especially relationships) 5.5 Approve Requirements (Conflict and Issue Management; Approval was formerly an element)
4.2 Manage Requirements Traceability	5.1 Trace Requirements (“Configuration Management System” becomes “Traceability Repository”) 5.4 Assess Requirements Changes (Impact Analysis moved here)
4.3 Maintain Requirements for Re-Use	5.2 Maintain Requirements
6.1 Prioritize Requirements (from Requirements Analysis)	5.3 Prioritize Requirements (Moved from Requirements Analysis in v2)
4.4 Prepare Requirements Package 4.5 Communicate Requirements (both become part of “Communicate BA Information” in Elicitation and Collaboration)	4.4 Communicate Business Analysis Information
New Task:	5.5 Approve Requirements
5.0 Enterprise Analysis – v2.0 tasks	6.0 Strategy Analysis – v3.0 tasks
5.1 Define Business Need	6.1 Analyze Current State 6.2 Define Future State
5.2 Assess Capability Gaps	6.1 Analyze Current State 6.2 Define Future State 6.4 Define Change Strategy
5.3 Determine Solution Approach	6.2 Define Future State 6.4 Define Change Strategy 7.5 Define Design Options 7.6 Analyze Potential Value and Recommend Solution (Note: ours is more complete than the BABOK comparison)
5.4 Define Solution Scope 7.4 Define Transition Requirements	6.4 Define Change Strategy
5.5 Define Business Case	6.3 Assess Risks (was an Element in v2 Business Case task) 7.6 Analyze Potential Value and Recommend Solution (Business Case is also now a General Technique)
6.0 Requirements Analysis – v2.0 tasks	7.0 Requirements Analysis and Design Definition – v3.0 tasks
6.1 Prioritize Requirements (Moved to Requirements Life Cycle Management)	5.3 Prioritize Requirements
6.2 Organize Requirements	7.4 Define Requirements Architecture
6.3 Specify and Model Requirements	7.1 Specify and Model Requirements
6.4 Define Assumptions and Constraints	6.2 Define Future State 7.6 Analyze Potential Value and Recommend Solution
6.5 Verify Requirements	7.2 Verify Requirements
6.6 Validate Requirements	7.3 Validate Requirements
New Task:	7.5 Define Design Options (pulls together v2 Determine Solution Approach, Assess Proposed Solution, and Allocate Requirements)
New Task:	7.6 Analyze Potential Value and Recommend Solution (pulls together v2 Define Business Case and Assess Proposed Solution)
7.0 Solution Assessment & Validation – v2.0 tasks	8.0 Solution Evaluation – v3.0 tasks
7.1 Assess Proposed Solution	7.5 Define Design Options 7.6 Analyze Potential Value and Recommend Solution
7.2 Allocate Requirements	7.5 Define Design Options
7.3 Assess Organizational Readiness	6.4 Define Change Strategy
7.4 Define Transition Requirements	6.4 Define Change Strategy (Also see Requirements Classification Schema)
7.5 Validate Solution	8.3 Assess Solution Limitations
7.6 Evaluate Solution Performance	8.5 Recommend Actions to Increase Solution Value
New Task:	8.1 Measure Solution Performance
New Task:	8.2 Analyze Performance Measures
New Task:	8.4 Assess Enterprise Limitations

Table 1: BABOK v2 vs. v3 KA and Task Differences (table modified from BABOK Guide® version 3)

BABOK VERSION 3 KA AND TASK SUMMARY

The changes to BABOK Knowledge Areas and their associated tasks on the surface may seem to be significant. Only one KA name (BA Planning and Monitoring) survives intact from v2 to v3. Only nine task names are the same or roughly the same. This article does not cover details like inputs and outputs, and many of those names have changed from one release to the next.

Upon closer examination, though, the changes are actually not so dramatic. We can summarize a few observations.

Even though most KA and task names have changed, in many cases they are merely refinements rather than significant changes. For example:
- The Elicitation KA in v2 is now Elicitation and Collaboration. Most tasks in that KA are the same with the addition of the “Manage Stakeholder Collaboration” task.
- The v2 “Conduct Stakeholder Analysis” task in Planning and Monitoring has been changed in v3 to “Plan Stakeholder Engagement.”
The Requirements Management and Communication KA and Requirements Life Cycle Management (RLCM) are essentially similar. An important addition is that prioritize Requirements is placed in RLCM.
Enterprise Analysis has become Strategy Analysis, essentially broadening its scope. It now includes devising change strategies, transitions, and organization readiness.
Requirements Analysis is similar in v2 and v3, despite the addition of the concept of “Design.”. An important distinction has been made by IIBA between requirements and design, which boils down to the distinction between business needs and solutions to those needs.
- Requirements – the usable representation of a need (see our forthcoming article on the BA Core Concept Mode).
- Designs – usable representation of a Solution. A new task “Define Design Options” has been added to focus on the BA work in designing solutions. Another new task “Analyze Potential Value and Recommend Solution” actually pulls together facets of two tasks from v2.
Solution Assessment and Validation has been renamed as Solution Evaluation. There are three new tasks as the table shows. They were added to clarify the work of evaluating solution performance over its lifetime including organizational constraints.
Out of the 32 tasks in v2, only eight have been added, a 25% change. That means 10 have been removed since there are now 30 tasks in all.

In short, BABOK version 3 is better organized than its predecessor, and with refined KA and task names contains a structure that better reflects the practice of business analysis.

In the next part of this article, we explore changes to BA techniques in BABOK version 3.

Don’t forget to leave your comments below.