Filters:

  • Technologies

  • Instructors

  • Business Analysis Tools as found in PMI PBA Business Analysis and the IIBA CBAP


    For more PMI-PBA Business Analysis Certification Training see our 5-day course available both in classroom and online with virtual instructor-led training.

    PMI-PBA: Business Analysis for Project Managers and IT Analysts (PMI-PBA Certification)

    For more PMI-PBA Videos see:


    By Steve Fullmer (PMI-PBA and PMP Instructor)

    In this video, PMP and Business Analysis Instructor Steve Fulmer presents the toolsets that are available to Business Analysis as found in PMI’s Professional Business Analyst Certification (PMI-PBA) and the IIBA Business Analyst Body of Knowledge (BABOK), the Certified Business courses.

    Video Transcription.

    Tools are tools. We’re getting a little bit of a preview of the kind of content you’re going to see in the class, if you attend our PMI‑PBA Business Analysis for Professionals, Project Managers, interested parties.

    One of the things that I think is important to help people understand is that tools are tools. The tools of business analysis, whether you want to learn from IIBA, through the Business Analyst Body of Knowledge (BABOK), the Certified Business Analyst practice areas, there are 6 of them.

    CBAP Practice Areas:

    • Business Analysis Planning and Monitoring
    • Elicitation and Collaboration
    • Requirements Lifecycle Management
    • Strategy Analysis
    • Requirements Analysis and Design Definition
    • Solution Evaluation

    I hate to say they’re silo‑centric. It’s more situational, I think would be a better term. These are sets of tools that help apply to meet different needs or characteristics of the Business Analyst profession.

    There are 6 practice areas, from planning business analysis to eliciting requirements, collaboration amongst your various stakeholders, your technical and functional personnel versus your customers, your sponsors, process oriented personnel, actors, personas, all kinds of terminology associated with the people that are affecting all of your business practices, not just project related ones.

    Identifying requirements and making decision for which requirements is certainly part of Project Management, but it’s a bigger set of tools when we talk about the business analysis arena than it is just under Project Management.

    PMI-PBA Practices (Domains):

    • Needs Assessment
    • Business Analysis Planning
    • Requirements Elicitation and Analysis
    • Traceability and Monitoring
    • Solution Evaluation

    If we take a look at it simply from a Project Management Institute (PMI) perspective, this is the focus of the course. PMI refers to the practice’s domains, and there are 5 instead of 6. The difference is, as I suggested in a separate video (The Difference between PMI-PBA Business Analysis Certification and IIBA CBAP Certification), is there tends to be a sequential approach to helping you identify which tools you might use. It’s just a different way to look at tool selection, tool application.

    You may also like:  Planned Value – A simple explanation for an Earned Value concept

    As an example, we identify whether a business has a need. Not all needs turn into projects; some of them can simply be operational changes, operational improvements. Yes, we can affect those through projects, but sometimes they’re not of such a large scale that demands that.

    An example that a Business Analysis might suggest is the concept of “Just in Time.” A customer needs something as quick as you can get it to them, so you’re going to figure out what solution tools you have today to affect the solution that you hand to your customer just in time, like it as fast as possible.

    That doesn’t lend itself to the more formal processes that might be used for a Predictive Lifecycle, or an Adaptive Lifecycle, which includes the concepts of Agile methodologies or programming.

    We have lots of ways to identify needs, some of which turn into projects, but we don’t need to do customized business analysis planning.

    That’s the role of identifying what the business analysis deliverables need to be. Does the Business Analyst need their own communication management plan, or do they simply supplement a project communication plan that would be inside of a Project Management Plan, and who owns which?

    In a Project Management Communication Plan, we’re identifying how we’re communicating with the stakeholders as we go through the temporary unique aspects of a project. How do we make sure that stakeholder needs are met?

    In PMP Project Management Fundamentals and Professional Certification, you learn about the interest/influence, or interest power grid, depending on which version of the Project Management Body of Knowledge (PMBOK) you learned that from.

    That’s how do we interact with people during the project, but a Business Analyst has to be concerned with more communication than just the Project Stakeholders. A Project Management Communication Plan is about the project, but a business analyst communication plan is about how the stakeholders communicate with each other all the time, potentially independent of projects.

    If that’s a concern that you’ve got as a Business Analyst, either during the support of a project, or independent of projects, it’s a different approach. Do you need one, or don’t you?

    As you go through Business Analysis Planning, you’re identifying which of the different deliverables, the different tool sets, you might need, but that’s based upon the needs assessment of the customer. Is this a long term predictive type of approach? Is this a purely operational approach? Is this an Agile, let’s see, if we can go through this intuitively or cyclic, in order to try get the solution that we need?

    You may also like:  PMP: Change – The Purpose for Projects November, 4, 2014 Video and Presentation Files

    It’s the environment and the needs that you identify during needs analysis that help us identify what business analysis deliverables we have, which in turn drive the requirements and elicitation we might use, which in turn drive the traceability and the monitoring of the requirements.

    Quite often, we have projects that moves so quickly, we don’t have the ability to take the great detail necessary to do thorough traceability of each of our requirements, so we look at those requirements that are high priority or maybe regulatory in nature.

    It’s simply a different focus in terms of how we gather, track and trace requirements in the bigger scheme than rather just a single project. But it is sequential in nature. This is the big difference, I believe, and why I like the idea of providing the PMI‑PBA approach. It gives you a logical approach.

    You’re not going to use Agile and adaptive methodologies, unless your approach suggests the need you got are iterative or adaptive in nature.

    You’re going to use more specific tools, so we follow this logical approach that says, if we use this kind of, essentially, needs assessment, we’re more likely to use a particular kind of business analysis plan and a different kinds of requirement elicitation.

    It’s really about the business analysts thinking and strategizing, regularly and repeatedly. It’s figuring out the best approach to take, while others are trying to scurry off as fast as they can to make specific activities, deliverables, or overall projects meet the multiple needs inside of a business.

    I look forward to seeing you in the classroom or online.

    Steven Fullmer
    Interface Technical Training Staff Instructor

    Steve teaches PMI-PBA: Business Analysis Certification,  PMP: Project Management Fundamentals and Professional Certification, Windows 10, and CompTIA classes in Phoenix, Arizona.

     

     

    Share your thoughts...

    Please fill out the comment form below to post a reply.