Engaging Project Stakeholders (Part 4) – The Requirements Kick Off

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
  • Questions

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.


Requirements Activity

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.

A great way to do this is through a documented Requirements Management Plan (sometimes called a Requirements Work Plan) which I go into in more detail in the next post of this series.

Questions

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?

© 2010-2011 Real World BA, LLC. All rights reserved.
7 Responses to Engaging Project Stakeholders (Part 4) – The Requirements Kick Off
  1. Steve Chihos
    November 23, 2010 | 5:34 am

    Wow!
    Great article filled with excellent advice. Thanks for sharing!
    I do a lot of project launch events and I have always found it the best way to get things off on the right foot is to have a structured, very focused launch event.
    We typically mix in:
    – the results of alignment (goals & objectives)
    – introducing the work plan (who will do what starting today)
    – some team building (at least who’s who + roles)
    – lay-of-the-land (where to find shared docs, how to report status, etc.)
    – team ground rules and project processes
    By doing these things, the team is able to start working the very next day on the right things!
    Thanks again for the series and keep up the great site!
    -Steve

    • Real World BA
      November 23, 2010 | 2:00 pm

      Thanks for the feedback, Steve! It really is so important to get the team aligned and ready to work together. I agree that the lay-of-the-land is an important item to note. In my experience, this is usually covered in the Project Kick Off but is well worth calling out again so it doesn’t get missed.

  2. […] stakeholders that will be participating in the requirements process, the one next thing is the Requirements Kick Off, which is the subject of the next post in this […]

  3. […] Part 4 of this series, I outlined the Requirements Kick Off meeting which is different from the Project Kick Off. As part of the Requirements Kick Off I suggested that […]

  4. […] of your project and at the beginning of every meeting. This is a great item to cover in your Requirements Kick Off as you’re explaining what to expect. Let your attendees know that this is where you will […]

  5. kai
    September 2, 2011 | 10:06 am

    My requirments have already been signed off but my boss wants a kickoff meeting. I don’t want to read through the requirements but I think he wants to use the opportunity that the developers and qa are there to go over the requirements with all the customers in the room. How can I facilitate the meeting without “reading” the requirement doc with all parties confirming they understand the requirements and we can officially start? If possible I would love to make it interactive and get their particiapation so If I start with the first requirement moving through all 10..its not dead,boring and mentally leave the room?

    • Real World BA
      September 7, 2011 | 11:14 am

      Interesting challenge, Kai. Thanks for bringing it to the blog.

      I would start by trying to better understand the purpose of the kick off. You indicate you think the purpose is to get the developers and QA involved, which I would usually consider as part of a Requirements Review and not a “kick off”, per se. If the point is to kick off development though, it may just be a terminology issue.

      If part of the goal is to ensure that everyone has an understanding of the approved requirements, you are faced with the common challenge that we all face. How to make sure everyone shares the same understanding without reading the document.

      I usually like to use the document as my guide, walking through each section but mainly highlighting the salient points without reading it to them. If you have process flow diagrams within your document, this can be a great facilitator of that discussion. Be sure to call out any areas where there is a lot of detail that the developers and QA need to be aware of (detailed business rules, etc.) which they will need to digest in greater detail.

      And to improve the interaction, ask your key business stakeholder(s) to highlight areas that are particular important/challenging and maybe dive into those in more detail so that all parties involved understand the complexities that are of concern.

      If the kick off has a different purpose, please reply and let me know and I’ll see if I can offer any other tips for you.

      Anyone else have any suggestions to share?

Leave a Reply

Wanting to leave an <em>phasis on your comment?

CommentLuv badge
Trackback URL http://realworldba.com/engaging-project-stakeholders-part-4-requirements-kick-off/trackback/