Author: Walter Stinnett

Walter Stinnett serves as a Program Manager for Edwards Performance Solutions. He manages a large federal government training contract and teaches primarily Microsoft Project and project management courses. He joined Edwards in 2004 as a Project Coordinator and Scheduler and provided project planning and scheduling support to a variety of commercial and federal government clients. Walter’s certifications include the PMP and MCTS.

Requirements Management Panel Discussion – Transcription

Please find below a transcription of the audio portion of Walter Stinnett’s Requirements Management Panel Discussion, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience. Melanie: Welcome MPUG community and welcome our panel of presenters that you see up on the screen here today. We are doing requirements management Q&A. Today’s session is a panel discussion and we welcome you to join in. To that end, we will be sending an always adorable MPUG pug and matching USB drive to several audience members that ask questions to our experts. You can post questions to the question chat window that you could see up here on your screen, and our organizers can read those out during the session. Or you can also see the hand raised option there. If you click that, you’ll come up to the top of my Q&A poll here and unmute yourself, and then I will unmute you as well and you can join in the discussion directly. Melanie: Now I’d like to introduce our organizer and driver of this event, Walter Stinnett Jr. Walter serves as a program manager for Edwards Performance Solutions. He manages a large federal government training contract and teaches primarily Microsoft Project and project management courses. He joined Edwards in 2004 as a project coordinator and scheduler and provided project planning and scheduling support to variety of commercial and federal government clients. Walter’s certifications include the PMP and MCTS. You can view his requirements management course on mpug.com on demand anytime. I think we have four or 500 people in there enjoying that course right now, so thank you, Walter. I am going to hand this session over to Walter. Walter, you should be up. Walter Stinnett: Let me unmute my microphone. Welcome everyone to our requirements management Q&A and panel. This is where we’re going to be answering all of life’s questions. We’ll be glad to do any life counseling here while we’re on, of course I’m just kidding. But thank you for joining us. Melanie, I want to thank MPUG for this opportunity as well to be able to speak to you answer your questions. Requirements are very important. In fact, I think they are right at the very top of the list of some of the most important things that need to be done in a project. Because if you don’t have proper requirements, you won’t really be able to fully and successfully understand the scope of your project and to be able to implement your project. Walter Stinnett: I am joined by some of my colleagues, and I’ll give them an opportunity to introduce themselves here in just a moment. Melanie, just a little bit of an update in terms of my position. What I’m doing is that we won the follow-on contract to the one that I’ve managed. I am actually there at the client’s facilities helping them with their training programs and such. Interestingly, that really fits right in with the requirements because on a continual basis I have to understand what the requirements are. I’m still a program manager. With that being said, let’s go ahead. I’m going to give everyone the opportunity to introduce themselves and I’ll start down here with Jeff. Jeff, if you’ll go ahead and introduce yourself, then we’ll go to Jana and then Mary. Jeff Bongiovani: Certainly will. Walter, minimize your email. Sorry. All right. Well, good afternoon everyone, or morning, or evening, or whatever time zone you happen to be in. I’m Jeff Bongiovani, I’m the manager of training and development for Edwards Performance Solutions. I lead a team of designers and facilitators to design, develop, deliver courses, both for external as well as internal customers. Edwards currently offers a library of like 50 plus courses focusing on the fields of project management, systems engineering, leadership, business process improvement, and cybersecurity. Before my time with Edwards I served as a software technical programming and business skills instructor with a global training company for about 17 years, as well as taught in-home piano and trumpet lessons for children and adults. That’s the gist of me. Jana Meacham: Hi, my name is Jana Meacham, I am a project manager with Edwards Performance Solutions. I’ve been here since 2012, currently assigned to Center for Medicare & Medicaid and working on continuity operations and pandemic planning, which is very timely. I’m a certified project manager, PMI, ACP, scrum master, and I’ve also had training in change management through a couple of entities most particularly Prosci, which is a change management research organization. That has been my passion as well as project management. I thank you, I’m looking forward to this today. Mary Holland: Hi there I’m Mary Holland and just to confuse you on the screen, so my name’s on the screen, but Jana and I decided to share a room. But anyway, I’m Mary Holland. I serve as our Edwards Management System chair and the Edwards Management System is our quality management system. Were ISO 9001:2015-certified, and also appraised at CMMI version 1.3 level three, that’s a capability maturity model. I shepherd that and our suite of policies and processes, as well I’m the quality assurance manager. I have worked in federal, state, local government. I’ve consulted, I’ve worked at not-for-profits and also in the corporate world, so I have a different range of experience and perspective. Walter Stinnett: Thank you, Mary, Jana, Jeff. We have a broad spectrum of expertise here. I think that if you have a question, begin to think about it. If you have any questions, go ahead and put them in the question box or raise your hand so that Melanie can take you off of mute to interact with us to ask a question, feel free to do that. We invite you if you have any questions to do that. As you are writing your questions, thinking about your questions and such like that. Let me just mention here that if you take the course that I have up on MPUG, that is based upon the PMI, Project Management Institute’s processes for requirements management. There are a number of different types of processes and steps to go through. Walter Stinnett: Now, we know how important requirements management is. In fact, if you look at the pulse of the profession, which is an annual poll that PMI does that in 2019, probably around 30 or so percent of the projects failed. One of the main reasons that they failed was due to faulty requirements management, so we see how important that is. In fact, really, if you don’t do the requirements, you won’t be able to define the scope of your project. That’s going to be, it’s just very, very important to be able to understand the requirements. Any questions at all? Any questions. Melanie: It is quiet from the audience so far, Walter. Walter Stinnett: Okay, no problem. No problem. Jeff Bongiovani: Well, I’ll ask a question, Walter. Walter Stinnett: Go right ahead, Jeff. Jeff Bongiovani: When they conducted that survey and they’re talking about faulty requirements management, what does that mean? Faulty requirements management was a matter of documentation, proper elicitation. What do you believe would be faulty requirements management? Walter Stinnett: That’s an excellent question, Jeff. Jeff Bongiovani: Thank you. Walter Stinnett: When I think of faulty requirements management or faulty gathering of requirements, I think it goes back. It can be any number of things along the step of the way, along the way towards having documented requirements. One of the very first things that needs to be done, which is a requirement, is to understand who your stakeholders are. If you don’t understand who your stakeholders are, then you will not be able to really understand what the needs of the organization are. It can go back to that. It can go back to faulty, not understanding who your stakeholders are, not communicating with them. It could be that once you understand who your stakeholders are, you’ve got them because you want to make sure that if you have any types of meetings, brainstorming meetings or anything like that, that you have the correct stakeholders involved. Walter Stinnett: How many of you have ever been in a meeting where you didn’t have all of the stakeholders or the correct stakeholders? Well, that meeting is useless. It’s just useless. So understanding going back, if you don’t have that, that could be [inaudible 00:11:17] faulty. You really have to step out on the right foot right from the very beginning. If you know your stakeholders and you have all of your stakeholders, and you understand who they are, having then making sure that the elicitation process that you understand fully what the stakeholders needs are, and that you’ll be able to ask the correct questions to be able to get the information. Those are some of the things and there’s many other things. Walter Stinnett: We’ve got a couple of comments here and I agree absolutely here. We’ve got, [inaudible 00:12:06] says, “It sure was a useless meeting without all key stakeholders,” absolutely correct. We’ve got Brian who says, “I find that requirements are often written too vaguely. I believe that there should be some great detail in a requirement. How much detail do you suggest to make it a good requirement that is testable?” That is an excellent question. Let me just open it up to the floor. Does anyone have a answer to that? How much detail do you suggest would make a good requirement that is testable? Any thoughts? Jeff Bongiovani: Well, a vague way to start that might be, know your audience. I mean, it’s quite different. If I’m asking let’s say, “Walter, will you help evaluate this course, this presentation?” Now, there’s a given assumption because I know you’ve evaluated courses before, you know what to look for, you know what things to find. But there are instances where you would have to write out a checklist or a list of standards. These are the things we’re looking for, here are the examples. If you find an example of this, we don’t want it. So point it out or correct it, that sort of thing. It very much does stem from the audience, whomever you are designating to do that. Jeff Bongiovani: I think it also depends on the type of project, I mean, or the assignment itself, or whatever the thing, the schematics are. I mean, if we’re talking about technical drawings and architectural design and engineering, yeah, you have to have a certain set precision with those. But as we move into things like, well go ahead and make a two-hour course on, X, Y, Z. Yeah, and just make sure it’s snappy. It’s snappy, what does that mean? Cite examples, show me samples, that sort of thing. Walter Stinnett: Yeah. That’s a good point, Jeff. Yes. Go ahead, Jana. Jana Meacham: Yeah. I just wanted to share an experience I had previously that may help with this. I agree, the stakeholders need to be in the room but defining the stakeholders is the key. My background is healthcare. I’ve worked on a hospital-wide computer implementation. In 1998, believe it or not, there was not an entire hospital-wide system at that point, and I was responsible for two modules. One was diagnostic imaging, one was scheduling. When I built my team, I chose the people who were doing the work. That meant at that time film librarian because they still used film, receptionist, technologist, physician. Receptionists, because they are often the people who are never asked how things should work, but they are the people who can provide the [inaudible 00:15:25] advice. It actually worked really well. Jana Meacham: That was before I actually studied change management and project management. It was probably coming out of my experience of having to live with changes that somebody else decided that I should have. My goal was to do it differently. Now, in terms of how many requirements, it may depend. If you are using agile, you’re not going to necessarily have a lot of requirements at once. It’s going to be fluid. Agile may or may not fit every type of project, we know that, but it can be very effective. That also, again, brings in the people who are doing the work into the room so that they can help share their expertise and help design the change. Mary Holland: I think, just add on to it, this is Mary. Sometimes you can have the right stakeholders but they may not even know how to describe what they want or what the requirements are. If it does happen to be an agile project that’s great, because every couple weeks you’re going through, “Okay, this is what we’ve got so far. Is this looking like what you wanted?” And they can give some feedback, and that helps feed into the next cycle. But even if you’re doing waterfall, I mean, it’s really important I think when you write the requirements. Or let’s say you’re receiving the requirements from a stakeholder that it be a two-way street, and that there are some checkpoints where you say, “Okay, this is what I’m reading or hearing. This is how I interpret it.” So that you can confirm that you have a shared understanding of what was said. Mary Holland: As far as level of detail, one of my favorite examples is my husband is an electrical engineer and he put a new toggle switch on the wall so that it would work with our outlet, which was great. Functionally it works. Unfortunately, he put it like two to three feet in the wall so the picture I wanted to hang there is now higher than I wanted it to be because he didn’t really consult me on that. There are sometimes unspoken or unknown requirements until you’re down the road. As much as you can try to brainstorm and anticipate what might come up for whatever the scope of your service or product that you’re developing is that’s helpful too. Walter Stinnett: Great. Thank you, Mary. Yeah. I think all of that is very important to understanding the detail that needs to go into your requirements. One of the thing here is that to understand is it testable in terms can you… if you have a set of requirements, which are the capabilities, the conditions that are needed to meet a stakeholder need are for whatever specific product service and result that you are developing, you’re going to deliver is, can you write success criteria for that particular requirement? When you look at that requirement, is it written such that someone can come in and they can read that particular requirement and understand actually what it’s needing? In other words, if there is some ambiguity, if one person thinks that has an idea as to what it might mean, and another person has another interpretation. Walter Stinnett: Well, that is just one little test right there that you can have that might tell you that maybe the requirement is not as specific as it needs to. For example, if you have a user story, it might be written in such a high level that someone might say, well, there’s a lot of things that need to take place to be able to actually fulfill this particular user story. Well, that user story might actually be what it was called in epic, and it’s at a higher level. You could probably break that down into more bite sized types of user stories and such. Absolutely great answers and great question. We have another question from Linda here and she asked, “Yes, I was going to ask that question. How are some ways you can tease out actual requirements from a stakeholder that is not sure of what they want? I want a painted rock, what color? I don’t know, just bring it to me and I’ll tell you if it’s right.” Walter Stinnett: That’s an excellent question. I think that probably many stakeholders, they might have an idea of what maybe they want but can’t really express in detail. Well, I think that one of the things that can happen, and everyone here can also join in as well and answer the question, is that you need to think about a plan. First of all, when it comes to elicitation is understand the objective. Understand what information that you are actually wanting to derive from that stakeholder be specific in that. Then once you know that overall objective… let’s say for example the project is to upgrade all of the computers in your organization. Well, an objective might be, just throwing this out here, is upgrading computers with the new operating system for this department. Walter Stinnett: Well, that is an objective, then you can begin to focus in on what are those questions? How many computers? How many people are needing the computer? Are there any other types of changes? You can begin to think and brainstorm the questions that need to be taken. Even while in an elicitation meeting, don’t just stick right to those questions. If there is something, if someone answers the question and then something comes up, then ask it because all of these questions that need to be asked to get the information you need to do needs to be at every level of abstraction for that particular product service and result. That would be my answer to that question. Anyone the panel, do you have any recommendations? Mary Holland: Chances are, if a customer is working with you, you have some expertise or skill that they’re seeking. You might have experience working with something similar, if not exactly the same, and coming up with the dimensions. In Walter’s example for a laptop refresh, you can think of size, connectivity, user interface, compatibility across laptops, all kinds of aspects of that that you’d want to brainstorm and think through and make sure that you understand what the customer needs are for that. Similarly with any product or service, you can really… like the painted rock example. Okay, we’re talking about paint. There are different types of paint. Talking about different application styles, there are different sizes of rock, different content of rock. Mary Holland: There might be a cost-limiting factor that you know and that’s going to drive some of that. You can always for sure consider cost and time when you’re determining requirements and the laptop example or the refresh, maybe it needs to be done in three months and you know a certain product isn’t going to be available for six months. Those are some thoughts on that. Jana Meacham: [inaudible 00:24:01]. Walter Stinnett: Jana. Jana Meacham: Yeah. Walter Stinnett: Could you do me a favor and speak up a little bit louder there since you’re not right in front of Mary’s computer here? Jana Meacham: Okay, [inaudible 00:24:16]. Okay. One of the things I learned is simply the five whys and that can be applied to [inaudible 00:24:22]. But it’s like, I need this rock. Well, why do you need it? Well, I want to paint it. Well, why do you want to paint it? Well, I want to paint it, my daughter wants to paint it. Well, why does she want to paint it? Well, she wants to put it into this rock garden along the street. Well, is it a color? You keep asking, keep talking, but really the five whys or again the five hows makes people think more about why they want something instead of just saying, “Well, I want this, go do it.” That’s one thing that I have found useful at times. Walter Stinnett: Thank you, Jana. All right. Great question. This is a good one going back to stakeholders from Hannah. “How do you combat stakeholders simply not engaging? We recently rolled out a new project management workflow and early in the implementation our groups spoke up and said their step wasn’t included and it should have been. However during the planning gathering meetings they didn’t say anything. This isn’t an easy task or a step to fix.” Good old stakeholder engagement. I think all of us have had in some way, maybe the experience of stakeholders who aren’t fully engaged. I want to open up to the panel. Do you have any thoughts on that? Mary Holland: Definitely getting sign-off on requirements is important. Those stakeholders were at the meeting and they were silent. They could still be asked to sign off on, okay, “Here are the requirements we had,” and they could sign off on it. Depending on the relationship, whether it’s contractual or working relationship or whatever, you can… we’re working with an outside vendor right now to finalize some training, and they are very clear. They give us plenty of checkpoints to reflect back where there are changes, but they’re very clear about, “Okay, at this stage we wouldn’t expect more than 20% changes. At this stage 10%, and at this stage there should be none.” It really helps to set up expectations along the timeline as well for the reviews. Wouldn’t you agree, Jeff, that’s helpful for them? Jeff Bongiovani: Most definitely, yeah, I was going to mention that. It certainly is as the matter of sign off. Then it goes to the other question as well, what do you do when the customer doesn’t really know what they want? A lot of times people don’t know what they want until you give them something that they don’t want. They look at it it’s like, “That’s not what I want.” If it’s feasible to have prototypes, to have… for example in that one review you’re talking about Mary, they actually did send a template prototype. It didn’t have all the content in it. It’s like, do you like the way this looks? And we were able to give feedback which then informed them, “Okay, we got to change all of these things out there.” Yeah. Being able to have in the face of the customer that’s more frequently [inaudible 00:27:59] to change their mind you have to take smaller steps. Jeff Bongiovani: That means you have to have more or greater iteration and samples. But I was thinking when that question was going around as well, it’s like, oh, we got to pick out a carpet for the house. What does the person do? They come to your house, they give you all these samples of carpet. “Go ahead and feel it,” that sort of thing. It’s a little different when you walk in the whole room and it’s covered in that carpet. It’s the same thing when you want to buy a house. So what do they do? Do they just describe the houses? No, they take you to the house. You walk through the room, “I don’t know if I feel this. Oh, what are they doing over here with this?” That sort of thing. You need to provide the customer with the experience of the end product as best and most feasibly as you can and just work back from there. Mary Holland: Speaking of samples, in the training example I was using where we’re working with a vendor. I mean, so there was the look that Jeff was describing before they even got into investing a lot of time populating with content. They checked the look, but they also gave us audio samples, “Whose voice do you like?” They’re really thinking about what are all the dimensions of a training experience? Whatever service or product you’re providing, you need to think about or know what are all the possible dimensions of interest in my user’s experience? Jana Meacham: This is Jana. Something that, again, I’ve done in the past, and this may or may not work depending on the size. But if people don’t speak up in a meeting, for whatever reasons, they will lose out. It’s often the same people speaking up in a meeting. I have used silent brainstorming. I’ve used it for risk management and I have used it with high level requirements management. That way, so you go through the process where they can write down what they want, what they think they need. Then you do the usual steps of organizing and collating. You could go into voting if you needed to, but that helps the people who either they don’t feel the power to speak, they’re nervous about speaking, or whatever it is. It helps them also participate and it levels the playing field. Jeff Bongiovani: I just want to add one more thing. Not to keep on going with the whole training thing that we’re experiencing, but that comes to mind is one of the concepts within Six Sigma which is the CTQ or critical to quality and building what is called a critical to quality tree. Whatever you’re producing, product or service, there are certain key points. For example, the voiceover is probably more critical to quality because you’re going to hear that for 45 minutes. You’re sitting through an electronic training. You’re going to hear that voice for 45 minutes, so that better be on point. That better be something that you can all agree upon, that you have an idea what everybody’s going to like. As opposed to, well you know that little square in the corner there, that should be pink instead of green. Not really going to matter. Jeff Bongiovani: I don’t know if somebody’s out there complaining, “You know what? That should have been blue instead of pink,” and stuff like… no offense if you review the training and you said that. But the point of the matter is, there are certain key elements of the product or the service that you’re providing that you know are more integral, going to have a greater amount of effort to correct in the long run, are going to be more [inaudible 00:31:58] you could say the volume of effort to produce it. Things that for the most part will be representative of the product or can undermine its entire quality. That’s where you start to think, “Okay, well, if they’re not going to answer any of the other questions or not bring it up, at least I can list those things that are the highest critical to quality features and try to be more proactive about getting those answers.” Jeff Bongiovani: Which the third party developer really did. They sent out I don’t know how many different voices, male, female voices. We had a little championship where it’s like, oh, it’s between these two. It’s like, who is it going to be? We did a voting thing. That’s critical I think. Walter Stinnett: Great. Thank you all. Yeah. Along the same lines with Jana mentioned the silent brainstorming. You have things which is similar like the Delphi technique, which is you send out an anonymous email to get people’s feedback and for their requirements. Then you collate that and you send that back out anonymously. That way you can eliminate if there’s anyone who is… everyone is on an even playing field, you don’t have someone dominating the meeting or you don’t have anyone who is afraid to speak up. So excellent points everyone. From Laurie, “As a project manager and given a new project on a topic you’re not familiar, you don’t know what you don’t know. How do you know what questions to ask?” This is similar to our earlier discussion. Walter Stinnett: For example, software implementation project for a system you’re not familiar. You need to understand the current. See Laurie put this in all caps, current business process first. It hours of jumping into understanding the business need before determining how to implement a change with a project team. Yeah, I think we all agree with that, that you need to understand. Whether you are working on a project for a client or whether it’s internal, it’s not like, “Okay, well, we have a need and we’re going to talk about.” This goes into organizational change and change management, and we’ll talk about that here in just a moment. But the whole aspect, the whole emphasis of a project is change. Taking where you are, your current state, and moving to a future state. Those requirements will really, they’ll be dictated in terms of where you’re going to be going. Walter Stinnett: So it’s not like, okay, well we know basically what is needed. Then, okay, let’s go ahead and start gathering the requirements. No, there needs to be time taken to be able to fully understand that need. Yeah, I believe that we all agree that if there’s something that you are not familiar with, that you need to understand, the question is so how do you know what questions to ask? I think the answer to that is, ask questions. That might seem a little bit simple there, but ask questions. These may not necessarily be the exact questions that you’re going to be elicitating the requirements from, but understanding really what is behind the stakeholder’s thoughts in terms of why they want this particular change, why they want to implement this project. Don’t just talk to just one person, talk with more than one person to try to get those questions. Walter Stinnett: It might be, as we’ve mentioned before, as I mentioned earlier, is that once you are asking these questions, you’re actually in a formal elicitation process, then the answers that are given may actually… other questions might come to mind that you might ask. It’s going down the rabbit hole of understanding all that is needed for that particular project. It’s not necessarily easy because, yeah, you may not necessarily know. But if you get a full understanding as much as you possibly can on the project or whatever, the product, service, and result that you’re wanting to deliver, then you can begin to understand a little bit more about what questions you should be asking and what direction you should be going to be able to gather the requirements that are needed. Any thoughts? Any other thoughts from anybody else on the panel concerning that? Mary Holland: One of my initial thoughts was Google and YouTube can be your friends. Part of what I was hearing is feeling like you had enough comfort about what the content of the implementation was to be able to support a group. But I mean, you’re going to have some of the similar steps through any implementation, whether it’s software or probably even something else. There are going to be some comparable steps. It may just be giving yourself some level of comfort about the specifics, if you will. I think you’re on mute, Walter. Walter Stinnett: Thank you. Yeah, those are excellent questions here. We’ve talked about questions here, we’ve talked about stakeholders and such. This next question from Farhan, Farhan, I hope I pronounced your name correctly, is, “Additional requirements during project execution leads to scope creep. Is there any recommendation to mitigate such risks?” Well, I think this goes to what we call, which is a very important aspect to project management of requirements management. You really aren’t doing requirements management unless you have a requirements traceability matrix. A requirements traceability matrix, however detailed it might be based upon the complexity of your project, is a way to be able to track your requirements through the entire life cycle of the development of the project. If you don’t have that documentation, then you will not be able to know. At some point when you have your requirements, you’ve come to a specific point. Once you have your requirements, once you’ve written the requirements out, you’ve gotten approval from the stakeholders, then those requirements are baseline. Walter Stinnett: Once they are baseline then that would be a way to then be able to track those requirements through the life cycle of your project, so that you’ll be able to know if there’s additional requirements. Then it goes back to understanding who your stakeholders are and how to engage them. Have you ever had a stakeholder who you’re four months into a project and they come to you and they say, “Well, we have a change of priorities here.” Well, do you just absolutely say, “No, we can’t do that.” No, you’ll need to go back to your team and discuss them and then be open with what the actual risks are and the impact. But one way to just keep from, to make sure that you need to have everything documented as thoroughly as possible so that you understand the requirements that you have baseline. So that you’ll know that you’ve got to do requirements of trying to be included into your project. Any other thoughts from the panel on that? Mary Holland: My thought is scope creep may not necessarily be a bad thing if it means a product or service, someone’s going to prefer more. As long as the stakeholder understands what the schedule or time, and resource, or cost impacts are. You’re going to need me longer on this project and it’s going to push out the delivery a month or whatever. If they’re willing to accept that, that may be okay. But if cost and time are key drivers, then I think you just need to have tools to be able to show very clearly what the impact is and what the constraints are around any nice to have versus need to have suggestions. Walter Stinnett: Very good. Thank you. All right. Those were excellent questions. If there are any other questions that you might have, feel free to write them into the questions or raise your hand so Melanie can open up your mic to speak. But let me ask this real quick like, we’ve talked about change and really that’s what the project is all about is impelling change. It is going from the current state. You have some need that is motivating the organization to improve however way that they might need to, or you might be needing to develop something for a client but at the end there’s going to be some kind of change. This is really key. I want to give, Jana, if you wouldn’t mind. Jana is our change management SME here is, what types of maybe thoughts or things that you might be able to share that would help the organization to accept change. That would help them to move in that requirements process knowing that the whole purpose of that is to define your scope, to develop a project that in the end there’s going to be some kind of change. Any thoughts there Jana? Jana Meacham: Yeah. I think having a good sponsor is key because a good sponsor is going to help break down barriers. They’re going to mandate if necessary. They’re the person who should be, they need to have the authority at that level to make the change. If needed, to work with other people in the organization and say, “Yes, we’re doing this.” Change management is both the hammer and the carrot, the stick and the carrot. Sometimes you don’t want to do the change, but sometimes it’s necessary, and so that sponsor can help with that. However, if it’s a change that is not critical, that again can be, I’m just trying to think of experiences I’ve had, something that can just be put in place. In other words, there are some things like when we get new computers, we just get new computers. We don’t put in our order for the computer. Jana Meacham: However, once we get our new computers… sorry, there’s a fire engine going by here. Once we get our new computers, if we need some modification to we have a great IT department, they’re willing to work with us. That is a change that is both dictated and flexible. But again the sponsor, and don’t hesitate to tell your sponsor what you need. I worked with a team on doing a change in records management file management, and they had files were everywhere. They couldn’t find what they needed when they needed it. So I was asked to be the PM on this project. I did go to the sponsor and I said, “I need you to be present at least occasionally at the meetings. I need to make sure that people understand that what we’re doing is critical,” because it was critical, and he was great. Jana Meacham: He didn’t show up at every meeting, but he did show up enough that people knew that the change was coming from his position of authority. While there was flexibility in a lot of the requirements, the change was going to happen. So use your sponsor. If you’ve got a good one, that is really going to help. If you don’t have a good sponsor, that’s a challenge. I think that makes it harder. Sometimes that is the case. Work within your organization. If that’s a concern, then use whatever resources you have to let that concern be known and maybe someone else would be put in that position. Walter Stinnett: Great. Thank you very much, Jana. I appreciate that. Any other thoughts there Mary or Jeff on that? We’ve got another question to come in and this looks like a good question for Jeff here. Good. This is related. This is from Farhan again, “Can we manage requirements or requirements traceability matrix using Microsoft Project or still need to use something like Excel or any other product? Jeff Bongiovani: Yeah, it all depends. For example, we use a combination of both. It depends on the project. But we, for the most part, work within checklists, within Microsoft Excel. I’ve used Adobe Acrobat fill in the blank forms for QC efforts like going through a course and just ensuring, okay, this is there, this is there, this is there. That sort of thing. Microsoft Project is necessarily, it’s the estimation tool for the most part, if you did have schematics or other requirements. The problem is that the software instructors now taking over for a second. The limitation is that you don’t necessarily have much space in your notes, credible space in the notes section which you can add a notes field for your different tasks. You’re better off say for example, creating a hyperlink for each one of your tasks that takes you to an external file, like a word document or something like that, that lays out all of the various requirements. Jeff Bongiovani: Microsoft Project is fantastic, but you’ve got to think, the total potential behind it is making use of the other Microsoft products together. It’s the Microsoft team, or as they say, Microsoft Office not Microsoft individuals. Within that, yeah. Usually that which is easiest to send out, or communicate, or retain. Now on the other hand, beyond Microsoft Project, I think if you’re using something like let’s say Microsoft Teams where you could set up a workspace or SharePoint, you’re much better off having a system where multiple people can access the same file for contributions as well. You could set up a Microsoft project file to link to a SharePoint file or something like that, or a Teams workspace file. I hope that answers your question. I don’t know. But hopefully that helps. Walter Stinnett: Thank you, Jeff. Now, Jana, there at your does CMS and stuff like that. I’ve heard on several occasions some of the software that’s being used. Do y’all use, I know there’s Jira, Confluence. Is there anything else that you all use? I know that you’ve done for requirements. Jana Meacham: Not that I personally have done. I do know that some of the groups have started using Box as well because SharePoint can have its limitations. But the challenge of course is to keeping everything within federal guidelines for security. That always becomes a bit of a challenge, security, protecting information, all the things that government is required to do. Yeah, you mentioned Jira. Some of those are in use, so there’s, SharePoint’s the big one that I’ve seen, but there may be others because I don’t work on the IT side, so I don’t know exactly what they may be using. Walter Stinnett: Thank you, Jana. Mary Holland: I think the key there, and Jeff mentioned it too, it may depend on what is your stakeholder used to understanding or what works for them so that you can communicate? It might mean you need to adapt and learn a new tool or you could go to some common denominator like Jeff mentioned Excel or Word or whatever. But I think making sure that the consumer of the information can actually use the tool I think is really important. Walter Stinnett: Yup. Thank you all. Continuing on in the theme of monitoring control and we’ve talked about just briefly about the stakeholder, the business need, elicitation, a little bit about documenting the requirements and stuff like that. I mentioned the requirements traceability matrix when it comes to monitoring and controlling. We need to monitor and control our risks. The primary way that we can do that is through the requirements traceability matrix. Staying on top of that, ensuring that your requirements, that your product is still meeting the requirements that were originally set out. That really goes through the beginning of the entire process all the way through to the development of and the implementation and the delivery of that product when it comes to quality. If you are familiar with the triple constraint, which is scope, time, and cost, well, if you’re familiar with that little graphic with scope on one side, time on the other side, and cost on the other side, usually we’ve seen it and we’ve used it where there’s quality right in the middle. Walter Stinnett: Quality is going to be really very, very important. Mary you’re our quality SME here, not to say that Jana and Jeff aren’t SMEs or anything like that when it comes to quality. But being that you’re our quality manager, how important is quality through the whole process of requirements management through the implementation of a project, and even afterwards. Mary Holland: Right, right. I think all the things we’ve been talking about are components of ensuring quality, like having your requirements plan and using whatever tool is agreed to the requirements matrix whatever. Then along the way having those reviews, whether you have internal peer reviews before you then have some external reviews, those are really important. I think you need to have a list. I’m looking from your course, Walter, there were quality attributes of requirements. I think you need to, for any given project or service, determine what are the attributes that are important, and then keep checking on those. As far as risk goes, transparency is really important in managing the risk of successfully addressing the requirements. Mary Holland: It may be that there are some where you have more latitude and it’s okay if something happens to just accept it and move on. There may be others where you need to work and get ahead of it to come up with plan A, B, and C to make sure that that requirement is addressed. I don’t know if that exactly answers your question, but quality is no more than really making sure you understand the requirements and then mapping them out, and then following that map. Walter Stinnett: Thank you, Mary. Yes. Any other thoughts here? We are winding down. Let me see. Melanie, is there any person who wants to ask a question or is there any question that may have come in in chat or anything like that that I may have missed? I want to make sure that we capture every question here Melanie: We are a little shy today, Walter, we have no hands raised yet. You have done an excellent job. You’ve handled every question that’s come through chat. Thank you. Walter Stinnett: Yeah. You’re welcome. You’re welcome. Great. As we wind down here, it is almost one o’clock. I want to thank everyone for your questions and hope that what we have been able to share has been helpful to everyone. I guess to wrap it up here, I think I want to just mention how important communication is. I think it really goes back to communication. Of course we’ve mentioned about understanding, being able to understand who our correct all the stakeholders are. But if we don’t, even if we have our stakeholders and there really isn’t a specific being very important in terms of communicating, then that is going to make it really difficult to really fully understand what our requirements are. We’ve got about four minutes left. Is there anything, maybe last words, that any of our panel would like to mention just really quickly? If not, that’s perfectly fine. Mary Holland: No, thank you. It’s been an enjoyable discussion. Jana Meacham: Thank you. Walter Stinnett: All right. Well, Melanie, there’s a few more minutes left. I’ll hand it back to you and thank you for the opportunity to be able to have this panel, to have a discussion on requirements management, and also feel free to contact us. Contact me if you have any questions. Melanie, I believe that there is a little comment section for each of the courses that you can add things in there as well if I’m not mistaken. You can correct me, Melanie, if it’s wrong- Melanie: They can comment directly to you on the course. If any of you would like, I can send out your contact information with the follow-up survey. A Very big thank you to you all today. You did an excellent job. We haven’t been open for this kind of live panel discussion in a long time, so thank you for putting ourselves out there. It was wonderful. A huge thank you to the MPUG community for attending live today, and those of you who watch on demand. I will be sending swag to everyone who’s asked questions today. Thank you for choosing to learn with us. As I mentioned, I’ll also be sending a survey shortly. Please let us know what you thought of today’s format. Melanie: I’ll quickly draw your attention to the screen here. Next week we will be doing the same thing, we’re going to talk about, we’ve taken your frustrations, misconceptions, and consolidated those. We have speakers coming to talk with you in a panel discussion again on those frustrations and misconceptions and how they make users suffer. We’ll have a senior program manager for Microsoft there joining this discussion. Come with your questions, come ready to join us. I will pop the PDU activity code up here on the screen in a minute, and I’ll leave it up on the screen until the end. Again, thanks to our presenters. Great job today. Walter Stinnett: Thank you very much, Melanie. We really appreciate it. Jeff Bongiovani: Thank you.

