In the next section of our document, we're going to take a look at business risks. In our last video, we talked about the vision statement, and how that ties into the rest of the information that has been included in the document. The business risks are more about issues, problems, things that we think may arise during working on the project during the launch of the project just after the launch of the project, things that we think could be potential issues. And that is so that we can talk through those things as a project team and determine how to address those risks. So we want to first document what we believe those risks are, so that at a later time, we can have a conversation about those and determine how we can address those risks to mitigate them, possibly keep them from happening at all, or if they do happen, what we can do To resolve the problem, so let's go ahead and take a look at some business risks that we have identified for this project in our vision and scope example.

So we have three business risks here. Risk one is resource allocation, given many shared resources on this project. So what we're talking about here with this risk is one that probably applies to a lot of projects and a lot of different organizations. And that is that everybody's really busy. Nobody these days is usually assigned to just one project. You have the technical team, the testing team, the BA is the project manager.

All of the developers everybody that's working on the project isn't just working on this project, most likely they have multiple other things that they're working on and their time is going to be split between those things. So a lot of times we feel the need to call this out as a business risk. Especially If we've had issues in the past where our projects have been delayed, because the resources are working on another project that is deemed a higher priority, so if that's happened frequently in your organization, then most likely your stakeholder is going to want that documented as a business risk, because they've had problems with that in the past and they want it notated, that they feel like there's a risk of that happening with this project. Risk number two is possible customer confusion when we go live with the new site for North America, but other regions are still using the old sites.

So what we're saying here is that if we have customers that may be look at not just the North America site, but they also look at and do purchases from our other regions. They would on day one of the launch say go look at the North America site and And see that there's now only one website. So if they want to order widget one, or widget three, or widget 10, it's all from the same website. But then maybe they go to the site for our European region. And they see that one hasn't been consolidated yet. So if they want to buy widget one there, they go to one site.

But if they want to buy widget 10, they still have to go to this other site. And that could be some confusion for them about, Hey, wait a minute, when I go here, it looks completely different from when I go here. And over here, I still have to make my purchases from a bunch of different sites. So they're recognizing that the fact that we're going to do this phased rollout approach where first North America gets the updates and the other regions get it later, could cause some potential confusion to our customers. So I talked about mitigating risks and talking through them and kind of figuring out how to address them a way to address that risk. Could be to do some announcements prior to the north america launch, that actually goes out to everybody in all of our different regions, so all of our customers and letting them know that we're developing a new site format, and that it's being rolled out to North America first, but that it is going to be rolled out to the other regions to kind of set everybody up for if you go to our north america site, you're going to see something that looks different from the other sites for the other regions that you may also be using.

So that would be one way to mitigate that risk. Our next risk is temporary increase in customer calls to our call center due to rolling out the new site by region rather than all at once. So what we're actually saying here is that risk to may create risk three, so that confusion could cause cause to our call center, which would be more calls than what they're used to having. So if maybe they take an average of 500 calls per day, it's possible that that might increase to 525 or 550 a day, but because they have the same number of staff, they have to be able to handle all of those calls, or they have to make the decision that one of the ways to mitigate that risk might be to hire some temporary help in the call center throughout that launch, or repurpose some people that are in different areas that could help and assist with those calls for a certain period of time until they die down somewhat.

However, if we are successful at mitigating risk to then that would also help in mitigating risk, right. So if we came up with that communication plan to communicate the changes to all of our customers across our regions, then that may help to say okay, because we've done this, we feel like we're actually not going to have that much of an increase in calls. So we may not need an additional staff or bringing on people out of other areas that we pull into there because we feel like it's going to be much less calls and we'll be able to absorb those. So by mitigating two, we may also be able to mitigate three. But that's really what business risks is about. You want to identify what they are so that everybody understands them, and so that you can come up with a plan to try to mitigate those risks.