I’ve been getting questions about the upcoming changes to the PMI Professional in Business Analysis (PMI-PBA)® exam. This is understandable, since PMI has announced an exam change for June 25, 2018 to harmonize the exam with The PMI Guide to Business Analysis released in 2017. Exam Changes For 2018, the only change to the PMI-PBA exam is a minor lexicon update to harmonize the terminology between the terms used in the exam questions with The PMI Guide to Business Analysis. This simply means that some questions might be reworded to better to reflect the terms used in the guide. The good news is if you are studying for the exam, the change is not significant, and you now have one more resource to use as a study tool. If you have taken the exam and did not pass on your first try, this new resource may explain business analysis is a style which…
I was fortunate to attend and present at the Building Business Capability Conference (BBC) last month in Orlando, Florida. Just like every past year, the best part of the conference for me is getting together with old friends and meeting new business analysis professionals who are enthusiastic about improving their organizations. This conference has continued to grow every year with many new categories of track sessions. I attended some great sessions from the Fast Forward track, topics like robotics, artificial intelligence, and ideas for new organizational structures for the changing world. I also enjoyed modeling, elicitation, and analysis sessions picking up tips on improving basic business analysis tasks.
What to expect for the Needs Assessment, Planning, Analysis, Traceability, and Monitoring, and Evaluation Domains. This article is a compilation of a series of blog posts, found on Converging 360, written by Barbara Carkenord throughout the writing of the publication PMI-PBA Exam Prep Guide.
Maybe we cannot have just one model or standard set of definitions for all types of projects. As the project management discipline matures, we have discovered that different types of projects require different management. This whitepaper recommends that scoping should be tailored to the type of project and product being undertaken, rather than trying to design a standard scope statement or statement of work (SOW) for all projects.
Who uses Business Analysis Skills and what is Business Analysis? IIBA® (International Institute of Business Analysis)™ defines the discipline of business analysis as “the practice of enabling change in an enterprise by defining business needs and recommending solutions that deliver value to stakeholders.” The definition describes work which could be performed by almost any employee in an organization. Anytime an employee puts an idea in the suggestion box, it is possible they analyzed a need and are recommending a solution.
Analyze Why You Procrastinate
I generally don’t procrastinate― in fact, I often do things too early and end up reworking a bit when circumstances change. But when I do procrastinate, I become very frustrated with myself for letting something go that could have been done earlier under less time pressure. So why do we procrastinate? I have analyzed my delays and usually find when I dread doing a task (like paying bills or preparing taxes), I procrastinate. People also procrastinate when they are unsure about how to do a particular task. It is okay to procrastinate as long as you know why you delaying and have performed risk analysis.
BAs love Requirements Management Tools!
I love requirements management tools and wish all business analysts had access to them. Requirements management tools allow you to create requirements in a structured, organized fashion, consistent with other projects which leads to better stakeholder communication, better analysis and better products. More importantly, being able to reuse requirements increases productivity significantly. Unfortunately few analysts have access to these tools. They are expensive, fairly complex to learn, and don’t always easily integrate with other tools used in an organization. But that may be changing! DevOps is gaining acceptance and requires software development technology including requirements management tools which are integrated with other application life cycle management (ALM) tools because requirements are a critical part of the DevOps process.
I was recently asked by one of our customers to facilitate a requirements elicitation session on a change to an existing system. The software functionality is fairly simple so the group scheduled an hour session and just wanted an experienced facilitator to help lead the discussion. The session was already scheduled when I was asked to participate so I didn’t have much time to prepare but I did talk with a few of the stakeholders to get some background before the session. One of the business people wrote up a current state description which was very helpful in outlining the discussion. As I did some last minute preparations the night before and discussed the session with a colleague we realized that the customer had not really articulated why they had initiated this project.
The most difficult part of discovering and analyzing requirements on agile teams is determining how much detail is needed and when we should discuss the details. Early advocates of agile approaches, like SCRUM, emphasized a high level product vision at the beginning of development and then quick, lightweight user stories to support the vision detailed before each sprint. They suggested that we don’t need to get into any details until sprint planning. But as more and more teams are attempting to use agile approaches, the challenges of this requirements approach are exposed.