Posts tagged ‘Requirements Management’
When are you done with Stakeholder Requirements?
Business Analysis is part science and part art. Unfortunately, one of the aspects of it relating to art is how to decide when you are done. There is no hard-fast rule that you should have X requirements for every Y stakeholders. But there are a few techniques that you can use to evaluate your progress and increase your confidence in having a complete set of Stakeholder requirements.
1. IPO – Inputs, Processes, Outputs
When I suspect that I’m nearing the completion of my requirements gathering, I take a few minutes to walk through my process models (if I have any) and compare them to my requirements. I evaluate whether all potential inputs have been satisfactorily documented in my requirements. Then I review the business processes and whether each one seems to be completely defined, whether through requirements or assumptions. Finally I evaluate my outputs. Does every process have a clear owner of an output at the end?
2. CRUD – Create, Read, Update, Delete
I inherited this method from working with far too many Data Analysts in my career. Whenever I have a requirement that involves the need for new information, I consider CRUD. Do my users need the ability to just Create this information or do they also need the ability to Update, Read, or Delete it? What about the variety of users based on their authentication levels? I don’t suggest getting into the details that would lead you into Functional Requirements but you can make sure that you have all business user perspectives captured with this technique.
3. Industry Models
Many industries have models published that outline the business processes required in their field. Many consulting firms or associations publish these documents. I would encourage any Business Analyst to use every resource available to them to try to find out if one exists. If you can’t find one – BUILD ONE! While working as a Business Analyst for a Product Development team, my peers & I built a Spoke & Hub model. We evaluated that every product launched (Hub) meant that we should consider a static list of business areas (Spokes). This was very helpful for all of us and improved the consistency and completeness of our requirements.
Hopefully these ideas sparked your thought processes! I’d love to hear what techniques you use for evaluating for completeness of your Stakeholder Requirements. Post a comment and let me know what you’ve tried!
More Than 1 Answer to a Question
In a recent requirements gathering session that I was having with some stakeholders, I was struck by a simple rule that I am going to adopt as a BA. When a question is asked, by myself or a stakeholder, I’m going to seek out more than one answer.
Think of it like this – someone asks a question to a group, and almost immediately, a confident sounding person responds with a logical answer. What does the group usually do? Nod their heads, and then move onto the next topic. But wait…. that was a response from one person with one perspective! When you are eliciting requirements from a group of stakeholders, every person in that session brings to the table a wealth of information from past experiences, existing work experience, book knowledge, etc. And we all know that there is usually more than one way to do things so why would I, as the BA leading the meeting, be satisfied with a single answer.
There is way too much risk to allowing the meeting to go forward with this one response. What if someone in the room figures their input isn’t needed since someone else already spoke up, yet we miss valuable information because of their silence? What if another person just figures the question is answered and they might get out of the meeting early if they just nod their head in agreement though they know of another potential answer. Too much risk!
So here’s my plan. When someone asks a question, I’ll ask the group for thoughts in response. When Person A provides their response to the question, I’m going to accept their response. Then I’m going to ask, are there any other logical answers based on other scenarios? Are there logical answers based on other perspectives – perhaps from someone in a different role or department? If I still get silence, so be it – I tried. But there is a chance, that I’ll get additional input and that will be worth while the extra 90 seconds to ask the question.
Let me know what you think! How do you gain input from others in your meetings? Do you have any tricks for soliciting input from others?
Making the Most of Your Meeting Time
Most people who know me well know that one of my strengths is time management. I prioritize everything I do against my objectives and value every minute of every day. So I’m constantly looking for tools to help improve my efficiency in the activities that take up the most of my precious 24 hours. And if you look at my calendar – meetings are the evil that consume the majority of my time.
If meetings are going to consume that much of my time, it is best that they are efficient not just for my sake, but also for the sake of others participating with me. Here are a few tips that I have developed over time.
1. Clear purpose – if you cannot define the purpose – the “verb” that should come as a result of your meeting – CANCEL IT. And let’s be clear – “discuss” is not a verb. The verb should be actionable.
Here’s an example:
Purpose: Discuss the options around the configuration of the widget
Better example:
Purpose: Determine the widget configuration that best meets our needs and constraints.
It is actionable – it tells your stakeholders that they should come to the meeting prepared because a decision will be made. If you cannot clearly statement an actionable purpose for your meeting, if it is yet another “status” meeting – then you should look for another way to satisfy your need or look to another meeting to combine purposes with the same stakeholders.
2. Interaction – I cannot stand meeting wall flowers. If you are taking up space in the meeting, then you need to participate. When I host a meeting, I’m looking for everyone to participate. If someone is there to “just observe”, they need to excuse themselves to go get other work done. As a meeting host, I’m going to try to elicit information & interaction out of everyone so our meeting is fulfilling to everyone.
3. Questions - I do not call meetings just to hear myself speak. Actually in a lot of my meetings, I hope that I am facilitating active dialogue – not providing it. If I feel a lull coming over my group, I am going to ask questions – even ones with obvious answers – just to get the group talking.
4. Preparation – this tip cannot be under-valued. If I am hosting or participating, I am going to come prepared (okay, I’m not perfect but I’m going to TRY to come prepared). I usually have a good feel for who is attending the meeting, what I am looking for out of the meeting, and a few pre-thought topics that I want to discuss. This also helps with tip #3.
5. Touching Base – I picked this idea up just last week. I was sitting in a meeting and at the end of the allocated time, the host asked if anyone had any questions. Good thing they didn’t, because they stood between a hungry group of stakeholders and the door. I am going to try to start asking that question throughout my meeting instead of the end. It’s very natural to ask at the end – and should be asked at the end but I am going to encourage questions throughout the meeting going forward.
6. Meeting Notes – Yes, I dread typing up my 5 pages of notes but I do not provide a word-for-word playback of what occurred in the meeting. However if you need this - check out my post on the LiveScribe pen. Depending on the meeting, I provide a select set of information. At a minimum, I provide Attendees, Topics discussed, Action Items taken.
For a requirements session (in my BA role), I add in Requirements Captured. I have recently also added Terms Identified (also used in my Requirements Specification) and Test Scenarios Identified (bonus as I don’t always have a QA resource engaged during the Requirements phase of my projects). My theory with this information is that it should help in facilitating a faster requirements approval step on my projects. Time will tell…..
7. Decline – Yes, I decline meetings. If I do not think that I will add value, I say no. I also say no if it does not align to my objectives to participate (often I suggest rescheduling if needed) or I delegate if someone on my team is empowered to attend (as a decision maker – not a note taker).
There are only 24 hours in a day and for most professionals, meetings consume a significant amount of this time. Some of the strongest professionals I have observed have found ways to make the most of their time.
What techniques do you use to make your meetings most effective for you and/or your meeting participants?
Putting a Bow on It
The BABOK tells us all that we need to know to be a good Business Analyst. But what makes a person a GREAT BA? I call it “putting a bow on it”. Here are some tips that set the good apart from the GREAT!
- When you start a new project, setup an introductory meeting with your sponsor & IT Project Manager. 30 minutes to get to know each other, gain insights on objectives, risks or issues, etc. Starting on a solid foundation, you are more likely to lean on each other when times get tough on the project.
- Reach out to others playing a role on the project as they engage or prior to their engagement. Find out what you can do (as the BA) to help make their lives easier. QA, Data Analysts, and Trainers LOVE this!
- Don’t just start inviting people to meetings. Let them know the project is starting, what they can do to learn about the effort (assuming a kick-off hasn’t been held), and ask them if they know of any conflicts during your tentative timeframe for eliciting requirements.
- Once you have scheduled your interviews, elicitation sessions, JAD sessions, etc – publish a schedule to your IT Project Manager and sponsor so they have a single list of sessions, participants, durations, locations, etc.
- Provide your stakeholders a summary of all sessions held once per week with the HIGHS & LOWS. What were some of the recurring questions/areas that came up consistently? Where there any significant “ah ha” moments that they might find useful? Are you on track with your session schedule or might you need to schedule a follow-up or slip a meeting or two? You might be able to partner with the IT Project Manager to publish this note in conjunction with them.
- Send out your deliverables along the way – don’t just assume that everything has to be sent in a final presentation mode. Let them know that you have a draft set of use cases, a work-in-progress process model, etc. They might enjoy the chance to review it – or wait until the end – their choice, but at least they have a choice.
- Offer 1:1 sessions if stakeholders don’t have time to attend meetings. Yes, it’s taxing to your schedule but it can go along way with engaging a stakeholder who wants to be included but has other obligations.
- Send a note (handwritten is EXTRA wow) to stakeholders who actively participate in meetings or who are super prepared for interview sessions. If appropriate, drop their boss a note. People like to know that their effort is appreciated!
None of these things are terribly time-consuming but they can make a big difference in the relationships you form during the project and ultimately the overall success of the effort!
Bridging the Gap
I am thrilled to be a guest author this month on Bridging the Gap. My post is in response to a reader’s submitted question about how to take his established Business Analysis Center of Excellence (BACoE) to the next level.
I hope you will check out my post on this amazing website. Laura Brandenburg does an amazing job in hosting this site and has great resources for anyone interested in Business Analysis. This is a site that I use often to gain insights!
I hope you will check out the site and my post!
