PROJECT MANAGEMENT How to Write a project scope statement

1. WHAT YOU WILL LEARN: Developing any project scope requests that you identify the requirements for the product, service, or even results of our project and all the work required to complete a project successful. Which is something you're going to learn how to do in this course. There are three parts to developing a project scope. All of which you're going to learn, okay, So these are the things you're going to learn as you continue with the lesson. So the three paths or the planning phase in which you put together a team and figure things out with glucagon, put together teams that you start working on, activities that are going to do the prediction, number to predict and production requirements where you collect all the necessary data and authorization for the project. And finally, writing a project scope, which is where you make your project scope or fissure, all of which are covered here. Now here's the thing, but the time you're done with this, okay, but the end of this course, you're going to be in a position to actually not only learn all that stuff, but write a project scope. So you are going to assume that we want to do undertake a porous structure and you're going to have direct the project scope for that construction. That is going to be part of our project, the course project. Because the whole idea here is learning by doing our muscles manner. That teacher right here on Skillshare. And I focus on things relating to business, finance and legal aspects. So as you're going through these, you happen to have a question. Don't just sit there, don't hesitate to ask, right? Because that is how we learn. So let's get started. 2. ASSEMBLING THE TEAM AND KICKING THINGS OFF: Predict cycle can be summed up as follows. Initiation, planning, execution, monitoring, and control, and finally, closing in project management. Once you've secured the agreement of the relevant stakeholders, which is something you normally do by giving them the project charter and having them committed to eat the planning phase stats. Usually this involves assembling a project team. You need to bring together the people are going to work with. And that process will mean getting into details. Getting the details regarding things like the work required to deliver the project objectives, the requirements and deliverables as promised in the project charter. The project manager in this case, you have to ensure that the team you've selected, the team you've put together has the required skills, the necessary skills needed to achieve the requirements. Because if you put people together because they're your friends or relatives and they can't actually get the project done, then. Well, there are a lot of things that are going to go wrong. The entire project team may not be engaged in the planning effort. However, the key or most critical team members must be engaged in the planning. Once you bring together the team, their normal at this point, you have the kickoff meeting, okay? Which is, which is a good way to start start with an official meeting that shows that things are now checking off. The purpose of this meeting is to bring the team together to review the project charter, to ensure that everyone understands why the project has been initiated. And to ensure everyone knows what the project intends to deliver. This actually becomes a good way of also engaging your stakeholders or the project sponsor. You, during the kickoff meeting. You also may want them to be there so that they can see that things are moving on in the right direction. So that is the first part. Okay. So you remember you had a project charter and these people have a grid tweet and now you're kicking off your project. 3. WHY WE START WITH SCOPE OF WORK: If you're going to have any decent predict plan, then you obviously need to start by clearly defining the scope of work to be to be undertaken. Projects scope defines the project in terms of what will be produced. These are the deliverables and all the work required in order to produce the project deliverable. So there is my, we start with the project scope is, okay, just think of the project, the triple constraint. Okay? The projects triple constraint are talking about the scope, the project cost, and the project's time. The scope of work becomes the basis for the budget we will require, as well as the schedule of activities. So you're not going to know how much the project is going to score, is going to cost. Us aren't going to know how long the project is going to take. If you have no clue what is going to be done in that project, instead of just goes that way, okay, So you have to figure out what is going to be done. Now, once you know what is going to be done, then you know how much it is going to be done, it's going to cost, and how much time, how long it's going to take. Because there is a correlation between the amount of time taken to achieve these activities. Are there to turn a tech and activities and how much it actually cost. When sometimes that relationship is direct, the more time you check, the more money you spend because of things like fixed costs, branch, salary for the people or things like insurance, all that stuff. Of course, there are things that vary, like raw materials, which will depend on the level of production, but that isn't the point of this video. So that is one of the reasons why actually that is a key reason why we start with the project scope. By starting with the scope of work, we can build the details of the project by establishing these forecasts one result early in the planning phase. This keeps the project, team and stakeholders focused on the objective and achieving the results of the project. So that will also ensure that the team keeps the discussion around the project scope. The scope must be defined in such a way that all project objectives and requirements can be met. It includes the work necessary to monitor the project as well as delivered the result of the project. The point is, we need to understand exactly what it is that we are going to deliver. Meaning what, Meaning? What is the product, service, or result that will be created? And what requirements must the product, the service, or the result, meat. That is the reason why we create the requirements documentation, the scope of work, as well as work breakdown structure. This point, remember, as you're going along, if you have any question, just ask. Okay. See you in the next video. 4. REGARDING COLLECTING REQUIREMENTS: It kind of is obvious that are not going to effectively understand the scope of work. If you don't understand what exactly it is that needs to be delivered in the project. Not just the final end deliverable, but also any incremental and ciliary deliverables as well. This will also include the sort of deliverables required to get the project done. So you're talking about things like elements of the project plan and that collect the project requirements. Input is going to be needed, okay? It's going to be required from all the stakeholders in the project. Your project is only, only going to be sustainable if all the people that are part of it are involved. Hello Somebody just going to say I wasn't part of that and therefore I don't like it and things of that nature. So to collect all the requirements, you need to collect information from all the relevant stakeholders. This includes the project team as well. The comments for the project and its resulting product or service can be collected by meeting one-on-one with each stakeholder. Or stakeholders can be brought together for a group session of documenting requirements. And that is not just about requirements because it also, I mean, if you take something like bring them together, the stakeholders as a group, successfully do that. It means that any conflicting issues, any conflict that might, these stakeholders may actually have these. We'll give them a good opportunity to resolve such conflicts because if the sponsor doesn't really agree with one of the sponsors doesn't agree with the other, then this becomes a chance for them to hash out. The conflict that the project can successfully. The coef requirements collected must support the objective of the project. For example, if the project purpose is to plan and implement an India party which also aims to generate future sales for a business, then a requirement to invent non potential clients would contradict the project purpose and objective. Also, the project one is you have to be cautious because sometimes when you call people for this meeting, they start generating requirements that are not even going to be related to the project. So you want to keep things realistic. If you realize that somebody's tearing away from the intended goal, then it's your job. That's the reason why you're a manager. You're not just a project manager. You are a manager. So the managerial skills kickin, you have to bring them back to whatever is relevant to this project. Remember, requirements define what is needed in order to meet the project objectives. They do not know the requirements. They do not define how their work is going to be done. So always remember that they tell us what is needed, not how those whatever is needed is going to be achieved or is going to be done, your comments will generally fall in the following categories. Product, technical or functional requirements. Project process or management requirements, quality or performance requirements, business or organizational requirements, support or operational requirements, profitability, or sales and marketing requirements. Those are some of the things that are going to be, to be figuring out, okay? Yeah, it's sort of need to know these things before you just jump in and start typing the scope. What exactly you're typing, you don't even know what is, what is needed. So that's new collecting data regarding the requirements. 5. HOW TO PRIORITIZE REQUIREMENTS: So before we look at examples of requirements, I just want you to remember that after collecting requirements, okay, because it's not going to be one thing. You are going to have to prioritize these requirements because it kinda makes sense that if you have a lot of things that are supposed to be achieved, you sort of need to know which one is supposed to be achieved fast. Which one takes priority over which one in case the clash. So that is the reason why you need to understand how to prioritize requirements. A technique to prioritize requirement is called the Moscow method or the Moscow analysis, which means that each requirement is going to be prioritized in terms of must-have, should have, could have, or want of must-have requirements are critical and must be included in the project in order to meet the objectives. Should have requirements are important and should be included in the project if the time and budget allows. Otherwise, they can be delivered letter or perhaps in the next release of the product. If, if, if you're dealing, you're dealing with a project, if you're dealing with a product, that is basically if the project is supposed to, to result in the development of a given product, could have requirements are nice to have if they can be included, but the project can still be delivered and conceal meet project objectives without these requirements, included, won't have requirements and agreed to by stakeholders from the outset that they will not be included in the product or in the project delivery at this time, but can be revisited in future. Again, there isn't no you prioritize this requirement is that this will allow you, the project manager and the project team understand what exactly is supposed to take precedents or what exactly supposed to take priority over, Overwatch. Okay? So that is, that is why this is important. The privatization is important, not just something you do because it's something you supposed to do as you're managing projects, we just put a tick. It is important by prioritizing requirements. We these parity levels. This allows the project manager some flexibility when building the project budget and schedule. For example, if all the requirements are to be included in the scope of work and the budget is not sufficient to deliver them all, then the project manager can remove some of the could have or should have requirements from the scope without jeopardizing the project purpose and objectives. Of course, it just don't remove these things because you aren't going to remove something. Or when you've removed something, you will let the stakeholders know that something has been checked out. Because somebody might be very powerful that in as much as those things were could have. I'm really hoping to have them when they've been taken out of the project. You let them know at all times the project manager must ensure that the requirements traceability matrix is kept current to indicate which requirements are included in the scope and which are not. So that is the reason why you need to have the traceability matrix door. That is something that you're going to look at in these, as we continue as well. Support that beat. If there is any question as always, let me know. And that is how you approached it. That is how you prioritize the requirements. Okay. So see you in the next video. 6. HOW TO DOCUMENT REQUIREMENTS (Requirements Traceability Matrix): Here's what we know so far. All project requirements are collected and documented, reviewed, and approved by stakeholders. The requirements become the basis upon which the work activities okay. First of all, the scope of work, those requirements become the basis upon which the scope of work is defined and activities to be undertaken sort of created. This is where requirement disability matrix comes in. There is a multi matrix is a grid that links the product requirements from their origin to the deliverable that satisfies them. Recommend traceability matrix provides a means to document each requirement, as well as which objective and deliverable it is associated with. It also provides the means to document the agreed to priority for each requirement. So we're talking about a simple table that will show how a requirement can be dressed from the source all the way to the execution phase of the project. So if we are making something, we are making, the project is about making a simple gadget. Then why is it circular? So something like that can be traced from wherever suggested that all the way to the final result. So that is what the traceability matrix does. Here's an example of such. In this case we have a separate networks and the party that is the whole idea, these requirements traceability matrix. And let's say I'm the Project One is the right, is what we have. We have the traceability matrix has categories, which the functional categories, the number of recombinants we have, and then the priorities and objectives. What are the objectives regarding the requirements? The deliverable test, and whether it was the delivered, whether it is accepted. So like in this case, we have the first category, F1, okay, So you've written them as F1 all the way to the numbering system kind of just varies. These are functional categories which have to do with the activities that you're creating. And then we have project categories which are basically related to the project itself. Okay? So let's see, for example, the faster the party must be able, the party, the party space must be able to accommodate 200 guests. We've tables and chairs for eating. And then the space. What about the space? The space for all the 200 degress should be 250 square feet area and all that. So this is something that we must have. Why? Because the objective here is to have our guest remain seated for at least two hours. And now we know that this one has been achieved. Well, it will depend on the setup and how do we check. So we'll check the size, the number of tables, as well as the number of chairs. And was this something that was approved by the sponsor? Yes, it was. And so that's something that must be held. What about something that we should have? Something like the participants requires a list of confirmed guests, names that will be attending, at least in this case, seven days in advance. So it is something that we should have. Of course, the objective is the same to have the guests suited for two hours and all that. How do you know that this one as well? It's simple. We will look at the guests. And what exactly do we look at from the guest? Those who have RSVP as per the required debt. So look, these are things that those are things that, that is an example of, that is an example of a traceability matrix. One more thing, if you look at this from the project point of view, Let's say something that okay, so must have, must have been predicts. An example, your project stakeholders requirements will be documented, tract, delivered, specified. Notice that is something that we must have objective. We need to have at least two interfaith guests, comments and all that. So, um, yeah, that is an example of the predictors ability matrix. And do your budget. I mean, I don't want to go through the entire thing because I've linked it in the resource aspect of these, of these lessons so you can download it, go through each, check if there is something that is not clear, ask I mean, it just don't want to waste your time by reading each box and all that. That is an example of a project's traceability matrix. You need to have that because, I mean, not project requirements, sorry, because you can trace the requirements from the origin. You can just check, was this on achieved? Was this an achieved was not dishonest, not why? Because it failed at this point. That is what that does. So project management can be as simple and it can be as complex, but the basics are still the same. If there is any question as always, let me know. See you in the next video. 7. WHAT IS A PROJECT SCOPE: If a project is a ventrally a grid, the contractor or the project manager will have to ensure that the customer's specification is satisfied. In every respect. The project manager's commitment will not be confined to the technical details, but must also encompass the fulfillment of all specified commercial condition. That is where the project scope statement comes in. Of course, the question is, what is a project scope statement? Now, these are key document to define the scope of the project. The project scope statement is similar to the project data in that it defines the objectives and deliverable for the project. However, the scope statement is prepared during the planning phase and as such, will be more detailed than the project charter. Let's say you have no clue or a project charter is actually it's, it's, it's something that once you're done with this course, you can just check. It's also one of the causes that reading is or the predicts chatter compares with the project scope. So the predict shadow will show the following. The project Papas, measurable project objectives and related success criteria, High-level requirements, high level production description, boundaries and key deliverable overhead project risk, summary, milestones schedule, pre-approved financial resources. Key stakeholders list in our predict approval requirements. Project exit criteria, assignment, assigned project manager and the responsibility and the authority level, name and authority of the sponsor, or even other persons authorizing the project charter? Yeah. It looks like if it has many things, but those things are not as detailed as what you'll find in the project scope statement. The project scope statement will show the following, but in a detailed manner. So it will have project's scope description that is well elaborated. Project deliverable, the acceptance criteria, and project exclusion. So what I'm trying to say here is that you see, you develop a project charter with one thing in mind to show the relevant stakeholder or stakeholders what the project is going to be like, Okay? So that they can accept the project, so that they can approve the project. Once the project has been approved. This chapter is kind of just designed to secure their commitment. Once that has been secured. Now you stop there, we'll walk, you tell them what is going to be done there you come up with a project scope, which is now a more detailed version of what is actually going to be done in that project. So project charter intends to secure the agreement of the project stakeholders. The project's scope is supposed to show them what exactly is going to be done or is going to happen in that project. 8. PROJECT SCOPE DESCRIPTION: In this section of the project, you are going to give a narrative description of the project. And the expected results, of course, are going to be more. We're going to give more details because these different from what you wrote in the project charter in the sense that in the project charter you just reacting that with an aim of securing the agreement of this relevant stakeholders. Now that you have the agreement and commitment, it's time for you to give more details. The project objectives are also indicated which bidder must be clear and measurable. Okay, let's, let's look at that in practice. Alright, so you have your project description in this case. First of all, the project project is the desert networks and the Apache. And yep, So what exactly is this predictable about? That is shown in the project description. But the purpose of this project is to plan, is to plan, implement, and evaluate their IP network or the end of your party for 200 friends, business, or even colleagues and neighbors in this case. Why are we doing that? Because you want to thank them for their support and business and friendship over the years. Now, how does that help us from a business point of view? Well, we're thanking them, as well as to generate new sales opportunities. So this is important for our business. Now the project must meet the following objectives. One, to ensure our guests feel valued and enjoy their food and entertainment. Which will result to the wrist, which will result into the guests remaining seated for at least look at supposed to be at least two hours or more. Sorry. Now, the guest, number two, guest Mac, at least 25 positive comments. Okay, good the host, that is something that will help us to figure out if they enjoyed being there or not. And you also intend to generate at least a minimum okay. To generate a minimum of five prospective or the prospect sales order, which include specific follow-up appointments. So that is actually an example of a project description. Notice it tells us what the project is about and it tells us why exactly we are undertaking that project. It's not just for a social reason because in this case it's actually a business project. The India parties, not just a party, we are doing that because you also want to get some cells, some cells deals from it. Alright? So that is an example of project description. If you're writing yours, now you can start doing something like that. Okay? What is your project description? What project you want to undertake and put down the description. 9. ACCEPTANCE CRITERIA: This now is the pathway you write measurable criteria that key stakeholders used to give approval for the deliverables and objectives of the project. And that is going to look something like this. Alright, so in this case, our acceptance criteria would be heavier. But the word all planned activities received on time. And we denote that delivery of material or food, provide food. Table chairs for maximum of 200 invited guests. Um, something like the budget, the budget for the party does not exceed $10 thousand or even ensure that less than ten per cent of invitees, not sure. So you want to make sure that there are no accidents or illness costs to the people who've attended. Ensure the party proceeds regardless of weather conditions, which means you're going to have to take that into account that the weather can go wrong. Basically, these are the criterias that the stakeholders used to approve the, the undertaking of the project and that become part of your butt of the acceptance criteria, Which means what, which means as you're going through the project. So that as you're writing the project, you project you, you've chosen to undertake, if you can, let me know that. Talk about that. The people are going to finance this project. If it's going to be financed by other people or the people can be affected or affect this prediction directly. What were their, their, their demands for that project to proceed or not to proceed. That is something that you write in these, in this part of your project scope. Okay. See you in the next video. 10. PROJECT DELIVERABLES: Okay, So now you talk about the outputs of the project, which is what deliverables are. Deliverable can be those created during the planning execution or even the closing phase of the project. In case of a party, our end-of-year party. Here's an example of those. So we have our project deliverables in this case. Now, look, the project plan is documented and approved by the participants. And then we have the debt given. And the plan is supposed to include all these components we can about the organizational chart, the scope statement, breakdown structure, the budget, the schedule, risk plan, all this stuff are part of that particular deliverable. We also have another deliverable repair guest list by 15th. And that will include these going to be part of things that you're going to download in the resource so you don't have to read all that, but just follow along. Okay. Next, the supplier contracts negotiated, this should have been negotiated by should be negotiated by fast to me. And what are the things that you're going to be looking at as you negotiate tech. An example of this, a document of complete list of all suppliers that will be required for the party and confirm with the participants or all that stuff. We have supplier contracts are awarded or at least approved before they're already that are approved by that debt. Supplier. Deposits of page invitations are mailed. All these are going to be part of the things that amount to deliverables. And that is something that you need to make sure that is there as part of your project. Now, you will notice that there are a lot of deliverables because if you're going to undertake the project, pay 10 thousand for the project, then the question is, where we'd bring the project because you want something, okay? Remember that triple constraint, that is the project scope, which is exactly that's project's going to do. There is a term, there is the budget. Sometimes the scope can also be called the quality, okay? So the thing we intend to achieve that is important and that is what deliverables are. Therefore, you really have to be serious about this bit of your project scope. Just contract for things and then say, yep, I'm done, move on. No. This is what the project is all about. So ensure that you've given it your all and you've you've written, you've routed properly, basically. Again, if you're struggling with anything at this point, the lamina. And remember, again, you can download the PDF version of this in the resource bit of these costs. And then you can use it as we, as we go along. 11. PROJECT EXCLUSIONS: This bit is very important in your project because the client could just want anything, glands, plants want many things in that project. But then it's important for you to let them know that there are things which will not be in this particular project, even if they are normally there in other projects. And that is important, basically the project exclusion, that is what we need to talk about, which, which could include features, functions, service, or deliverables. You let them know that those features, those functions, those services, are not going to be part of this project. So you let them know that in the project scope. Um, here's how you do that. Alright, so in this case, we let them know that no additional insurance needed. Now, additional insurance need to be procured in order to hold this party. That is something they need to know. A photographer will not be included in the scope. So if you're under photographer, get your own or pay extra for one. No floral arrangement will be included in our party. Party. We don't really want to worry about the floor arrangement. And that is those three things are things that they should not expecting this party. So it depends. It could be a website because somebody has you to build them, a website or somebody has you to build them are softer and then they start saying, my friend has this website and it has this thing. Will that also be here and then tell them no, that will cost you extra. Or there's this software which does a, B, C, D, will mine also do that. It's like that is the reason why you have the exclusion bit so that they know that these are not going to be yes, they are normally there in similar projects, but they're not going to be there in diesel. And the reasons are 123. Right? So that's the thing. 12. CHANGE MANAGEMENT PLAN AND CONTROL BOARD: What if a stakeholder has something that they want changed in the project? What if as a project manager, you want something changed? How you manage changing the project is the main thing that you're going to be talking about in this patch and short change management plan is something you want to show in your project scope statement. Things that can change the project will include the project scope, deliverables, requirements, budget, or even the schedule, despite the consequences of changes. Okay. Despite the results of the changes, all changes must be documented, tracked, reviewed, and status. Also, don't forget to show the person who's making the change. Why? Because we need to assign responsibility. So the person who initiated the change or the parcel know basically the person orchestrated the change or the person who approved the change, we must show that person. Now how do we do that? Well, here's how we do that in the project scope, this patch, you're talking about how change you'd be managed. So these are going to write or something along these lines. Okay, so in this case, we have we have the change management plan and control board. Regarding the change management plan, talking about change control process, scope will be managed, monitored, controlled by means of work breakdown structure. Alright, created by, created for this project. And that is just going to go into carbo to work breakdown structure. You're talking about hierarchical structure, which shows a task and all the activities involved in that task. If there is any change that is going to be reflected in the WBS, any changes required externally initiated by a client or internally shift where they predict team will require a change order to be completed. Let me show how the change order is. In this case, we're talking about this one. So this is the change order form. So if there is any change that is to be made here, it will be reflected here. So we have the project name and then there is the debt. And we have the project manager know who's requesting for that change. Then we have the details description of the proposed change. Why the reason for that change? How will that change impact on the project? And now that they've written that, well, then you also show to be completed by the change control board. These are the people these were it will show whether the change has been approved or not. So we have these analysis required and all that stuff. We have the change thetas as it had been approved, as it had been rejected, as it had been deferred. See, all this stuff. Alright. All these is just part of the part of the change order which is required to be to be completed. Now the change board itself. Okay. These are the pupil are going to be to be in charge of the change and what these people. So you show, in this case we have the project manager, the sponsor. Because remember, our US is a party and external stakeholders such as supply, because sometimes the change you're trying to initiate, you don't want one supplier or something blue the supplier they supplied certain type of food you do answer that. You want that change to your like nano we're honored percent vigor. So something like that. And then you want that to be changed. So how will that affect the project's scope or elite afraid the project time? How will it affect the project cost? So that's why the external supplier has to also be involved if that change relates to them, okay? So that is how you manage change in the project. 13. HERE IS YOUR ASSIGNMENT: Okay, so now at this stage, I just want you to remember that the idea here is learning by doing. And so as you go through that onto to assume that you are about to build a house or your project. The project in this case, honored to assume that you're a project manager and the project is building a house. Don't worry. If you don't know anything about construction that is not important. The important thing is you make up the details. I want you to write a project scope statement for that. Okay? It's part of it's part of your project. So don't worry about being wronged or a boat, you know, all that. If you are stuck at any point, do let me know. So write that. 14. NOW THAT YOU ARE DONE: Now that you're done with the course, I mean, it's not really that long of a cost rate. Just want to point out that if as you're going through this, you find it helpful, don't hesitate to give it a positive review because those are important for a number of reasons. One, it helps other people to also be in a position to access this course because it's, it's, it's recommended to them. And also tells me to know if this course was helpful to you. And of course, if there is any question has evolved as pointed out throughout the entire video, you ask and also, and to recommend another course which I did on outright our project charter and manage stakeholders. So that is something that you can also check in after you're done with this or know that you're done with this one. Because a project charter comes first and then the project scope statement. So you can check the tone that OneNote as well. So I'll see you in the next course.