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.
I love the end of the year articles about the top ten movies of the year, or top ten books, and also the New Year predictions like “12 trends to watch in 2017”. Every year during the holidays, I find myself reading these top ten lists and predictions but this year I began thinking about why they are enjoyable, and whether or not they are a good use of my time. As the leader of a book club, the top ten books of the year lists are a great source of ideas for my group so my time reviewing them is useful. But what about from a work and career perspective; should I be spending time reading about the top ten training trends from 2016?
I came across a new phrase last week, which I really like: “aggressive transparency”. I saw this phrase in the Project Management Institute, Inc. exposure draft of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. It is used in the Project Stakeholder Management chapter referring to the fact that agile approaches strive to be very transparent so that stakeholders always are aware of project progress. I liked the phrase and searched on it to see if I could find where it originated.
We teach prioritization techniques in many of our classes and many of the conversations we have at conferences and meetings are about how challenging it can be to get a group of people to agree on project priorities or even individual aspects of a product. As I was working on my 2017 strategic plan, I decided to write a short post on prioritization and metrics.
As a program manager at RMC Learning Solutions I have to prioritize projects and make recommendations to my management. We have many ideas for new courses, products, and services which are competing for our time. Prioritizing requires us to assess the expected value of an idea against its expected cost and then compare it to other ideas.
I’m going to the BBC Conference (Building Business Capability) next week and am really looking forward to the sessions, the exhibit hall, and networking with other professionals. I realize that I am fortunate to be able to attend several conferences each year, but I know many people are lucky if they get to go to one. If you are going the BBC or another conference, make the most of it. Here are some tips for preparing to attend a conference which will help you get the most value.
This is the fifth and final post in a series about the PMI-PBA® certification. The last exam area is the Evaluation domain and includes the work necessary to make sure the solution is ready for the stakeholders, and that it delivers the value expected. This is the last domain in the PMI-PBA exam content outline which includes Needs Assessment, Planning, Analysis, and Traceability and Monitoring. Solution evaluation is where all of the work of the project comes together. Business analysis work in this domain assures that the solution is ready for use in the business area. To make sure it is ready, it must be thoroughly tested, the end users must be ready to use it, and the organization must be prepared for its impacts. Business analysts are important team members in this work.
This is the fourth post in a series about the PMI-PBA certification. The Traceability and Monitoring domain follows the Analysis domain and includes much of the business analysis work that is traditionally called Requirements Management.
Paying attention to the details is good business analysis
How many little mistakes do you see?
I open the newspaper in the morning and see a typo. I open my email and see a grammatical error. I go to a web site and a menu button doesn’t work. How many “little mistakes” do you see in a day? Corporations are pushing employees to work faster and get products to market sooner. Is this agile or is this sloppy? Many companies sacrifice analysis and attention to detail to increase revenue but it won’t pay off in the long run.