What is the requirements management plan? It’s a component of the project management plan, and it describes how project and product requirements will be analyzed, documented and managed.
Basically it’s the process that we’re going to go through to gather these requirements and then manage them and track them, to ensure that we’re delivering on those customer requirements right up to the end when we finish delivering the project.
With the rise of the business analyst role, almost every project will have a business analyst and many organizations will refer to this requirements management plan as the business analysis plan.
Because we’re describing the process of how we’re gathering these requirements and then tracking them there are a few different things that can go into our requirements management plan. Don’t forget with any plan we can make it small – it can be simple like just a couple of lines in an overall document, or if it’s a large project and there’s a lot of people involved and there’s a lot of stakeholders and it really needs to be spelled out, it could be a document of its own. And that could go into your project management plan. As long as it covers off these things in general usually you’re pretty safe.
Things required in a Requirements Management Plan
So how are we going to track and find these requirements? How are we going to report on them? How are we going to initiate changes, and how will those impacts be analyzed? How will the requirements be traced tracked and reported on, to make sure that we are delivering to our customer at the end and that they’re happy. What authorization levels are required to approve any changes? (This will tie in with our configuration management plan for any documents that will be baselined).
Requirements prioritization, how do we prioritize them? Are they based on business value? Who does that, who decides and the metrics that will be used for rationale? This helps get everyone on the same page. Are we going for speed in a process? Are we going for cost reduction? Whatever it is it’s good to write it down so that everyone is on the same page.
Lastly one of the most important things, the traceability structure. This reflects the requirement attributes captured on the requirements traceability matrix. In other words the traceability matrix is a separate document to this that will tie into it and show us how we’ve got our requirements and how they are actually related to the scope, and ultimately the items that we’re delivering. There needs to be a clear line, clearly shown, which is why it’s in a matrix format. You’ve got your requirements down the side and as it goes along it shows how they’re relating to the scope that you’re delivering. And that rounds out the details you will find in a Requirements Management Plan.
What is the final report? It is a report that provides a summary of the project performance and how it went, either during that phase or during the entire project itself. As with all things in project management it can be a small piece of work or it could be a large detailed document in itself. It could be formal or it could be informal. It could range from a document just a few lines in your project measurement plan, or it could be the outputs of a retrospective if you’re delivering a feature using agile for example.
A retrospective occurs for us to say what went well, what didn’t go well, what still puzzles me and what have I learned. Asking those questions and feeding that back into the process and that could be documented as a final report for that iteration or that particular feature.
There are many different ways to use the final report. It can include things like the scope objectives – were they met? And evidence of them being met. Has the scope been verified, and has it been delivered and accepted by the stakeholders? The quality objectives, actual milestone delivery dates (when did we deliver these things) and any variances in those. Did we say we’re going to deliver here but we actually only delivered there? What were the variances, and why.
This also feeds into our lessons learned register. Lessons learned from the project will really help future projects if this information is available.
We’ve got cost objectives – the actual versus predicted cost, reasons for any variances, same with the schedule and same with any risks. Did we encounter risks? How did we resolve them? All of that can go in the final report.
The final report puts it in a nice sort of nice package for the end of project report. Part of this could also include a handover document to whoever you’re handing over to or ultimately delivering this project to. All that information that they might need down the track, who to go to for this system access, who to go to if they need to get more of this resource once it’s gone into BAU. That can be part of a handover and can potentially go into the final report as well.
What is the configuration management plan? It’s a plan that defines those items that are configurable. In other words the items that require a formal change control – usually items that have been baselined, they have been locked into a point in time.
These things might be to do with your scope, your schedule, your cost, usually locked in at a point in time beause we don’t really want those to change without any formal process.
We don’t want them to change on an ad-hoc basis because obviously these will affect and impact the outcome of your project. If we’re changing the scope or the schedule or the timeline or the cost involved, those documents are usually baselined and then they require that formal change control process, and the process for controlling changes to these items.
So while it usually relates to these baselined items such as the project budget for example in our cost baseline, schedule, scope statement and work breakdown structure where we’ve broken down the scope statement into smaller activities for us to complete in order to to deliver those features or those pieces of scope.
In order to change this we’ll need to go through the configuration management process.
Like all plans in your project management plan it can be small, just a few lines of text or it can be large and detailed. It could be an entire document of its own design, depending on the size of the project, depending on the enterprise environmental factors (EEFs) of your organization. The main point is to outline which of those documents will need formal change control, and that can be completely up to you and the project sponsor. You can work together and advise which things need to go through a formal process to change. Anyone can raise a change request, and in your change management plan you note the change process, such as where that change request will go into once it’s raised. Once that change is approved after going through the approval process, we will need to realign the project scope or schedule to suit these new changes. Maybe more money or funding comes in, so you’ll have all of these steps and these steps will need to be outlined, and that’s why we have the configuration management plan.
What is the issue log? Throughout the life cycle of a project, you (as the project manager) will normally face problems or gaps, inconsistencies or even conflicts in a project. This stuff happens all the time, because your project is designed to bring about change, and so there will always be little things happening – stakeholders to manage or things people will be unhappy about. Maybe the scope needs to change, all of these little things are happening all the time in a project and they occur unexpectedly, and they require some action to bring everything back on track so that it doesn’t impact the project performance in general.
That’s when we need to raise an Issue, once these things have happened.
The issue log is a project document where all of these issues are recorded and tracked. It’s important to note that an issue and a risk are not the same. Before something happens, it’s noted as a risk, and we can note that in the risk assessment, and we’ll assign things like controls to that risk so that we can prevent the risks from happening. We’ll assign owners of those risks to look at the activities around those controls, make sure that things remain on track. Obviously not everything always goes to plan and we can’t always think of everything that will happen, so if something does happen it becomes an issue.
An issue should be noted in the issue log at that time. The issue log will help the project manager effectively track and manage those issues. We’re going to be assigning extra information to these issues so that we can effectively track those issues, and we’re ensuring that they’re investigated and resolved and closed.
Issues may happen at any time, and the issue log is updated as a result of the monitoring and controlling activities throughout the project’s life-cycle. As part of controlling issues it may result in a change request as well. If we’ve raised an issue and it’s resolved, but it is something that needs to change like the scope or the schedule, then we need to raise a change request. Maybe we’re changing one of those baselined documents, around our scope, our time or schedule, or our cost.
These are the three most most important things that will be baselined, and that might need to go through the formal change control process by raising a change request. Then you can update the issue log with all of the appropriate information once that’s resolved.
The data that we’ll put on our issues are things like the issue type, who raised that issue, the description of the issue, priority (is it high, is it low) who is assigned to the issue to manage it ongoing, the target resolution date (is in June, July or August etc), the status current status and of course the final solution to resolving that issue, which is where that change management or the change request might come into it if something needs to change.
So overall it’s a very important part of your project, because you will need to raise and manage these issues as they occur. You’ll still need to keep an eye out for risks as there are you know on the horizon as well before they turn into issues all of this is part of managing a project and keeping it on track and that is the Issue Log.
The project management information system, or PMIS as you will see it referred to in the PMBOK guide, is the coherent organization of the information required for an organization to execute projects successfully. That of course is a bit of a mouthful, so what does that actually mean?
Typically it’s one or more software applications – so it’s not just one IT software application it’s a whole bunch of applications – and the process that’s associated with those software applications for collecting and using project information, most typically with the activities related to the project. It relates to who’s doing what, and when they are doing it. And that would relate to the schedule – when these activities are being done, and potentially to the scope as well. Scope is being ticked off as we’re going along on our project, and that will impact what activities are done, and the activities need to be assigned along a schedule so that we understand when these activities are going to be completed.
All of these things you can’t just rely on word of mouth for this to happen – you need to put them somewhere so that people can see them and understand what’s being done as part of your project. And that is where our PMIS comes in.
So it’s not just one IT system, it’s an entire system or approach including tools and processes. It’s the different cogs and they all intertwine and they all relate to each other, and they help move each other as part of the whole system. Your project measurement information system would include things like scheduling software tools, work authorization systems for work packages (i.e. who they’re being assigned to, who’s receiving them, are they able to work on them?), configuration management systems (i.e. the change process).
Are you changing the scope, who does that go to, does it go to the project sponsor? What’s the process there? And this IT system would facilitate that configuration management.
Document management systems, so where are all the documents being held? Information collection interfaces to other automated systems, so corporate knowledge bases, lessons learned or perhaps procurement systems that you might need if you’re hiring people or resources. Automated gathering and reporting on key performance indicators or KPIs can also be a part of this system, for example how is the project tracking?
You’ve probably used a project management information system or part of a project management information system in your life already. Some of these things will include a Kanban board, if you’ve used Atlassian JIRA or Trello, this is very simply a Kanban board where we’re moving tasks and activities across the board from “in progress” or the backlog through to “done”. And that’s how we’re tracking those activities, it’s very very simple. You might have an internal company SharePoint page, and that’s where you’re keeping all the documents for your project. Or you might have a Confluence page or something similar. The IT system itself doesn’t matter. But it does matter that you have something to hold the documents, for future projects to learn from and also for the governance around your project. This also helps the governing bodies (such as a project management office) see the activities, and that the proper governance has been checked off, that you’ve done the proper documents for procurement, for hiring people, or you’ve done the proper documents for making a change to the scope for example.
Lastly, resource calendars or an online project schedule. You might be able to see see Billy or Fiona or Helen for example, all these different people and you can see when they’re assigned to the activities and also when they are available to work on your project. That’s a very useful part of the information of your project, and that is an outline of the project management information system.
A change request is a formal proposal to modify any document, any deliverable or any baselined item (that could include your project management plan, your scope statement for example). The most common of these documents are related to the Scope, Schedule or Cost of the project. For example, are we changing the the dollars involved? Are we changing the time involved? Or are we changing the Scope that we’re delivering in our project. All of these will need a formal change request once a document or an item is baselined.
Any project stakeholder may request a change. Change requests are processed for review and disposition through the change control process, and change requests can be initiated from inside or outside the project. They can be optional or they can be legally or contractually mandated. Perhaps a legal change has happened and that requires a change that needs to go through the formal change request process, so that we’re going getting the appropriate approvals to change either the scope, the schedule or the cost. We want everyone to be across this change, we don’t want to just be changing the schedule on an ad-hoc basis otherwise people are going to get upset. We do this often times when issues, gaps or problems are found while the project work is being performed. A change request can be submitted to modify things like our project policies or procedures – maybe we need to do things in a different way – the project or product scope as we said, the cost or the budget which we’ve touched on as well. There’s the schedule or the time, if something is going to be delivered in June but all of a sudden according to our analysis it’s going to be delivered in September and maybe that’s going to affect the cost because we need more resources, then people need to know about this through the appropriate methodologies and the appropriate process, which is this change management process.
The quality of the project or the project results – if that’s going to vary significantly then perhaps we need to raise a change request as well. Maybe something simply is not possible to do, or maybe we’ve found a better way to do something and we just need to to put that into our scope so that everybody is aware. For this reason, change requests might include:
Corrective action where we’re bringing a project back on track. For example we’re aligning the project activities to something that we’ve found.
Preventative action – maybe we’re preventing future performance from going off-track, for example we see the schedule coming up in September instead of June, and that’s something that we want to bring back on track. Maybe we want to crash the project resources, where you add a lot of resources and money and cost and that’s going to bring it back into June so that we can get it done. Maybe we need to fast-track the schedule, which is doing everything in parallel instead of doing everything one after the other, and that will get it all done in time.
Defect repair – as we’re going through our quality control, maybe we’re doing our test plan and testing the item and that comes up with a defect, but that actually changes the scope of the project. So it relates to scope again, we need to make a change and we need to make a formal change through our change management and change request system.
Of course we could have just general updates to our project, where maybe a customer has found that they don’t like something and we need to change that. Or maybe the situation has changed where they don’t need it until September and we can actually physically change that project schedule. All of this is completely up to you as the project manager, and usually you’ll be working with the project sponsor and the people involved who you’re delivering this project for, and the team that you’re delivering with.
The change management plan is what describes the process for these change requests. How do how do you raise a change request, for example? And what do you need to do? Who does it go to? Does it go to the project manager, then to the project sponsor? Does it need to go to a steering committee? What is the approval process of these change requests?
If we’re involving more money, and it needs to come from the project sponsor or a governing body then that needs to be approved by those people. This process can just be a few lines in your project management plan, noted as a change management process. Or it can be a complete document outlining the process. A lot of this depends a lot on the environmental factors – the enterprise environmental factors which you’ll see in almost every PMBOK guide process. That just relates to how a company works and how it operates on a day to day basis. All that will affect how you raise a change request, and what you put in your change management plan. And that is the process and the idea behind Change Requests.
When we’re developing the project management plan a lot of the time we’re going to need to create baselines.
Baselines are one of the key concepts that is really important, because they are a point in time where data or information is locked in place, with any changes needing to go through a formal change or configuration management process to be reviewed, approved and accepted.
There are multiple documents that require baselining in your project management plan, and most of those will relate to the key constraints in your project such as:
Scope – the scope that you are going to deliver.
Time or the schedule – you might have your Gantt chart or the locked-in schedule, and you don’t really want that to change because you’re delivering something at the end and your customers are relying on that to be delivered.
Cost – if someone is sponsoring this project or paying for this project then of course they don’t want that cost to change, at least not without the proper approval process.
So what are these documents that we’re talking about? Well the need to be baselined fairly early on in your project, during the initiation and planning of your project.
First of all we’ve got the scope baseline. This is the approved version of a scope statement, a nice simple statement of what you are delivering to your customer. Then you’ve got the associated work breakdown structure or WBS and its associated WBS dictionary. That’s basically the scope broken down into smaller parts.
Then ultimately the activities that we’ll need to to deliver those parts – all of those parts of your scope – we want to lock that in so that we know that we’re going to deliver it on time, and we know if we’re not going to deliver it on time.
Then there is the schedule baseline, which is the approved version of the schedule model (that can be your Gantt or even just dates and activities depending on how you outline that in your project management plan) and can be used as a basis for comparison to the actual results so once it’s locked in. For example, how are we actually tracking over time? Are we on track, or we not going well? That’s what we really want to know.
Lastly we’ve got the cost baseline. This is the approved version of the time based project budget where we’ve got our activities, the things that need to be completed and we’ve got the cost associated with those activities. All of the schedule and the scope – if any of that changes then obviously that will have a big impact on the cost of the project as well, so all of these things are interrelated.
Before a baseline is actually defined, all of these documents can be updated as many times as necessary. You’ll find that right at the beginning of your project, during the project charter and maybe just before you’ve locked in your project management plan, no formal process is required at that time. But once that baseline is locked in then they can only be changed through the “perform integrated change control” process which we’ll probably notice is around 4.6 in the PMBOK guide. Any stakeholder can raise a change request, that’s how this is done. Anyone related to your project, whether it’s someone impacted by the project or whether it’s the sponsor who’s sponsoring the project, whether it’s the people doing the the work packages in the team of the project, they can raise a change request for that to be looked at which will go through the change control process. That change control process is usually outlined in your project management plan as the configuration management plan.
What Does a Configuration Management Plan Process look like?
It will be different for each organisation and even each team you work in. Maybe the process for you is raising a change request to the project manager, the project manager checks it out with a few different stakeholders or the required information, or maybe that’s someone in the project management team who then goes through to the sponsor or to the associated steering committee for example. Depending on how your project is outlined, which of course relates to the enterprise environmental factors which you’ll see come up a lot in the PMBOK guide. This is how the company operates, and every company is different. There will be similarities, there might be templates, there might be different politics or different parts of the company that need to be approached, or maybe different parts of the company that don’t talk to each other at all. You need to be aware of these enterprise environmental factors in how to get work done and that will impact the configuration management plan, which is how to make changes to your project and your project baselines once they are locked in. And that is project Baselines.
This one is really fantastic because it looks into forecasting and maybe figuring out whether we want to spend money on a particular project or on another particular project. It really gets into into the meat of it before you kick off or initiate your project, and that’s what makes it really really great to learn about and to know about these forecasting techniques.
Using Future Value, Net Present Value, and Internal Rate of Return
For your project returns, there are many different ways to forecast these these things and as you initiate your project you may need to show your stakeholders the potential benefit that might come out of your project or what you’re going to deliver. Are you delivering a million dollars, or is it something else in benefit – maybe it’s customer value or customer goodwill as some soft benefits. Or is it some amount of value over time, potentially every month or every year for example.
To do this there are three common methods of forecasting that you will see on the PMP exam and in your project management career as well. You’ve got Future Value (FV) where we’re looking at what the value of a dollar today is in the future. Net Present Value (NPV where we’re looking at what the total outcome of our project three years into the future is, what that’s actually worth today. And our Internal Rate of Return (IRR), where if we’re delivering a million dollars over three years, what’s the actual percentage return in today’s figures?
For all of these on your PMP exam you really just need to choose the highest for each of them – so Net Present Value if you’ve got a choice between a hundred thousand dollars and a hundred and twenty thousand dollars, you choose the hundred and twenty thousand dollar one. It’s the same with Future Value – choose the highest future value, and choose the highest percentage for your Internal Rate of Return.
We’re also going to show you how to calculate these, just so know them, and it’s a little bit of fun as well.
Future Value
Future value asks “What would our money be based on a certain rate of return?” For example an interest rate, if we’re earning five percent a year or ten percent a year, in this example our future value equals our current (present) value multiplied by 1 plus our interest rate (so 1 plus 0.10 for example so it ends up as 1.10) to the power of the time – so in this case we’ve got three years. Let’s look at this example.
The value of a thousand dollars, in three years time, at ten percent interest.
We’ve got a thousand dollars, times 1.1 – so 10 percent (0.10) is our interest plus 1, to the power of 3. “To the power of” means 1.1 times 1.1 times 1.1, that’s three times we multiply those by each other. And that ends up to be 1.331 when you multiply all of those together. So we end up with a thousand times 1.331 and that gives us our future value of 1331. That’s how we figure out the future value at a certain rate of return.
Let’s say our project is going to give us a return of 10 per year, that’s very promising and that’s our potential return. We can do this the other way as well. We could say if we’ve got 1331 dollars in the future, and we want to figure out what that’s worth today then we actually just use divide instead of multiplication. So we just we go 1331 divided by 1.331 or our 1.1 times 1.1 times 1.1, and that will give us a thousand dollars in today’s value. So that’s how we do that looking backwards, and that’s important because that’s what we’re going to use for our Net Present Value.
Net Present Value
Now you might see this come up in financial accounting and statistics and that sort of thing, it’s a really cool technique to figure out what the project returns would be worth today, versus a certain rate of return and the future cash flows that we’re going to get out of our project.
Net present value equals the cash flow of year 1, divided by 1 plus our internal rate of return (which is our interest rate) and again, this is sort of foreshadowing for our next one which is the internal rate of return, but let’s say it is in this case 10 percent again. So it’s a 0.10, and we’ve got 1.1 again. So looking at the example we’ve got cash flow in year one or month one or whatever the the actual time frame is (it’s your choice), we’ve got $500 and we’re dividing that (now we’re looking backwards) instead of multiplying it, so we divide it by 1.10 and that gives us 454.
Great! Very easy. Now we’ve got our second year, or our second month or our second day, with $500 again. Now we divide that by 1.10 to the power of 2, so it’s 1.10 times 1.10 which equals 1.21. Then 500 divided by 1.21 gives us 413, and so on and so on, to the power of 3, to the power of 4, to the power of five – you could do as many of these as you see fit. You add them all together and then you minus the initial investment (we invested a thousand dollars into this project) because that’s a cost to us, it’s not a benefit that we’re getting. And all in all we get 243 dollars.
Now of course in the real world this might be 243,000 dollars, or 243 million dollars. Whatever size project you’re working with, or if it’s a personal project maybe it is 243 and that’s wonderful. But any positive return, that’s what we’re looking for, and the higher the better as we said.
Internal Rate of Return
Which brings us to the Internal Rate of Return. The Internal Rate of Return naturally flows here because we’re using the Net Present Value again, except what we’re doing now is we’re trying to figure out what that Internal Rate of Return is. It’s that interest rate we’re trying to figure out, usually through trial and error. So basically we have to figure out what that rate of return is, and we go up a little bit, down a little bit until we get to the stage where it’s the percentage that makes our Net Present Value equal zero, or as close to zero as we possibly can.
So again, the higher the Internal Rate of Return the better. Let’s go through an example just so it’s not too confusing. The initial outlay for our project is a thousand dollars, and we send that out to create our project – that’s our cost, so minus a thousand dollars. And then what we’re doing is we’re adding all of the benefits to that over time, so in this case we’ve got 400 cash flow, 400 cash flow, 400 cash flow coming in for each time period – let’s just call it every year. Let’s say we’ve got three years and each of those years we’ve got 400 coming in.
Now remember we’re doing that “dividing” instead of multiplying, because we’re trying to figure out the current value of these future cash flows. So using that dividing instead of multiplication. Let’s go through it. We’ve got 400 divided by 1.10 – we’re going to have a guess and say 10 percent is our is our interest rate – and that gives us 363. Now 1.1 to the power of 2 (so 1.1 times 1.1) equals 1.21, so 400 divided by 1.21 is 330. And so on and so on – again we could do this for as many time periods as we want – and then the next one to the power of three for our third year gives us 300.
So minus a thousand, then we’re adding 363, adding 330, and adding 300, and that gives us 993 which is just shy of a thousand so that’s that’s really close now we could fiddle around with this a little bit if we wanted to, we could say maybe it’s going to be a higher percentage maybe it’s 1.11 maybe it’s 1.12, or maybe we go the other way and we try and figure out which way do we need to go to get the closest percentage, to get it as close to 0 or just above as possible.
And that is our internal rate of return, remembering that when you get the question on the exam you might have three projects, one with an internal rate of return of 10 percent one with 12 and one with 15 percent, and for our purposes we want to choose the highest internal rate of return.
And these are all of the forecasting project return techniques that you will see on your exam and in your project management career.
Welcome! Let’s look at the key concepts from the PMBOK guide. In project integration management, when we start off with the project charter, the business case is one of the biggest things that feeds into that project charter. It’s the very first step that we’re looking at.
What is a business case?
The approved business case is a business document most commonly used to create our Project Charter which is that very first step in the PMBOK guide process groups. The business case describes the necessary information from a business standpoint to determine whether the expected outcomes justify the required investment. It’s our basic cost vs. benefits – we’re asking and analysing “Do they weigh up?”
That’s why our business case is commonly used for decision-making by managers or executives above the project level, for example the project sponsor who ultimately will potentially fund this project or at least provide the resources in their part of the organization to proceed with the project.
How do we create a business case?
There are a few things that we can do and the first is to research or analyze any of the following below just to see if that investment is going to be worthwhile. It may sound simple but you do have to do the legwork, you have to actually do a little bit of mathematics, and probably a bit of research to figure out if it’s going to be worthwhile.
You could research any of these things, for example the market demand. Out there in the world are our customers saying that this is exactly what they’re wanting? Then maybe that’s what we’re going to create.
Is there an organizational need? Maybe we’re wanting to combine a few departments, maybe the company is downsizing or maybe it’s growing and you need to create a new department and all of a sudden that requires resources, processes and things to be set up, and that could be a project that needs to be kicked off.
Customer requests, for example let’s say you work at YouTube and you’re seeing customer feedback who really want this feature, and everyone is requesting it all the time. Then maybe we want to check whether that’s worthwhile, how much is it going to cost? And we put a business case forward to get it approved.
Legal requirements, if you’re working in financial services or maybe you’re working in health there’s always legal requirements. There might be royal commissions, for example the government making changes to the legalities around your profession and that requires you to make a change. That also requires you to see whether it’s worthwhile and create a business case.
Ecological impacts, where we want to reduce the paper or we want to reduce our carbon footprint. Do we want to look better towards the market because we’re a better ecological company? What do we need to do, is it worthwhile? Can we spend the dollars and can that give us an outcome that’s worthwhile?
Social need, where recently the COVID response and the social need and the vaccines that need to be created, those are projects. How much do they cost? Do they need government funding? Is that cost going to be worth the effort for that particular vaccine, or maybe there are a hundred different vaccines on the cards and so which one is the most worthwhile? Which one is going to be worth vetting for that investment? That’s where the research comes in, and that’s your business case.
Lastly once we’ve done all that research, we simply write the case, which is a short document outlining what we have found.
There are things that will impact the business case, such as enterprise environmental factors which are the way an organization actually works. Is the work done by conversations in the hallway? Or is it done by this approving manager? Or is it done by a project management office? Does it have to go through the proper governance, through this particular area, what are the actual enterprise environmental factors of the company that you’re working in and how does work get done? Make sure you know.
Organizational process assets are things like templates that are accepted practice, and a business case has to be done in that particular template. Many companies work this way.
Lastly we make a recommendation based on our research. If it’s only going to cost a hundred thousand dollars to do it but we’re going to make five million then I think this is something that we would hopefully approve based on that investment and that potential return. We look to put that into our project charter and initiate our project.
The Requirements Management Plan
The Final Report
The configuration management plan
The Issue Log
The project management information system
What is a change request?
Baselined Documents in Project Management
Project Return Forecasting
The Business Case