 Science tells us that your brain is now in a much more receptive state to new information. You are calm and relaxed. You are in the perfect mental mode for gathering requirements. Good afternoon. Thank you for coming. My name is Jordan Hirsch. I'm a senior digital strategist with Phase 2. And a large part of my job is making sure that we're building the right things for our clients. So my talk today is about how to make sure that you're building the right things for your clients and for yourselves. All right. Any questions? The slide is not out of order. The point of this slide is to tell you that you do not need to wait until the end to ask questions. If questions come up throughout, you are absolutely free to raise your hand or I guess shout them out if you're feeling kind of rude or super passionate either way. All we ask is that if you do have a question, please say it into the microphone because the session is being recorded and we want to make sure that your question gets heard by everybody. So I'll start off, show you how easy it is to ask questions by asking a question of view. How many people here in the great client-vendor divide would say that you are on the client side? How many people by show of hands hire other people to do work and build technology for you? I would describe that as a smattering, okay? How many people put yourselves on the vendor side? Excellent. And the rest of you are just interested observers. You are auditing this session. You will not receive course credit. Okay. So this will be primarily aimed at the vendors given the makeup of the crowd. But clients, there is a ton of hidden messages in here for you too. So pay close attention, see if you can glean them and if not, I'll point at some of you if I can remember who raised their hand and try to make it really clear. Any questions so far? Very good. All right. Off to a good start. The awesome song you were just hearing was by the famed poets, rock and rollers and project managers known as the doobie brothers. The song is called Tell Me What You Want and I'll Give You What You Need. And I think that song is a great reminder of the fact that when we are gathering requirements and we are starting out at the beginning of a project mourning everything that we're trying to do, it's tempting to think that our jobs as vendors is to give our clients what they want. That's the worst thing you could possibly give someone is what they want. Not that I'm comparing clients to a toddler, but if I were, I would say that my two-year-old wants to hold a knife. That's not a good idea. So instead I try to give her what she needs, which is something fun to play with. For clients, it's very tempting to want to say yes, right? Clients ask a lot of things of us. We want to be nice people. We want to say yes. But if we're really doing our jobs, we are listening to what people tell us they want, and we are digging and doing the work to actually get to what they really need. Because giving someone something they want, I mean if you've ever given someone a gift that they really asked you for, you know, you might know sometimes it's great for a little while. You've given them something they want, and that feeling is super nice until a little time goes by, and they realize it wasn't really what they needed. And then they want something more, and they're left unsatisfied, but you've already done all this work of giving them the thing that they said they wanted, and why can't you just listen to me and just tell me what you really want. It's not their fault. It's our fault. It's on us as vendors to be better listeners and to do the work of really figuring out what people need, not to give them what they want. So the path to giving people what they need is through requirements gathering. Super exciting topic, right? Not dry at all. So let's start out, dive into the excitement, make sure we're all talking about the same thing. Hidden message here. This is a key aspect of requirements gathering. Make sure everyone's on the same page with your language and your terminology. Requirements, the way I defined them, are simply the things you need, your new technology and or project to accomplish. They're necessary for any kind of project, right? Not just for technology projects, but that's our context here today. Requirements allow you to communicate your vision to an implementer who can then build your vision and bring it to life. Requirements are how you tell someone else when they're done building. About requirements, we don't know when we're finished, right? It's not enough to simply say, well, we've spent all the budget and we've hit the deadline so we must be done. You might be done, but you're not finished. Requirements tell you when you're actually finished. Why do we care about requirements? For the same reason that you would not hire a general contractor to redo your kitchen without having some idea of where you want the cabinets to go, right? That's requirements. Every project needs requirements if it is to be successful. They are your measure of success. They are your mark of completion. They are the agreed upon understanding of what it means when we say that we built this thing properly. Everybody clear on requirements? Anyone violently disagree? Good. Anyone violently agree? Very good. Violent agreement. Thank you. Very nice. Oh, but you say, we can't afford a discovery phase. What are you crazy? Poor discovery and requirements gathering. This was actually the phase in high school was voted the project phase most likely to be skipped, which is very sad. Yes, it made it cry at night. No one understood it. And all it ever heard from people was, I'm sorry, you know, you sound great, but we just don't have the time and money. Our project is special and unlike other projects, ours is short on both budget and time. So we're kind of in a unique case here. So we're just going to skip requirements and let's just assume that we're getting it right. Sadly, gathering requirements while it might sound like a luxury is actually essential to your project. And you are going to spend the time doing it, whether you plan for it ahead of time, good, or whether you don't, bad. That was a hidden message for clients. But you say, we're agile. We don't need to gather requirements. Agile will fix everything. By show of hands, how many people here are agile? Awesome. So you guys know, right? You never have to gather requirements. Agile just tells you what to do somehow. You just do it and then later on figure out if it was right. That actually doesn't work out very well. Even in agile, you are gathering requirements as you go. It is a part of the process. It is a structured part of the process. You may not go off into a quiet room for a month and do all your diligent, quiet work and then come back with a stack of requirements, but you're still doing that work. You're still gathering requirements. You're just doing it as you go. Agile is not a license to skip gathering requirements. Gathering requirements is a license to do well. Not gathering requirements is a license to f up your project. Actually wrote f. So that was a good job of me not saying the whole word. If you skip your requirements gathering, you are essentially flying blind. And a report released just last week by the FAA says that is not the recommended way to fly an airplane. So danger zone ahead. While the danger zone is a cool song, it's not where you want your project to be. And if I had worked out my iTunes thing properly, danger zone would be playing right now. So just everyone picture that for a moment while I take this sip. Thank you. OK, great. So you're sold on why you need requirements. We all agree on what requirements are. We've got violin agreement in the back. Let's talk about some best practices for requirements gathering. Number one, answer this question. Why are we here? We're all busy people. We're a unique client that does not have a lot of time or money. Why are we spending time together on this effort? What is the point of this enterprise? Establish your goals and objectives early. Even if you think you know, right? Everyone knows we've been talking about this new website for a year and a half. We all know what the goal is. OK, ask this person at the table, ask that person at the table, and then ask the vendor. You may well get three different answers if you get answers at all. Even if you think you know, write it down. Write it down, show it to everybody. Have everybody agree to it. Have everybody agree to it in writing. Get approval of these goals. Put them up on a wall where everyone can see them. Reference them frequently. Goals provide a framework for decision making and for prioritization. And throughout your project, you're going to be making decisions and you're going to be prioritizing. When something new comes up halfway through the project, it might. Goals let you ask the question, OK, does this new thing help us achieve our goal? If the answer is no, then you can put it aside for later. If the answer is yes, you can try to make room for it. But if you don't know your goal, you have no framework in which to make this decision. And you have no framework in which to explain this decision to someone else. When the CEO checks in, it says, how are things going? Why is this different than the way it was the last time I looked at the requirements document? Well, it's because in alignment with our goals, we had to make the following changes. You now have an answer for that question. Goals, goals, goals, goals. If you take nothing else away from this, establish your goals, write them down, get everybody to sign off. Questions about goals? Sweet. Good crowd. All right, we've got our goals. Let's prioritize. Again, I don't want to shock anybody. You might want to sit down in the back. But there is actually not time to do everything in a project. Unfortunately, you have to make some hard choices. You have to make trade-offs. In the agile world, we talk about MVP, the minimum viable product. How small can we make this thing and still launch and call it a success? What's the least amount of work we can do? We get to that by prioritizing. But even if you're not working in agile, you are still going to have to make trade-offs. There are still time and budget constraints. There are still resource constraints. There are always constraints in the real world. Prioritizing helps you make sure you are always working on the most important thing at the right time. Even if you're prioritizing long before you build, you still know what general order you're going in so that if you ran out of time or money or resources halfway through, you were always working on the most important parts. And you knew they were the most important ones because they were the ones that were most in service of your goals. Yes, gold star for you guys. Very good. Prioritizing helps you focus your efforts and make sure that you are not wasting your time. Important note about prioritizing. You do not simply prioritize once, call it a day, and move on with your project. Prioritizing is an ongoing process. As conditions change, revisit your priorities frequently. Make sure that you are not wasting time. If you're not prioritizing, you will most likely waste time and money on things that don't matter. If you have time and money to waste, you are excused. You may go. If you don't, if you're one of those unique projects that does not have that, then you should probably be prioritizing to make sure that you're focusing your efforts. Any questions? OK. Active listening. Requirements gathering is a process of listening. You are asking people questions. They are giving you, at best, incomplete and often contradictory answers. So if you're just listening and writing down what you hear, that's great. You will get a lot of good information. You will get a lot of misinformation. You will get a lot of information later that you really might wish that you had earlier. People, unfortunately, just won't tell you everything, even when you ask. It's not their fault. They're not being coy. I mean, they might be being coy. They're probably not being coy. People just don't always think of everything at the moment that you ask them. Even if you ask them to do their research and come prepared and tell me the top 10 things you need the system to do every day, two weeks later they're going to think of an 11th thing that's going to change everything. You can get around this if you practice active listening. Active listening is the art of listening with all of your senses. It means listening not just to the words that you're hearing, listening to the words that you are not hearing. What are people not saying that you may be expected them to say? Why aren't they saying that? Why is this person saying something slightly differently than this person? Active listening means paying attention to tone and to body language. If I say to you, oh, we need to add a blog. That's a very different message than, we need to add a blog. And that's a very different message than, we need to add a blog? OK, great. Those are very, very clearly very different messages. But if you're just writing down, oh, add a blog, you've captured nothing of the real import behind that statement. Active listening is kind of like a Jedi mind trick because it lets you learn so much more from someone than what they thought they were telling you. In active listening, you are constantly filling in context around what you're being told so that you can really view it in a meaningful way and not just as a standalone piece of information. Active listening has an added benefit. This is just for the vendors, OK? Vendors listen up. When you pay attention to someone, they trust you. This is a cool way to gain your client's trust by listening to them. Clients, you can listen up now. And in a relationship built on trust, you are set up for mutual success. This is nice when things go wrong later, which they will. When you trust the person that you are working with, it's easier to get through the hard times, OK? If you're not practicing active listening, you are missing vital information. Any questions on active listening? I'm not going to make you repeat it into the mic. But for the recording, I will say that someone made a joke. There's a real question in the back. Would you mind coming up to the microphone? Or if you want to shout it out, I could repeat it. The question was, what techniques can you use to elicit the hidden answers that you might not get the first time? Fabulous question. So one thing I'll say is, after this talk, I'll be updating the session page with a link to a blog post on active listening that I wrote last week. Thank you to Annie here in the front for forcing me to write it. But Annie's tweeting it right now. But off the top of my head, the next slide will answer that question, which is ask follow-up questions. This is a great technique that really does force you to practice active listening. If you try to just ask follow-up questions without paying attention, your questions won't really make any sense. You might be asking people to repeat themselves. It's not very helpful. A good phrase to use is, help me understand dot, dot, dot. Just repeat back what you just heard. Help me understand why you want a blog on your website, your website which does not have any frequently updated information and has no staff. Just help me understand. So you do want to keep value judgments out of it. But help me understand is a great phrase. Other tips for active listening, eye contact, don't have a laptop open in front of you, try taking notes on paper so that you're not distracted. Repeating back what you heard and a few more that'll be covered in that blog post. So why ask why? Here is a story that may help elucidate the answer. This is a true story. This happened just a couple weeks ago. I had a client tell me that we need your help updating the about us and help section of the website. OK. Why, I said. Oh, well, because people can't change their password. OK. Why is that? Oh, people don't understand how to use the form where they can reset their password. OK. So what you want is an updated help page. What you need is to fix the UI on your reset password form. I was not going to make that connection without asking why. They just wanted to add a block of text to the about us page that said, hey, by the way, if you're having trouble resetting your password, here's what you do. That might be one way around the problem, but it's not the solution. It's not a true solution. And it's a classic case of what somebody wants versus what somebody actually needs. So ask probing questions. Say, again, help me understand. Or I'm hearing that. If you keep hearing the same piece of information from a few different people, repeat it back. Repeat it back to the group. Say, I'm hearing that your password form is hard to use. Or maybe you can say, I heard it in when we conducted user research. Help me understand why it is the way it is. Help me understand is a very powerful phrase. It's non-confrontational, and it often really does help you understand something, which is also a nice side effect of this whole process. Question everything, basically, is the takeaway from this. Question everything. Even the goals. As a vendor, you cannot tell your client what their goals are or what they should be. You can help guide them through the process of finding their way there. And a great tool in that is to ask them why. Why is this a goal? What does this really do for you? Why would you ask that question? Are you making a joke? For the recording, there is another jokester in the audience. I don't know what led people to believe they could interact in this way. But if you don't ask why, you risk solving the wrong problem. And that sucks. Are there any real questions about asking why? Anyone at all? Don't be shy. Question in the front? So the question was, do we use a template or some kind of form to gather requirements? It depends on what type of requirement we're gathering. If it's a stakeholder interview based on a very specific process, maybe that someone has to go through with the tool. But yes, we might use the same set of standard interview questions to make sure that we're normalizing our data across everyone that we talk to. Sometimes it's a much more open, free-flowing discussion. Sometimes watching a usability test is actually part of gathering requirements. So that's a very, very structured example. So I'd say there's not one form or one tool that will get you through every requirements gathering session. A lot of people like, when they're taking notes, there's a popular tool called Omni Outliner for the Mac that people are big fans of. Personally, I use Evernote and I just make bulleted lists. Often our team will use Google Docs if there's a few of us in a meeting, so we can collaboratively take notes together. I find that very helpful. So it depends, but there are a lot of tools that can help with the process. Does that answer your question? All right, was there a question over here? Yes. So the question is, help me understand your question. So the question is, as part of asking these questions, are you also kind of restating requirements back to people? That's interesting that you asked that because I had a slide about this that I took out because I thought it was redundant and next time I will put it back in. So excellent question. The answer is yes. You are explicitly restating, so the flip side of help me understand is, I heard this and then you kind of repeat it and you don't just have to do that for something that you have a question about. The slide I took out was about transparency, called a transparent note taking. And basically what it means is that after you go through a requirements gathering meeting, go back home, clean up your notes, send them around to the entire group, including your client, including the stakeholders, anyone who was there and say, here is what we captured during this, did we get it right? Sometimes that will open up a horrible can of worms because people disagree about what was said. But if you're doing a good job writing things down and you're practicing active listening, more often than not people will say, oh, wow, I didn't realize that we were all saying the same thing, but yes, this is clearly an issue that we have. So yeah, it's definitely a good practice to send those notes around and just to, again, repeat back what you're hearing to make sure you have it right. These are complex projects that we all work on and there's a lot of complicated information going around and we are human beings trying to do a machine's job. Question at the mic? People sometimes come to me via an RFP and can you hear me okay? Yeah, can you come up just a touch closer? And sometimes the RFPs are clearly very well developed and they're extremely detailed in terms of what they perceive their requirements to be. So usually I'll make some personal contact with them before submitting my proposal, just sort of to say, hey, I'm submitting a proposal. But would you recommend, even before you submit the proposal, asking if you can have a little time with them to ask some questions, because what if you do your proposal and then the RFP really just was pulled out of thin air and it really doesn't reflect their requirements and I am speaking from personal experience, thank you. So what did you do in that case? I submitted a pretty open-ended proposal and I said, but I do have some questions about some of your requirements and then we sat down and that ended up being a really complicated project at my level, which I'm not talking about, some huge website, but a complicated project with a lot of interaction of is this in scope, is this not in scope? I fortunately documented everything so I was able to refer back and say, we talked about some databases but I think this is a lot more than we were originally talking about and in the end, I felt very good about the website, they felt very good about the website, they paid more than they thought they were going to, I perhaps made a little less than I thought I deserved but not too bad. So in other words, it was a lengthy process of give and take, which I do feel I could have handled better right from the start. So I like that story. I'm not usually an advocate for doing free work. I think there is a place for some free discovery work if it's really benefiting you as the vendor, it's also benefiting your client. If you get an RFP and it's very muddled and fuzzy, it's often a sign that the client doesn't necessarily yet know really what they want. All right, it's a classic sign that maybe they haven't gone through the process of figuring out their goals. So the free discovery work can consist maybe of just an hour, sit down with them, hey, here's what we heard from your RFP. Help us understand what your goals are for this project so that we can submit our best response and really try to solve your underlying problems. You can use those exact words, those are great, that's trademarked, so there's a small fee. But that's how you can both use, here's what I heard and help me understand at the same time, which are both very powerful phrases. So yeah, I think a little bit of free work at the beginning, if it's really in service of you as the vendor and making sure that you know what problem you're trying to solve, I think that definitely pays dividends. Just make sure that you can feel where the line is between that and 10 free requirements gathering sessions and here's your stack of requirements and now you can shop these to another vendor and oh, I forgot to charge you. So there is a line there, make sure you know where it is. Excellent questions, thank you everybody. Question in the back. The question is, at what point do you stop asking why, stop navel gazing and just get down to building? The answer is when you understand the answer to why. If you don't understand the answer, it's a risk. If your client doesn't understand the answer, it's a massive risk, right? If they get it and you still kind of don't get it, okay, they've done their best to explain it to you and you're still not getting it, perhaps go forth and build, right? Again, you gotta find where that line is for you. If they can't even answer the question, that's usually a red flag that you're about to waste time building something that you might have to go back and change, right? It's not that we don't, like it's not the worst thing in the world if you build something that doesn't get used. When it becomes a problem is if you build something that doesn't get used and then they say, well, this isn't really what we wanted because we didn't really think it through, so we're not gonna pay you anymore and the deadline's gonna stay the same but we need you to go back and redo it or build a different version of it, right? That's where asking why pays off. Just asking why it can turn into sort of a corporate therapy session if you let it go too far where, when a company tries to explain the purpose behind a product like a website that represents them, you really ask them to explain the purpose of the organization, which can open an entire therapy session. So make sure you are keeping a handle on that. So it's a great point. Don't let these sessions sort of spin off into a philosophy discussion unless you really want to and you're getting paid for it. So as the vendor, I think you're in charge of kind of locking down like, you know what, we've talked about this one enough. I think we all have a good understanding. We have a comfortable sense that we're gonna build something that you're not about to ask us to rebuild as soon as we're done. I think that's where the line is. All right, I will advance. Know your stakeholders. These are the people of whom you are asking all these questions. If you're doing a good job, they will not get to this point. However, I worked on a website as a rebuild and redesign for a large museum in New York. We were, no joke, we were their 12th vendor. Not counting the two times that their internal web team tried and got fired and got replaced and tried again and got fired. So we were their 12th vendor. So yes, giant red flags, still not entirely sure why we took the project at the time. This was not phase two, by the way. We don't make those kind of silly decisions. But by the time we got there, the pitchforks and the torches were already out. So how do we mitigate for that? Talking to the right people. Think through the purpose of this tool or this project. Think through the process. Who's gonna have to use this thing? What are their technical abilities? What are their technical limitations? Are they gonna get trained? Do they actually have time? Let's say it's a new website build. Do they have time to update this website? Or is a bunch of work about to get dumped on them? Do they have time to learn a complicated administrative interface? Or are they gonna have something that's forced upon them that they really hate, rise up against and sink your entire efforts? If your users will not adopt the tool, that will reflect poorly on you. In six months when you've been replaced with another firm, they're not gonna remember that the reason was that the editorial team didn't have time to learn the tool. The reason was, oh, that last vendor did a terrible job. We hate them. We can't exactly exactly remember why, but we know they're awful and they're gone. So now you guys are gonna clean up their mess. That is not a good scenario for anybody. You can get around this by talking to the right people and raising these concerns, okay? These are good questions to be asking. Who's gonna have to use the system? Why? What are they gonna try to do with it and what constraints are they under? Keep in mind also, projects can have hidden stakeholders. This is a fun pitfall. There may be people that don't get mentioned in the requirements gathering sessions or stakeholders that no one really thought to bring up to you, but we have this one guy in accounting who's also gonna have to use the tool to run a super complicated report. We'll tell you about that more right before we launch. Don't worry about it right now. Follow up on that. Are you that guy? Oh, you've had, yeah. That will happen. It's not always easy to uncover hidden stakeholders, but if you're practicing your active listening, you might get a clue or an inkling that those people are out there. And you might start to cast a little bit wider net in your requirements gathering efforts to talk to those people. Don't forget the executives. Executives love to have their opinions asked of things because they are paying for these projects. They will have opinions. Loop them in. Make sure that your project has some sort of internal backing. And if it doesn't, make sure that you're aware of it and make sure that your client is aware of it so that everybody can kinda plan for that from day one. The whole point of requirements gathering is to not only know what you're doing, but to mitigate surprise. Executive buy-in or lack of executive buy-in is a nasty surprise. It's a lot easier to plan for if you know about it at the beginning. Last but not least, and the comment, and I can attest to that, I've worked with them for many years. Non-profit boards are worse than executives, we were just told. That's an excellent reminder. Don't assume that you can make everybody happy, but you can at least have everybody give their say and air their opinions. And if you're actively listening, you're making them heard. And when you make somebody feel heard, they no longer feel quite so nervous that you're gonna screw everything up. Last perhaps least, there are users of the website who are not the editorial staff or the admins. There's people who visit a site, I guess visitors maybe we could, let's call them that, we'll call them site visitors. I just coined that. People will use the website that you may not be thinking of. You may not always have time to do full-on user personas and all that. But keep in mind that if you build a beautiful site and you never put any thought into how the users might try to interact with it and the users hate it, once again, guess who will get blamed for that? Not the users. You will get blamed for that. You don't wanna get blamed for that. This is a process in avoiding blame because there will be nothing to be blamed for. So remember to include the users when you're doing your stakeholder research. If you skip this, you can basically end up with a tool that nobody wants to interact with, nobody wants to visit, nobody wants to use. And once again, you will get angrily replaced and the next vendor will get his or her turn in the shooting gallery spot. Questions about stakeholders? Cool. Ponder while I take a sip of water. Very good pondering, I can hear it. Drupal's great. I am required by the DrupalCon Association to say that at this slide. It's not the answer to everything. Requirements gathering is about requirements. It is not about tools. I'm gonna say that again, because it's a mistake that I see happen over and over and over again. Requirements gathering is about requirements, not about tools. Requirements are about what you need your system to do, not how you're going to accomplish that. Really pay attention to what you need and to what your clients need. Do not get distracted by shiny objects and fun, cool technology. I had a client add web conferencing to a project years ago in the early days of web conferencing, just because somebody saw an article that said, oh, in higher education, web conferencing is this hot new thing. Let's add that. Okay, what will you do with it? Go ahead and add it, okay. Great. So, if you have a tool in mind when you go into your requirements gathering, it's very easy to slip into this mindset of, oh, well, the tool doesn't really do that, so why don't we focus on this instead? Or the tool does this really well, so maybe we should add this to the site. That's not building what someone needs, that's building what your tool does. The beauty of working with an open source system like Drupal is that we can adapt the tool to meet the needs of our user rather than asking our users to adapt to a tool. Even if Drupal is not the right fit, and if you're using another system, keep that in mind. People are much more likely to use a tool that has been adapted to their process and their needs as opposed to the other way around. Okay, you do not want to be in a mindset of, well, the tool doesn't do that, so that requirement is not important. Any questions? What are requirements about? Yes, you guys are coming along. All right, requirements was the correct answer. If you're good listening. Sadly, we are only human beings. We have not yet achieved the beauty of the robot who can do no wrong. The point here is that remember that because you are human, you didn't get everything right the first time through. All right, requirements gathering are an attempt to wring science out of art. This is an art, having a conversation with someone, asking them questions, getting meaningful information. We're trying to take that and turn it into a science, a scientific artifact, a list of things that has to be done that we all agree on. One of those is very methodical and mathematical and analytical, and the other one is very touchy-feely. Very dubious brothers, man. So as human beings, we are much more comfortable in the touchy-feely side of things, even if we're nerds. And yet, the best requirements gathering efforts, no matter how good you are at that touchy-feely stuff or how much of the science side you bring to it, you're simply not going to capture everything because you are a human. You will think of things later. Your clients will think of things later. Things will change, priorities will shift. Ah, what do we do? Don't answer yet. I'll tell you, build in time to your projects to manage your requirements as you go. Gathering requirements is great. It is not unlike gathering a bunch of cats. And then you put the cats in a room, and you neglect to notice that the room, maybe the walls don't quite come down all the way. There's a gap, say, about cat size, and maybe one cat sort of slips out, and then another cat follows it, and you catch that first one, you kind of bring it back. Okay, boy, now there's three cats gone and this is suddenly eating up a lot more time that we're not building. Things are starting to spiral out of control. If you plan from the beginning for time to manage your cats, excuse me, to manage your requirements, you will not be surprised by the fact that you have to spend time on that. Just like gathering requirements in the first place, this is something that you're gonna end up doing anyway, so you can either plan for it in the beginning, maybe give someone a little bit of sticker shop, sticker shop, excuse me, upfront, and say, look, we need to spend time and money on this every week. Part of our process is managing these requirements, or you can leave that out and spend the time anyway, except in that scenario, you're jeopardizing your budget and your timeline. Requirements are simply not static, and if you accept that, you can make this a graceful part of the process. Spending time on your requirements as you go simply helps you mitigate the fact that you're already starting into disadvantage by being human and therefore imperfect. Any questions about robots? Yes, excellent question. The question was, should we also be revisiting goals to make sure that they're not shifting over time? Goals do not quite have the cat problem. They don't try to run out of the room and dissipate and change quite so fast. They more have the problem of the thing where you hang your keys when you come into the house and you put your keys there and then you walk past it all the time, so you sort of forget that's where your keys are, and when you go looking for your keys, you can't find them because they're there. You see it so often, you just kind of forget it exists. It just kind of goes right out of your mind. It doesn't seem important. Goals are worth actively revisiting primarily when you have to prioritize or when you are debating maybe adding something new to the project or taking something out of the project. So I don't think you need to sort of constantly be hitting them. You don't want to bang people over the head with them, particularly if it was a contentious process to get everyone to agree to them in the first place. So you want to be careful. You're not reopening the goals up for discussion and debate. You are simply revisiting the goals that we all agreed on in writing at the beginning to help us make decisions. So yes, I would say do revisit the goals as needed. They're not as slippery as requirements. Any other questions? Great question. The question was how do we translate requirements into tasks or user stories or something in a process that we can deal with? So phase two, we work in the scrum agile methodology. So I spend a lot of my day translating requirements into user stories. I think user stories are very, very valuable. I don't include them as part of this because they don't apply to everyone's situation. Is anyone not familiar with user stories? So a user story is a way of describing a requirement that describes what a feature is, what type of user benefits from that feature, and most importantly, what is the value of that feature? So it encapsulates the who, the what, and the why of a feature. Very importantly, not the how. So when we build our user stories, we are intentionally divorcing our requirements from their technical implementation for as long as possible. Because we wanna have discussions about what someone needs. We do not want to have a discussion until we absolutely have to about how we're going to build it, all right? Because once you start talking about how you're gonna build it, you need to have basically locked down what the thing is and why you're doing it. And the why helps you drive the how. Knowing that a search has to be fast, right? Is very, that might drive a different implementation than knowing that a search has to be extremely detailed and faceted. Those are two different search experiences. So if you can encapsulate that value with your requirement, that will definitely help the developers understand which direction to go when they get into the building. Does that answer your question? We also use Jira in terms of an actual tool. I like Jira very much. Any other questions? Yes, would you guys mind coming up to the mic? We're at our last slide so we can have free question time if you like. So with the last statement of not describing the how and your user stories, at that point is it useful to have developers and the user gather or in the requirements gathering process because they do get into the weeds often of describing the how and at that point how do you stop them from getting into the weeds? That's a great question. Developers, and I was a developer for many years before I sort of switched tracks to kind of the analysis and strategy side of things. So I do understand that temptation to kind of dive in to like, but how are we gonna implement this? I do find it's very helpful to have a representative of the developers at these meetings. So like on our projects, we'll have a technical lead for example. I like having that person there because he or she will bring up important things that we might need to know. You know, if we're discussing the faceted search with all of the different options, that person might be able to say, you know, hey, we actually just built something very similar to this in a previous project and we have a cool thing we can reuse. We don't wanna go too far down that path because we don't want that to drive what we build here, but it's helpful knowledge. It tells us, okay, the size of this or the complexity might be smaller than we thought because we've already built most of it. Or they might be able to say, well, given what you guys said two meetings ago about your IT and your internal hosting, that's gonna represent a problem. The point is not that we're gonna cut the requirement, but it gives us a warning, right? It tells us this is very, very complex or maybe this is less complex than we thought. So I like to have kind of a single representative from the developers at these requirements gathering sessions if we can get them. It's not always possible to get their time at that stage. Excuse me, but I think it's very, very valuable. And another question is what stakeholder should be represented there? Developers, project owners, clients. Yes. Are they both stakeholders or are there any ones that should not be specifically represented? It depends on what kind of meeting you're having. If you're in the early phases and you need to learn how, maybe it's a media site and you need to learn how the editors do their job every day. You might just need a couple editors and an analyst to write things down. Maybe you wanna get their boss out of the room so they can speak freely about their frustrations. So you wouldn't necessarily need the project manager there for that and the developer team. If you're meeting with their IT people about their hosting requirements and their uptime requirements and security requirements and various compliance with things, then clearly you'd wanna get more of your developers in there and you'd wanna get more of their IT people. So I think the answer, I'm gonna say it depends. Again, I've said that a few times here. But the answer is really kind of size these appropriately based on what you're trying to get out of it. So actually just like requirements, all of your requirements gathering sessions should have a goal. At the top, you should be able to say, here's our agenda, here's why we're here, here's why these specific people have been invited, here's what we wanna get out of it. Okay, great, thanks. Jor. I have two questions. The first is just a quick technical question about running a session. You described earlier sort of getting out from behind the computer using pencil and paper. But then you also talked about software tools you use for note-taking. Do you advocate maybe having a person who's doing the talking and the listening and then a person who's doing the typing? Because I can't keep up with pen and paper the way I can with Evernote or something like that. Yeah, it's an excellent question. I also, despite advocating it for others, I don't use pen and paper, just I have terrible handwriting and I'm slow at it. I do, if I don't need to be on Google Docs or something, I will sometimes take the crazy step of shutting off my wifi during a meeting and just taking notes. But yes, if you are running a requirements gathering session, you should not be the primary note-taker. As an analyst, I find that note-taking is a perfect role for my project manager. That gives them something to do. It helps them feel included, makes them feel like they're part of the process. So it's kind of nice for everybody. Are there any project managers here? Anyway, oh hey guys, what's up? Oh, Kelly, by the way, Kelly Rogers over there, amazing note-taker. But seriously, but they are, in all seriousness, they are able to take better notes because they're not also asking the questions at the same time. Because if you are really taking detailed notes, it's very hard to be thinking of that follow-up question of like, oh, that made me think of something that I wanna come back to. And that thought's kind of dissipated by the time you've written down the thing that you're trying to get down. So absolutely, if you can, split those rules out. Okay, so second question is where I work, we have a pretty robust project framework that involves requirements. And then at the end, acceptance testing that traces back to the requirements to make sure that they were all fulfilled. Since you're describing a process where you're translating requirements that you've gathered in these sessions into user stories, do you, can you talk more about what happens at the end and how you trace back to make sure that you've built what was defined? Do you trace back to the user stories or do you go full circle back to the requirements? So my answer is pretty specific to the agile scrum process and specifically the way that we do it. So as part of a user story, we don't stop at just that sentence, that as a system admin, I want to upload files so that I can share them with the whole team or whatever it is. Part of every user story is sort of that one sentence description. And then there's a conversation piece where we dive into details. And then there's a confirmation piece, the three C's people call it. The confirmation piece is how we tie it all back together. There's different methods of writing your confirmations. There's a given when then is one structure. There's simply just a numbered list of, to basically here's how you know you've completed this thing. The login in the system is this type of user. Click on this thing, upload this file. This should happen. Make sure you don't get any errors. Hit save, make sure the next screen looks like this. If you can do all that, then this ticket was, or this user story has been satisfied and your client should accept it. So yeah, so I think part of every good requirement are enough information to actually build it and testing steps to know that you've built it correctly. You mentioned you used Jira. Do you track user stories in Jira or requirements? We used the Greenhopper plugin for Jira, which gives you access to, you can make scrum boards, you can make combine boards. You can basically run a whole agile process through it. So we find that very, very helpful. Do you have something that maps back what you entered in Jira as a user story to something that you wrote as a requirement? Depending how we do it. So the way is getting very specific to us, but the way that I like to do it personally, I like to have my sort of the main part of the user story in Jira, right? And then I often will have a link to a Wiki page, which is where we've actually captured the requirements. The reason being, if you're using Jira, every time you edit the ticket and change, okay, maybe we found out that some number changed or the business rule changed a little bit for this one requirement, it doesn't keep a version history of what you put in that big description field and 20 people get an email every time you touch something. As opposed to if you link off to a Wiki page and say, okay, the requirements for this are here and the testing steps are on this page, you've got version history, people can go back and see what changed. There's sort of a single source of truth and you don't have to go hunting through the comment revision or the set of comments on a Jira ticket to find out like, oh, if you look eight comments down, that eight should be a six or whatever it is. So that's how we try to keep them connected but separate so each tool can play to its strengths. Great, thank you very much. Sure, thank you, good questions. Hello, aren't you warm in that hat? Oh, it's to counteract the air conditioning. Ah, okay. So my experience- Oh, you have a question also, okay. Sorry. My experience has been that integrations can come with hidden requirements and I'm curious what your best practices are for incorporating those. Integrations, can you give me an example? Salesforce. So hidden technical requirements? Well, this was the hidden stakeholder accountant's requirements that we were not just close to us since it was a whole just hidden ballooning part of the project. I mean, that's a unique case but it's sadly also not a unique case. You know, like that's, I don't know if that's necessarily specific to an integration. Integrations do have their own special set of sort of hell that come along with them because often if you're integrating with a third party tool, you may not have access to their developers and their support staff. You know, you maybe you have, if you're lucky, maybe you can get a half hour with a sales guy who's like, our product's the best, you should integrate with it. Like yes, no, no, we have to in two weeks. Can I have information, please? What you can do is really drill people on what are you expecting to get out of this integration, what are you doing now that you need to keep being able to do after the integration happens? What do you want to do now that you can't do that this integration is supposed to solve? You know, if you can answer how will we know this integration was successful? So it's sort of, it's the same questions that you're asking kind of of any project but the answers are very, very important because when it's not your technology you can't just go in and fiddle with a few things and sort of adjust as you go. So I don't know if that helps. It's not, you know, there's another area where it's very, very helpful to have tech people there. You know, as many as you can come in force and ask the hard questions about like what happens under this set of scenarios? What if the load is X? What if we're hitting you from API version 1.2 and you upgrade to 1.3? What happens to this decade old report that some guy runs every year? So if you don't know about the decade old report you're in a bad spot but if you're asking hard questions at the beginning hopefully you'll have some inkling that it's out there. Okay, thanks. Sure. Hey Jordan. Hello. Pin and paper. Very nice. So my question for you is your advice to make sure that you're keeping on top of requirements and that you're going to have more come up. Is that just scope creeper? Is that dealing with making sure that you're grooming your backlog? So if you're in the world of Agile then what I'm referring to primarily is backlog grooming but it's also, it can take the form of scope creep. Backlog grooming can easily lead to a series of offshoot questions. This is the hidden dark side that I save till people are leaving about asking why is that when people really force people to answer that question they realize like, oh, really we need 10 things. We don't just need one thing. Sorry, it's easy for people to try to add scope at that point if you are using a backlog and you're sticking with your scrum process and you've got your story points, you can say, okay well all these things sound important. You're telling us, I'm hearing that these are very, very high priority. You've helped me understand that they have to happen. They're gonna add 25 story points. Now help me understand which 25 story points are going to go away, right? Or are going to be waiting until maybe post launch or a future release. So there's ways to say no by saying yes. You're saying yes, these things will happen later. They're not gonna happen at launch. So for us, yes, this takes the form of backlog grooming. Backlog grooming, I think the backlog is kind of an attempt to stamp out the idea of scope creep because it can't creep if you're constantly penning it in, if you're constantly managing it. So a little bit of both. I mean scope creep I think happens when people have different operating assumptions about what they mean by things. Going back to the very beginning of this talk about sort of a shared terminology, well we thought that a sign up form meant this. You thought it meant a five page form that writes to this external database and signs them up for newsletters, et cetera, et cetera. So if we all have a shared understanding of what the terms are and what features really mean, I think scope creep is a lot less likely to happen. Thank you. Sure. All right, last question. Hi there. Hi. Hi, so I have a question actually. So how can you define the relationship between a PM and a BA? Now the reason why I ask that is because... Jovial. Right, so the reason why I ask that is because within our own team, our PMs are actually wearing three different hats. They're doing project management. They're doing resource management and they're wearing the hat of a BA. So they're doing requirements management and requirements elicitation. So having those multiple roles actually conflict with each other? They don't necessarily conflict with each other. I mean, if you remember that you're all on the same team, you know, you're not fighting for different things. It's not like your PMs are trying to actively add scope to make the client happy and you're actively trying to cut it, right? You're all just trying to have a successful project. I would say I think it's a lot more challenging for someone to wear all those hats at once. I've certainly seen it done. I've done it to a small extent. When I was a contractor just out on my own, I was wearing all those hats at the same time. It's a lot of hats. It does not leave a lot of room in your head for thinking or forgetting work done. I was also developer at the time. So I was wearing all the hats. I don't recommend it. I think it leads to things falling through the cracks and it leads to much wider cracks. So I don't think those roles should be thought of as being in conflict at all though. Right, they're complementary and they're both in service of the same goal. So if you recognize that then even when they seem to conflict a little bit, I think just coming back to the idea that you're all serving the same purpose can be very, very helpful to sort of get that harmony going again. Right, yeah, what I mean by conflict is, for example, oh, we're running out of budget and the project manager is like, oh, we're out of budget so we don't want to get that requirement done anymore. So that's sort of... So the business analyst doesn't necessarily care if the requirement gets done or not. They care if it is documented properly and if a developer has enough information to actually execute it successfully, right? You're all answerable to the client. The project manager, usually more so than anyone else. So, yeah, I mean, listen to your PMs. I don't think you're doing the business analyst role any good if you're fighting tooth and nail to add requirements back in that you don't have budget for. Right, okay. You don't need to fight that good fight. One last question is, you mentioned earlier that to how to translate user stories into actual, actionable items that your developer can do. So right now within our team we do have the user stories. Now, the problem is, how do we actually get the developer to do... Oh, these are the things that you have to do for each of these user stories. If you're following the scrum methodology, that is a good outcome of your sprint planning sessions. Right, your user stories are in good shape. They have enough information that your developers understand what's expected of them. Your sprint planning time is time for the developers to get their heads together and say, now that we have enough information, here's how we're going to approach this story. These are the steps that we need to take to carry this out. So the actual tasks will be coming from the developer? Yes. Okay. So we have our user stories on top and then our technical tasks is kind of children in Jira of those so they kind of move all together. Right, okay, thanks. Sure. All right, two more. We'll go lightning fast before they kick us out of the room. Do you have anything specific you ask for coming in on a project midway? Besides... I ask not to do it. Does that count? I hope that the person who was in my role before me on that project took good notes, was documenting things. I ask for any documentation they have. If I'm not able to get that, I might ask for some extra meetings. Clients will balk at that, yes. But I try to make the case that it's in service of their project. You know, like I know you spent this time with someone else and I'm very sorry, some information got lost. You can use words like, you know, time has passed and priorities may have shifted so I want to revisit what came before and make sure we're still on the right track, which is a helpful lie for saying, I don't know what's going on and I need you to tell me. What if you got, say, oh, in four years, we never considered that? I'm sorry? What if you got, oh, in four years, we never considered that? We never considered what? Any, like writing things down or you're talking about stuff that they've just never, it's been off their radar. Yeah. Well, it seems like now would be a great time for us to revisit the goals of our project and make sure that we're still working towards the same, the correct things, right? That's a good time to fall back to your goals. You know, like, oh, this thing that you haven't considered that I think is really important, your goals dictate that we need to spend time on these conversations so that we can help you achieve them. Always show the trade-offs, right? Yes, we can skip this meeting and that means that you may not get what you really need in the end. So, strike fear into their hearts and be shameless about it. All right, final question. How do you deal with the... Can you speak into the microphone? How do you deal with the build it and they will come kind of questions, you know, where you look at it and you say, this is not going to work in your organization but there is a stakeholder that's adamant that you have to have that. So now that the clients are slowly shuffling out of the room, we can all talk amongst ourselves about the dark truth that sometimes you have to build the wrong thing. If possible, put someone else's name on it. But in all seriousness, don't be afraid to have the hard conversations where you say, what we've heard. Again, it's not, you'll get more traction with saying, you know, what I'm hearing from you and your organization as opposed to like, my opinion is the following. So what I'm hearing is that your users are really not going to be able to benefit from this tool because we heard this, we heard this, we heard this. You are telling us to build it anyway. It is our role to build it. I mean, if there's a big enough gap, you know, and maybe you've finished a discovery phase but you haven't signed the dotted line for the build yet, if you really feel that you're about to build something terrible or useless, you know, it can be a company decision perhaps to part ways at that point. I mean, that's an extreme decision but it can and should happen from time to time. I think as long as you're stating these things out loud over and over again, you are somewhat covered, you know. Get them written down in part of the project. Yeah, CYA a little bit. But you'll also see seeing their A, if you will, so that, you know, you have, because you're showing them your notes, right? These are, they're signing off on everything that you're hearing and they can show the higher ups. Like we all kind of collectively said, maybe this wasn't the right thing but you told us to do it anyway. So we might not get the results that we think we're gonna get and here's why. So it's all about removing the element of surprise. Okay, thank you. Thank you very much everybody, great questions. Thank you. Oh, and if you have a moment, please do take a minute and evaluate the session. They should be putting up the evaluation form up on the session page which you can get to at bit.ly slash Austin Rex. Thanks.