Too busy to crawl the web for interesting Business Analysis content? Not interested by social networks noise? The Busy BA Reading List brings you the best Business Analysis articles and websites I came across while surfing the Internet.
Welcome back! My publishing rate is going down these days (thanks to the girls’ first year at school), but don’t worry, I’m still reading a lot about Business Analysis. In this edition, you’ll learn how to prevent mistakes when working with requirements (even if it’s a good idea to fail sometimes), what requirements statuses can teach you, and much more. Start your week with a refreshing dose of knowledge, continue reading!
From Eric the Business Analyst
This blog posts was published since the last edition of the Busy BA Reading List:
Worst requirements mistakes
Listing requirements is easy; eliciting and managing them is not. In one of his latest posts, Ulf Eriksson identifies the biggest mistakes people commit when they are working with requirements. Working without a strategy and a plan seems obvious, but most BAs tend to overlook these and start the work right away, which usually lend to poor and/or missed requirements.
Not using the right tools also seems obvious, but in order to perform a good business analysis job and to provide useful artifacts to your team, you need to use the best tools adapted to each situation (like this, this or this). And thinking that your job is over once your requirements are delivered can also bring you bad surprises; one of the coolest part of the BA job usually starts there (more on this in a future post). Of course, someone who read the BABoK would never commit such mistakes 🙂
Bad ideas are good for you
Mistakes and failures are essential to learning (link unavailable anymore); without them, one would not be able to figure out what’s working and what’s not. Following this logic, Duncan Watts explains why having bad ideas and sharing them is critical to your personal and professional growth.
Considering that a few years ago, my master thesis led me to no conclusive result (other than concluding that my model failed to explain something), I think I’m a good example of this theory!
Following project progression with requirements statuses
I often struggle to find meaningful statuses for my requirements lists, and I usually follow my inspiration, leading to poor consistency for my stakeholders. This should not be the case anymore after reading Joy Beatty & Karl Wiegers thoughts on this, as they provide a clear and consise list of requirements statuses, along with their meaning.
As a bonus, you’ll learn in this article how tracking your requirements statuses over time will help you follow your project progression more easily than with a simple percentage; the last time you have to report that the job is “90% done” week after week is near.
System design is not complicated, it’s just performed by the wrong people
I often describe my role as a Business Analyst by explaining that anyone can elicit and manage requirements, but that not everyone is good at it (ie doing the job vs. doing it well). Tim Bryce makes an excellent work describing this reality in one of his latest post at ModernAnalyst.com:
As I keep insisting, it is not that system design projects are complicated, it’s because we have the wrong people trying to perform the task.
Do you like what you’re reading?
Image credits: hbrinkman @ freeimages.com