Creating the Project Scope

6. Making a prototype

Another way to collect requirements is to make a prototype. A prototype is a model of a solution. Now one prototype, probably the most common, is where you have a throwaway prototype, just like where you sketched out the solution, where you might have a mockup. So for example, like in this picture, there's a model of the building that these guys are going to create. Well, that's obviously not the building. So it's a mock up of what the end result is going to look like. So it really doesn't have any value other than communicating what the idea of the solution is. Another prototype that we have is a functional prototype. So there's some functionality so that the prototype might become part of the project deliverables. And a great example of this is web design. If you've ever hired a web designer, they may mockup a sample website for you and then you can edit it or tell them different colours or whatever. But with the work that they've done to mock it up, they can go ahead and use that as part of the end of the solution. So that's a functional prototype. Some prototypes when we do storyboarding, so that's hard to say. A storyboard is a way to show the flow or to create a story of how you go from the start to the finish. It just tells the story of your solution. And then you have different players on the stage, and the players are really just different components, like the servers or the end userinterface or the different graphics that you use. So order in, order out, or a workflow are examples of storyboarding. And then you might use a context diagram. A context diagram is where you take your project scope and you create a model of the solution, and this actually shows all the different components and how they work together. So if we had a business system, we would have servers. You'd have your individual workstations, you might have a database and printers, you might show the workflow, like email or how someone saves a project to a file server or what have you. And then the individual people are called the actors. And usually, actors are played by their roles and their associated responsibilities. And that's a context diagram, and that's also a prototype.

7. Using a requirements traceability matrix

Continuing our conversation about managing requirements within the project, there is a tool that you can use called the Requirements Traceability Matrix. It's just a table for tracking and tracing your requirements through the entire project. You might also see this abbreviated as an RTM. So what are the requirements? Traceability matrix? Well, it's a table of all of the requirements in the project. It identifies your business needs, project objectives, theWBS deliverables, the product components, the development. What stage of development is it in? Even things like test cases, if you're doing software development, you do what's called UAT's Usability Acceptance Testing. So you can track those through this table as well. It's easier to see one than to just describe one. So let's take a look. This is an RTM sample. So you can see at the top, we have the project, the description. If you are dealing with cost centres where you're building different departments for the time being, you might include that information. Now, the actual table is what's important. Each requirement gets an identification. So it's kind of like a pin box. With this identification, you could have a requirement of five. 4356, for example, and the next one will be 57, and so on. Then the description of what that requirement is,how it satisfies the business need, the opportunity of why we're doing the project, thegoals or objectives, then specifically the project objectives. Typically, project objectives are going to be three things. They're going to be time, cost, or scope. And you might see those as key performance indicators. Now, we've not really talked about the WBS yet, other than it's a visual decomposition of the project, but theWBS Deliverables is a way of tracking that requirement back to the specific deliverable in the WBS. And so you can see, as you go to the right, there's more information and more information and you can even add more columns or so on. But the goal here is that you trace it. You're tracking the requirements through the entire project. So when you get to the end of the project and you do scope validation, you can look at every requirement and show that it went through all of the phases or all of the steps where it was mapped to the specific deliverables that the customer expects. So that's what a requirements traceability matrix looks like.

8. Defining the project scope statement

