Business analysts apply knowledge from the BABOK and other resources to improve their performance against their goals. In this section, we explore each knowledge area and learn how to improve.
Right, I might be branded a heretic, but I’m going to say it. Organizations that deliver every project that they kick off (with the project’s scope intact) are either extremely lucky, extremely risk averse, or extremely misguided. This sounds like a contrarian view, and may even sound a little controversial. In fact, you might (quite [...]
The agile movement promotes positive change when it encourages teams to work together to create products that are fit for purpose with as little non-value-added activities as possible. Agile approaches embrace mechanisms for continuous improvement, and include practices that can be traced to Lean thinking, a management philosophy that aims to identify what creates value [...]
Verification ensures the intrinsic quality of the requirements. Although it would be a significant waste of time outside academic circles, I could verify requirements for a solution that had zero business value and that my organization had no intention of funding. They’d be verified but not validated (and we’ll get to validated next). The purpose [...]
While we’ve already talked about the importance of Preparing for Elicitation and Conducting Elicitation Activities, it’s not enough to stop there. The next two (and IMHO, critical) tasks in the Elicitation Knowledge area are Document Elicitation Results and Confirm Elicitation Results. The purpose of Document Elicitation Results is to: Record the information provided by stakeholders for [...]
When I first started my consulting business just over 3 years ago, I intended to focus solely on understanding the capabilities of legacy systems. Unearthing requirements had become a bit of a pet passion of mine and I realized that in every BA role I’d had in years prior, I was always trying to find [...]
The User Story: simple and elegant. “As a ______, I want to _________, so that I can __________.” Why must a user story only be used for Agile projects? I was at a seminar recently where the speaker kept talking about user stories only in the context of an agile project. Is there a thought [...]
If you know even a little about Agile, you’ll have heard of the idea of using index cards for managing requirements. It might seem like a trivial concept, but I’ve had some unexpected successes with index cards recently, so I thought I’d share them with you. The concept Here’s the concept. Now, brace yourselves, because [...]
Again, like we did in Assess the Proposed Solution, we are finding ourselves in the midst of the solution world in a very defined way. Allocating Requirements is a task that is done by someone, and if it’s not done by the BA, we might be missing an opportunity to create more value for our [...]
If I had a dollar for every time I heard a vendor say, “I know the perfect solution, and I just happen to sell it!” I’d be a retired BA. Instead, I’m a practising BA and one of my responsibilities is to help businesses understand that not all vendors are all-seeing and all-knowing. Nik Gebhard [...]
There is a distinction between the project requirements and the requirements package. Requirements can be organized, sliced and diced, torn apart, allocated, put back together, assigned attributes, etc. Packages are finely wrapped presentations of requirements in ways that suit a specific stakeholder audience. Very often we conflate the two, or start with the package before [...]