Project Scope PDF

Why is Scope Management Important? Scope management ensures the project team only does the work needed to complete 5...

Why is Scope Management Important? Scope management ensures the project team only does the work needed to complete 5 the project. It prevents extra, unnecessary work (scope creep) that could waste time or resources. PROJECT SCOPE The scope represents the expected deliverable, with its features and functions, as well as the work required to create it. PMI describes project scope management as a set of processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Elements such as size, color, dimension, weight, performance, and style are all discussed under scope management. Documents detailing design, behavior, appearance, or size, and engineering drawings illustrating the deliverable, contribute to the project's scope. In waterfall scope management, we plan the deliverable’ features and functions, then turn to the work that must be performed in order to create them. The scope starts as a high-level description in the project charter and is elaborated into granular details during planning. This is crucial because detailed information is needed for execution. For example, a high-level scope description for a stadium project might state, "this project is to put up a 90,000-capacity stadium, 800 washrooms, and 50 ticketing offices." While this summary is adequate for the charter, it lacks the necessary detail for execution. Elaborating the scope ensures it can be completed within the constraints of time, cost, and quality. Detailed planning assesses feasibility and ensures accurate estimates for time, cost, quality, and resources.  The Scope Management Plan and the Requirements Management Plan  Scope planning is conducted by the team, led by the project manager or a scope manager assigned to the project. The team first creates the Scope Management Plan, which guides all scope-related actions throughout the project life cycle. Any specific preferences on handling scope aspects in planning, execution, monitoring, controlling, or closure are included in this plan, making it a key reference for the team. Scope Management Plan: 1|Page This is the "rulebook" for scope. It tells the team how to handle the project’s scope throughout its life. For example, if a team member wants to add a new feature, they’ll need to check the scope management plan to see if it’s allowed. Additionally, the Requirements Management Plan is created to support the Scope Management Plan. This document directs efforts in requirements elicitation, analysis, and implementation to meet stakeholders’ objectives. For large and complex projects, it helps keep project requirements cohesive, refined, and integrated. Requirements Management Plan: This document outlines how to collect and handle the requirements (things the project must achieve) to meet stakeholder needs. For instance, in a mobile app project, the plan would cover how to gather user needs, such as what features users want most (e.g., a dark mode or faster loading). Stakeholder Engagement and Requirements Collection  Scope planning begins with engaging stakeholders in the Collect Requirements process, which has two main objectives: gathering detailed project requirements and evaluating how each requirement contributes to the project's objectives. PMI defines this as the process of determining, documenting, and managing stakeholder needs and requirements to meet objectives. Collecting requirements is delicate and crucial for project success. It ensures the team understands stakeholders' needs. Compromising on this process risks developing solutions that resonate with users. Some teams, due to laziness or apathy, may rely on assumptions, risking the creation of products that stakeholders may not accept. Collect Requirements Process: Involves directly engaging stakeholders to understand what they need. It’s about listening, documenting, and making sure you know the “  why” behind every request. Classifications of Requirements  Product or Solution Requirements are often provided by the client. For commercial projects aimed at creating business value, requirements are gathered from markets through benchmarks or engagement with target users. These requirements include quality and functional attributes, and overall look and feel that appeal to the end-user. Product/Solution: Features users want, like a “Buy Now” button on a shopping site. Technical Requirements focus on how the work will be conducted, technologies used, and procedures to create the solution attributes. These come from the execution team, supported by historical data, experts and industry standards. For example, a software team might choose a relational database for a client requiring heavy data relationships. Most clients lack technical knowledge and usually initiate solution requirements, not technical ones, although some try influencing the workmanship despite limited understanding of technical standards. Technical: How the product will be built (e.g., which technology to use). 2|Page Transition Requirements facilitate the adoption of new solutions by users. They may be integrated into the product, communicated directly to onboard users, included as instructional manuals, or provided through training before use. Additionally, rules and best practices aid in adoption. For novel solutions, supply and support systems significantly influence purchase decisions and increase adoption. Transition requirements can be derived from historical data, real-time observations of prototypes, or insights from subject matter experts. Transition: Needs to help users adopt the product, like training videos. Business Requirements are essential to achieving predefined business objectives, primarily maximizing profit and return on investment. They encompass aspects like investment cost, production cost, customer acquisition cost, life cycle cost, and customer lifetime value. Poorly analyzed or implemented business requirements can undermine projects, even if solution, technical, and transition requirements are met. For example, Twitter has struggled with monetization despite excelling in other areas. Analyzing and implementing business requirements effectively is crucial, especially in the software industry, where monetization is challenging. Successful examples include Facebook's strategic shift under Sheryl Sandberg and the mobile gaming industry's habit-forming and monetization strategies. Business: Project goals that drive profitability (e.g., low production cost). Regulatory/Compliance Requirements are mandatory standards needed to comply with laws or industry regulations, ensuring project work and deliverables meet legal standards. These requirements protect lives, property, and the project environment. They are collected from bodies such as standards authorities, food and drug agencies, metropolitan authorities, and environmental protection agencies. Project teams must stay updated on new regulations from these bodies. Business: Project goals that drive profitability (e.g., low production cost).  How requirements are collected  The Stakeholder Register started during project initiation and elaborated throughout the project serves as a useful input in knowing who to engage, the kind of requirements to collect and the degree to which their contributions can influence the project’s outcome. 3|Page  Context diagrams are essential for understanding a client's business, especially in large and complex organizations. They provide a visual map showing how various components, (people, processes, functions, technology) interact to create business value. This helps the project team develop solutions that fit the business context. For example, when creating a solution for a bank, understanding the bank's operations and how its elements interact is a crucial starting point. Context Diagram Sample for a University. ADMINISTRA- TION MEDICAL FACULTIES CENTER LECTURE UNIVERSITY CANTEENS FACILITIES HALLS & SPORTS & HOSTELS RECREATION LIBRARIES Interviews are a powerful approach to understand people and collect relevant information that contribute to the creation of the project’s solution. During interviews, people respond to structured and spontaneous questions regarding the proposed solution, and these responses are used to refine the product and the project work. Interviews: Talk one-on-one with stakeholders to understand their needs (e.g., asking a manager what specific functions they want in a new software tool). We also use focus groups to bring some predetermined stakeholders together to brainstorm the proposed solution for the purposes of obtaining further information that generate, regenerate and refine the project’s outcome. Facilitated workshops Focus Groups/Workshops: Get a group together to brainstorm and gather varied input (e.g., developers and designers discussing app features together). 4|Page Brainstorming: Free-form ideas without judgment, like listing all possible features for a new smartphone. Observation: Watch users interact with similar products to learn what they like or dislike. If you’re designing a new coffee maker, observe how people use their current machines. bring cross-functional stakeholders together to provide diverse perspectives and evolve solutions. For instance, creating a self-drive car requires input from various disciplines. In software development, joint application development (JAD) workshops gather developers, network administrators, business representatives, customers, and end-users to brainstorm solutions. These workshops also help stakeholders with differing views find common ground and establish consensus. During brainstorming sessions, allowing a free flow of suggestions without immediate assessment encourages participants to contribute more freely. The nominal group technique offers a gentler way to evaluate ideas. After gathering enough information, the moderator helps the group collectively own and assess the ideas, then rank or prioritize them based on which best serves the project's interests. In group brainstorming sessions, individual brainstorming may be necessary if participants are influenced by others or a charismatic leader. Mind-mapping enables unbiased, independent work, capturing diverse viewpoints. The resulting similarities and differences will accurately reflect participants' true opinions about the product. Benchmarks exist for emulation, with industries establishing standards for projects to meet. Benchmarking also involves collecting similar product samples, incorporating their best features, and striving to meet or exceed these standards. Questionnaires and surveys are useful for targeting a broad, diverse audience with a quick turnaround. This initially daunting task has been simplified and streamlined by technology. Social media platforms enable targeting specific demographics, and software tools can analyze and interpret responses swiftly and efficiently. Observation can be a more effective technique for understanding people’s expectations of a solution, especially when respondents are unwilling to engage or their responses might be biased. It is also essential when respondents have difficulty articulating their needs, such as with babies or pets. In software development, observation is used to validate assumptions about ease of use by watching a new user navigate the system. 5|Page Large collections of ideas can seem chaotic, but affinity diagramming organizes these requirements into groups based on similarities. Initially, project requirements can be classified into solution, technical, transition, business, or regulatory categories. Further classification can be based on sensitive categories specific to the project, such as age group, income levels, education, or geography. Prototyping visualizes project requirements by creating samples, replicas, mock-ups, demos, or pilots from initial requirements to refine and generate additional ones. Using imagery to stimulate thinking, prototypes mimic the final outcome to enhance communication, refine requirements, and validate expectations before significant investments. Multiple generations of prototypes may be developed, each improving on the previous one. The final prototype is created when stakeholders agree on the design. Prototyping reduces rework and wasted effort, saving time and cost.  Voting  Differences in project requirements can lead to stakeholder conflicts. Decision-making criteria, such as voting processes, are used to resolve these conflicts. In majority rule, decisions are made when more than half of the group agrees. If there's no majority, a run-off is held between the top two opinions. Plurality makes decision on the most supported requirement. Unanimity requires all referenced participants to agree before a decision is made. In autocratic rule, one person makes the decision for the group, potentially affecting their commitment if they disagree with the decision.  Requirements Documentation and the Requirements Traceability Matrix  The requirements documentation is a key artifact from the requirements collection process, containing all project scope requirements. A requirements traceability matrix links requirements to their origins and the project phase or deliverable they satisfy. Requirements Documentation: This is a master list of all requirements gathered. Think of it as a checklist that ensures every user need is noted. Traceability Matrix: 6|Page This tracks each requirement from its origin to the final deliverable. If you add a requirement like “ allow guest checkout on a shopping site,” the matrix links this back to customer requests, ensuring you don’t miss it later.   Finalizing the Project Scope and the Product Scope  Finalizing the product scope is a crucial moment in scope planning, where the team defines what will and will not be done, considering all constraints. The product scope details the deliverable's features and functions, while the project scope outlines the work required to create that deliverable. In finalizing the product scope, we also specify exclusions. Due to competing constraints, not all collected requirements will be included. Some requirements are mutually exclusive, and only one can be performed after an alternative analysis. Others may fall off the priority list or be excluded if they become unjustified after planning. Documenting these exclusions ensures stakeholders understand what is not being done, solidifies project boundaries, and helps prevent scope creep. Scope creep refers to any work done outside the scope baseline. All features must be included in the scope baseline before implementation. New features requested later must be formally approved, controlled, integrated, and added to the scope baseline. Scope creep involves changes that enter the project unofficially and without proper integration. PMI observes, managing the project scope is primarily concerned with defining and controlling what is and is not included in the project. In finalizing the product scope, the team performs product analysis, scrutinizing the individual components that make up the deliverable, and examining their integration on how they engineer to deliver the project’s intended value. The team may also establish the acceptance criteria on this level so those who create the deliverables will understand what “done” means and create them to specifications. In finalizing the product scope, the team conducts product analysis to scrutinize individual components and their integration, ensuring they deliver the project's intended value. Acceptance criteria are also established at this level to define "done," guiding the creation of deliverables to meet specifications. 7|Page Once the product scope is established, the team focuses on developing the project scope – the work. This involves analyzing various implementation approaches, considering material components, cost, time, quality, safety, and risk to determine the best approach that serves the project's interests. A consolidated document called the project scope statement is created to capture both project scope and product scope. This important document serves as the foundational block for creating the scope baseline. The project scope statement contains: The Product Scope (details of the deliverable with its features and functions) The Project Scope (details of the work) Acceptance Criteria (definition of acceptability) Exclusion Statements (what we are not doing)  Breaking down the work: Work Breakdown Structure and Work Packages  Once the project scope statement is created, the next step in scope planning is to break down the work into smaller, manageable components called work packages. Project deliverables, initially bulky, are decomposed into smaller parts on different granular levels. In a predictive life cycle, the project scope begins as a narration in the Project Charter. The deliverables and work are then detailed in the Project Scope Statement, which is subsequently broken down into work packages. This breakdown uses a hierarchical structure, decomposing work into branches and sub-branches, ending with the smallest components called work packages. This entire structure, presented as a chart, is known as a Work Breakdown Structure (WBS). The practice of breaking down work is common across industries, aimed at simplifying tasks to improve performance, management, and control. A key advantage of bottom- up approaches is that they make it easier for the team to establish reliable estimates for cost, schedule, and resources. 8|Page The figure above illustrates a sample WBS for a stadium construction project. In breaking down the work, the project scope statement serves as the starting point but is not identified as a level on the WBS. The first level breakdown may be represented by the project's phases, with the example showing four phases. Each phase is further decomposed until the work elements reach a level that satisfies the work package rule. As decomposition progresses, higher-level components are broken down into multiple elements beneath them. Eventually, all project work is broken down to the lowest levels as work packages. The primary goal of the WBS and its tree-like structure is to achieve total coverage of the work, reducing the likelihood of oversights and ensuring that no tasks slip through the cracks. According to the 100% rule, the sum of the individual components at the lowest level of the WBS should equal 100% of the work description at the level above it, ensuring nothing is overlooked in the decomposition process. In the past, work was presented in list format, leading to critical oversights. The WBS also prevents duplication of effort, ensuring efficiency. While decomposition has its advantages, excessive decomposition can lead to inefficient resource use. A good WBS is typically kept within three to seven levels. A common rule of thumb is to create work packages that take between 8 and 80 hours to complete, where less than 8 hours is too small and more than 80 hours is too large. Understanding the principle behind the concepts is crucial. The principle of creating a WBS or work packages is simplicity for ease of management and control, aiming to create deliverables with minimal defects. If a task will take 81 hours, the focus should 9|Page be on whether simplicity is maintained rather than strictly adhering to the rule. If a 60- hour task presents unwarranted risks due to its complexity, it may be prudent to split the work to reduce those risks, even though it falls within the rule. Project leaders are not robots merely following rules. Best practices, by principle, should be adaptable. Creating a WBS fosters team bonding as members collaborate to plan the work. This collaboration is vital in project management and should be leveraged. Planning together allows each team member to understand their role in the next stage, enhancing their commitment, buy-in, and support for the project. The WBS can also serve as a communication tool, illustrating the project components to any stakeholder who needs to understand the project's structure. Writing directly in a WBS, as shown above, is not an acceptable practice. More commonly, WBS elements are coded, as illustrated in the figure below. The descriptions of these codes are then documented in a companion document known as a WBS dictionary, which is kept alongside the WBS as a reference. 10 | P a g e   Control Account and the Scope Baseline  A Control Account is a management review point for measuring performance, typically established above the work package levels, sometimes by combining about three work packages. At this level, the scope, schedule, and cost are evaluated Control Account: together to assess performance. A checkpoint where you assess if scope, schedule, and budget are on track. For example, after completing the foundation for a building, check if it meets planned quality and cost. A scope baseline is established by consensus between the project team and senior management and cannot be changed unless through a formal change control procedure. Scope Baseline: The final, agreed-upon version of the scope. It’s like the contract: you can’t change it without approval. Major components of the scope baseline include: 1. Project Scope Statement 2. WBS 3. WBS Dictionary Take note that the Scope Management Plan is not a part of the scope baseline.  Scope Performance  The performance of the scope is measured against the scope baseline, which essentially includes the features and functions of the deliverable (the product scope), the work required to create it (the project scope) and associated work packages. The purpose of scope management is to meet the objectives of the scope baseline. Scope performance management involves monitoring, evaluating, and controlling. Monitoring ensures the work and deliverables align with the plan. Evaluation measures any discrepancies between the work and deliverables. Control involves implementing corrective and preventive actions for non-conforming elements. Changes to the scope baseline, such as adding, removing, or modifying features, require a formal request to the change control board for approval. Baselines are created and approved by consensus and can only be changed through a formal change control procedure. 11 | P a g e It is possible for a team member to work differently from the plan or implement features outside the scope baseline (scope creep) – it happens. This could occur when the team member thinks differently about a situation and implements what they believe is right to "help the project" without informing or seeking approval. Although this is not right according to the protocols of change management, we don't dismiss the action. Instead, we investigate the reasons behind the action. While proper procedures may be violated, the reason for the change could be tangible and beneficial to the project. Variance Analysis is the technique used to compare actual performance to planned performance to determine any variation to project work.  Scope Validation  Validating scope is a crucial process where the customer inspects and formally accepts completed deliverables. This process, performed on created interim deliverables, allows the team to gain acceptance, confirmation, and confidence to continue work on approved deliverables, thus avoiding the error of going down the wrong path. Scope validation occurs multiple times throughout the project life cycle at the creation of tangible deliverables. Regular inspections and formal acceptance at each level keep the customer involved, significantly reducing the risk of developing unwanted solutions. Variance Analysis: Measures if the project is following the planned scope. For example, if your plan was to complete 20% of work by a certain date and you’re at 15%, there’ s a variance. Expert judgment often acts on behalf of or in collaboration with the customer during scope validation. This doesn't necessarily mean the customer must personally inspect deliverables; instead, a consultant or subject matter expert can fulfill this role, ensuring the necessary technical know-how is applied. Scope validation also makes acceptance and sign-off on the final deliverable almost automatic, as the final deliverable is essentially a sum of its accepted parts. Regular acceptance of individual components typically leads to overall acceptance of the complete project. 12 | P a g e