Skip to main content

Author: Cynthia Low

Top Ten Tips for Tackling the CBAP Exam

It’s no surprise that the certification of business analysts is more sought after today than ever before. Worldwide the demand for qualified practitioners, and the ability for them to quickly demonstrate their capabilities in requirements management and development, continues to grow.

Growing almost as quickly is the number of people taking the Certified Business Analysis ProfessionalTM (CBAP®) exam. The 150-question exam is based on the International Institute of Business Analysts’ (IIBA®) Business Analysis Body of Knowledge® (BABOK®). This constantly evolving business analyst’s handbook reflects the most current, generally accepted business practices, and is one of the best references in preparing for the challenging multiple-choice exam.

So what does this mean to you? For those looking to take their careers forward, or to give themselves an advantage over the competition in the job market, the CBAP certification can mean an advanced career path, documented professional expertise and a positive impact on your organization. The exam is as challenging as the certification is valuable, but the time you take to prepare, from collecting and submitting your extensive application materials, is well worthwhile.

As with any standardized testing, there are literally hundreds of sources for information, tips and strategies. From that mountain of information, here are 10 widely recognized best practices for applying for, preparing for and taking the CBAP exam.

  1. Take your time, part 1. Even applying to sit for the exam will take a significant amount of time. Most experts and CBAPs agree that you should give yourself at least eight hours total to complete the application. Yes, you read that right. Eight total hours. (When you read #2 below, you’ll understand why.)

    Read each question and section carefully. Answer to the best of your ability and take the time to really focus on the application.

    To further minimize omissions and errors – or the odds of having your application rejected – always use the IIBA-supplied templates, available with the application at http://www.theiiba.org/ under “get certified.”

  2. Know the requirements and fees. To successfully apply for the exam, you must demonstrate your professional experience, specifically in indentifying business needs and determining the best solutions for business problems. The completed application must meet the following five requirements:
    1. Work Experience: 7,500 hours of verifiable, hands-on business analysis work over the 10 years preceding your exam application.
    2. Knowledge Areas: Demonstrable experience and expertise in at least four of the six knowledge areas: Enterprise Analysis, Requirements Planning and Management, Requirements Elicitation, Requirements Analysis and Documentation, Requirements Communication, Solution Assessment and Validation, and Business Analysis Fundamentals.
    3. Education: High school or equivalent
    4. Professional Development: 21 hours of verifiable coursework in the past four years, directly related to business analysis.
    5. References: Two references from a career manager, client (internal or external) or CBAP are required. These references must indicate that you are a suitable candidate for the CBAP® certification.

      Next, consider applying for IIBA membership before applying for the exam. As you will see below, the fee schedule for the exam varies, depending on whether or not you are an IIBA member, with savings of $125 for members (exactly the amount of the application fee). Consider the idea that you will probably join IIBA after gaining your certification- so why not essentially apply for “free?”

      Fees:

IIBA® membership fee:

$95 USD

 

Paid annually.

Application Fee

$125 USD

This fee pays for the processing and administration of your application.

It is non-refundable.

 

Exam Fee –

for IIBA®Members

$325 USD

The fee pays for the initial exam sitting and will NOT be reimbursed if you do not pass the exam.

 

Exam Fee –

for non-IIBA® Members

$450 USD

The fee pays for the initial exam sitting and will NOT be reimbursed if you do not pass the exam.

Please note:  You can submit both the application and the exam fees with your application. If your application is declined, you will be reimbursed the exam fee.

  1. Know your study style. Once you’ve applied, you can then expect to devote a substantial amount of your time and attention to preparation. Experts estimate total “ideal” study time at anywhere from six weeks to six months.

    Before jumping in, have a clear understanding of how you learn and retain information. This point can’t be stressed enough. Quite simply, what many people forget, especially if they haven’t taken an examination in some time, is that not every study method works for every person.

    For example, you may be a visual learner, or perhaps you remember spoken words more readily. Do you do better taking classes and interacting with others or working through study guides on your own? Tailoring your preparation to your style will save you hours – if not days – of frustration and increase your confidence on exam day.

  2. Know your resources. With the vast number of available study methods and resources, narrow your choices by creating a list of study resources and be very selective, keeping in mind your personal style (#3 above). CBAP study guides featuring practice examinations are available, as well as business analysis courses to help you prepare for the exam, maintain your certification, and build upon your existing skills. 

    Regardless of the preparation regimen you ultimately choose, it’s wise to contact your local IIBA chapter. Many chapters offer study groups, or you can leverage the knowledge of peers who have already achieved their CBAP® certification.

  3. Get a flash of brilliance. Even in this age of palm-sized computers and high-speed mobile Internet, one popular preparation method is decidedly “low-tech.” Many CBAPs laud flash cards as study tools for exam terms and definitions of each knowledge area – so much so that the study technique is actually featured in many preparation courses. Even if you’ve chosen not to take a formal course, consider making some flash cards for yourself. They’re an easy, efficient way to study anywhere.
  4. Demonstrate intimate knowledge. Memorizing terms and knowing the BABOK is just one part of passing the CBAP exam. Since the exam uses situational scenarios throughout, understanding of language, usage and context for all six knowledge areas is also very important. Success depends on your ability to align your business analysis experience with the exam questions.
  5. Know your activities. Next, memorize the tasks and activities within each knowledge area. If you aren’t already, become familiar with the input and output of each activity across all knowledge areas. Knowing what you’re supposed to get out of a solution will increase your confidence as you work your way through the examination. 
    You can get a feel for activities by creating your own small models for each knowledge area or by using the models included in many of the available classes or guides.
  6. Know your modeling. Usage, process, flow, data and behavior models are all areas tested on the exam. Since the exam focuses on practical, situation-based questions, it’s very important to devote significant time to practicing modeling and more importantly, becoming familiar with when to apply each. 
  7. Practice, Practice, Practice. All the studying in the world is for naught if you’re surprised when you sit down for the actual exam. Whatever your preparation method, be sure to develop a plan for practicing with CBAP-format questions or full-blown practice examinations. Set aside three hours, find a quiet spot, and work your way through. After a few practice exams, and knowing exactly what to expect, the real one won’t seem so intimidating.
  8. Take your time, part 2. The night before the exam, don’t try to cram or re-read the BABOK. Just get a good night’s rest – it is a three-hour-long, taxing test, and being focused and alert is the best favor you can do for yourself.

    On the day of the exam, dress comfortably and bring paper and pencil to work out your answers. Most testing facilities provide these, but it never hurts to be prepared.

    If you’ve memorized items, you are allowed to write on the exam booklet, so get them written down before you begin – it will give you one less thing to think about.

    Finally, put everything you’ve learned to use and pace yourself. You’re not scored on how quickly you complete the exam and rushing leads to costly mistakes. If you do not pass the exam, you must wait three months before you are allowed to re-take it.

    Scoring the exam takes up to 30 days and results will include knowledge area breakdowns for those who have not passed.

    Without proper preparation, the CBAP examination can be intimidating. However, if you solidify your skills and knowledge and take advantage of your experience as a Business Analysis professional, you’ll have your certification sooner than you think.

    Good luck.


Glenn R. Brûlé, Executive Director, Client Solutions, ESI International, is author of CBAP   Exam: Practice Test and Study Guide, First Edition. He has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI International, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn is a Member of the Board of Directors and Vice President of Chapters of the International Institute of Business Analysis (IIBA).  For more information, visit http://www.esi-intl.com/.

The New Role of the Business Analyst and The Strategic Implications

The new role of the BA is far more strategic in both the organizational sense as well as at the project level. In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams. This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

  • The organizational structure must support the actions of a “strategic” BA position. 
  • The BA candidate must have wide skill sets, encompassing many general management competencies.

As organizations shift to become “projectized,” the roles and responsibilities that have supported projects within a traditional matrix structure must shift as well. Over the years we have seen organizations struggle with the following challenges related to shifts in both structure and culture: 

  • Broken or disjointed cross-functional communication channels. 
  • Uncertainty around roles and responsibilities within the project structure and beyond. 
  • Quality concerns at the point of project delivery. 
  • Skewed scope statements and, thus, implementation plans due to early-stage breakdown. 
  • Overall loss of productivity on project teams due to lack of continuity and methods.

The items noted above are tell-tale signs that several strategic components of a best practice project management environment are missing. In the past, we addressed the discussion around project office and methodology; the topic of BA is an integral component to bring both of those items to life in the real world.

Forward looking or best in class organizations have aggressively embraced the concept of the BA role. What sets them apart from the old school thinking associated with this job title is the escalation and expansion of the roles, definition and responsibilities. Not too many years ago, a BA may have been confined to a very technical role within an IT environment working on specifications, functionality and even some quality and testing related to one or more project life cycles. Today we are seeing BA positions filled from across the organization and expect that this trend will continue, as it should.

Let’s address these points in the context of how they can be leveraged to meet the challenges:

Broken or disjointed cross-functional communication channels

A BA should be in front of any project communication produced, from the point of team inception to the close-out phase. This interaction does not mean that the BA takes on the role of project manager (although we have seen organizations combine the two roles), as it is not effective on larger and longer term initiatives. Our experience shows that an independent BA position can help to promote better communication, align protocol and help the project manager to extend his/her reach into the project teams.

Uncertainty around roles and responsibilities within the project structure and beyond

The BA functions as a tour guide through the project plan ensuring that all of the moving pieces are touching at the right points. We call these critical communication points and they can be built around time, budget or deliverable expectations. The BA will be assigned a protocol map within the project structure to enable better access to expectations, and provide for a proactive way to reach team members.

Quality concerns at the point of project delivery

In reality, the BA is monitoring quality points through the project life cycle, thus producing a quality product at the close of the project. Very much like the thinking around proactive quality control, the BA is in front of each deliverable and monitors the progress against the project plan. This allows for immediate communication between the project manager, customer and associated teams.

Skewed scope statements and thus implementation plans due to early stage breakdown

The planning stages of a project are obviously critical to the implementation plan and ultimate quality. A BA should be assigned early in the process and work hand in hand with the project manager to ensure the highest level of intimacy with the plan. Just as important, they need to have a direct connection to the internal and external customers in order to ensure collaboration and proactive attention to emerging issues.

Overall loss of productivity on project teams due to lack of continuity and methods

A strategic BA assists the project manager and PMO with the execution of best practice within an organization’s project management structure. The BA has a unique opportunity to guide the process through an existing methodology and essentially help the project to operate in better alignment. This is accomplished by having a dedicated individual who is consistently working against the deliverables and is not distracted by the operations management associated with the project manager’s job.

By taking the above steps you have begun the shift toward the organizational structure needed to take advantage of the BA position. With that said, we still have one more change to make in order to secure success.

It is obvious that the BA role, as defined here, will require wider skill sets than the more traditional BA position, still driven from the IT departments of yester-year. To that point we have begun to see a trend where the BA position can spawn from either business or IT. This is an interesting point as it speaks volumes to an organization’s maturity around project management. Imagine, for just a moment, an organization that has no boundaries within in its functions and everyone on the team collaborates toward a common goal. I like to call this organizational desegregation and cultural morphing. As we begin the next phase of benchmarking the project management industry and clients, we are beginning to see this shift as a representative of the next wave of advancing thought in the project management space. It was not too many years ago that I published an article on the emerging role of the project manager as the CEO of his/her project. I am confident that the BA role will take a firmly positioned spot in the upper hierarchy of any world class project organization within the next few years.

In order to succeed the BA will need to have a competency profile that meets the following criteria: 

  • Excellent understanding of both business and technology within the project environment. 
  • Be a leader, communicator and professional. 
  • Understand the skills associated with internal consulting techniques. 
  • Be proficient in project management skills as well as a complete understanding of the internal process. 
  • Epitomize the essence of a collaborator and team player. 
  • Understand and be able to navigate through the organization’s politics and structure. 
  • Be able to manage without having authority via negotiation. 
  • Understand true stewardship-based service.

So, the BA role probably looks a little different than a traditional structure may have dictated. Yet, this is the trend and, I believe, will become the norm. As organizations look to enhance productivity and quality while reducing cost, they are finding this role to be extremely important. Additionally, project managers we spoke to during the research for this article all stated that having a BA on the team made their job easier, and allowing them to focus on deliverable based activity.

It is important to note that this type of structure is recommended for mid- to large-size projects, but on the smaller initiatives we found that these attributes were part of the project manager’s role.


Phil Ventresca is Founder, CEO and President of Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Phil has utilized his extensive background in management and consulting to lead AMS to its current status as a multi-million dollar enterprise with an international customer base. Phil has led the organization to recognize several strategic breakthroughs such as developing partnerships with distance education providers, software developers and publishers. Through these efforts, AMS has emerged as a leader in consulting, training and assessment services. He has also founded three other businesses which remain under his direction, PTV Equity Management, WIT Group and AMS Aviation. For more information regarding this topic Phil can be contacted at [email protected].

Real Reuse for Requirements

A telecommunications company in a hotly competitive market needs to deliver the next generation of cell phone to its customers quickly, and at the lowest possible cost. The company wants to adopt a baseline set of requirements for the next generation project, but must make necessary modifications to leap ahead of the competition.

An automotive supplier must produce embedded software components consistently and reliably for its OEM clients. To do so, the supplier’s development process must account for the slight variations required by each manufacturer.

Requirements reuse provides organizations, like those illustrated in the scenarios above, with the unique ability to share a requirement across projects without absorbing unnecessary duplication of artifacts within a repository. This is a critical capability that accelerates time to market and cuts development costs. Shared requirements can either track to the ongoing change made by the author or they can remain static if the needs of the project dictate. Further, change to a shared requirement can be made by anyone and the system handles the branching and evolution of that requirement appropriately.

The concept of reuse is a familiar notion within the software development realm, but less common when considered in the field of requirements management. There are various definitions and use cases which must be taken into consideration when implementing a solution to address requirements reuse.

This whitepaper discusses the elements that make up a requirement and establishes common understanding of how requirements evolve, how that evolution is retained, and how organizations can reuse requirements to speed business innovation, reduce complexity and control costs.

Dissecting a Requirement

To understand the concept of requirements reuse, we must first look at the various parts of a requirement: data, metadata and relationships.

Data
Describes an object, and is relevant to the object itself. An example of data may be a summary or description of a requirement.

Metadata
This is data about the data, which aids in organizing or using the object within a process. It typically describes the current state of the object, and has the same scope as the data itself. For instance, metadata may describe the State/Stage within a requirement workflow (i.e., Approved, Rejected, Satisfied, and Tested).

Relationships
This characteristic of a requirement allows you to model: 

  • structure (i.e., Consists Of, Includes); 
  • history (i.e., Revision Of, Derived From); 
  • conceptual links or traces (i.e., Satisfies); 
  • references (i.e., Defined By, Decomposes To); 
  • security (i.e., Authorized By, Enables).

Any given requirement can have information in each of the data, metadata and relationships categories. When requirements are reused, any or all of the information can also be reused.

An organization’s chosen requirements management tool needs to have an underlying architecture and the user capabilities that support the strategic level of reuse dictated by the demands of the organization. Since reuse can occur at a number of different levels by leveraging the data, metadata and relationship elements of a requirement, flexibility is also critical to solving the reuse challenge.

History, Versions and Baselines

When implementing a complex reuse scenario, or even a system where requirements persist release after release, one must be able to identify significant points in that requirement’s evolution. In the development world, these significant points are called “versions.” This term may mean different things to different people, so we will begin with a definition of the term “version” as it applies to requirements reuse and show how it relates to similar terms like history, baselines and milestones.

Consider a system where requirements are captured within requirements documents but are stored as individual items within the repository.

History is the term used to describe the audit trail for an individual item or requirement. All changes made to the item, whether it is to data, metadata or its relationships are captured in its history. History answers to the who, when and what questions with respect to changes to that item.

Version represents a meaningful point in an individual item’s history. Not all changes to an item are significant and warrant a new version of the item. For example, the reassignment of a requirement from Nigel to Julia would not require a specific version identifier. The change is recorded to the item’s history, but a new version is not created.

Baseline is a very similar concept to version but has a much different scope. Individual items are often organized into groups or sets. In the requirements management domain these sets are called documents and a baseline is a meaningful point in a document’s history. Some organizations use a slightly different definition for baseline. Rather than being a snapshot in time for a given document, a baseline, as defined here in the context of requirements reuse, is a goal to work towards. For the purposes of this discussion we will call the goal-oriented baseline a milestone in order to distinguish between the two.

Requirements management claims to allow for the versioning of individual requirements. Many tools support versioning by way of cloning or copying the entire requirement. Even fewer solutions relate the copy to the original requirement.

Although related, versioning and reuse are not the same. The concepts of versioning are often confused with that of reuse. In the next section, we will explore various reuse scenarios to illustrate the differences (and the benefits) of versioning and reuse.

Reuse or Not Reuse? – The Many Flavors of Requirements Reuse

Requirements Reuse without Reuse – Share

The ability to share an item between projects, documents or other work efforts could be considered a form of reuse. Under this definition all of the projects that are sharing the item see, and can possibly even contribute to, the evolution of the item. The metadata on the item is shared as are all the relationships and the data.

This is not real reuse. I question whether to call this reuse at all, but it is included here for completeness.

Requirements Reuse without Heritage – Copy

As mentioned previously, copying an object from one place to another can also be considered a form of reuse. In fact, this is the form of reuse that Microsoft Word (or any other non-Requirements Management tool) supports. When an analyst opens a document, selects some content and performs a copy/paste gesture into another document, they are reusing that content for a new purpose. This form of reuse has no knowledge of heritage or “where did I come from” and of course changes in one document have no impact on changes in the other. In fact, changes are completely independent and one document has no knowledge that change occurred in the other, let alone what the change might have been.

This is also not real reuse. Any flavor of reuse must minimally include a pointer to where the original content came from.

Requirements Reuse with Heritage

Given the above scenarios, let us assume you can answer the “where did I come from” question. Augmenting the copy with the pointer back to its origin provides several options for reuse. It is the manner in which this link is leveraged that will differentiate each of the following reuse models. Most RM tools available today have some notion of links or relationships – if not at the individual requirement level, at the document level. Document level links are better than nothing, but they are not very powerful. In the long run, they don’t really answer the traceability question in sufficient detail to be meaningful.

Having a link to an item’s origin is the start of real reuse though it is certainly not the end.

Requirements Reuse with Change Notification

In this situation, a requirement and all related information (data, metadata and relationships), is reused in its entirety. Project state determines the state of the requirements at the time of reuse, and any change to requirements in a reuse scenario causes a ripple effect, flagging all artifacts related to those requirements as suspect.

Requirements Reuse with Change Control

Reuse with Change Control is similar to Reuse with Change Notification in that data, metadata and relationships are reused in their entirety. This seems, and in fact is, the same as the Share topic discussed above, however, there is one significant difference; the two projects sharing the same requirement only share it until the point in time where one project needs to change it. When the information changes a new version/branch is created and only items referencing that new version are declared suspect. All other projects or documents are unaffected.

Requirements Reuse with Annotations

In the two reuse paradigms above, the requirements and related information (data, metadata, and relationships) are reused in their entirety. In Reuse with Annotations, only some of the information belonging to a requirement is identified as a candidate for sharing and reuse. The rest of the information is specific to the project or document. The shared information is held in the repository while the other information belongs to the project or document reference. Each instance of the requirement being reused has its own metadata and relationships. The project or document state is, or can be, independent of the state of the requirements that are contained within it. New versions of the requirement are automatically created when the shared information in the repository is changed. These changes that trigger new revisions can suspect other references, as well as other items in the system, by the ripple effect of that change. For example, changes to requirements may affect test cases or functional specifications downstream.

Once you have project or document independence in terms of the metadata, you have the ability to model both a dynamic (share) and static (reuse) form of reuse at the same time. The project manager or analyst decides if they want to remain consistent with the evolving requirement in a dynamic way or if they want to lock the requirement down such that the impact of change does not affect their project.

Requirements Reuse with Annotations and Change Management

Applying change and configuration management paradigms onto the requirements management discipline in a single integrated and traceable solution can bring the power of reuse to a new level. By incorporating a process on top of reuse and controlling how and when requirements can be modified and reused enables you to reap these benefits without unnecessarily branching and versioning objects unless it is authorized and appropriate to do so. Requests for Change (RFCs) come in, get filtered and are directed by various review boards. Some of these RFCs get approved and assigned to users to affect the requested changes. Ideally, this change management process can define what types of changes can be made; whether it is modification, branching, applying a baseline or other gestures. Only when an approved RFC is associated with a requirement can an analyst modify the requirement, causing the system to version and branch accordingly, and notifying the related constituents appropriately.

There are clearly, additional reuse models that are not described herein – Component level reuse, documents reuse and various combinations of these with annotations and change management for example. This paper provides only a sampling. The business needs and strategic goals within the group, business unit or business as a whole will help determine which model is most effective for the project or organization.

Is Requirements Reuse Right For Your Organization?

Requirements reuse is not for everyone. There is a broad spectrum of need in terms of requirements management tooling in the market today, and organizations first need to know where they lie on the requirements maturity curve.

realreuse1.png

1 The requirements maturity curve is not really a curve at all but a measurement of the current process and tools used and/or needed within an organization when it comes to requirements management. As organizations evolve along the curve, the need for more capabilities – such as change management, process and workflow, traceability, reuse, etc. – within their requirements management framework exists. 

Many companies are still in the infancy of requirements management. They have not yet adopted a requirements management tool, and are currently using business productivity applications such as Microsoft Word or Microsoft Excel to capture and track requirements. They may look for capabilities such as ease of document import, rich text support, and downstream traceability to ease business adoption. These organizations are not yet at a point of requirements sophistication where reuse support is necessary – or maybe they are but have not found a tool to support their needs.

However, if an organization has progressed on the maturity curve with respect to requirements management, and is managing multiple projects and thousands of requirements in parallel and seeking to reduce complexity, lower cost of development, and shorten innovation cycles, then requirements reuse is a concept that should be investigated.

Let’s face it, regardless of where an organization falls on the curve, reuse in its most basic form will provide a boost to productivity. Rather than re-writing requirements, copy them and modify them for the needs of each project – you will save keystrokes as well as leverage the structure and organization these requirements were managed under in the past. After all, how many different ways can the requirements for logging in to an application be specified really? Ok, likely quite a number, but within any one organization the need to standardize and streamline application access exists and leveraging requirements from one application to another to provide this similar type of functionality can only be a good thing™ (Martha Stewart).

In any case, concentrate on the problem domain before jumping into the question “is requirements reuse right for me?” What challenges is the organization facing in terms of requirements management? Here is a list of sample questions an organization can ask to determine if reuse is a concept that could be leveraged and if it is, which flavor of reuse is best suited to the need. 


Doug Akers is a Product Manager at MKS Inc., (www.mks.com) the global application lifecycle management (ALM) technology leader, that enables software engineering and IT organizations to seamlessly manage their worldwide software development activities. through a single enterprise application, resulting in better global collaboration and higher roductivity. MKS supports customers worldwide with offices across North America, Europe and Asia. Doug Akers can be reached at [email protected]

The Art (or not) of Blamestorming

When times get tough, when people get stressed, and when they are faced with a crisis, it is interesting to observe how many people seem to suddenly become skilled in the Art of Blamestorming. Loosely defined Blamestorming is a meeting of like-minded people who enjoy sitting around in meetings, deciding who or what they are going to blame for their current plight.

How many good Blamestorming sessions have you had in your own organization recently? You probably know some people who are highly skilled at Blamestorming. Some people are so proficient that they do not even need an organized meeting in order to practice their art. They do it at the water cooler, in the elevator, on the phone and some are even skilled enough to record it on paper or send out by email.

In our current economic climate it is not difficult to become a skilled Blamestormer as there are so many easy targets to pick from; Wall Street; The Government; Over Spending Home Owners; Greedy CEOs; Oil Prices and the like.

Unfortunately though, Blamestormers tend to lead their organizations on a vicious downward spiral of panic, falling morale, resignations, lack of focus on solutions and a lack of vision for the future because they are too focused on finding someone or something to blame for the past.

What organizations need now more than ever are not people who are looking to place blame, but for leaders who are prepared to step forward and take some responsibility. To take responsibility for how we got here, what needs to be done about it, what does the future look like, and how are we going to execute a plan to get there. 

Good leadership is always about responsibility and never about blame. Of course there are always things that occur that are beyond your control and yes they can affect your current situation. Strong leaders though will instinctively know that sitting around discussing who is at fault will achieve very little.

Instead they will ask themselves some of the following questions: 

  • Did we really have a contingency plan in place for recessionary times?
  • Have we created a culture of innovation so that we can look at new ways to grow?
  • Have we created an agile organization that can adapt quickly to changing needs?
  • Have we built a loyal engaged workforce who have faith in their leadership and will stay with us?

In the days ahead, organizations that have developed strong leadership will be thinking about how to learn from the past, be innovative today, and provide inspiration for tomorrow so that they emerge stronger, leaner and well prepared when the upsurge occurs. They will not be wasting time with the Art of Blamestorming.


Bryn Meredith is a principle of Bluepoint Leadership Development.  He has extensive experience as a business leader, entrepreneur and leadership development specialist. Bryn can be reached at [email protected]

Enterprise View of the Business Analyst Role

BAs Tend to Have a Narrow Focus on Project Related Work

All too often, the BA is unable to focus upon the right areas during a project due to a lack of enterprise analysis prior to the project. Because of this lack, the BA is forced to do requirements elicitation at too many levels at once rather than having focused requirements analysis at the business level leading to requirements elicitation and subsequent analysis at the functional level. This leads to several dangers.

Danger #1

The BA is put behind the curve from the beginning of the project.

If there has not been sufficient elicitation and analysis effort at the business level before the project, the BA is trying to define the business level requirements while simultaneously building the functional and system level requirements that will deliver/support those business requirements. Most of us have been in projects like this and we know that the pain level is high. 

Danger #2

The BA is very likely to make discoveries during the project that should radically redefine the project; however, promises have been made and no one wants to explain why this was not anticipated. This leads to projects that deliver what they promised but are perceived as unsuccessful because expectations have changed during the project. One solution is to manage expectations; another is a better use of the change control process.

A Wider and More Appropriate Focus

The Business Analyst’s Body of Knowledge (BABOK) v1.6 has a visual in section 1.6.1 (shown below) that shows the relationship between the knowledge areas. I find the picture is effective in conveying a message that the real role of the business analyst is in project related requirements activities.

enterpriseview-1.png

One way to look at the BA role is to view Enterprise Analysis as encompassing the other BA activities shown in the BABOK. If you take that view, then the BA has a much clearer set of duties and activities before, during and after any project activity.

Using Enterprise Analysis as the Driver

The following graphic allows us to look at the BA’s role more holistically.

enterpriseview-2.png

If we look at the role of the business analyst as primarily enterprise focused, we can use distinct phases leading from opportunity identification to solution definition to development to implementation and finally to the analysis of new threats/opportunities surfaced from the solution’s existence. This allows greater clarity in the business analyst’s role and deliverables.

Strategic Phase (the first column in the picture) 

enterpriseview-3.png

Clearly there is (or should be) a phase where the business analyst  is working with business management to create and maintain the business architecture, identify opportunities to pursue, and develop a portfolio or projects from which business management selects those most beneficial to the long-term goals of the organization. These deliverables are listed in the BABOK as associated with Enterprise Analysis (EA).

The BA is definitely using all the project management fundamentals here, but the objective is not to produce a specific new application or process. The focus here is to act as a consultant/support arm to the business management so that opportunities can be identified, explored and selected or deselected. I find that most of my clients have too many projects going at once. In addition, many of these projects have conflicting goals and measurements. We, the BAs, have an opportunity at this stage to establish our credentials as a business partner by helping the business management define a portfolio in which projects are prioritized and staged to maximize business benefit. This would also have additional benefits to organizations such as HR and IT that are stretched too thin under the current approach. 

This strategic phase is where the BA has the opportunity to elicit and analyze the business requirements so that the portfolio decisions can be made as to which projects are worth pursuing. In addition, the BA has the opportunity to include parties who will be affected by any projects initiated from this phase. This would include, but not be limited to, groups such as project management, quality assurance, and training

The BA at this point should be producing a set of deliverables some of which are listed below.  We use the balance as the symbol in the list to reiterate that each is a narrowing of focus and more detailed analysis of a subset of the deliverable which preceded it.  These deliverables include:

  • A set of opportunities from which management decides those to be pursued,
  • For those selected opportunities, the BA develops alternative solutions with associated trade-offs. Management decides which alternatives to pursue, if any.
  • For selected alternatives, the BA would be doing a detailed analysis that will be the business case for projects to be done. This will include the business level requirements that will be addressed by specific projects.

Project Phase (middle column) 

enterpriseview-4.png

This phase has received the most attention in the general literature and this is not meant to be a complete coverage of the phase. The intent here is to show how the usage of the strategic and operational phases improves the project phase.

The strategic phase leads to project work. In the project phase, a set of selected business requirements should be used as the base to initiate the requirements effort at the next lower levels.  A key point that I am trying to emphasize in this document, however, is that the likelihood of this phase being successful is substantially improved if the business analyst has had the opportunity to produce those products identified in the strategic phase.

Similar to the strategic phase, the BA’s deliverables during the project tend to build upon each other. These include, but are not limited to:

  1. Testing/Acceptance criteria for the business requirements being addressed by this project.
  2. Functional and non-functional requirements that need to be accomplished to support the business requirements.
  3. Trade-offs between different approaches for project delivery
  4. Test strategies that will be used during the project to demonstrate that requirements have been delivered.

Frequently, there has not been sufficient work done in the strategic phase (i.e. the EA work has not been done). If so, the business analyst must retro-fit that work into the project. This puts us right into Dangers 1 & 2, identified earlier. Since we have already launched the project and committed to a delivery/completion date, the business analyst doesn’t have the time needed to produce those work products with enough rigor. Worse yet, the project manager who has been driving the planning and execution efforts based upon the approved project scope will be frustrated when/if the business analyst’s detailed work shows that the project should be redefined.

Operational Phase 

enterpriseview-5.png

In any case, a solution is eventually delivered. Once any solution is in place, the BA enters a new analytic phase. The solution, by its simple existence, opens up new ideas. Once people are dealing with the solution, they start thinking about what could be. This will include high level and low level ideas.

High-level

These will be a mixture of threats and opportunities that the BA should identify by working with all levels of the organization. These ideas can be brought to the attention of senior management and becoming input to the strategic phase.

Low-level

No solution is ever complete or perfect. The BA, working with the solution users and customers, can identify a set of improvements, fixes and general changes that will allow the next version of the solution.

Closing the Loop

The BA needs to be looking at a lifecycle which starts before and lives after the project. We can better acknowledge this by adding the strategic and operational phases to the view of our work. It also institutes a feedback loop to that life cycle which will allow us to establish and build upon the role of BA as a consultant/business partner.


John Slack is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. John has over 30 years of experience in business development, project management, business analysis, and professional development. For the past decade he has focused his time on a mixture of active project management and analysis of business operations as well as the development of training for project management and business analysis. His projects have ranged from the retail to high tech sectors including the planning and rollout of business strategy for companies such as Digital Equipment Corp and Intel, to the development and rollout of software applications for companies such as DirectTV, Motorola and American Airlines. 02/09