This course is about the vision and scope document. So let's talk a little bit first about what the vision scope document is, and why it's important to us before we get into looking at the actual template and going through the different areas that are in the document. So there are two standards really right now that are used for projects, and that is waterfall, and agile as far as the sdlc goes. And a lot of companies these days are using mostly agile, but there's many projects that are still done in a waterfall way as well. And the vision scope document really works for both of those projects because the vision and scope document doesn't have anything to do with how the requirements are documented or how the work gets done for the project. The vision and scope document is all about the variables Getting of the project and defining what the actual project is about.

So in the vision and scope, we're really trying to get to what's the reason behind the project? And what are the things that the business team is looking for as part of the project? So in other words, what are the features that they're looking for from this project? So let's talk a little bit about who fills out the vision and scope document. I'm about to tell you something that may make you crazy, or it might make you happy. There's no definitive answer to who fills out the document.

I'll explain the crazy versus happy in a minute. But first, let's continue the whose responsibility is it discussion? So it's based on a couple of different things. One thing, what's the standard at your organization? So as a contractor, I worked at many different companies and I always asked about their standard procedures to make sure I was following them. Some companies have the BA do it.

Some have the sponsor stakeholder, do it Some even had the pm do it. And sometimes it was a combination of those people. So I'll explain what I mean by that. As an example, I worked at a company that wanted the business owners to take more responsibility in defining what they wanted from the business perspective. When I started there, they didn't have the concept of vision and scope document. So when I heard they wanted to do this, but didn't know how I suggested the vision and scope and shared a template with them that I used at a previous organization, they liked it and wanted to move forward with it with the understanding that the business owners would submit the vision and scope document with any project requests that they made.

So this is what they thought would help them with getting those business owners to take more responsibility in defining what they wanted. The IT department was really excited about introducing that document and they felt that it would really help them have a better understanding of what the business owners wanted and It was helpful when they actually submitted the document. And when they filled it out correctly, we'll get to the part about filling it out correctly. In the next chapters. When we go over what goes in the document for now we'll stick to the part about when they actually submitted it. We had times where the sponsors and stakeholders basically ignored the request or just didn't submit it.

And each time we asked, they said, Oh, I haven't had time to do that yet. And the project would get held up and eventually management would just cave and say, No, let's just move forward without it. We can't hold up the project just because we didn't get a document. Now, what do you think happened in those situations, when we didn't get a vision and scope document, we were basically walking into our first requirements session, completely blind. We had no idea where we were starting, and we had nothing to tell us what the boundaries were. So they could basically ask for anything and we had no idea if it was supposed To be part of the project, because we had nothing to tell us what the project was.

So needless to say, that did not work well. So when we had a business area that didn't submit a scope document, we started and by we I mean, we as in the BA team, we started setting up scope definition meetings as our first project meeting. And we would go through the sections of the scope document and ask the business team questions, and we would basically complete it for them. So in that scenario, it was supposed to be the responsibility of the business team. But we as the VA team stepped in and did it when they wouldn't or couldn't. So why do you think we did that instead of just moving forward without it?

It's because it made our analysis tasks way easier, and it helped the team and the projects succeed. If we just said, well, the business team was supposed to give us a scope document and they didn't so if we miss Something it's their fault. That just wouldn't be a good idea, right? It's not a good stand to take. The entire project team gets blamed when a project fails. So pointing fingers isn't going to help.

And it tears down relationships with people that you're going to have to work with, again on another project. I guarantee you, Murphy's Law. If you end up in a situation where you have a bad relationship with somebody, you're going to end up working with that person. Again, if not on the next project, a couple projects down, it's just not worth it. It's better to just take the lead and help the team be successful and help the project be successful. So I want to go back for just a minute and talk about that thing I said earlier about it can make you crazy or make you happy.

When I said there's no definitive answer for who fills it out. The reason I said it could make you happier crazy is because this applies across almost everything we do as business analysts. They is really no one way to do any task that we as we always have to do. There's so many different ways to do it. And so much of it is related to what type of project are you working on? What size of project are you working on?

What's the complexity of the project? What's the team like that you're working with? How do people like to give information? How do people like to get information? There's so many different ways to do it, that if you're somebody that just wants to have a set of tasks, and it's the same tasks, and that's how you'd like to work. There's nothing wrong with that.

But in the role of a BA, your job may make you crazy, because it's not always like that. If you're somebody that likes to do things, differently, likes to try different things likes to have a variety of ways of doing things. Then you're gonna like the fact that there's no set way because you can do different things based on What you feel like is going to work well for that project. That's really what I'm talking about when I say it might make you happy, or it might make you crazy because just about everything you do as a VA can be done in multiple ways. In our next chapters, we're going to be getting into what goes into the vision and scope document. And I just wanted to point out as an FYI, that the vision and scope template that we're going to be covering in the course, can be downloaded from the resource area for the course.

So you'll have a copy of this template.