So, when it comes to planning, we want to know the answers to three basic questions: What are we going to do? How are we going to go about doing it? How do you tell when a job is finished? You’ll have a thorough Project Plan at the end of the planning phase. This project plan will have a few elements, such as requirements and scope. Structure of Work Breakdown (or as we call it WBS) We’ll have a schedule, some kind of deadline, then cost and budget, and finally quality. Let me preface this with a disclaimer for anybody considering taking the PMP. More processes with their inputs and outputs are included in the PMBOK handbook.
Let’s get started with the criteria. It’s all about “knowing what stakeholders desire” when it comes to gathering requirements. So, what exactly do you want? Are you aware that we done something similar with the project charter? As a result, we’ll just take the project charter and add extra information and specs to it. what we wrote in the project charter, and expand on it. This is simple with my boat-building endeavour because there are only a few people that matter.
However, if this was a very large project, you’d need to meet with those major stakeholders and make sure their requirements were included in the plan. What method do you use to determine who the stakeholders are? Do you recall the stakeholder database? This isn’t a simple task, as you can see. I mean, gathering needs is the most straightforward part. But keeping your sanity is the most difficult part. Because as soon as you start gathering criteria, everyone will demand the finest of everything, regardless of expense, quality, or timeliness. They’ll also have requirements that are incompatible. There will be squabbles. And, at this point, you don’t even know the budget or the quality.
So, based on your assumptions, you’ll need to gather the requirements in some way. That isn’t an easy task. If my wife approaches me and says, “Hey, let’s go get you a new car!” It’s now or never. She inquires, “What kind of car do you want?” I want a Porsche 911GT3 as my first automobile. I’m not going to think about the family budget or upkeep costs. I’ll just express what I’m thinking. That is also true in project management. When you ask your stakeholders what they want, they will aim for the stars. As a project manager, you must keep things in check and explain to others that life is full of trade-offs. Just a quick tip: when it comes to gathering criteria, there are a plethora of options.
Just stick to a good meeting if you ask me, and if you can. Gather everyone in a room or on a teleconference to discuss the requirements. If you conduct interviews one by one, you will be confronted with a plethora of contradictory requirements. Bring everyone together and let them quarrel and fight, but at the end of the day, you’ll have your requirements written down. The next step is to define the scope of the project. The scope of the project is defined by what is and is not included in it. The phrase “scope” is a good example of this. When looking through a scope, you can only see a limited amount of information. We’ll need a few documents to do so, including the Project Charter.
The one we did as part of our initiation. Then, to establish the scope, we’ll need the requirements document we just produced as well as any other information we can gather concerning risks, assumptions, and limitations. One of the most critical steps now is establishing the scope. Because, in reality, inexperienced project managers include everything in the project requirements document as well as the project scope. As a result, your project plan becomes a near-impossible task to complete. It is, in fact, their fault. The implementation would be much smoother if they stood up to project stakeholders during planning. So, while you’re writing your scope statement, keep this in mind. Please bear in mind that what you put in there you’ll be responsible to execute. Try not to go overboard.
Product scope, project scope, deliverables, product acceptance criteria, what is not part of the project, limitations, and assumptions may all be included in your project scope statement. It’s better if you can be more explicit. Nothing that is subject to interpretation should be included. Now that our project scope has been completed, I’d like to introduce you to Scope Baseline. So, what exactly is this? Establish a baseline. So, the scope baseline is made up of three elements:
1) Scope statement
2) Then, we need Work Break Down Structure. I’ll refer to it as WBS from now on.
3) And finally we need WBS Dictionary.
Don’t worry, this is all really straightforward. In fact, WBS is a lot of fun to do. So, now that we have the scope statement, let’s move on to the WBS. Now, I’d want to take a moment to pause you and make an announcement. You can’t afford to get WBS wrong. Project management is nearly entirely based on the Work Breakdown Structure. Whatever project methodology or framework you employ, such as Prince 2 or PMI’s, you’ll always have a Work Breakdown structure. It’s critical.