Requirements Management Panel Discussion

Event Description: Join us as we open the floor for Q&A on the topic of Requirements Management This session is a follow-up to Walter Stinnett’s Requirements Management Course.  Watch Walter’s course on demand now. Learning Objectives: Project Management Institute (PMI)® Professional Development Units (PDUs): This Webinar is eligible for 0.75 PMI® PDU in the Technical category of the Talent Triangle. Presenter: Walter Stinnett serves as a Program Manager for Edwards Performance Solutions. He manages a large federal government training contract and teaches primarily Microsoft Project and project management courses. He joined Edwards in 2004 as a Project Coordinator and Scheduler and provided project planning and scheduling support to a variety of commercial and federal government clients. Walter’s certifications include the PMP and MCTS. Have you watched this webinar recording? Tell MPUG viewers what you think!

The Importance of Considering Quality and Change in Requirements Management

Introduction Requirements are the basis of any project. When developing products or services, defining requirements are critical to successfully satisfy project needs. To define the project scope and fully build out a work breakdown structure (WBS), you must first learn what stakeholders require. A clear understanding of project objectives is key. Once you grasp them, you can begin to translate them into requirements. The Project Management Body of Knowledge (PMBOK® Guide) defines quality as “the degree to which a set of inherent characteristics of a product, service, or result fulfills the requirements.”  Successful delivery of products or services is linked to quality – adhering to the requirements, both formal and informal. Documenting Requirements When you document requirements, be sure to confirm mutual understanding with your stakeholders, including establishing customer acceptance criteria. Those criteria may include satisfying specifications, complying with internal and external standards, and meeting any deliverable timing constraints. Acceptance criteria help set and manage stakeholder expectations and balance needs and constraints. Using standard, repeatable processes can help prevent rework and defects. Every step along the way, track risks and communicate them to the customer and relevant stakeholders. Before delivery of a service or product, verify work products satisfy requirements. Verification and Validation Verification and validation are important tools to ensure customer satisfaction. Verification can ensure products and services meet customer requirements, identify issues early, and prevent rework. Verification tools include ongoing quality assurance and quality control, peer reviews, and testing. Validation ensures a product or service will function as intended in its specified environment. Some ways to validate services include final customer acceptance, customer evaluations, and operational lessons learned. Managing Change Creating change is the driving force behind most projects, but organizations must first understand their current state to define a desired state. Requirements are the result of knowing where they want to be in the future. All projects include some element of change and most of the time that change directly impacts users and stakeholders – you know, those people who can make or break projects. Whenever people are involved, managing change is as important for long-term success as managing scope, requirements, schedule, and budget. For busy project managers, I propose some easy steps to take when managing change: Organizations proactively managing change, as well as projects, gain a competitive industry advantage. Conclusion Requirements management is an essential aspect of any project, and when done correctly, it can ensure customer satisfaction and project success. Managing change is also crucial in order to stay competitive and adapt to the ever-changing world. For more information on requirements management and change management, visit PMI.org and MPUG.com for articles and resources on the topic.

