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
