All right now we have covered all of our sections that were related to the scope and the features. So now we're going to get into our third section of the vision scope document, which is business context, and that is three dot one, project priorities. So for the project priorities, we're looking at what are the things that are important to the stakeholder related to this project. So things important to the stakeholder are related to features, quality, and schedule that is a set set of dimensions, if you will, that are included in the document, others can be added. But those are three things that are generally important to the stakeholder and that we are including in this template as three Areas doesn't mean again that you can't add more to it because you absolutely can. But that's what we're starting with here was so for the features, we're going to talk about, what are the constraints related to that.

So all features in the release must be fully functional. So we're saying anything that's included in any release, whether that's release one, release two, whatever release it is, the expectation is that all the features are fully functional that we are not going to release something that has major defects. We expect that if we put a feature out into production, that that feature is functioning correctly. Then we also want to note, what are the rules around change management related to features? So what we're saying here is that any feature changes must be approved by the sponsor, and updated in the Brd note that we did not say that feature changes would be updated. In this document, the expectation is that once we've completed all of our reviews of the vision and scope of the changes and updates have been completed, and everybody has signed off that needs to give approval to the vision and scope document, that we won't be changing that going forward.

What will change is the business requirements document, which is where we're actually documenting the requirements that are related to the features that are in this document. So we're saying from a change management perspective, the expectation is that the changes are made in the Brd then we have quality as a dimension, we're talking about the quality for the site. So we're expecting that the site is up 99.9% of time. What that tells us is that the stakeholder is expecting the site to be up and available almost 100% of the time. If we find that during testing, that there needs to be a change made to that, because they've realized that during testing that when an update is made to the site, that it actually causes a higher amount of downtime. So when there's a monthly release of updates, we'll be down what amounts to 2% of the time.

So that means our uptime is only 98%. So is that acceptable? Is there something that has to be changed, and technically how we're implementing this site so that we don't have that much downtime, right conversations will have to be had, but if any changes are required to the scope based on those results of testing, it would require prior approval by the sponsor, and then updates again to the Brd then we have scheduled the North America launch will be the first week Release and all other regions that must be launched within 12 months of the NA launch. So again, we don't know the timing yet of the NA launch, but we're saying what we said initially in the vision for the document that all of the regions should be up and running by 12 months after the launch of the North America website. Any changes to the schedule, once the initial launch date has been published, must be approved by the project sponsor.

So meaning, once we've determined that, say North America is going to go in September, if we find that we can't complete everything by the following September, then that change in the schedule has to be approved by the project sponsor. So that is an example for you of project priorities, the dimensions, the constraints and the change management process for each of those. Now, let's take a look at next section, which is deployment considerations, these are things that the stakeholder feels need to be thought about when we're looking at launching these changes into production. So the first thing is URL mapping strategy must be fully tested in advance. So that goes back to the feature that we had about wanting to make sure that we redirect our old domains to the new domain. So because we have three sites that we're basically combining into one site, we want to make sure that those old sites are being redirected.

So we want to make sure we have a strategy in place to do that and that it's been tested. Prior to deployment, we'll need to be vigilant around SEO, which is search engine optimization and search results, especially immediately following the new launch. So this is saying that we weren't To make sure that we're keeping that in mind, and that we've got somebody that's really looking at that after we have the launch marketing resources, we'll need site administration training, and some time with the developers to understand where, how to make desired edits, based on the way in which they will have tailored the back end. So this is saying, hey, since the marketing team is going to take on the task of making the updates to the content on the site, they need to actually understand how to do that. And they're going to need to know that before we launch, because the day we launch even, they may need to make updates.

So they're going to need to understand how to do that. Before we actually launch we'll need a plan for subsequent regional deployments beyond North America to be managed by each of those regions. So what we're saying here, the stakeholder the sponsor is saying that we know that we're going to do the same process for the other regions, but we're going needs somebody at each of those regions to manage this project from there. And so those are things that are noted as deployment considerations. They're not requirements. They are not exclusions or limitations.

They're things that have to be kept in mind and things that need to be kind of checked off as, you know, to do items that have been completed things that have been thought about so that those things don't become problems at the time that we launch. So that takes care of project priorities and deployment considerations.