Project Requirements Management – Part 3: Monitoring and Controlling Requirements Transcription

Please find below a transcription of the audio portion of Walter Stinnett’s session, Monitoring and Controlling Requirements, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience. Welcome to the final part of my three-part series on project requirements management. This presentation, we’ll be discussing, monitoring and controlling requirements. And our lesson objectives will be, we’re going to define requirements traceability. Monitor requirements to ensure quality is maintained, and explore tools used to trace requirements. But before we begin with the material, let’s go over some quiz questions. Again, hopefully by the end of this presentation, you’ll be able to answer these. So our first question is, which of the following is a function of requirements monitoring and controlling? Secondly, what is requirements traceability? Traceability in an agile life cycle consists of? Rather, each requirement is not uniquely and correctly identified in a traceability matrix, true or false? Which of the following is not a change control tool or technique? Which of the following is a technique for minimizing requirements creep? What is the requirements management baseline? How are the requirements monitored and controlled in an agile lifecycle? Well, hopefully before the end of this presentation, you’ll be able to answer those questions. But as I begin, take a look at this little humorous graphic. You’ve probably seen this before and I think it really tells it like it is when it comes to a project where requirements and scope are not traced and monitored. For instance, notice the very first tile there, how the customer explained it. And then how the project leader understood it, how the analysts designed it, how the programmer wrote it, what the beta testers received, how the project was documented, what operations installed, how the customer was built, how it was supported and what the customer really needed was just that tire swing. So what went wrong with this project? Why did it start out with something that really wasn’t what the customer wanted and ended up, certainly, not anything that the customer originally wanted? And I think the reason being is that along the way, in this requirements management process, there was not an appropriate traceability and monitoring process set up. And this is a good illustration that monitoring and controlling requirements starts all the way at the beginning of the entire requirements process. For example, the very first tile here, how the customer explained it. Did the customer really explain it? I think that this was… It goes back to and as well as the second one, how the project leader understood it, goes back to the last presentation when we talked about elicitation. That you really don’t start writing are translating the requirements from the stakeholders until you have elicited and drawn out what you need so that you completely understand the intent of the stakeholders. And I don’t believe that this happened with this project at all. So I want to go back to a slide that we saw in the very first presentation, and it is the importance of requirements management, and specifically these statistics. This is from the PMI, pulse of profession survey and it says that 47% of unsuccessful projects fail to meet original goals due to poor requirements. And 39% of failed projects, identify in accurate requirements gathering as a primary cause of failure. Something is going on here. And the question is, what is it? What is going on? Why is there a 30% failure rate that are the result of inaccurate requirements gathering or poor requirements. And I think it goes back to this emphasis on monitoring and traceability. Because if you monitor and you trace the requirements, and we’ll get into what traceability is in a little bit, and what monitoring is in a little bit, you are ensuring through the lifecycle of the project that your product service and result is meeting those requirements, that you don’t have that uncontrolled scope creep. So you see here how important it is to have a proper requirements management process. The whole aspect of requirements traceability and monitoring falls under the scope control or the control scope process. This is where you’re going to be monitoring the status of your project, and product scope. And if there are any changes to the baseline, speaking specifically of the scope baseline, then you’re going to need to understand why it changed, what is the degree of the variances, what types of preventive and corrective actions you’re going to be needing to make. Where are you sending those change requests to, hopefully it is a change request board or change control board. And we’ll look into that here in a little while. This is important. Because if you don’t have a proper requirements and monitoring controlling process, then your project can get way out of control very quickly. Now, let’s talk a little bit about verification and validation. And I think this goes really right along with traceability and monitoring and controlling because in essence, really, you’re doing this process. And this is primarily in a systems type of situation here. But the verification process is providing objective evidence, a system or system element fulfills the specified requirements and characteristics. The system is being built right. That’s really what you are doing when you are verifying the project. And you’re making sure that the element, the system, the element, the product service, and result is fulfilling the specified requirements that were set out for. The validation process on the other hand, provides objective evidence a system, when in use, fulfills its business and mission objectives and stakeholder requirements, achieving its intended use in its context. So the team in this particular instance here is, you’re thinking about that the team built the right system. So verification, the system is built right. Validation, the team built the right system. I think that these are very close and there’s not a whole lot, I think difference between the two because really what you’re doing is you’re monitoring and you’re tracing the requirements. You are ensuring that the product and service and result or result is meeting the requirements that were originally set out for that. And that’s what you’re doing. You are verifying and you are validating. So what is requirements monitoring and controlling? You are iteratively monitoring the status of the requirements. When we say iteratively, you are coming back to the monitoring of those requirements. Whatever in whatever way that you do that or whatever timeframe that you do that. Generally, we believe that it’s best to have more frequent status meetings as opposed to fewer. For example, status meetings one to two weeks as opposed to a month because if you wait a month in between status meetings, then there’s a whole lot of water it’s gone under that dam between the meetings. It’s important to have them frequently. It’s managing requirements baseline over the project lifecycle. You are ensuring you’re measuring your project against that baseline. You are measuring those requirements against that requirements baseline. The status or the requirements are communicated. You’re just communicating where the requirements are at any given time. Ensures requested changes to requirements are processed properly. And key requirements sometimes called key performance indicators should be identified and marked as such, and monitored closely. Here are some activities in the monitoring and controlling process. You’ll notice in the far left, you have your requirements planning process. Where you’re going to be iteratively planning your monitoring and controlling. Of course, there are other aspects to this requirements planning that we talked about in the first presentation. Once you have your requirements, you’re going to begin to trace them. You’re going to baseline those requirements, you’re going to… Your stakeholders are going to approve the requirements and communicate that approval. Once you’ve have baselined the requirements, you’re going to begin to monitor them. You’re going to manage the changes to those requirements. You may be submitting change request to the change request board. And then you’re going to be documenting and communicating those results. In an Agile lifecycle, requirements are controlled during monitoring and controlling by managing the backlog. The backlog is the list of prioritized and estimated user stories. The backlog is going to be reviewed and revised for each iteration, allowing more opportunity for new requirements to be addressed. One of the things that is a hallmark of Agile is change. Therefore, you could possibly be having change throughout the entire lifecycle. Even from going from sprint to sprint, because at the end of each sprint, there will be a sprint review that is where you will be receiving customer feedback which could based upon that feedback, cause you to have to change the work that’s done in future sprints. And then once the scope of an iteration is decided upon, changes are managed and controlled accordingly. And that’s really what I just talked about. So it’s going to be, the monitoring and controlling is going to be on a more frequent basis because you’re doing work at each sprint and you’re going to have a review after each sprint. Once you have listed your requirements, you have documented to them in the requirements document as well as the requirements traceability matrix, you are going to baseline those requirements. The baseline is that approved list of requirements. That’s all it is. You’re going to be using that to measure you your project and measure those requirements against that baseline. That is what is going to tell you what has changed. If there’s requirements that have been added, scope that’s been added. You don’t want to change the baseline at all, ever unless it goes through a robust change control process, or it is a change in a contract. And as you see here in the adaptive or Agile lifecycle, baselining requirements is performed by maintaining a product backlog. So what we are fighting against, and there seems to be always a fight sometimes, or at least you are, this is what you’re trying to avoid. And that is requirements creep. And that’s a term used to describe the subtle way that requirements grow in perceptibly during the course of the project. It is the tendency for a set of requirements to relentlessly increase in size during the course of development. And that is going to result in a system that is more expensive and complex than originally intended. And often the changes are quite innocent. And what appear to be changes to a system are really enhancements in disguise. So this is something that needs to be watched throughout the entire lifecycle of the project. Because it can result in a system that’s more expensive, more complex than originally intended. But how can we keep and minimize requirements creep? One of the first things that we can do is that early on in the requirements definition phase, is to flush out those conscious and unconscious and undreamt of requirements that might otherwise not be stated. What we’re talking about here is that in the scope statement, if we go back to the first presentation. The scope statement is that particular statement that contains in, whether it’s in a prose or paragraph form, are listed as in a spreadsheet and bullets, defines what the scope is or lays it out there. But one of the characteristics or, of a scope statement or characteristics of the information that is in a scope statement is the project exclusions, what shouldn’t be a part of the project, what shouldn’t be included as scope. And this is really what it’s talking about here when it says to flush out those conscious and unconscious and undreamt of requirements. You are putting it on the table so to speak. You’re not letting it be unstated. And this will allow you when you are able to express those to write them down that would be something that you can then look to in the future, to see as you are managing your requirements against the baseline to see if those things that you said were to be excluded have crept into the project. You want to establish a strict process for assessing requirements changes. You want to set up a process by which you are on a consistent and frequent basis, managing your requirements against that baseline. How are you going to do that? How are you going to implement that process? This is something really that should be in the requirements management plan. We talked about that during the first presentation. And then establish official channels for submitting change requests. We’ll talk about change control board in a little bit. But there needs to be a process. How are you going to… What system are you going to set up, that will allow for change requests? Is it going to be electronic? Where they send… where someone could submit changes or is it going to be by paper? How are you going to do that it needs to be official. Also measure the functionality of each requirement change requests and assess its impact on the rest of the system. You need to be able to understand and state and see how those change requests are going to impact the rest of the system. Will it have impact on any down level or lower level requirements? And then determine if the proposed change can be accommodated within the fiscal and technical resources of the budget? Can you afford it? Is it really appropriate to spend the money for what needs to be done? Whatever process that you set up, you want to make sure that it will do what it is supposed to do. If it doesn’t, if you aren’t able to minimize requirements creep, you’re going to have a project that’s going to look like this hybrid of a rabbit and a bird. That project is going to end up not looking like what you had originally planned. And it’s subtle. The requirements creep could be in, for example, like gold plating. Gold plating is adding functionality to something. It’s improving something. Even though it’s not part of the scope, original scope. You’re adding to it. So while gold plating on its surface might look good, because you might be adding functionality, you might be improving something. If it wasn’t in the original scope then it shouldn’t be included in the product and service and result unless it goes through that change control process. So here’s requirements traceability. As I mentioned earlier, you want to start this off really early, even at the elicitation step. And requirements traceability refers to the ability to describe and follow the life of a requirement. In both a forward and backwards direction. In other words from its origin through its development, and specifications to its subsequent deployment and use and through all the periods of ongoing refinement and iteration, and of any of those phases. Performing requirements traceability analysis is an important part of software engineering. Because it ensures that all of the requirements have been adequately considered during each phase of the project. And there aren’t any scope holes developed. When we talk about quality, quality is ensuring that the product that you set out to create is meeting the requirements that were originally set out for. And you really won’t be able to truly know as you go through the lifecycle unless you have this traceability. One of the things that is important is to determine the approach that you’re going to take, when it comes to traceability and monitoring. Consider how it will be performed. Define how requirements changes will be managed. The approach appropriately sizes the level of traceability and formality of the requirements change management process for the situation. So what this means is that, depending upon the size of your project, the complexity of your project, the extent and the size of your requirements traceability. Now, here are some characteristics of an appropriately sized approach. The process, it’s a process that minimizes the likelihood of missing requirements in the final product. That’s really what we’ve been talking about. It is not time consuming and wasteful to maintain. You certainly don’t want to add so much work building a traceability and monitoring approach that you’re going to spend wasteful time maintaining it. An appropriately sized approach, a change management process that ensures that changes align with business, and project objectives. Change management process that makes it simple to implement necessary changes. And a traceability and change process that align to organizational standards and satisfies regulatory requirements. These are the characteristics. Again, some of the key words here, is minimizes the likelihood of missing requirements. The process is not time consuming or wasteful. The change management process aligns with the business or project objectives. The process makes it simple to implement necessary changes. And the traceability and change process align to organizational standards and satisfies regulatory requirements. You don’t want a process, as I mentioned it’s going to be time consuming, that’s going to be wasteful. You want to make sure that the change management process aligns with your procedures and policies set out for your organization. They might have specific policies that will dictate how the change management occurs. How the change control board will work. And if you can have that appropriately sized approach, then it will make it more easy to manage those requirements than otherwise. So what are the benefits of traceability? They ensure that each requirement adds business value. Because what you’re doing is that you’re going to be tracing those requirements to business in needs, goals and objectives. Why did we start doing the requirements management processes in the first place? I talked about this in the last presentation. We are meeting a need. Remember what I said need is? It is the gap between where we are now and where we want to be. That is that need. That need or the requirements or the project impels change. The whole thing about projects is that you are moving from the current state to the future state. Those requirements if they were properly gathered will add business value because that is what is going to be used to bring value to make the change. You’re going to be meeting those stakeholders expectations because you’re getting the requirements from those stakeholders. And then it manages scope. If you know what your requirements are, and you trace them throughout that’s going to give you the ability to manage the scope of your project. You’re going to be able to keep the scope creep, in control. So let’s take a look at some traceability properties. And you can ask yourself this question and answer these questions. Is each requirement uniquely and correctly identified? What are we talking about? Well, if you look down at the examples here you will see the number. The parent is 1.119. And the child is 1.11 9.1. Sort of like the numbering system in a WBS work breakdown structure. Is each low level requirement trace to a high level requirement? Notice the example again. You’ll see that the child requirement is more specific in terms of what that system is about. While the parent is more general. So you’re going from general to specific. When you look at your requirements, especially the lower level requirements. Can you say that the child requirements, add up to the parent requirements? Or if you’re looking at these two requirements, the child and the parent. Do they not look related? Are there things in the child that doesn’t look like would be a part of, for example, the topology diagram of basins that is mentioned in the parent? The lower level requirements should be able to be traced to the higher level and the higher level be traced to the lower level. And I like what it says here in this box. Traceability allows for communication when there are changes. A change to a lower level requirement can impact other levels. If you have all of these requirements that are related to each other, the parent to the child. Then any change up here, if they are properly linked, is going to cause changes down at the bottom. So with traceability that will allow you to keep a handle of that, to see that and to be able to deal with it if needed. So here are some more benefits of using traceability matrix. More detailed requirements surfacing are linked to baseline requirements. A complete set of baseline requirements has sufficient detail to build a feature or set of features. Work products created across phases such as design and test documents are created for each approved requirements. When there’s a requirement with no associated work product, there is a risk that important components might be missed. And as I’ve mentioned already, scope creep is prevented. As more detailed requirements are understood, then you can link them to those baseline requirements that is similar to that child and parent relationship that we just looked at. If you have a complete set a baseline requirements, that should be enough for you to be able to build a set of features, the product that you are wanting to deliver. It will allow you to be able to plan each set of work across each of the phases, especially if you understand the requirements and those requirements are consistent across the whole lifecycle of the project. Here is an example of a requirements traceability matrix. As you see this, this is just one, I mean you’ve probably have traceability matrix that you’re using. If you are, that could be similar or could be different. There is any number of ways that you can build these. It really doesn’t… It’s however your organization can best use this particular tool. In this particular instance, you see the higher level ID to the left and then an associate ID. You’ve got your requirements description. Also, you have your business native opportunities and goals and objectives included here so that you can continually monitor through the life cycle of the project that that requirement is continuing to meet the need. That it’s continuing to provide the solution for whatever that need is. You might have project objectives. Here’s where the elements in a WBS come to play. Because you can have the associated WBS element which is the hierarchical diagram which details the entire scope of the project. You can trace that requirement to the elements in the WBS. If there is for example, you have all your WPS has delivered but there are requirements listed and traceability matrix that doesn’t have a WPS element. Then you may want to think, “Is this particular requirement here that doesn’t have that related element in the WBS, is that requirements creep?” And then you have others. You have your product design, your product development and test cases. This is based upon the requirements of your project. Here’s another traceability matrix and this is an actual matrix for a project that I was on. And this one is based upon change request. It was from a Project Server implementation project that we were hired by this agency, to come in and help them with the standing up for the Project Server and with training their population on the use of the system. But after the Project Server went live than that, they set up a change request process to where anyone could submit a change request to the system electronically, and then it would go to a change request or change control board. And if it was approved, then it was assigned a number. Once that change request was approved, then the developers started working on that change request to update the Project Server system. And they did that by first of all developing business requirements for that functionality, or I should say business requirements are the high level need, why are you making that change? And then from the business requirement, functional requirements were then created, that detailed the actual functionality that would be implemented in the system. Then you had your systems integration tests, and then your user acceptance tests. And we were responsible for the user acceptance tests. So this worked out to where you could trace the user acceptance test all the way back to the change request, and backwards and forwards. You can be assured that as the user was working through all of the functionality, taking the steps, then you would be able to tell, “Well, did that…: Whatever the user was doing as a test, did it meet the function of those requirements? In other words, were those functions fulfilled by what the user was doing? So where does traceability come to play in an Agile lifecycle. The define change request process adds new requirements to the backlog. As I mentioned earlier, the monitoring and controlling happens at the backlog level. And that at the end of each sprint when there is a sprint reviewed, where the customer was giving feedback to the team, that team could then turn around and implement that change into the next sprint based upon the change that was made to the backlog. There still needs to be a change request process. It’s not that you would simply give the customer feedback and then implement that change. But on the same token, a lot of your change control boards might take a long time too, for that change to go through the system and the change control board may take a long time before they could approve that change. And in fact, that’s what happened in that Project Server system. I submitted a change and it took probably eight months before it was approved. But you can’t wait that long in an Agile lifecycle. Changes need to be approved very quickly. As a result, most change request change control boards are usually the, primary person is the product owner. They’re the ones who are going to say, “Yes, this change is appropriate. We can implement this change, so it won’t take so long.” You’re going to be adding the change and whatever the result of that change to your planning sessions, for your follow up iterations. And then prioritization process determining the next set of features for subsequent sprint. That, whatever that change is that you’re going to have to determine what are the next set of features? Are you going to have to change the prioritization of which user stories are you going to use or develop? Which are you going to be adding new user stories? Or removing? All of this plays a part once you have a change request that has been approved in an Agile lifecycle. Let’s talk about managing requirements changes. Managing changes to requirements and other product information entails maintaining the integrity of the requirements, and the associated deliverables and work products ensuring that new requirements changes align with the business need and the business objectives. And one of the key benefits of requirements change process that it provides a process, to manage changes to approve requirements while minimizing product and project risks associated with uncontrolled and unapproved change. But this is important because it could be that as a result of traceability, that you need to make a change. Therefore, if a change request is submitted, you’re going to need to analyze it, there’s going to have to be an impact analysis to evaluate the impact of that change, how it will affect the other requirements, how it will affect the, maybe the functioning of the system or product that you are delivering. In adaptive projects, change is ongoing. In fact, adapted methods expect that requirements will change as stakeholders learn what they want as they see the solution and evolve. On adaptive projects, the prioritization process is used to determine if and when a change is considered for inclusion in the product. On the other hand, on the predictive approach, plan driven approach, a change is a modification that is requested after the requirements have been baselined. In those changes may arise at any point, but changes are harder and more expensive to accommodate in a predictive life cycle. They are generally going to be reviewed as requested by a governing body, for impact on the in process work. And if value of pursuing the change is deemed greater than the impact on cost, time and resources, the change is more likely to be approved. So I’ve already mentioned the change control board on a number of occasions already in this presentation. So this is the formally charted group responsible for reviewing, evaluating, rejecting or approving proposed changes to the project. This change control board or CCB, they’re going to document and they’re going to communicate those decisions to the stakeholders for information and follow up actions. The CCB could be project team, sponsors, subject matter experts. And the PM will not work on any non-approved changes. What decisions could be made? Well, the change could be approved. The necessary updates to the impacted business analysis deliverables are made. The change could be deferred. The decision to defer making the change, if that is the choice of the CCB, is documented along with the rationale for the decision. It could be rejected. The decision to reject the proposed change, again is documented along with the rationale for the decision. Unlike the action for deferred change, there’s no future date reminders established in the plan, because that work is not going to occur. But when the change is been deferred, there could be set up a specific date in the future, that it could be reviewed again and then the circumstances may change that that change could be approved. And then you might have a situation in which more information is needed. Therefore, you’re going to have to provide more information. It could be any number of things. It could be, for example, how the the change could impact lower level requirements. It could be having to do with the schedule. If the change was implemented, how would that affect the timeline of the project? Or the cost of the project, is it going to cost more? So that’s really what we’re talking about there. But this is important because you really just don’t want just willy nilly changes going on in your project. It needs to go through that robust change request process. Now, what are we doing when we talking about change? One of the things that we’re doing is variance analysis. You’re determining the cause and the degree of difference between the baseline and actual performance. What’s really the difference? You’ve probably heard of variance when you’re talking about earned value. In other words, here’s the baseline your project should be, a certain amount completed at this time. But when you do the status it looks like that, what should have really been done should have been done a month earlier. Well, from that current status date from behind, whatever that date is that it should have been completed, then in between is that variance. And this is a way to manage your actual changes when they occur. You’re able to see what that variance is and that can help you to determine, “Well, how are we going to handle this? What corrective actions are we going to take to be able to deal with the changes that were made as a result of whatever has happening in the project?” Another aspect of change is configuration management. This is important because it has to do with the versioning, the correct version of requirements. For example, as it says here, that applying configuration change management principles may provide a number of assurances. Correct version if the configuration item is in use by the project team. Changes to configuration items are made only by authorized individuals. A planned means of notifying stakeholders of approved changes to configuration items in place. A record of configuration item changes as kept to support auditing and closure activities. There’s nothing worse than you then having worked on a document or whatever I happened to be working on. And somebody made changes without me knowing it. And some of my changes were overwritten. And that’s because there wasn’t really a good configuration management system. It may have been because the document that we were working on was on the network drive. There wasn’t any way for me to know necessarily what generally what the changes were made. This goes along when it comes to configuration management. There are all kinds of different types of systems out there that you can use, to store documents that provide that configuration management. You want to make sure that you have a configuration management plan, so that you know how that configuration is going to be done. What are going to be configuration items, how are you going to manage the versions? Here at the company where I work, we use SharePoint for all our configuration management items. And we have a process that if it is a CI item, configuration item that we have to check it out, we make our changes, then we check it in and that we are required to provide a, what changes have been made into that document. So this is vital to keep everything straight when it comes to your work. So here are a number of different types of change control tools and techniques. On projects following the predictive life cycle, the change control tools can be manual or automated, and are used to manage the change requests and resulting decisions. These tools they may already be in place within the organization. When a change management tool is being introduced into a project, the needs of all stakeholders involved in the change control process should be considered. So a couple. Here’s the first one, Configuration Management System or CMS. The configuration management system helps ensure that the solution being built, conforms to its approved project information. It’s going to provide a way to verify it, the conformance, for documenting changes and reporting the status of each change throughout the project lifecycle. You’re going to be able to understand if there is a proper configuration management system, that if it is followed correctly, that the documents that you are going to be opening and looking at, as it says here such as models and traceability matrices, are stored and easily accessible and that you are looking at the latest versions. And speaking of versions. Having a version control system in place that tracks the history of revisions. It can be a simple system using document name to reflect the date, time and version number. Or more formal approach using a tool that requires documents to be checked out of a library, updated and checked back in. The safest of course, is going to be the more formal approach. We were in a project one time and they were sending out a report to all of the various components directors that had to be filled out with information. They had this one document on a network drive. And every single month they were talking about this amount of information being overwritten and that been overwritten. So it was a real mess. But if you have that formal system that will allow you to have to check it out, make the changes, add version comments and check it back in. Will go a long ways towards protecting the integrity of that information. Now impact analysis is a technique that’s used to evaluate a change, in relation to how it will affect the related elements. What impacts is it going to make to the project, to the requirements? As it says here, it’s including identifying risks associated with change. So what is the impact? Because you might have risks, you could possibly have threats, which are the negative risks that you would need to identify as a result of the change. So your impact analysis will help you to determine what the scheduling costs implications might be. But the whole point here is that you want to ensure when it comes to monitoring and controlling requirements, you are wanting to ensure that one, that your baseline is set. That as a result of your baseline being set that you monitor your requirements through the lifecycle of the project, to ensure that you don’t have requirements creep. And you do that by having a fully filled out requirements traceability matrix. So that you can monitor those and you have a requirements baseline to where you can understand the variances of your project. And when you do that, you can have a better chance of ensuring that you protect against scope creep, and requirements creep gold plating. So that ends my series. I want to thank you for attending. Please, if you have any questions, don’t hesitate to send me an email, give me a call. I’ll be glad to help you in any way. So again, thank you so much for joining this series. And I’m sure that MPUG will be providing many more opportunities to learn from our community. So, thank you. Watch the on-demand recording by clicking here

