In our last video, we talked about what the vision and scope document is, whose responsibility it is to fill it out and some general information about the document. In this video, we're going to look at the cover page, the table of contents, and the revision history. So, for the cover page, there's a few pieces of information that you will fill out that is specific to the project, for example, the project name, you're also going to want to fill out whether or not this is an approved version or a draft. So you see here the information that we have that's in blue. That's the information that we would expect that you would update based on the project you're working on. So your project name, approved or draft at this point when you're just starting it.

It's always a draft, your version number and we're going to Talk about that in a minute, who is prepared by if you're creating the vision and scope document, then it would be your name here. If it's being done by a stakeholder, a sponsor a PM, somebody other than you, their name would go here, and then the company name, and then the date that the vision and scope document is being created. The reason I said we'd go back and talk here about the version number is because I wanted to tell you a little bit about how I like to do the versioning. And there's no set rule here on this. But when I'm starting a vision scope document or any version of a document, and it's still in draft form, so I haven't shown it to anybody yet. There haven't been any reviews of it yet.

Then I start out with a dot one version. So here you would change this to zero dot one. And then as you continue to make updates to it, you would change it to zero dot two, zero dot three So on and so forth until you're done with your updates and you're ready to do a review of it for the first time, when you're ready to do a review of it for the first time, you will change that version number to one dot O. And then based on what comes out of that review, you will change the version number to one dot one, one dot two, so on and so forth. If you get to the point where you truly have, say 10 revisions of it, then at that point, you would change it to two Dotto. That's generally the rule that I follow.

There's no hard and fast rule on that. That's just how I do it. So you're welcome to do your number versioning in a different way. If your company does it in another way, or if you're used to doing it in a different way, but I wanted to give you an example of how I do it if you're needing a way to define how you do your version numbers. So that covered Our overview our kind of cover page. So now let's talk about the table of contents.

So the Table of Contents is going to be broken down by the different sections that we have in our vision and scope template. The reason I want us to talk about it is because you want to make sure that you are updating that table contents. As you're completing the document, the page numbers are going to change, you might actually add or remove a section, if maybe there's a section in this template that doesn't apply to your company or they don't want that section in there, there could be things that you change, and you want to make sure that you're updating that table of contents. So in Word, you can select the f9 function. And when you select that function, it's going to come up with two options for you. And that would be update page numbers only.

Or update entire table. I'll tell you, I rarely use the update page numbers only. Even if I'm pretty sure that All I've done is added enough information that something moved down on a page that I didn't actually change any sections or anything, I still will usually choose the update entire table because to me, it's better to be safe than sorry, and just update the whole thing. So for me, I usually choose that option rather than just choosing update the page numbers. Let's talk now about the revision history. Really what the importance is of the revision history when it comes to the vision and scope document or really any document that you're making updates to.

So with the revision history, you see that we have the name, the date, the reason for changes and the version that those changes took place in. Let me tell you a little bit about why I feel like this is so important or even critical. Why do you think I would say that it's critical. I'm going to explain that to you. Think about that for a second and see what comes to mind to you about why the revision history would be critical. And then listen to this example that I'm going to give you and see if what you were thinking was along the same lines, or if you actually had a different opinion about why it's critical.

So if you were working on a project, and let's assume that it's a large, rather complex project, the vision and scope draft has been completed, and you're reviewing it with the project team. During the review, one of the stakeholders stops you when you're talking about a feature and says, oh, we're not going to need that feature, because we just signed a contract with a new vendor, and they do that differently. So this isn't going to apply by the time we move these changes to production. So you need to take that one out. You ask if anyone else has any concerns with removing that feature? And nobody says anything, which is pretty typical sometimes in meetings, and you say, Okay, it looks like we're all in agreement.

Meant to remove this one. And because you're sharing the document on the WebEx, you go ahead and remove that feature so that everyone sees that you've deleted it, and then you move on in your review. So a few weeks go by, and you've got some requirements done. And now you're ready to review those requirements that have been written to support those features that were included in the vision and scope document. So during that review of the requirements, one of the stakeholders says, Hey, I think we've missed some requirements. I don't see anything here for the ABC functionality.

Why is that? And you as the VA refer back to the features list and say, well, we don't have a feature for that, right? Because you always should be tracing your requirements back to those features that were requested. And as a matter of fact, now I remember that we removed that feature during the scope review. So you say that to the stakeholder and the stakeholder says I wasn't in that review why If we remove it, you can't remember why it was removed, just that it was. So the Revision History will tell you what was removed, because sometimes you won't even remember that.

And why, along with the version that it was changed in. So this brings me to the importance of saving all versions of the document. So what I do for this is I create an archives folder for each project that I'm working on. And every time I make changes to a document, you know, once it's been published for the first time, I save it as a new version and move the previous version to the archives folder. So this is going to save you some time and energy and frustration. If you don't remember why something was changed or what was changed, then it's possible that you might get asked to go back and change it again because you don't have anything to back you up on why you took it out in the first place.

So you'll be asked to go back and change it and then someone may speak up again later. And you may have to change it back again, it can be really frustrating. And it also kind of gives the impression that you don't have it together. So not only is it really important to have a revision history, and keep track of the changes that you made, and the reason for the changes, but also to keep those previous versions of the documents so that you're able to refer back to them and see exactly what was there prior to the change. And then you have the more recent version, of course, that has what it was changed to. Those are some really important reasons for the revision history.

And I don't know what you were thinking maybe when I said that it was critical, but just take your thought and compare it to what I said. And you may have other reasons or you may have thought initially, hey, that's not critical at all. I don't understand why she's saying that's critical. And now you've got kind of that background on why I feel like it's critical.