So, we’ve had the Project Kick Off and now it’s time to start digging in to those requirements, right? Not quite yet. While the Project Kick Off sets the overarching framework of what to expect, the Requirements Kick Off prepares stakeholders for what is happening right now.
I kick off each phase or step in the process separately. The kick off can be a formal, separate meeting. Or it can be the introduction during the first meeting in each phase. It all depends on the size and scope of your project. But it’s important to kick off each new phase or step for a variety of reasons:
- It re-sets and confirms expectations
- You might have a different subset of people participating who may not have been involved in the Project Kick Off
- It gets your stakeholders in the right frame of mind
And this happens before you elicit a single requirement.
The objective of the requirements kick off is to set baseline knowledge and expectations for the upcoming requirements work.
Requirements Kick Off Agenda
I like to cover the following basic areas when kicking off the Requirements phase of a project:
- Ice Breaker
- What are Business Requirements?
- What Makes a Good Requirement?
- Requirements Activity
- What to Expect
Is an Ice Breaker really necessary?
If you’ve been working with the same team for a while, an ice breaker may not be necessary. But if any of the team members that you’ll be working with are new, don’t underestimate the benefits of spending even a few minutes on this. You’re going to be asking people to get comfortable talking in front of each other, and even if this is a team that works together on a day-to-day basis this is outside of their normal tasks.
You can Google “ice breaker” and find a lot of great resources for ideas. Two classic ones that I use regularly are:
Two Truths and a Lie
Give everyone a small piece of paper and have them write down two things that are true about themselves and one thing that is a lie. Encourage them to be creative and share some fun, not-so-well-known things about themselves. Collect all the pieces of paper and read them one at a time, and have the group try and guess which one isn’t true. I’ll give you mine – try and guess which one is the lie in the comments below (and feel free to share your two truths and a lie as well):
- I have moved 10 times in the last 10 years.
- I swam with wild dolphins in Hawaii.
- I once won enough money in a single bingo game to buy a new car.
Something You Think Is Unique to You
In this ice breaker, give everyone a small piece of paper and have them write down one thing about themselves that they think is unique and that no one in the room knows. Collect the papers and read each one out loud. You can then either have the group guess who it belongs to, or ask for a show of hands to see how many people this applies to. This gives people a chance to see where they might have some common interests or activities that they thought no one else shares.
By the way, be sure to participate yourself in whatever ice breaker you choose. You are part of this team, and you want them to feel that from the very beginning.
What are Business Requirements?
Hopefully by now the room is a little more relaxed than when you first started. Now you can start getting everyone focused on what lays ahead of them. Start by explaining what requirements are. Even if the team has worked with you before and you “think” they know what requirements are, remember this is likely not their primary job and taking a few minutes to remind them goes a long way to keeping them engaged. (Remember the story I shared with you when I assumed the team knew what requirements were?)
If you recall from a previous post, I define requirements as “The What But Not The How”.
I use this short and sweet definition because it sticks in their heads. Make it really easy for them to remember what you’re after. And it identifies that what we focus on will be solution-independent. Remember, it is not your stakeholders’ responsibility to think about the best solution to their need. It is ours.
Acknowledge that this is hard! It is likely they are not used to thinking this way. They are used to asking for what they think they want. But, in order to provide the best service, a Business Analyst is not an order taker. Be consultative, and prove your value.
Assure them that you will guide them through the process to get the right information. Take this responsibility upon yourself. Let them know that if they ask for a requirement that seems to be solution-oriented, you will be digging deeper to better understand. You may be rephrasing what they are saying to clarify your understanding to ensure that you can capture this as a requirement.
Over time, I’ve found that the team actually helps each other to challenge the requirements and to push themselves to stay solution-independent. I’ve proudly facilitated meetings when development was listening in and asked how the business wanted something done; and had the business users indicate that it was their (development’s) job to figure that out.
What Makes a Good Requirement?
Take a few minutes to explain the characteristics that make a requirement “good”. This is not a judgment of whether their requirement is one that should be pursued, but rather that the way the requirement is worded is thorough. There are many descriptors to help describe the characteristics of a good requirement. I at least like to call out the following:
- Cohesive and addresses only one thing.
- Complete and fully stated, with no missing information.
- Consistent and doesn’t contradict any other requirement.
- Correct and validated by the stakeholders.
- Externally Observable meaning that it can be seen or experienced by the user.
- Unambiguous and concisely stated without the use of jargon or acronyms.
- Verifiable and testable.
Now you’ve defined what requirements are and how you’ll work with them to word them, but how do you get them to start thinking this way? Practice!
Conduct a mock requirements session (just a few minutes long) for something that is not related to their actual business. This way, they can just practice and get the hang of what it will be like without getting hung up on whether it’s a “real” requirement for them or not. This is also good if you have a variety of stakeholders and they don’t all understand all aspects of the business – no need to leave anyone out.
Pick something that will likely have at least a common understanding for everyone. Maybe it’s a backyard landscaping project, or planning an event. You can choose to be the customer and voice your requirements and ask the team if the requirement contains a specific solution or if it is generic enough to allow for multiple solutions to be presented. Or you can be the party planner/landscape architect and ask them for requirements, and show them how you would guide the discussion to understanding the underlying needs. For example, if they ask for a deck is that solution specific? What kinds of questions would you ask to understand if a deck meets their needs?
What to Expect
Now you’ve given them a feel for what will be coming with the next set of activities. Bring them back to focus on the immediate next steps. Tell them what to expect this week. Don’t make any assumptions that they remember what you said in the project kick off, or at the beginning of this meeting for that matter.
Also prepare them for some of the techniques that you may use in a facilitated meeting. Acknowledge that it can be difficult to shift to this way of thinking and it may take a little getting used to. People usually ask for exactly what they think they want, but it’s our jobs to understand the underlying need.
You may be asking “Why?” a lot. This can be frustrating for your stakeholders, as they think they know what they want but when they really start talking through the underlying issues they may come to realize that what they’re asking for doesn’t solve the right problem. By preparing them for this now, they won’t feel like you’re challenging them or questioning whether they should be asking for something, but that you’re just wanting to be sure that you all understand the true nature of what is required.
Explain the techniques and schedule you’ll be following and who will need to be involved. Will you be interviewing people individually? Sending out a survey? Shadowing workers? Facilitating meetings? Whatever methods you’ve determined to be effective for the information you’re needing to understand, let them know how you plan to do that.
Don’t forget to ask for those questions. There is bound to be at least one. Remember to ask “What questions do you have?” (which lets them know you are expecting and are ready to answer them) rather than “Are there any questions?” (which is often followed by silence).
How do you get the team focused and oriented to beginning requirements? When was the last time you used an ice breaker?