Project Requirements Management – Part 2: Gathering and Writing Requirements Transcription

Please find below a transcription of the audio portion of Walter Stinnett’s session, Gathering and Writing Requirements, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience. Welcome to part two of the three part series on Project Requirements Management. In this presentation, I will be discussing the topic of gathering and writing requirements. Our lesson objectives are we are going to define the requirements gathering process and write well defined and properly structured requirements. But before we begin the presentation, let’s take a look at some quiz questions and hopefully as I go through these and you’ll be able to answer them by the end of the presentation. The first quiz question is, what is a business need? What is a needs assessment? A completed requirements document should be? Elicitation is used to produce information relevant to a project by drawing out information from stakeholders, true or false? Which of the following is not a technique used during elicitation? Requirements should conform to which property to be well-written? Product requirements should be written to state? And which of the following is included in the needs assessment process? Well, hopefully by the end of the presentation you’ll be able to answer those quiz questions, so let’s go ahead and begin. What is a business need? I like what James and Suzanne Robertson says here. This is taken from their Mastering the Requirements Process book. They say that, “Requirement’s are not really about requirements. Requirements activities focus on understanding a business problem and providing a solution for it.” So, what is a business need? As you see here, it is the impetus for change in an organization based on an existing problem or opportunity. The need could be from your stakeholders, it could be from legislation from Congress or a strategic initiative from management. A solution space is how that stakeholder’s need is going to be met. I like to look at the definition of a need as this: the gap between what is and what should be. The gap between what is and what should be. In other words, the gap is right there in there middle so we are going to have to find a solution for that gap so that we can move our organization from where they are to where they want to be. In systems engineering, the process of needs assessment is called mission analysis. That process focuses on the identification of the primary purpose of the solution, which is its mission. So, a mission is a purposeful action or task directed towards accomplishing a specific objective based outcome and level of performance. I like what Charles Wasson says in his book, Systems Engineering Analysis Design and Development. He states that, “Mission success requires insightful planning and solving the right problem with the right system at the right time.” How do we determine the need? Well, we determine the need by doing a needs assessment. This is generally done to examine the business environment and address a current problem or opportunity. It is generally going to be requested by the stakeholder. It is normally the whole needs assessment in determining what the business need is, is often done as a precursor to the project charter. As well as giving a justification for the project, as well as afterwards, you understand what the product, service and result is or the objective of the project. Then you can begin to analyze how you are going to meet that particular need. But first, you have to identify what that need is. Here is the process and we’re going to walk through just the whole needs assessment process here. First of all, you want to identify the problem or opportunity. What problem are we solving? What problems do our customers have that this opportunity will address? As you are trying to identify the problem or the opportunity, think not only about the need, but the opportunity as well. Is there an opportunity? Is there something positive? Is there the ability to gain more of a market share and so on like that? But a needs assessment involves the completion of a gap analysis. During this first phase of the needs assessment, you need to determine what you already know about the organization’s needs. Whether it is to be additional resources, new technology, market expansion. It’s about figuring out where you are and where you want to be. You also need to discover other undisclosed needs that may be hindering you from moving from where you are or where you want to be. You’ll often rank those needs in the order of importance and then you’ll set the scope for your research. You’ll know based upon identifying the problem and/or opportunity, where to go in your research to eventually identify the actual need. Once you’ve identified your problem or opportunity, then you begin to investigate that. There are a number of different ways that you can investigate the problem. You’re going to be collecting information that you need to better understand the gaps. You’re going to collect data. It might be from internal company records or it could be externally through market research techniques, such as surveys and analysis of secondary data, including statistical data. After all of that data is collected, it will be organized and analyzed. Here’s some questions that you might answer as you are investigating that problem or opportunity. One: who? Who does the problem affect? Is it specific groups, organizations, customers? What are the boundaries of the problem? Organizational, workflow, geographic? What is the issue? What is the impact of the issue? What impact is the issue causing? What will happen when it is fixed? And what would happen if we didn’t solve the problem? When does this issue occur? When does it need to be fixed? Where is the issue occurring? Is it only at certain locations? Is it only with certain processes or procedures? Then finally, why is it important that we fix the problem? What impact on the business and the customer? What impact does it have on all of the stakeholders? These are some areas where you can investigate and you can answer these questions to help you to further understand what that problem and opportunity is. Once you’ve investigated, then you can begin to gather relevant data to evaluate the situation. Once there’s an understanding, it is necessary to gather that relevant data to identify the magnitude of a problem and opportunity. Now, this is the key here. It might seem like you’re continuing to investigate and gather information. Yes, you are further gathering information concerning that need, but you’re going a little bit further here. You need to understand the magnitude of the problem or opportunity. This is known as sizing up the situation. The lack of data can result in proposing solutions that are either too small or too large compared to the problem at hand. You need to attempt to measure the size of the problem or opportunity to help you to determine an appropriately sized solution. You don’t want to gather such information or have the lack of information, so to speak, that you can’t really know what the size of the solution is that you might need. Once you’ve identified your problem or opportunity, you’ve investigated it, you’ve gathered relevant data so that you can understand the magnitude of the situation so that you can gather the appropriate sized requirements, now once you’ve done all of that and you know what that need is, then you can begin to draft a situation statement. A situation statement is a guide that will give you direction on what that need is. It answers the question, what is the problem that needs to be addressed? As you see here, there is a specific format that a situation statement should be written in. The problem or opportunity of A, has the result of B, with the impact of C. When you have a statement of the problem, it’ll be easier for you to set your objectives and the necessary steps or actions. It serves as a lighthouse to guide you and lead you in the right direction for what you need when it comes to finding the solution for that problem or opportunity. Consider an insurance company. Like many companies, the insurance carrier took advantage of new technologies across its business and has an extensive internet presence. The organization wants to exploit mobile technology to improve its claims processing. Listen to this situation statement. The cost for processing insurance claims is rising steadily, increasing at an average rate of 7% per year over the last three years. The existing method of submitting claims either by phone or the internet, involves significant processing delays and has resulted in the need to increase staffing to process calls and personally investigate claims. Now, if we take a look at the situation statement, what is the problem and what is the result of that problem and then the impact? Well, let’s take a look at it. The problem, I think, is the cost for processing insurance claims is rising steadily. The result is the existing method of submitting claims either by phone involves significant processing delays. And the impact has been the increase of staffing. If you can understand what your need is and what the problem and you can write it out in this structured manner, it can help you to determine the direction you need to go to implement a solution for that particular problem. I like the quote that says, “A problem well stated is half solved.” In other words, if you can state the problem as well as you possibly can, then you’re already down the road to determining a solution. Once you have the draft situation statement, then you’ll want to obtain stakeholders’ approval. You want to get agreement. This is a key step in this whole process because the situation statement is going to guide all subsequent work for assessing the business need. When this formal draft situation statement, the actual approval is skipped, it makes it difficult to determine whether the essence of the current situation has been captured. Stakeholders are very important, you need to get agreement, you need to make sure that the stakeholders agree with what you have said and that your situation statement is accurate. If it’s not, then you’re going to be guided down the wrong way if you don’t get that approval. Once you understand what the need is, then you can begin the whole gathering of requirements process. This starts with a process called elicitation. Elicitation is the thorough discovery of business requirements. One of the reasons that this is so important here, is that requirements, especially from your stakeholders, may not be really readily available in the way and in the form that you want. Those requirements may not be documented anywhere, they might be residing in the minds of the stakeholders. Also, you may not be able to fully understand what the stakeholder is trying to request. In other words, it may be a little bit ambiguous what they’re saying. So you would need to clarify what those stakeholders are saying. As it says here that elicitation is the discovery process used to bring forward or produce information relevant to a project or program by drawing out information from stakeholders and other sources. That’s the key thing here. Eliciting those requirements really is drawing out. You’re drawing out information from those stakeholders. For those of you who have children, you remember when they were toddlers and they began to form words. What did you do? You tried to draw out those words. Well, stakeholders are like babies. Just kidding, just kidding. But sometimes the information you need might need to be drug out of those stakeholders kicking and screaming. This elicitation process is going to be highly cyclical. It’s going to be repeated multiple times for each level of abstraction in the system. Whatever the solution is, you’re going to have various levels of abstraction. To really properly gather those requirements, you need to have that information at each of those levels. As you see here, the elicitation process is performed iteratively with analysis to progressively elaborate the information. This is just a simple process. The whole point here is that you keep asking questions until you fully understand what those needs are, so that you can write accurate requirements for the solution to that particular problem or need. How can you do that? Well, through a variety of tools and techniques, such as interviews, focus groups, facilitated workshops. Interviews, we all know what interviews, those are one-on-one interviews where you talk one-on-one with someone. This is the most popular type of requirement solicitation. It gives the analyst the opportunity to discuss in depth a stakeholder’s thoughts and to get his or her perspective on the business need and the feasibility of a potential solution. You have focus groups. Focus groups consist of pre-qualified stakeholders who gather to offer their input on the business need at hand and potential solutions. These can be very beneficial when key stakeholders are not particularly imaginative or forthcoming. A few more vocal stakeholders may help them think through articulate solutions. Requirements workshops or facilitated workshops involve gathering a previously identified stakeholders in a structured, facilitated manner. You’d pull everyone out from their particular setting, their work setting into a room and you lock the door and you don’t let anybody out until they’re finished. No, you don’t do that. But it is where that you have someone such as this picture, who is facilitating. Well, for focus groups you have a facilitator as well. But this is a type of workshop that is specific for requirements. Where I work we’ve used this type of workshop that’s called the BMPP process. The BMPP process stands for Big Monster Piece of Paper. It is where you will have all of the stakeholders in a room and you put up a really big piece of plotter paper and then you use Post-it Notes. It is a brainstorming mechanism and you can bring in other documentation that can support your brainstorming for understanding your requirements. But whatever form you might have to try to gather those requirements, you need a plan. An elicitation plan can be an important document that can help you to move through the whole process smoothly. Just like anything in project management, there’s a plan. A plan for this, a plan for that. These plans are used to guide you through the whole process of what you’re going to be doing and that’s the same here. It will allow you to clarify elicitation scope and really just organize the work that you need to do to elicit those requirements. As you see here, the information, what information to elicit. Where to find information, activities, how to obtain the information. Sequencing the elicitation. Oftentimes what will happen is that the information that you are gathering, let’s say specifically for someone says, “Okay,” one of the questions as it says here. “How many employees will be moved?” Well, somebody could say that and give you an answer, but really that might be dependent upon another question. As we see here with the sequencing, that how many employees will be moved is actually the second question. But the first one is what is the physical layout of both buildings? Oftentimes, when you begin to ask questions, the answers that you get will lead to other questions. You just want to follow it through, but if you can think of as many questions as possible prior to going in, as well as who the source of those answers are going to be and the methods, then it’ll help you to really focus in and not go on tangents or anything. But allow you to really focus in on the elicitation process. Here are some more examples of questions. For example here, as I mentioned here, is to determine what the questions are. Prepare them beforehand and you can enter those into the elicitation plan, as well as your objective. What is the objective of this elicitation meeting or interview or focus group? Having that objective will help you to focus on the types of questions you need to ask, as it says here. Agree on what equipment will be moved. The participants, the directors of IT operations, director of facilities, HR manager. Then you can begin to think about those questions based upon the objectives. If you don’t have objectives, then you might be just all over the place when it comes to asking the questions. You might actually miss some of the questions that you really need to ask. So this just goes a little bit in depth more into the elicitation plan. You’d want to include the objective in the elicitation plan. You’ve gotten to a point to where you are able to understand what the problem is and what the need is. Then you can begin to move on to the next process of translating those elicitation results into requirements. But before you do that, you need to confirm those results. This is where you are going to review these results with those stakeholders so that you can get stakeholder agreement, so that you can truly move forward. Those stakeholders are going to check for accuracy and completeness. They’re going to sign off on the results that you can move on. As it says here in the last bullet, the key benefits are validates stakeholders and elicitation results were understood. All right, so we have a set of elicited requirements. It probably might be more answers to the questions written, not so much in the form of a requirement, but just written as just information, as answers to the questions. Now, once you’ve done all of the elicitation that you need to do to be able to have enough information to translate that information into requirements, now you can begin to start writing the requirements. Let’s walk through this in this section on how to write requirements. You have different types of requirements, as we saw last presentation. But let’s be specific when it comes to personnel requirements. This requirement is in the form of responsible party shall perform such and such. You want to use the active rather than the passive voice and that’s pretty much the same for any of your requirements. It should state who shall, followed by a description of what should be performed. Here are some examples. Budget officer shall create report comparing data between multiple offices, by funding source. Analyst shall enter FTE work hours in payroll system. You have the person who is the responsible party, they shall do something. In these two examples, create and enter. For product requirements, this is similar. I mean, they’re all written similarly. In this particular instance it’s in the form product ABC shall XYZ. It’s going to state, as the personnel requirements, the product shall and whatever the product is going to do, followed by a description of what should be done. This is the key here when it comes to properly writing product requirements. You need to state what is needed, not how to provide it. In other words, state the problem, not the solution. Here are some examples. The system shall operate at a power level of, the software shall acquire data from the, the structure shall withstand loads of, the hardware shall have a mass of. These are some good examples here. Of course, you’d need to finish them off for whatever it needs to operate, acquire, withstand or have. Personnel requirements and product requirements and really, when you look at both of these they’re written the same, with a little bit of difference there. Hopefully, this would be a good way to guide you in writing requirements. Now, let’s walk through the requirements validation. What I mean by validation, I’m meaning that the requirements are written correctly. We’re going to go through that here. First of all, is the requirement written in an unambiguous manner? You want to use correct and unambiguous terms. There needs to be one correct understanding of the requirement. In other words, if multiple people look at the requirement, each of those persons should understand the requirements equally. Don’t use ambiguous terms, such as support, but not limited to, and/or, may, could. For example, the stereo amplifier shall provide outputs for two additional speakers at full rated power. But this is the incorrect way to write that. The stereo amplifier shall support additional speakers. Well, additional, what does that mean? Does it mean two, three, four, five, 10? It really isn’t clear enough to really understand in an unambiguous manner. Not only should it be unambiguous, it should be verifiable. Have you used specific qualitative or quantitative measures? Don’t use subjective or unquantifiable words that can’t be verified. It’s like in the previous requirement. Using the word additional is an unquantifiable word. When you are thinking about your requirements ask, “How will we verify or confirm the designed and built product met the requirement?” Here’s some other subjective terms you want to avoid: user friendly. What is user friendly? User friendly is really up to the user. They are the ones who are going to determine whether that is a friendly system or friendly action. That’s really subjective. Adequate, don’t use clearly or other words that end with LY or IZE. Here are a couple of examples. The system shall update the display every 10 seconds. That is the correct one. The incorrect: the system shall have a fast update to display. Fast, what is fast? It’s really unverifiable, you can’t really determine because fast might be in somebody’s mind a certain speed and it might be another speed in someone else’s mind. Unambiguous and verifiable. Thirdly, traceable. Is each requirement uniquely and correctly identified? Now, we’re going to get more into requirements traceability. We’re going to look at, I was about to say, requirements traceability matrix. We’re going to look at that, but in the third presentation we’re going to focus in on traceability. We’re going to look at some examples of requirements traceability matrix. Really, this is the characteristics of a requirement being traceable. Can it be uniquely and correctly identified? Is each low level requirement traced to a high level requirement? What about lengths between requirements and information and other documents? In a traceability matrix and in general, when you are writing the requirements, remember I mentioned earlier about eliciting those requirements at every level of abstraction. What are the children elements? Do the children elements aggregate up to the parent element? If there is something missing or if it really doesn’t aggregate up, then they’re not linked correctly. For example, the parent is the system shall allow user to display a topology diagram for basins. And look at the child. The system shall allow the user to display a topology diagram to show the upstream to downstream connectivity of basins in a forecast group. As you see here, just as in a work breakdown structure, the parent elements are more general, but as you begin to decompose the elements down into children, then it’s going to become more specific. You will look at those parent child and say, “Can the child be traced back up to a higher level requirement? And can that higher level requirement be traced down to a lower level requirement?” Then clarity. Your requirements need to be clear, consistent and written in a concise language. Just as the unambiguous, you want to ensure that more than one person understands the requirement. In other words, you want to for one thing, is to use the same terms throughout to be concise. You want to have some consistency with the language. For example here, the first on is an example of a consistent requirement. The maximum vehicle net weight shall be two tons and the vehicle shall have two axles. And the inconsistent version is the maximum vehicle net weight shall be two tons and the truck shall have two axles. Now, look at this. The first one uses vehicle both times, but the second one uses the vehicle the first time and truck the second time. That is inconsistent because really are you talking about the truck as the first vehicle? Well, yeah, I mean, it mentions that there, but really is it the first one? Could it be a car are they talking about because it says here and the truck. Really, how do you read that? Being consistent is key to help people understand what that requirement is for. Then readable. You want to use standard requirements terminology. Use simple words and phrases and concepts. Use shall, will and should correctly. If you’re going to be stating requirements, use shall if you’re going to be using the traditional way to write requirements. You see the example here. The ABS system shall illuminate a warning light in the event of and whatever the event of is. You’re going to use will in stating facts and then should for stating goals. As I mentioned previously with these requirements, you want to state what, not how. You don’t want to determine in the requirement or include in the requirement how it’s going to be done or how you’re going to provide it. It just states what is needed. Here are a couple of examples. The XYZ system shall measure room temperature. But this is the incorrect version. The XYZ system shall use a four wire thermo-couple to measure room temperature. Can you see the difference here? The second one is showing how you’re going to do that. That’s what it’s included, but you don’t want to do that. Let’s take a look at some, I guess you could say grammar. Touched on this a little bit already. Grammar, punctuation, sentence structure, those types of things. And specifically, we’re going to look at some problems that might be faced or that have been shown as maybe you’ve seen these issues and these problems as you’ve reviewed requirements. But the first problem is overly complex sentence structure. You’ve got multiple clauses, interrupters, you’ve got misplaced and dangling modifiers and unnecessary repetition. For example, the GUI, based on the Linux interface, but compliable to Windows and Mac OS versions 97 through 2002… You can tell that I probably should have updated to the latest operating systems. The GUI, based on the Linux interface, but compliable to Windows or Mac OS Versions 97 through 2002 and to encompass version 10, should allow the administrator or other user with similar access attributes to create new information, retrieve such information and subsequently edit existing information and save same to media, including but not to the exclusion of removable and permanent storage devices. Huh, try to read that in one breath. It contains four interrupters and unnecessary repetition. That’s a lot, it really doesn’t make sense, it really sounds like some fine print in a contract. So you want to avoid this. You want to use action words. Weak verbs are wasted word, while important activities are disguised as things. Let’s take a look at some examples of weak verbs. Make a determination, make a decision as to, give consideration to, render assistance. You could instead of wasting space on your paper by writing this out like this, you could use instead of make a determination, use determine. Instead of make a decision, decide. Then you see the other two, consider, help. It’s just a matter of thinking what is the most concise way to write these requirements that say what you want to say in the least amount of words that is direct and strong? Noun strings. This is where you have a dense concentration of information that creates ambiguity. Noun strings are a series of nouns with no connecting words to clarify their relationships. For example, acoustic leak detection system or intelligence system advance information. What does that say? Is it a system to detect acoustic leaks, or a system that detects leaks acoustically? Is this an early information about an intelligence system, or is it provided by an intelligent system? You see here that the way this is written, there aren’t any connecting words, you really don’t have anything that can clarify really what is this trying to get to? What is the purpose of this, so you want to be careful when it comes to nouns. You want to have the proper connecting words to clarify their relationships. Grammar and spelling. How many of you have a hard time spelling? How many of you rely on Spell Check? Well, sometimes you can’t just rely on Spell Check, especially when it comes to cell phones. That Spell Check can send off some embarrassing things, but I digress. But it’s important here. Grammar and spelling errors create more than embarrassment; they detract from credibility and may create confusion or ambiguity. I think that is true really with anything. If you are having grammar errors and spelling errors, it can detract from your credibility. It shows you as less of a professional than you are. Here are some examples. The system shall provide the capability to manage the system with a geographic and internet distribution of users. From an actual requirement document, first line, first table. The system shall provide the capability to manage the system with a geographic and internet distribution of users. Are the users going to be distributed across the internet? This one, the patient was treated for abdominal paint, instead of pain. The system backup will be located on the lover level. That’s really funny, it should be lower. The individual solder shall carry two or more units. That should be solider. You’ve had the experience when it comes to grammar and spelling and how that can mess things up. This is something that should be reviewed. Reviewed by multiple people. Here at the company where I work, we provide training and one of the things that we do is that we review all of our work. We have editors who do that and it’s very important before we actually send that out to whomever, before we teach it, to have that reviewed. It’s called quality, making sure that the process that we use one: is full of quality and that it meets requirements. Really, when it comes to quality in project management, that is one of the keys. Is that you are ensuring that the product is meeting those requirements that were originally set out for. That goes really into traceability and we’ll talk about that in the next session. So be careful with grammar, really in anything that you do because it can make your requirements not clear, not concise, not unambiguous, nor readable. Punctuation. This can always be a problem because depending upon how you punctuate, can dictate how the sentence or statement is read. As it says here, it causes ambiguity and confusion. For example, I leave all my money to Peter, Mary and John. Is that divided in half, where Pete gets half and Mary and John share the other half? Or is it divided into thirds? A comma would make all the difference. Here’s another example. There are two on-site systems. The on-site system, which has the higher readings, shall be consulted in case of irregular readings by the mobile system. Does this mean that both of the on-site systems will always have higher readings than the mobile system? Or of the two on-site systems, use the one with the higher readings? If the latter, remove the commas. Really, where you put those commas can really dictate your understanding of what is being said. Symbology, varying symbols or acronyms to mean the same thing and use the same symbol or acronym to mean different things. Here’s some examples. Seventy-eight degrees, 78 degrees Fahrenheit, all used for Fahrenheit temperature. Seventy-eight degrees, 28 degrees, that could be location, longitude, latitude and the temperature. Centigrade used elsewhere. Here are some acronyms. How many of you have used acronyms? I think we all use acronyms in some way or fashion. But if we don’t spell those acronyms out, then there would certainly be confusion and misunderstanding. For example, ATM. It could meant automated teller machine, asynchronous transfer mode, adobe type manager, acetone toluene methanol, adjustable trigger mechanism. I think you get the point here. We need to write out any acronyms, we need to be careful with symbology that is similar and can be used the same way but have different meanings. A user story is a requirement, feature and/or unit of business value that can be estimated and tested. It describes the work form the user’s perspective that must be done to create and deliver a feature for a product. It can be written as a type of user, I want some goal so that some reason and here are some examples. As a leasing specialist, I want the ability to upload an FS-81 document so that I can attach it to my lease file. As a content owner, I want to be able to create product content so that I can provide information and market to customers. Now just as those traditional shall statements that we looked at, you also have quality attributes for user stories. It’s spelled out as the acronym INVEST. A lot of these are similar to what we just talked about. It is independent. In other words, it should be able to implement the stories in any order and still realize benefit. Negotiable. One of the big things with agile is adapting to change. Stories can be revised freely when better ideas are developed. Valuable. Each of the stories should in some way be relevant to the customer or user. Estimable. I had a hard time saying that, estimable. It should be possible for a developer with relevant experience to roughly estimate a story. We’re talking about estimating using relative sizing. Small. Big stories reduce opportunities for incremental testing and require more elaborate planning. Then testable. Testable, write tests allowing you to validate an implementation and delivers on your intent. Once you have identified your requirements, you’re wanting to then resolve any conflicting requirements between the stakeholders. In fact, during this whole process of writing those requirements, you want to be communicating with your stakeholders along the way. Now, we’re going to talk about requirements traceability in the next session. You don’t necessarily start the requirements traceability matrix way after you already identified the requirements. You create that traceability matrix all the way in the elicitation process. You can update it as you go and you learn more information. You want to write and prioritize business requirements, why are you doing the work? Then you want to create that requirements documentation. All of those requirements need to be documented in that requirements documentation and the requirements traceability matrix. You want to obtain validation and approval of those requirements from the stakeholder. Then once you get that approval, then you can baseline those requirements. We’ll talk a little bit more about baselining requirements in the next session because those requirements are going to be used to define the scope of the project, as we mentioned last week. What about requirements document? Defines the requirements that make up a solution. It is used by the solution team to understand how to build a solution. They should be accessible within a tool, whether that is SharePoint, whether it’s in an Excel spreadsheet or any other type of web or desktop based application. And new versions of requirements should be communicated to the stakeholders. This requirements document is a living document. As you move through your project, there could be changes to the project. Therefore, you will have to go back into the requirements traceability matrix and update that. But you’re going to have to update the requirements document. This is all part of the monitoring and the controlling that we’ll get into next week. That needs to be continually updated. As you know more information, as you progressively elaborate through the project, then that needs to be updated. A completed requirements document looks like this. It is unique and normalized. Each requirement is stated once without overlap. In other words, you shouldn’t have more than one requirement for each aspect of the system. You don’t want to have, for example, one requirement that states the functionality, but then you have another requirement that states really the same functionality, but maybe takes it a little bit further. No, you don’t want anything to overlap. All of the requirements are linked and complete. What we’re talking about linked and complete, they are linked to address the customers’ needs. All of those requirements, does it meet those needs? That’s where traceability comes in. You can look at the traceability matrix. You could have a column in there that has the business need so that you can check to make sure. Is it written consistently? Does it identify scope and context? And is it maintained by version control? That is the process of gathering and writing requirements. Next week, we are going to be discussing monitoring and controlling requirements. If you have any questions, any comments, please don’t hesitate to contact me. I’ll be glad to help you in any way that I possibly can. Thank you for attending this presentation and hopefully we will see you the next time. Thank you. Watch the on-demand recording by clicking here

