How do you know when you are \"done\" with requirements? A critical touchstone is when all your stakeholders are aligned around the problem and the go-forward solution. Is everyone \"on the same page\". Are we all marching in the same direction? Great BAs root out disagreements and surface them so stakeholders can become aligned.
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 [...]
As a BA, joining a project that has been in force for some time can be challenging. There are normally a whole host of previous decisions that have been made, and it’s likely that key members of the project team will have already formed a working relationship with each other. You might not know the [...]
Just by nature of our work and our title “Business Analyst,” quite often the BA is put in a situation where they must influence others without being given the proper authority to do so. The PM is given the “Manager” title; everybody knows they are in charge. The BA is given the “Analyst” title which [...]
Oftentimes a business analyst gets involved in a project with multiple different business stakeholders with competing views. Before jumping into the analysis of the project or even defining scope, it can be helpful to pull together all the competing requests and categorize them. This activity can help shed light on the nature of the requests. [...]
Please indulge this second diversion into the world of Robert Pirsig’s Zen and the Art of Motorcycle Maintenance. Although this book really has nothing to do with business analysis, it has everything to do with how we approach technology and as I read it I keep seeing our profession in a new light. In the [...]
A few weeks ago, I posted about how to validate requirements without a formal, tedious, requirements walk-through. Alex Papworth followed up with an interesting comment and question: There is a point when you need commitment or signoff from stakeholders. This is necessary when estimates are provided and requirements need to be frozen (not talking Agile [...]
A few months ago I posted about how requirements walk-throughs are a necessity in any good requirements development process. I’m here today to tell you I’ve changed my opinion. It’s not that walk-throughs lack value. They definitely do. But the timing, scope, and methods of these reviews might need to be reconsidered. A structured requirements [...]
So when you reach that point of the project where your head simply hurts from how hard you are thinking, you’ve spent hours in meetings rehashing the same concepts, and yet you and your team members are not communicating effectively either about the problem or the solution, you most likely need to take a step [...]
During a documentation review, oftentimes no one wants to be the first to challenge something or point out a mistake. When reviews are passing along with a false sense of “wow, this is perfect!” I like to mix things up by pointing out an error in my own work or raising an issue with something [...]
You can logically argue that software requirements save time, save money, and increase the return on your technology investment. I believe all these things to be true, not because I’ve done any quantitative study, but because I’ve directly experienced it in my day-to-day work. But I’d like to focus on what brought me to the [...]