Collecting requirements and defining scope

- This is a bonus episode to prepare you for a greater discussion about requirements and scope. Join us. - You are watching ITPro TV. - Welcome in. I'm your host Lauren Deal, and with me is Robin Abernathy. And we're going to jump a little bit further into scope and requirements, but specifically, this episode is all about collecting requirements and defining the scope. So that's our focus for this one. - That's our focus for this episode. But before I launch into the deep dive of this topic, I do want to acknowledge something. If you are looking at the CompTIA objectives, you're likely to not see this topic even listed. I did not like the fact that it was completely ignored, because to me, the requirements in the scope are very important because it sets the work that you're going to do and until you document those requirements and then translate them into the scope of your product, you are not really going to be able to do anything. So what I've done is, I've included a little extra step here. The next two episodes, while I'm covering topics that are basic topics for some of the future things, they're not specifically listed in that CompTIA objectives list. That doesn't mean the content won't be on the test. By the way, they have a disclaimer that says, hey, our bullet point list may not be comprehensive, and we could add anything that we want to. Typical CompTIA. I love them. So what we're going to do here is I'm going to dive into this a little bit because I feel like you need to understand requirements and scope before we go into all those other topics, okay? So first of all, what I want to talk about is scope versus requirements. Now, the project scope is defined as the work that you perform to deliver that final project result. Whether it's a product or a service, the scope is what defines what it ends up being. And predictive projects, all of the scope definition is done at the very beginning of the project. It's part of the project plan. It's documented very well. But in adaptive approaches, the scope is refined over and over again as you recycle through. So there's two different approaches to it, but it still involves scope. It's just that in those predictive models, you're going to have it defined at the beginning where within those adaptive project, it changes over time. Now the project requirements are defined as the conditions or capabilities that are necessary to present in a product in your project's final to satisfy a business need and a stakeholder requirement. You get these requirements directly from your stakeholders. Now, I've mentioned it before, not all requirements may make it onto the final plan, but often you have a very good reason for not including them. Sometimes a requirement is given to you and it doesn't really satisfy a business need, it's just kind of this thing where, I'd really like it to do this. Well, is there really a business need for it? If there's not, we're definitely going to leave it out. But they give you those requirements and then the requirements are used to build the scope. So the requirements are first and the scope comes from the requirements. Now, to determine what work needs to be done, those requirements are given to you by the stakeholders, and those requirements affect the outcome because you've got to make sure that you meet the requirements that you agree to meet. So you've got to keep a documented list of the requirements, differentiate whether yes, we're going to meet this one, no, we're not, and here's why. You can't just say no. Often you need to give a why. And that way you'll always have that documented why there in case someone comes to you later. But for the ones you're going to keep, you need to then map them into the scope and track that requirement to make sure it's actually met at the end. If you don't keep track of it, it can easily get lost. So the first thing you do, of course, is you collect those requirements from the stakeholders. Now, there's a variety of ways that you can collect them from those stakeholders. You can have different data gathering methods. You may bring a large group of them together and brainstorm. You can hold one-on-one interviews or maybe one on two or three interviews where you are just writing all those requirements down. You can hold focus groups, you can send out questionnaires and surveys. Sometimes a questionnaire or survey is a very easy first grab to kind of give you the initial direction so that when you hand have these brainstorming meetings, you kind of know a little bit about what they want before you walk into a brainstorming making or a focus group so that you're asking the right questions rather than starting at the very beginning. The requirements gathered should be analyzed, determined if they fit within the project charter. Sometimes you're going to get a, somebody's going to say, I really want it to do this and you look at that charter and you go, that's not the purpose of this app and I appreciate that you'd really like it to do that. And we will note it as one of the requirements and maybe down the line we can handle that. All requirements may or may not make that final scope. And the project manager possibly working with the sponsor and the project team will determine the status of each requirement. Ultimately, the project sponsor has the main authority for rejecting requirement. The project manager can, but often if you get the support of the sponsor, because the sponsor's usually the person who's spending the money and they're seen as a higher authority. When you have to go back to that stakeholder and say, I got these requirements, but we just decided not to do this, and I've discussed it with the project stakeholder and we think it's best that we just don't include this particular requirement, it comes over a lot easier. And you'll see that once you get that project sponsor sign on, it's a lot easier for you to explain why. And it's not that it's easier to explain, you could have explained it before, but you kind of have somebody behind you going, you know, he said or she said, you know? So anyway, in predictive environments, all the approved requirements are documented and used to define the scope during project planning. But in an agile project or in an adaptive project, once again, it's refined over time. You might document the requirements and only have partial requirements and identify new requirements as you go through. And you may also only include a few requirements in the current cycle that you're going to complete. And that's just part of having an adaptive project. Now, you often can use diagrams, charts, or prototypes to provide a model of the expected project scope so that you can get a better picture of where your requirements are fitting in. And when you have requirements that are made on the project, you often will classify them into different categories. The categories may be a business requirement or it may be a stakeholder requirement, or it could be a quality or functional requirement. You sometimes want to give the reasoning behind them. A business requirement may be a little harder to deny, but a stakeholder requirement, especially if it doesn't really have a business requirement or a business need behind it, is a little easier to decline. So that's part of the reason why you kind of class them into areas. So you know, oh, this particular requirement is a business requirement and I just don't really know if we can ignore it because the business really needs this. Now, once the requirements are fully documented, the project manager is ready to define your scope and you define the scope usually with the help of experts in the particular knowledge area, particularly in similar projects. The project manager isn't always the expert in whatever you're creating. The project manager is an expert in managing projects, but they don't have to be an expert in whatever you're doing. That project manager may have never typed a single line of code. That's me. And your project manager may actually be of the opinion of, "Ooh, code." That's me again. So, you know, but they don't have to have code. That's not why they're there. They're there to manage the project, to keep the project team members on track, to keep everybody working together and to keep everybody informed. And that's okay. So oftentimes project managers will engage SMEs and they may even bring the project team in, especially if you're doing an application development project. The team understands coding and the writing of applications and then the releasing of applications. So you would bring those other people in to help you take those requirements and turn them into scope because you will develop from that a detailed scope statement that is an overarching statement that includes all of the things that you want included. Now, it's not details yet, it's still a high level. If it's an application, you might define the things you want that application to do, but you're not necessarily defining how you're going to do it or the individual tasks that are involved yet. That's going to come. Just wait. So basically, defining the scope is all about giving you that starting point so that you can start creating those activities. And remember, again, the project manager in most cases is there to guide, but often is not a authority, own the scope itself. They're just there to make sure that you can come to a consensus and get the scope thoroughly defined. - Wow. Okay. I'm so grateful for these bonus episodes because like you said, even though they're not in the objectives, this is really leading us to a greater discussion. And the more information we have, the more knowledgeable we can be. So please stay tuned for our next episode. We've got more coming your way. - Thank you for watching ITPro TV.