Project Requirements Management – Part 1: Introduction to Requirements Management Transcription

Please find below a transcription of the audio portion of Walter Stinnett’s session, Introduction to Requirements Management, being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions, such as those steps included in product demonstrations. You may watch the recording of this webinar at your convenience. Hello, my name is Walter Stinnett. And welcome to the first of three webinars on Project Requirements Management. In this first presentation, I will be giving an overview of requirements management. In part two, I will be delving deeper into this topic by discussing the process of collecting and writing requirements. And then finally, we will be ending up with a discussion on monitoring and controlling requirements. So, thank you for joining us today on this webinar, and let’s get started. So, our topic for this particular installment is, An Introduction to Requirements Management. Our lesson objectives will be the following. We’re going to define requirements. We’re going to delineate between different types of requirements. We’re going to identify why requirements are essential to the project success. And then we’re going to define the importance of stakeholders in the requirements management process. Before we start, I have provided some quiz questions. And as I read through them, keep them in mind. And hopefully, by the end of the presentation, you’ll be able to answer these correctly. So, the first question is, user stories are written from the perspective of the? Question number two, waterfall methodologies are best suited for what level of requirements uncertainty? Question number three, why are requirements captured? The next question, in a highly predictive life cycle requirements are? And the next question, which stakeholder group is closest to a solution? Successful projects meet the needs of stakeholders only at the beginning of the requirements cycle, true or false? What are the benefits of a requirements management plan? Requirements are defined as? So, hopefully you’ll be able to answer these questions. So, let’s begin the presentation. Every year, The Project Management Institute has a survey called the Pulse of the Profession. And in this particular year, which was 2017, they found that 47% of unsuccessful projects failed to meet original goals due to poor requirements. And 39% of failed projects identify inaccurate requirements gathering as a primary cause of failure. So, while this is in 2017, it might still be applicable to today. I haven’t been able to find, not that there isn’t, but I haven’t been able to find statistics in this manner for ’20 and ’21. But this really shows you the importance of requirements. Because look, 47% of unsuccessful projects fail to meet original goals due to poor requirements. In fact, in 2019 11.9% of every dollar was wasted due to poor project performance. Now, think about that. That is $119 million for every $1 billion invested. Not only that, but 37% of completed projects experienced scope creep. Now, in this study, it was determined that the top reasons for project failure were, listen to this. Now, as I say these, these aren’t in any particular order, but just think about this and think about your organization. Think about your projects. Do they experience any of these issues? One, change in organizations priorities. Two, change and project objectives. Three, erroneous requirements gathering. And fourthly, inaccurate cost estimates. So, when I look at that list there, I think in actuality, each of those is related to requirements. So, we can see if the importance of what requirements are for a project. And if there’s any type of faulty requirements gathering, any type of issues with that, how that can negatively impact your project’s success. So, why capture requirements? So, let’s just look at this here for just a moment. First of all, we talk about communication. Requirements if they are properly documented, will give you the ability as the project manager to communicate the scope and the breadth of your project. So, in other words, you will be able to… Let me just say it this way, that users will be able to understand what your project is about by understanding what the requirements are. We’ll get into not this week, but a really more in depth next week, talking about needs. How do you understand needs? And you can do that by understanding requirements. I think this goes without saying, when we’re talking about a solid foundation here, if you don’t have an adequate requirements for a system or product, how are you going to be able to really develop and deliver that product? So, as you see here, it provides a clear description. I think a lot of this really is talking about even the definition of requirements, serves as a foundation, the basis of design. So, you can see here the importance of requirements management. Can you think of any others? Just take a moment and think of why you capture requirements. Why is it important to your organization? Has the whole process of requirements management been a good process or does it need to be improved? Just think about those as we go forward. And hopefully, as we work through this particular lesson and the subsequent lessons that they will help you to be able to build a process that will allow you to be successful in your projects, by understanding the process of requirements management. Let’s take a look here at just a moment in context where requirements fall. Now, you may recognize these. We call them here where I work, monopoly cards. But you’ll probably recognize the processes here that are within the scope management knowledge area. And I’ve built it this way to just show what the flow is, to see how all of these processes work together. So, if we look at the far left, we’ll notice in the plan scope management, the main output of the scope management knowledge area is the scope management plan. And not only that, but the requirements management plan. So, right from the very beginning, you are laying out the details of how you’re going to be doing requirements management, how you’re going to be defining scope. If we can start right at this very first process within this knowledge area, that is going to help us to move through the whole process more successfully. If you haven’t adequately developed the roadmap on how you’re going to come up with your scope, how you’re going to do the whole management process, then that can be a detriment. But as you move through process, these the scope management plan and the requirements management plan is going to be an input into the collect requirements process. Now, if you’ll notice here in this list, excuse me, you don’t see scope management plan and requirements management plan listed. And the reason being is that it is rolled into the project management plan. Those are what are called subsidiary plans. So, they are rolled into the project management plan. You’ll see the tools and the techniques. And notice what the output are for the collect requirements process, is the requirements documentation and the requirements traceability matrix. Your requirements document is going to be that document that will record what those requirements are, along with other information. Now, your requirements traceability matrix, and we’ll get more into requirements traceability in the third session, but the requirements traceability matrix also is going to have a list of your requirements as well. Now, the difference between the two are that your requirements documentation or document is just going to be housing the requirements and other information. But you’re going to be using the requirements traceability throughout the entire lifecycle of the project to ensure that the product service and result that you are going to be delivering is still meeting those requirements. If you’ve successfully and robustly developed your requirements documentation and requirements traceability matrix, then notice what the flow is. Then you will use that. Again, you’ll notice here that it’s not listed in, those two specific artifacts are not listed in the defined scope inputs, but what you have in there are your project documents. Your project document are going to be containing, in other words, your requirements documentation and your traceability matrix. So, those are going to be used, especially the requirements documentation, to then define what the scope of your project is. And once you define what your scope is, then you will create a scope statement, which is a statement that details the description, the full scope of your project. And then finally, notice the process where it moves into your project scope statement and your project document are going to be updated if needed. And those are going to be the inputs to your create your WBS. And it is the output of your WBS, which is going to be your scope baseline. Hopefully, that gives you an understanding of the context of collect requirements and how it works within project management. And you can’t really be able to successfully create a WBS if you can’t define the scope. So, oftentimes, if you can’t define the scope, it’s because you haven’t fully and correctly, and accurately collected the requirement. Collecting requirements are so important, so important when it comes to project management and understanding the scope of your project. So, what are requirements? How are requirements defined? Well, requirements are defined as conditions or capabilities required to be present in a product service or result to satisfy a business need. In COSI defines it as a statement that identifies a system product or process characteristic that is deemed necessary for stakeholder accessibility. So, you have two things here. You have capabilities, those are the fundamental requirements of a system or feature, and those are solution independent. And then you have conditions, which are measurable, qualitative and quantitative attributes and characteristics stipulated for a capability. When you boil it down, it is what is necessary to build your product service and result. While there are factors that play into a successful project, requirements are the key. So, think about anything that you do, whether it’s work or personal, you might requires certain capabilities to properly do your work. How many of you have ever been at work and you just don’t have all of the tools that you need? Or let’s just bring it down to your personal life and at home. Have you ever tried to put up a fan and you just didn’t have the right tools to be able to do that? Or you’re trying to do something for your car and you just don’t have the right tools. It is difficult to be able to even finish what you started out to do, because you don’t have the capabilities to be able to do the work that you want to do. Well, it’s the same way with requirements. You have to have certain capabilities to properly build and deliver that product, service and result. So, here are a number of different requirements. Just take a moment to read through these. You can think of others. Maybe you have worked with, developed or gathered other types of requirements, but you have business requirements which are those higher level organizational needs. It might be that those business requirements are why an initiative has been undertaken. You have stakeholder needs, stakeholder requirements, which really are the stakeholder needs, what those stakeholders desire. And we’ll talk a little bit more about stakeholders a little later. You have solution requirements. Those are features and functions, and characteristics of a product meeting business and stakeholder requirements. They can be grouped into functional or non-functional categories. In other words, you’ve determined what the solution to the project is going to be, or to the problem, or to the need. And that’s what we’re talking about here. Functional requirements are product behaviors. Non-functional are environmental conditions or qualities required for a product to be effective. You’ll notice there what it says, those types of conditions, reliability, security, performance, level of service and supportability. Then you have transitioned requirements which are temporary capabilities, such as data conversion, training requirements, and operational changes to transition from a current state to a future state. And then finally, you have your system level requirements, which describe the functions of a system and what that system should fulfill to satisfy the stakeholder’s needs. So, these are all the different types of requirements that you might have. You could have, more than likely you could possibly have more than one type of requirements in a project depending upon what that product, service or result is. So, let’s take a look here for just briefly. We’re talking about requirements. So far, really what I’ve been discussing somewhat are the traditional view of what requirements are. But there are requirements when we talk about the agile type of life cycle, and those are user stories. And user stories are, as it says here, a short and simple description of a feature. They are going to be what will populate the product backlog, which is a list of those user stories. They are the requirements that the development team will use to develop the solution. As you see, they are told from the perspective of a user or customer of the system. And generally they follow this template. As a type of user, I want some goal, so some reason. So, for example, here are some user stories as a customer. I want to be able to find past recipes, so I can prepare them again. And then you see the other two here that we have referenced. Really, how are you going to be using your requirements? What type of life cycle are you using? Really, will determine the types of requirements often that you’ll be writing and collecting. So, if it is a predictive, waterfall type of lifecycle, you’re going to be doing all of the requirements management upfront. And we’ll see that here in just a moment. So, here is an example of the systems development life cycle. And there are any number of ways to define a system life cycle. In fact, if you ask 10 people, what a life cycle is, you’ll get 10 different versions of this graphic. But the key here is for your organization to choose the one that best suits the work that you’re doing. But here is really your sort of basic life cycled that you’ll find in COSI. And in the concept stage, that is where you’re going to be identifying your stakeholder needs, and you’re going to be exploring concepts and proposing viable solutions. It is in the development stage that you’re going to be defining and refining your systems requirements. You’re going to be defining your solutions description, the architecture and the design. You’re going to be initiating the initial system and integrating, and verifying and validating the system. In the production stage, you’re going to be producing the system. You’re going to be identifying, inspecting and verifying. Utilization and support stage, you’re going to operate the system to satisfy the users need and support. And support really is providing sustained systems capability. Retirement stage, you’re going to be storing and archiving and disposing of the system. But really when it comes to the system development life cycle, you’re going to be doing the majority of your requirements work here in these first two stages. So, when we talk about project life cycles, they occupy a continuum from predictive to adaptive. And you will see this chart here and you’ll notice in the first bullet, it really shows how requirements are handled in each of those life cycles. So, when we talk about predictive, we’re talking about that the majority of the planning is going to be done upfront. You’re going to be gathering and doing all of the requirements gathering and analysis, and elicitation write at the very beginning, so that you can have as much of information that you have. And then you’re going to work through the process, the project and deliver at the end. Iterative is that you’re going to be improving the products or results through successive prototypes or proofs of concept. So, every prototype is going to be yielding new stakeholder feedback and team insights. So, then you can take that feedback and you can improve the product service and result as you move through. Now, with iterative, you’ll notice here that requirements are defined iteratively, and there are elaborated on periodically during the requirements process. So, that means, for example, if you are in an iteration to where you are getting feedback from your customer, there are changes that need to be made. Well, that is going to mean that those requirements are going to possibly need to be changed again. So, you’re going to be defining those iteratively. And then finally, you have the highly adaptive or agile. Agile is you’ll notice here for the requirements. Requirements are elaborated at frequent recurring intervals for each iteration. So, in other words, what you have here is, for example, I have the CSM, the Certified ScrumMaster certification. So, I’m more familiar with Scrum, but you have all of your sprints that you are doing work in. So, at every iteration or increment, you’re going to have, for example, sprint planning to where you’re going to determine which stories that you’re going to work on. Then you’re going to have your sprint retrospective and your sprint review at the end. So, you’re going to see, well, what changes need to be made? Do we need to elaborate on anything? So, you’re going to be looking at what user stories can we work on in subsequent sprints. So, your requirements are going to be elaborated at more of a frequent and recurring interval. So, which lifecycle do you work in? Now, it could be a combination. It could be predictive. It could be adaptive or iterative. Oftentimes, that will determine how you are going to be doing your requirements management. Let’s take a look at this. And this is talking about requirements uncertainty. And really it’s similar to what we’ve already talked about in relation to the type of lifecycle. And depending on the scale, the novelty, the technical challenge and requirements, uncertainty, planning and budgeting for specific activities might become more challenging. If you take a look at this, now notice here, the waterfall methodology, it’s more suited for something that is simple, less uncertainty. It relies really heavy on being predictable. That is the falls within the simple. And one of the things here is that some projects have considerable uncertainty around project requirements, and how to fulfill those requirements using the current knowledge or technology. And these particulars uncertainties can really contribute to a high rate of change and project complexity. As the project uncertainty increases, so too does the risk of rework and the need to use a different approach. To mitigate the impact of these risks, teams might select life cycles that allow them to tackle projects with high amounts of uncertainty via small increments of work. That’s what it’s really showing here, that the more complicated and complex projects, then for the fact that in agile methodologies, you are doing smaller increments of work, therefore you can handle risk and identify risk on a more frequent basis, therefore that will allow you to be able to do more complex and complicated projects. Another thing, teams can verify their work more frequently when they use smaller increments, and they can change what to do next to handle that complication and complexity. If there’s chaos, this is really just reminds me, how many of you consider when you are handling your projects, doing your projects, that it just seems like all chaos, it might not be, but it just sort of seems like that. That is very, very risky for having projects that basically are in an area of chaos. Think about your project. Is it a simple project? Does it have simple deliverables? Well, what I mean simple, really no deliverable is simple. All deliverables really are important. But what is the complexity and uncertainty? Is there not a lot of uncertainty? Well, your waterfall methodology might be the best way to go about it. But if it’s your project is more complex, it’s more complicated, there’s more uncertainty, then your agile methodologies, to where you can do smaller increments of work, might be the best way to go about when it comes to your requirements into your project. Let’s talk about requirements planning here. We’ve given an introduction to what requirements are, why they are important. Your project life cycle will dictate oftentimes what your requirements will, the type of requirements or the type of gathering of requirements process that you will use. But no matter the type of project that you might be in, that you might want to start, there is one thing that needs to be done no matter what. And that is to plan. And in this instance, when we’re talking about requirements management is developing a requirements management plan. All of the management plans within the PIM bot guide really are just as this first bullet says, is to provide guidance and directions. And in this particular instance, it’s going to be guidance and directions on how requirements should be developed, managed, tracked, validated and reported. So, it’s really, I look at these management plans as roadmaps. So, you’ll notice some of the other aspects of the requirements management plan. It focuses on the scope of requirements activities conducted and deliverables produced. It documents how requirements should be prioritized, approved, and maintained. It establishes the traceability structure and implementation to reflect which requirements attributes are captured on a traceability matrix. It details the roles and responsibilities, and specifies how requirements are documented and communicated to the stakeholders. So, you see here how important the requirements management plan is to be able to detail all of this information, so that you would have a roadmap when it comes to the process of collecting requirements. And anyway, even all of the other requirements management plans, I can’t stress enough how important it is to ensure that you have a plan for those. Project managers have a challenge. They have a challenge. And the challenge is to keep these three factors, scope, time and cost in balance. Now, the purpose of me showing this particular slide is not so much to go into scope and time, and cost because you know if the scope is impacted or one of these parameters, the other two are going to be impacted as well. If you have increased scope, then there’s a chance that you would have increased time and schedule, and increased costs. Now, one of the things here, you’ll see quality right in the middle. That throughout your entire project, you’re going to be needing to keep scope, excuse me, quality in the forefront. But really, what I wanted to point out is the arrow circling around this triangle. Notice what it says here, stakeholder needs and expectations. So, really what are we talking about here? We are talking about the importance of understanding your stakeholders needs and your expectations. Because really, when it comes to requirements, you’re going to be eliciting, drawing out those requirements from stakeholders. Therefore, you’re going to be needing to understand their needs, and as well as the expectations. They might be thinking that the project is going to deliver one thing while you’re thinking another thing. So, we need to understand their expectations. Also, why this is surrounding this balance is that stakeholders could possibly impact your project negatively. Maybe they implement a policy change that then trickles down to you and now you have to stop and go right into planning again. So, there’s a lot of factors when it comes to stakeholders. So, we’re going to take some time here to look at the various stakeholders. What is a stakeholder? I think all of us probably know what stakeholders are. They are those persons who could impact your project or be impacted by your project. You’ll notice here, and accidentally had this under the graphic, but it is SMI, subject matter experts. And I liked this graphic here. I think it is a good representation of stakeholders. Stakeholders have different personalities, different types of influence. Maybe you have stakeholders that are like the turtle and the snail, they’re real slow, or like the ferret, maybe they’re really sly, or really young and new at the game. Or maybe you have the leader who really stands out or team members that talk back to you, even you’re telling them that what’s they need to do, and they talk back at you like the parrot. But whatever the case might be is that we need to identify those persons who need to be involved in the requirements management process. And here are some of the examples here, users, operators, organizational decision makers, again, I apologize for the typo here, regulatory bodies, subject matter experts, contractors, product owners, Scrum master, Scrum team. This list is not all exclusive. It really is, who needs to be involved? There is nothing worse than being in a meeting where you have planned to talk about requirements and began the whole requirements gathering process, and the wrong people are there. That meeting is useless. So, one of the very first things is to understand and identify who those stakeholders are. Now, here is a good tool. It is called the onion diagram, and it depicts the relationships between the stakeholders and the solution. You’ll notice here that is just one technique that you can use to model the relationships that exists between the stakeholders and the solution, that can be external to the organization or internal. But you’ll notice here that closest to the solution are those stakeholders who are directly involved with the development of the solution. So, they could be the development team, the developers, whomever those might be. Then, and the next level of the onion, you have those stakeholders directly impacted by the solution. Who are you building that solution for? Is it for your organization? Is it for the public? Well, they could be directly impacted by the solution, especially if it’s internal. Then you have stakeholders who interact with those directly impacted by the solution. Could be other people in the organization and other departments. And then you have external stakeholders. Those could be your vendors and third party contractors. So, this is one way that you can begin to think about who those stakeholders are by thinking about these specific categories. Each subsequent layer represents a lesser degree of relationship to the actual solution itself. So, once you’ve identified your stakeholders, then you need to analyze them, how much influence do they have over your project or idea? Can they help move it forward or could they stop it in its tracks? You’re going to be doing this analysis during the planning process. You’re going to be determining not only your power, which I just mentioned, but their interests, how much interest do they have? Will it be beneficial to them? Just think about your work or your project, will it benefit them? What is important to them? What will they want to know or not want to know? These are things that need to be analyzed. Find out as much as you can. It will really help you with a strategy to build better relationships with them. And why it’s important when it comes to the requirements management process, is that you’ll be able to determine who those stakeholders are and who needs to be involved in the requirements process. Now, you don’t want to necessarily have those who aren’t involved, I mean, who might not be touched, you may not necessarily want. If we looked at the onion diagram again, it might not necessarily be that you would want to invite. It could possibly be depending upon who they are, those external stakeholders. Determine first of all, before you even have a meeting, who needs to be involved? Who are your stakeholders? What types of power and interests that they have? How close are they to the solution? You can then invite them to your requirements management process. So, stakeholder requirements. Really, what you’re going to be doing, you’re going to be getting and understanding what the needs are. And then when you understand the needs, you’re going to be able to understand, be able to translate those into requirement. As you see here, they govern the systems development. They are essential factor in further defining or clarifying project development scope. They provide the basis for technical description of deliverables in an agreement. You’ll see here how important those stakeholder requirements are, because ultimately we want to satisfy our stakeholders. So, here is basically, this is how it works. Okay. Stakeholders have wants. Those wants are then refined to needs. And then the needs are then transformed into requirements. Think about your work. What are some of the things that your stakeholders want? And what is a want? A want is to greatly desire something, something that someone would like to have, but it is not always necessary. For example, I’m an avid photographer. And I’ve wanted a brand new camera, an upgrade. And I remember if I wanted something that was not feasible, like a new camera, my wife would say, “Well, you are old enough where your wants W-A-N-T, won’t, W-O-N-‘-T, hurt you. You’re old enough where your wants won’t hurt you.” Oh, I hated to hear that. What that means is that means is, you can want it as much as you want, but you’re not going to get it. And really that is true. When I think back and I’m thinking about the cameras that I wanted, it’s really true. So, the key point here is, is that I may have wanted to buy a new camera, but I really wasn’t taking into consideration on whether we could afford it or not. And really we couldn’t. So, it goes back to managing those stakeholder expectations. Now, a need is a condition or a situation in which something must be supplied in order for a certain condition to be maintained or a desired state to be achieved. I like to look at a need as this, is that it is the gap between what is and what should be. So, you have a current condition, you want to move to a future condition, that need is that gap to get you from the current to the future. So, here’s an example of really an informal requirements process. You have the stakeholder approaches the project manager. And this particular stakeholder says that, “I want a connection to the mainframe.” One thing that, and we’ll get into this more next week when we talk about eliciting and collecting, and writing requirements, is that often when we are gathering requirements, the stakeholders may not necessarily fully be able to articulate what they are wanting. So, if you look at this, he wants a connection to the mainframe, that really doesn’t tell you a whole lot, at least to that project manager, what is needed? Project manager begins to ask questions to understand the need. And the project manager continues to ask the questions until they have an understanding of what it is. So, in this particular instance, they only want one connection versus numerous connections. In this instance, the end game here is that requirements are formed from the needs resulting in a single connection to the mainframe with accompanying security. If you say the process here is that, first of all, you’re understanding what the stakeholders needs are, you’re understanding what their expectations are, you’re asking them to process that, to express that, well, that may not necessarily… They may know. Just think about, have you been in a situation to where you know what you want, but you just can’t express it fully? And you’re asked questions to, “Please, clarify.” Which really is the same thing. You are asking questions until… which is elicitation, really. You’re asking questions to understand what those needs are. Once you understand those needs fully, then you can write requirements. Requirements are important. Requirements are in every aspect of your project. You really can’t move on through the whole process of understanding and defining your scope, and creating your work breakdown structure unless you truly understand those requirements. You can’t get those requirements until you really understand who your stakeholders are. And once you understand who your stakeholders are, and your stakeholders could be organizational needs. It doesn’t necessarily mean individual needs. But you begin to understand those needs, and you can begin to elicit. And then you can understand, and begin to write your requirements, which is what we are going to be discussing next week when we talk about collecting and writing requirements. So, thank you so much for joining me on this particular webinar. I really appreciate it. We will continue next week on collecting and writing requirements. So, you see my email here, please feel free to shoot me an email, if you have any types of questions. I’ll be glad to help you with that. So, thank you so much for joining us. And until next week, bye. Watch the on-demand recording by clicking here.

