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.