Defining the project scope is the process of creating the project scope statement. So what is the project scope? Let's talk about that first. The project scope is all of the required work and only the required work. So you can imagine if we are constructing this house. In this house construction project, we will only do work that satisfies scope. So if we weren't responsible for the landscaping,we certainly wouldn't be doing the landscaping. But if we are responsible for everything inside this house, including the finishing and the roof and the windows and so on, that would be part of our scope and it would be clearly defined through requirements what constitutes scope. And so it's very important to understand that the project scope is all of the required work and only required work, and the reason why that's important. If we start doing work that is not required,we start adding little extras and little features. We're doing scope creep. And as our scope increases, our time and cost must match the scope like the iron triangle. And if they're not matching, we're spending money and time on things that are not in the project scope to define the scope. This is a project management process where we are creating a detailed description. This will become our project scope statement, a detailed description of the project and the product. So that's why requirements are so specific: they help us create and define the scope. Now, project boundaries are things like that. We will not do it. So, in that house project, we're not doing any landscaping. It creates that scope statement. This is a physical document that will serve as a solid foundation for the project's work. Now, here's a new term for you. It's called the project baseline. The project baseline is made up of three documents The project scope statement is the project work breakdown structure. And then, what always goes with theWBS is the project WBS dictionary. The WBS dictionary is a definition,just like a regular dictionary. It defines everything that's in the WBS. So, in that house project, the WBS dictionary would define the various bedrooms in the kitchen, as well as the type of cabinets used, and so on. It would explain what that deliverable is, and we'll talk more about the WBS dictionary coming up. Now, the ETOs are defining scope. We have the scope management plan, project charter requirements, documentation,and organisational process assets. Those are our inputs. Now, organisational process assets Remember, this is something that's been created for you to help you do your job. So an example here would be past projects that are similar. We could take that scope and adapt it to this project. Or you might have some templates or forms that you use to help facilitate the creation of the scope statement. expert judgment, product analysis,really studying what that product is, understanding what the customer expects, alternatives, generation. Do we have to use bricks or can we do a brick facade? Is it cement or are we going to have a stone foundation or whatever the case may be? Carpet versus tile facilitated workshops like we talked about in the last session for requirements gathering. We can do those as well, really defining what the scope is now. The outputs of the defining scope Obviously, the project scope statement But you might also have some project documents updated. And that's kind of a vague way of saying you may have to update those requirements documentation or your scope management plan so that you begin to identify what goes into scope. You might realize Oh. We left out this requirement and we need to be thorough and update our requirements documentation. It could also be that as you're going through this, you want to take something out of the requirements or make it a nice to have or should have, whatever the case may be. But you may have to goup and update other project documents. I want to talk about expert judgement because it's a term you're going to see a lot throughout the Pinbach and in this session. Expert judgement just means that, as the project manager, you're facilitating the conversation with people that are specialists in particular areas. So, imagine if we had a project in the healthcare field and you're not a nurse and I'm not a nurse, and we didn't have a thorough understanding of specific medical procedures or hospital departments or whatever. So what we'll do is hire a consultant,someone who is a nurse or a doctor, and then they'll help us build this project scope. Chances are, our project team members could help. So those would be our subject matter experts. You might be creating a new product, like a new phone app. So you go ask customers what they think of your idea or what they would like to see with this new app. You might go to professional and technical associations and see what resources they have available. Or industry groups. So there's all sorts of IT groups or constructiongroups or what have you, kind of like PMI,but in very specific chapters or I should say, specific disciplines that have groups, like there's IT and construction and healthcare and so on.

9. What's in a complete project scope?

What's in the project scope? As you know, the project is based on the project scope, but we really need to nail down what the contents of the project scope are. Well, in this presentation we're going to look at everything that goes into a project scope statement. There is a lot of information, but here are some themes that will help you through this idea of examining a project scope statement. Let's say, for example, that we are going to design this website, this cheesy shortcakes website that you see in this picture here. And so, as we begin this project, we really need to define exactly what exactly this website will do. What's the goal? Do we want it to be mobile only on this iPad or on your phone? Does it allow people to place orders? Does it provide recipes? What exactly does this website do? So that is our product scope description, and then we have product acceptance criteria. How do we know when we're done? What will the customer accept as done? So we have to nail that down. What are the deliverables that we will give the customer? Do we give them a published website or do we give them just the files and they can publish it? So what are the exact deliverables? Is there anything that's excluded? Like, we won't set up the PayPal connection, or we won't set up the merchant gateway, or whatever. So what are the project exclusions? Are there any constraints like a deadline or a budget? What are some assumptions? Assuming this is HTML Five rather than Flash. So what are the assumptions we have going into this project? So those are some big themes that you're going to see in the project scope. A lot of project managers get confused about the idea of the project charter versus the scope. Remember, the charter is the very first document that you create for a project. It authorises the project. The scope comes later. It's based on progressive elaboration, on more and more information. So we've already seen over on the righthand side, we've already seen the description,the acceptance criteria, and so on. But let's go back to the charter here on the left. The charter says why this project is going to exist. So what's the justification? What are the measurable project objectives? Really high-level stuff here. What are the high-level requirements? What's the description? Do we have any risk? Do we have that summary milestone schedule? Do we have a high-level budget? Do you know your stakeholders? What are the approval requirements? Who's the project manager and what level of authority does this PM have? And then what's the name and the authority of the sponsor? The charter If you look at all of these,the charter is a high-level envision and it's about authorising the project, the scope. Our focus is a little bit more narrow. Our focus on scope is about getting the work done. So the scope is all about what we are creating for the customer. Well, the charter is kind of a sales pitch to some extent. It really satisfies the purpose of the project. Why are we doing the project now? Sometimes you'll see this idea of updating the scope statement. When you update the scope statement, you're probably going to need to update the reasons why the stakeholder register has changed. So if you update the scope statement, let me back up the stakeholder register. It may not have changed. What I mean to say is that if the scope statement is updated, and there's a change in the scope, you may have to go to the stakeholder and ask who needs to be aware of these changes. So if we're doing a house in a third car garage and are going to add a third bay therein, we would go to our stakeholder register and say, okay, which stakeholders need to know about this third bay for the house in this garage? If we added that third bay to the garage, our requirements documentation would have to be updated and then our requirements traceability matrix may have to be updated. So the scope statement, if there's a change in scope, it's going to have ripple effects throughout the project. So throughout the remainder of our course, you'll see this concept of project statement updated docs and really what it means here is that if you update the scope statement, you have to look at all of the other documents that are affected by that change and update those documents to reflect the change.

ExamSnap's CompTIA PK0-004 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, CompTIA PK0-004 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.