Project Requirements Management – Part 3: Monitoring and Controlling Requirements

Event Description: This third session explains the importance of traceability and why it is essential to ensure quality is maintained throughout a project’s lifecycle. Provide examples of tools used to trace requirements. Learning Objectives: Presenter: Walter Stinnett is a project manager and serves as the Learning and Development Delivery Manager for Edwards Performance Solutions. He coordinates training, teaches primarily Microsoft Project courses, and has presented project management tools at various venues. He joined Edwards in 2004 as a Project Coordinator and Scheduler and provided project planning and scheduling support to a variety of commercial and federal government clients, including Swales Aerospace, Department of Justice, Federal Aviation Administration and the Centers for Medicare and Medicaid Services. Walter’s certifications include the PMP and MCTS. Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]

Project Requirements Management – Part 2: Gathering and Writing Requirements

Project Management Institute (PMI)® Professional Development Units (PDUs): This Webinar is eligible for .75 PMI® PDU in the Technical category of the Talent Triangle. Event Description: This second session reviews how to implement a structured approach to gathering requirements. Create clear and concise project requirements and review examples of complete, comprehensible, and verifiable requirements. Learning Objectives: • Define the requirements management process • Write well defined and properly structured requirements Presenter: Walter Stinnett is a project manager and serves as the Learning and Development Delivery Manager for Edwards Performance Solutions. He coordinates training, teaches primarily Microsoft Project courses, and has presented project management tools at various venues. He joined Edwards in 2004 as a Project Coordinator and Scheduler and provided project planning and scheduling support to a variety of commercial and federal government clients, including Swales Aerospace, Department of Justice, Federal Aviation Administration and the Centers for Medicare and Medicaid Services. Walter’s certifications include the PMP and MCTS. Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]

  • 1
  • 2