Transcription
Hi, I'm sure you remember last lesson, but just in case, let's recap. The logical process of scope planning: first, we analyze the available information on the project scope. Then, we gather detailed requirements and expectations. And finally, we document the scope. Simple enough.
But now, we're going to have a low-level look at this process. So, the first step, the project manager analyzes the high-level information from the project goal and scope gained from the initiation stage. These come from sources like the project charter, discussions with the sponsor, client, and stakeholders, and other project communications.
The next step is for the project manager to gather detailed requirements and expectations. This stage involves dealing with the stakeholders, the ones who started and approved the project, sponsors and senior managers usually, and of course, the ones who benefit from or are impacted by the project, such as external parties and departments within the organization. They are a reliable source of information on scope if the project manager asks the right questions. The meetings and workshops the project manager planned are utilized here. Remember, getting this information can be difficult, as these tasks are often non-straightforward tasks. This is where a project manager's personal skills and persistence are essential.
Throughout this task, a project manager may find discrepancies in the expectations of different stakeholders. For example, a senior manager for Lambari wants the sales team to have new computer software to aid their daily work, so expects this enhancement to be part of the scope. The goal of the project is to improve sales, right? However, new software for the sales department is not part of the scope here. Time and budget to do that are not forecasted, and from the triple constraint, you know what implications that will have. The project manager needs to adjust the senior manager's expectations to avoid wrongly expanding the scope. The pressure is on. The more experienced a project manager, the more detailed the scope will be. Of course, things will be missed and mistakes made, but the fewer, the better. And the more information a project manager gets out of the stakeholders, then the less likely big mistakes will occur.
Once the scope is as detailed as it can be, the final step is for the project manager to officially document it using a scope statement. A sample is in the resources for this lesson, although usually, the project management office uses a standard template. Think of the scope statement as a formal contract between the project manager and other stakeholders. It can be used as proof of what the project manager has and hasn't committed to do.
So, as explained, the purpose of the scope statement is to formalize the scope. Its format, however, is not user-friendly when it comes to the practical planning with timelines, actions, and owners, which will follow. This is where the project manager needs to perform another exercise of structuring the scope. Create a work breakdown structure. In the breakdown structure, the project manager starts with the goal and breaks down the project work into deliverables or packages. This is called a work stream, and it breaks down until the work package is an appropriate size to be given to one person. Then, for an even more user-friendly experience, they create a list with all these activities: an activity list, which details the person or people or department responsible for the task or activity, and they're referred to as the owner. Please note, we've just seen three documents that have the same information but are represented differently. The scope statement is formal, the work breakdown structure is a handy segregation of the different types of work or work streams, and the activity list is the skeleton of the project plan, the document everyone can refer to.
But hold on, we haven't mentioned how long these tasks should take, which is the basis for our next task, where we will detail the timelines and schedules of activities. Join us next lesson, and together we'll go through how to do this. See you there.
I know it sounds silly, but planning your plan is what makes the difference between a productive plan and that napkin mind map I mentioned a few lessons ago. Planning your planning does take a fair amount of time and effort, then replace plenty of things for a project manager to think about. First, the project manager must assess their own knowledge of the required work. Is it enough for a sufficient plan? Second, do they know all the stakeholders? If not, they need to get in touch and discuss what their involvement will be in the project. What will they be expected to do? For example, the project manager can't plan who will pay the construction team if they don't know who the financial team is. Third, they must recall lessons learned. No need to reinvent the wheel, right? Have they or any of their team worked on a similar project, and if so, what lessons have they learned that they can bring across to the current project? Lastly, what about any knowledge gaps? Are there any expertise that the project manager lacks? Do they need to bring in extra support for any areas of planning? A good project manager is not someone who knows everything, but somebody who can see their shortcomings and find the right people to compensate for them.
The project manager needs to determine how much time they need to put all the pieces of the project plan together. They will decide who they need to keep in contact with and if they need to reaffirm expectations. Reviewing the four points above will definitely help with that task. And in the case of meetings and workshops with stakeholders, they must make sure they have a clear agenda, a distinct goal, and a comprehensive list of topics to ensure they get the answers they need with as little resistance as possible. See, project managers really do have to think of everything. That's why the next lesson is going to be all about planning your plans. Plan. Just kidding. We're going to take a short interlude to explain a couple of planning tidbits that will be useful to know. See you there.
Before we move on to planning, I just want to interject with a couple of pointers that are worth knowing because we've got your back. The first one is a tip from PMI, so you know it's worth your time. Here it is: Planning is iterative. We've made it clear that planning covers all sections of the project, from timelines to risks to expectations, but it's important to know that before the planning is complete, you may often need to make modifications to the stages already planned. New information can always change the plans you've already made. For example, say you're planning timelines for the virtual reality area of your showroom. Last year, you added a section like this to a different showroom, and it took you two months. Therefore, when you plan this in your timeline, you use the same duration. A little while later, you start planning your resources, and you realize that two members of the tech team have left since last year, leaving you with 20% less staff. There's a good chance this will affect your timelines, and you will have to go back and revise them, adjusting the time and resources of the project. See, planning is iterative. Be patient, and until all areas have been analyzed and planned, you better write your plans in pencil.
Then we have what we call non-straightforward tasks. Some tasks are simple. We can imagine how they will be done and in how much time. Say one task is: organize a workshop session. The project manager reviews the necessary participants, finds a good day and time for everyone's calendars, books a room, puts a flip chart inside, and sends the invitation. This process is easy to predict and execute, right? There are, however, these non-straightforward tasks in our project. Let's say you're planning to project dynamic elements and animations on the cars, things like weather and different paint jobs. For this to work, you need to recruit an experienced software developer. Let's call this task: estimate recruitment duration. Sounds simple, right? You need to analyze and dedicate a number of weeks to recruit the person. You decide that two days are more than enough time to get the information needed to estimate this, so you write an email to HR and ask how many weeks they'll need to recruit an appropriate engineer. The same afternoon, you see a reply from HR. Excellent, looks like you'll have the estimate in one day instead of two. You open the email, and it says they can't give you an estimate until you tell them more about the ideal candidate: how many years of experience, what kind of projects have they worked on, what kind of programming language is needed, things like that. You stare blankly at your computer screen because you have no idea. The next day, you call your colleague in the IT department and ask them for the details. HR needs. They respond quickly with most of the information but recommend you get formal validation from Sandra, head of IT. But Sandra is on holiday for the next two days. You have no choice but to wait. When Sandra returns, she's happy to help but needs a day to go through the information and validate it. Finally, the following day, you get the information and send it over to HR. They review it and give you an estimate of seven weeks. Awesome, task completed. Although instead of two days, it took you eight days to estimate recruitment duration and fit it into your plan. Tasks like this, especially ones which involve other people and information the project manager is not fully knowledgeable in, can have unexpected results and complicate the process, which in turn can change plans. Keep this in mind as we move on to the next lesson and the real planning. It's all been coming down to this. Brace yourselves and see you in the next lesson.
Welcome. Are you ready to see how a project manager plans a project? Excellent. Over the next few lessons, we're going to discuss every step of the process, and by the end, you will be more than aware how essential the planning stage is in the project life cycle. At this point, the project manager should have what they need to begin planning. And this stage, the planning has its own structure so the project manager can cover all areas because, as we know, the more thorough the plan, the less likely the project manager will end up needing to spend resources fixing something later in the project. Breadth and depth, remember?
So, where do we start? That's right, scope. The project manager needs to know exactly what her or his project will involve before any work starts. Sensible, right? Thinking of our Lambari project, in order to prepare what you need to build the showroom and for it to be a trendy new building, setting the standard for all other car showrooms, you need to know exactly what this project will involve. What should the showroom building look like? How many floors? What cars are you producing? What color scheme will you go for? Which angle will the building face? This is why scope is the first thing you have to plan. You are accountable for translating the goal of the project into deliverables and then into tasks or sets of tasks. Collectively, these represent the scope, and the scope answers one question and one question only: What exactly does the project team need to do? I never said it was an easy question.
So, our goal is to have a new, top-of-the-range showroom in a new retail park, showcasing our newest, most state-of-the-art cars with well-trained staff and setting the standard in terms of showroom architecture. Deliverables are the building blocks of the project. They all come together to reach the goal. One deliverable is construction of the showroom. And the set of tasks needed to reach this deliverable are the following: one, lay the foundation; two, erect the walls and core structure; three, fit the floor; and four, paint the outside. And that is just one part of the scope. Remember, the scope is the broader concept. It's not just the product or an hour, for example, the cars, the showroom, and staff themselves. It includes all the additional work that needs to be done to ensure the product is not only created but meets the requirements and expectations of the project stakeholders.
Now, what if you find out there's a building already on the piece of land that you want to build the showroom on? You'll have to demolish it. This is not part of the construction deliverable but needs to be done before anything else can start. Therefore, it is part of the scope. If this had not been thought of, construction would be delayed, costs would be above what had been planned, and stakeholders' expectations would not be met. So, you will need to think of the product scope, that is, the tasks that need to be done in order to produce the product, the showroom in our case. Also, you will need to think of the project scope, which is all that you need to do in order to achieve the project goal, including the product scope. Say there is a small street next to where the showroom is to be built, and the residents on that street are of the clear opinion that it is the responsibility of the company that is building the showroom to renovate the street. Is that a responsibility of the company? The answer is in the scope statement of the project. If it's not specifically included, you cannot spend resources on this costly work. This is why scope needs to be described in detail, including what is not in the scope, of course. A little common sense goes a long way here. If you forgot to put door handles in your showroom project scope but included windows and doors, we would not deny the showroom 20 or so door handles. However, a few million dollars on a brand-new road that hasn't even been signed off by the city? Well, that's just bad planning. Of course, this is something that must be agreed between the construction company and the city when the construction rights are being signed, which is part of the initiation task. If there is an agreement for partnership and the company needs to work on the street, this must be formally added to the scope so you can assign the relevant resources.
Now, to sum up the scope stage: the project manager starts by assessing the information she or he has on the project's scope, being what they gained during initiation. Then, they gather detailed information on the requirements and expectations in the project. They use their expertise and that of their team members to cover all the gray areas of the scope that can and will affect their project. And finally, they document everything. If something arises, there needs to be an easy reference point for the project manager or other stakeholders to check in order to determine if something is worthy of their time and resources. Awesome.
In the next lesson, we will look at these three steps in more detail: how a project manager analyzes the high-level information, deals with stakeholder expectations, and how they document the scope in a user-friendly way. See you there.