How to Write Compelling Project Objectives, Scope, High-Level Requirements & Project Team?

1. Course Introduction: Are you writing a project charter and are finding it difficult to document the measurable project objectives, project scope, high-level requirements, and the project bim. You need specific guidance on what should and should not be included in your project objectives. You want to craft a project scope statement that is complete and considers every aspect of the project. If your answer is yes to these questions, you have come to the right place. As a project manager, you will always document and create a project charter has the first step of any project, or typical project charter includes all these components. In this course, you will learn measurable project objectives, project scope, high-level requirements, project manager name and authority level, and project team. Writing your project objectives require clear, measurable, and realistic actions that the project needs to achieve. A project scope statement defines the length and breadth of the project. Requirements are basically the expectations that your project must deliver. It is crucial to identify departments and teams when you begin your project. These components of your project charter are read by the project sponsor and the approving committee. And based on what you have documented, they will either approve or reject your project. Now, I have seen several projects being rejected because either the objectives are nothing but a description of what needs to be achieved. Scope of the project is not defined well. All the high-level project requirements are not clearly articulated. These components of the project charter documented by some of the seasoned project managers, yet they failed. The reason for their failure is simple. Their project objectives, scope statement, high-level requirements, and project team composition was not thought through. They were incomplete. The project managers did not pay much attention explaining and convincing their approvers that their project was critically. As a result, their documentation failed to impress. If you want your project charters to look comprehensive. If you want your project objectives, scope statement, high-level requirements, and the team composition to provide a complete picture. If you want these components to trigger immediate action from the senior management to approve your project, funded and promoted. You must do this course. I have executed several 100 projects in the industry, and each of my project charters were instantly approved, funded, and promoted by the senior management. And I'm happy to share my knowledge and expertise to you by virtue of this training with that background information of what you will learn in this course and why it is important. We will start our learning journey. 2. Write Effective Project Objectives: Measurable project objectives. Defining crystal clear project objectives is critical for every project. In this lecture, you will learn what our project objectives, tips to remember while creating these objectives and linking project objectives to your organization's strategic goals. So let us begin with the first question. What our project objectives? When you document the description of project deliverables, you articulate the success criteria of your project. However, if you would have noted the description of these deliverables is written in a subjective form. There is no objectivity in it. And that is a primary difference between the description of project deliverables and project objectives. Project objectives are specific, measurable, achievable, realistic, and time-bound actions that the project needs to achieve. You may recognize that the terms specific, measurable, achievable, realistic, and time-bound can be abbreviated as smart. That's the key. Your project objectives must be smart. Project objectives may be articulated as service level related, quality related, finance related, or customer satisfaction unrelated business objectives. I like to call these SQ FC objectives, that is service level, quality, finance, and customer satisfaction objectives. Service level related objective focuses on closing your project by a specific date. For example, we objective is to complete the Dodd-Frank regulation guidelines to 100% in our organization by the end of first quarter. The quality related objective focuses on improving your organization's quality aspects. For example, improving the quality score of your process by 20%. As the name suggests, financial objectives focus on the financial returns of the project. These could be cost-saving or cost reduction objectives. These could even be focused on objectives related to improving revenues, profits, etc. For example, reduce the travel cost by 15% by the end of this year. A customer satisfaction related objective focuses on measuring customer satisfaction. For example, improving the Net Promoter Score, popularly known as NPS, of your customers by ten basis points, by the end of this year. These four categories generally income pass most of the objectives. But depending upon your industry, field of work, or company, there may be more categories. Also, your project may have one or many of these objectives. Let us look at a few tips to create these objectives. Your objectives may be quantitative or qualitative. Quantitative objectives deal with numbers and can be measured easily. For example, financial objectives are measurable. You can easily see whether your project is meeting its financial objectives are not. Quantitative, objectives are subjective. For example, when you improve the customer satisfaction score, you may use a rating scale of one to five or one to ten. So the first tip is to ensure that your project objectives are measurable. Like we discussed earlier, it will be helpful if they follow the smart principle. The next important tip is to keep your objectives more realistic. If the objective is too easy to achieve, it may hamper team member involvement. If it is too tough, your team may lose the motivation to achieve it. It has to maintain the right balance. To be honest, there is no science behind it. You have to observe, listen, absorb, and assimilate from stakeholders and subject matter experts. Tip number three, set clear deadlines for milestones and key achievements wherever possible. Establishing clear target dates is critical and keep the ball rolling in your project. Tip number four, keep the objectives simple and straightforward. Complex, and convoluted objectives may sound great, but may not provide a clearer picture of what you plan to achieve in your project. Linking project objectives to your organizational strategic goals. Once you have defined the project objectives, you must look at those from a holistic perspective. Think about how your project goal is helping your organization support or meet its overall goal. You can work with the project stakeholders to set up the needed linkage between your project objectives and organizational goals. 3. Write Project Scope Statement: Project scope. Let's look at this example. When a company starts constructing a building, it puts a fence across its perimeter. This fence indicates a boundary within which the building will be constructed. It also allows people outside the project to know that there is work happening in that area. Definitively that the construction company has done nothing but scoped their work area. In this lecture we will talk about what is project scope. Why is it important? How to document a project scope? Let us begin. What is project scope? As you had seen in the example of constructing a building, a project scope defines a boundary to your project. You articulate what is in scope and out of scope. Once the scope is finalized and documented and the project charter is signed off, you will not make any changes. If stakeholders request to modify your project scope, you will put their request through the change management process. Please do not say yes to their scope modification request immediately. If you say yes to it, you are most likely initiating a phenomenon called scope creep. One study of failed projects indicated that scope creep is why more than 60% of projects failed. What is scope creep? You say yes, and add some new work in scope. Your team goes back and complete data gathering, compiling, analysis, and reporting for this new scope. This work takes time and your project does not move further for that period. When you come back to another project review with stakeholders, they end up asking why you are taking so long to move the project forward. They are not aware of the groundwork needed to bring the new scope to life, and thus, they start losing interest in the project. Eventually, the project ends up as a failed project due to scope creep. And yes, this is a common occurrence in every project. When you put the scope change request through the change management process, the change control board gets involved in determining whether the requested changes critical. If it is, the change control board approves the change request, it is only then you can modify the scope of the project. This formalized structure avoids trivial changes to be included and ensures only essential changes to be incorporated. Why is coping important? As we have just discussed, documenting the scope in a project charter avoids scope creep. This is the first reason why scoping is essential. The other reason is that as you move ahead in your project journey, some stakeholders may say that they were assuming this project. We'll cover a few more areas. This is where you can show them the signed off project charter with the areas that were decided and agreed upon to be in scope and out of scope. How to write a project scope? The project scope has two components. You have to document what is in scope and what is out of scope. Items that you include in your project will be listed in the in-scope section. And those that you do not include in the project, there'll be included in the out of scope section. 4. Write High-Level Requirements: High level requirements. Let's look at the construction example. When you are constructing a building, certain conditions or tasks must be met to ensure the building is well-constructed. These could be, the building should have good durability and endurance. In other words, all of its components such as slabs, walls, columns, etc., must ensure safety. Dampness may reduce the life of a building to a great extent. The buildings should be constructed such that there should be enough resistance to this dampness. There must be adequate insulation to heat, sound, fire, cold, etc. These are the high level requirements of your building construction project. What are these high-level requirements? What are the different techniques to gather these requirements? How to analyze the gathered requirements and how to document these high-level requirements is what you will learn in this lecture. Let us begin. What are high-level requirements? Requirements are a description of what your project must deliver. These requirements may come from the project objectives. Requirements may also come from project stakeholders, customers, or any parties. Your job is to gather accurate requirements. Your requirement should not be incorrect nor excessive. Suppose your requirements are incorrect, your stakeholders will be highly dissatisfied. If they are excessive, your project will cost higher and also take longer to complete. Some of the key challenges that you may face while you're gathering requirements are stakeholders may not be able to define their requirements as accurately as they should. They may only provide a few requirements and miss out on the others. Some stakeholders may provide contrary degree requirements to. Some stakeholders may provide every detail and some may only superficial level requirements. You may not include all the stakeholders in the requirements gathering process. Individuals who are not on your stakeholder list may press U to add their product requirements. Just be aware of these challenges. All you have to do is to ensure that the requirements you gather may complete sense for your projects. What are the techniques to gather high-level requirements? Techniques outlined here can be used together high-level and detailed requirements for the project. The first technique is meeting with project sponsor. It is the project sponsor who is responsible and accountable for the project. It is the project sponsor who approves the budget, resources and the project manager. It is the sponsor who removes any potential roadblock for the project. It is also the sponsor who is interested in your project success. You must seek an understanding of what the sponsor is looking to achieve from this project. Meeting or a call with the sponsor will help you capture critical requirements. Meeting with stakeholders. Stakeholders are the impacted parties of your project. Hence, capturing requirements from them is critical. You can use various techniques to capture the requirements. These techniques include focus groups, interviews, email surveys, among others. Project observations. As you gather details to document the project objectives, high-level requirements, etc. You will get a fair understanding of what the project is all about. These observations will help you craft high-level requirements for the project. How to analyze gathered requirements when documenting a project charter, you are in initial phase of your project. Hence, we do not need to capture every little requirement. All we need to capture are the high level requirements. What you must ensure is that the captured requirements are making sense. If they are not, you may want to prove the relevant stakeholders a little more to seek their guidance and clarity in understanding their requirements. How to document high-level requirements. Key points to remember, to document high-level requirements correctly. Documented requirements must be easy to understand and follow. They must be clear and unbiased. You may want to organize them into categories if needed. Keep the requirements at a high level. At this stage, in the future stages of your project, you will get the opportunity to provide a detailed overview of each requirement. 5. Write Project Manager Name & Authority Level: Project manager name and authority level. After documenting the measurable project objectives, scope, and high-level requirements, it is now time to document the project manager name and the authority level. The name of the person given the authority to lead the project must be documented in your project charter. It is the project manager. It would be best if you documented the following project manager responsibilities. Brief description of project manager work, and the authority of the project manager. You may ask what is the reason to discuss the authority of the project manager? That's a good question. In most organizations, project managers belong to different departments. They do not belong to the business. And since they do not belong to the business, they do not have the necessary hierarchical authority to decide the budget, schedule, or even staffing. But since the project manager leads the project, the sponsor must give this position than necessary authority to make the right choice at the right time. Although this authority, you would only last until the project lasts, it is essential to provide this authority to this role. And you must document a description of what the project manager is authorized to do. 6. Write Details of Your Project Team: Project team, it is crucial to identify the departments and teams involved in the project at the beginning of the project. This lecture, we will document the departments involved in the project and what role they play during the project. Let us look at an example. The facilities management and technology services group will work with the project manager to identify and evaluate available solutions. Representatives of the corporate risk department have been named to help ensure any potential risks. The procurement and the legal team will work together to release the request for proposal, acquire the solution, and keep it in a legally binding contract with the window facilities management and IT will install the Data card readers on each floor. Human resources will help provide the relevant employee data to handover the data cards to all employees. The business and payroll teams will work with the IT and the vendor to customize the reporting requirements. Business, human resources payroll. And IT will deploy the solution and ion out potential issues during the solution deployment. In this example, you will find that the department is associated with the project activities are listed. They are Facilities Management, Technology Services or IT, project management office, corporate risk, procurement, legal, human resources, business, payroll, and the vendor. In addition to listing these departments, they have also documented is Departments high-level role during the project execution. 7. Mini Project: Many project. Now that you are fully aware of all the steps needed to document the measurable project objectives, project scope, high-level requirements, and project team. Here's a mini-project that can turn your learnings to reality. First. Based on your learnings from this course, make a list of do's and don'ts of documenting the project objectives, scope, high-level requirements, and project team. Once your list is ready, document these components. If you are already working on a project, this activity can be executed for that project. Or if you don't have a project, you may think of a fictitious scenario. In practice, your newly learned skills. 8. Course Conclusion: Conclusion. So we have come to the end of this course. Let's recap your learnings. You began this course journey by understanding how to write appropriate project objectives. You then learned how to write a suitable project scope statement. Further, you learned how to capture the high level project requirements. Next was to learn why is it important to document the project manager name and authority level? By the end of this course, you learned what goes in creating a project team. That was your overall course journal. We have come to the end of this course. Please do share your review and I will see you in the next course.