In our last section of the vision scope, we talked about business risks. Now we're going to take a look at business assumptions and dependencies. Let's first talk about assumptions. So assumptions are things that we're making an assumption is true about the project. And we want to make sure that everybody knows it, and agrees with the statement. So it's something that we believe is true, but we want to make sure that everybody else agrees with us is true.

A dependency is a dependency for the project. So it's something else that has to happen in order for this project to happen is the easiest way to put that. So let's talk through some of these things and look at some examples. So we have assumption number one, which is utilize in house development team full time to complete the project within the desired date. range. So what we're saying here, as an assumption is that the stakeholder is saying that they're assuming that we won't need to hire a vendor to complete this work that our development team that we have in house will be able to build this new website.

So they're putting that in there because they want to make sure that they don't have to include in their budget, any outside resources in order to complete this project. Now, within the desired date range, I put this in red so that I remember to talk to you about it. This part of this assumption is not something that should be here. And if you've got this assumption, worded in this way in a document, you would want to go back to the stakeholder and talk to them about it. So why do you think within the desired date range is something that should not be in here? It's because we don't have a date range yet.

Now the stakeholder may have a date in mind. For when they want this project to be completed, and they want the changes to be launched in production, but the project is just starting, it isn't fair to put any time barriers around this yet, when we don't even actually have a complete and published vision and scope document yet, we have a draft that the stakeholder has submitted with what they believe should be in here and the vision and scope. But we can't set a timeline for the project until we know all of the facts about the project. And all of the project team members that are going to have tasks to do have the opportunity to think about what those tasks are, and come up with their estimates on how long they think it's going to take them to complete their tasks. So we don't want to put in any desired date range nor do we want to say as an assumption that the project is going to be completed within In the desired date range, because what the stakeholder desires may be completely unreasonable to what can actually be done once everybody looks at their pieces that they have to do for the project and the time that it's going to take them to do it.

So if you got this assumption written as it is, you would want to go back to the stakeholder and have that conversation with them and help them understand why the within the desired date range comment needs to be taken out of that. The next assumption we have is a review of current UX will be completed to determine how much can be repurposed. So what we're saying here is that the stakeholder has the expectation that our in house development team is going to look at our current design for the current websites and see what parts can they reuse from those various websites so that they don't necessarily have to redo the entire thing. There may be some things that they can use some of the assets some of the content tent, some of the code, things like that may be able to be used from the current sites so that we don't necessarily have to start everything from scratch.

So that assumption is in here because they want the project team to know that they have an expectation that the technical team is going to do that. And the technical team is going to see this vision and scope document. And they would be able to comment on that if they felt like that wasn't something that they have the intention to do, and explain why they weren't going to do it. Or of course, agree to it and say, yeah, that's what we were expecting to do as well. third assumption is access to a pm ba and QA resources. This one is probably in here, for the same reason that our first business risk is there.

So in our last video, when we were talking about business risks, we talked about the fact that that first one which is resource allocation and give him Many shared resources on this project was there because the stakeholder may have had issues in the past with people being spread very thin, right working on multiple projects, other projects taking priority over the one that they've had to be worked on. So they want that noted here as a business risk because they've had an issue with it in the past. That's the same thing for the assumption three that's listed here. They want to make sure that everybody is aware that the expectation is that we will have a project manager, we will have a business analyst, and we will have testers assigned to this project. So putting that assumption there helps to kind of put that out there to everybody that we expect to have these resources allocated to our project.

Now let's look at the dependency that we have listed here dependency one, which is the actually the only one that we have for dependencies is that the server upgrade project will be implemented prior to the site's project goals. Live. So this is an example where the organization may have another project that is in the works, that affects our project. So it would not make sense in this scenario to have our new website going live if it wasn't up and running on our new servers like the decision has been made, that it makes sense for these projects to go in this order service upgrade project first than the site's project. So the reason that we're putting this dependency in here and we're noting it here, is because if this server upgrade project were to get delayed for some reason, that means our projects going to get delayed.

So that's why it's important to note any dependencies also in your vision and scope document.