لخّصلي

Unit5: PROJECT SCOPE MANAGEMENT
PROJECT SCOPE MANAGEMENT INCLUDES THE PROCESSES REQUIRED TO ENSURE THAT THE PROJECT INCLUDES ALL THE WORK REQUIRED, AND ONLY THE WORK REQUIRED, TO COMPLETE THE PROJECT SUCCESSFULLY. MANAGING THE PROJECT SCOPE IS PRIMARILY CONCERNED WITH DEFINING AND CONTROLLING WHAT IS AND IS NOT INCLUDED IN THE PROJECT.

•5.1 PLAN SCOPE MANAGEMENT
•Plan Scope Management is the process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled. The key benefit of this process is that it provides guidance and direction on how scope will be managed throughout the project.

Loading…

•5.1.2 PLAN SCOPE MANAGEMENT: TOOLS AND TECHNIQUES
•5.1.2.1 EXPERT JUDGMENT
•Expertise should be considered from individuals or groups with specialized knowledge
•or training in the following topics:
•Previous similar projects, and
•Information in the industry, discipline, and application area.
•5.1.2.2 DATA ANALYSIS
•A data analysis technique that can be used for this process includes but is not limited to alternatives analysis. Various ways of collecting requirements, elaborating the project and product scope, creating the product, validating the scope, and controlling the scope are evaluated.
•5.1.2.3 MEETINGS
•Project teams may attend project meetings to develop the scope management plan. Attendees may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for any of the scope management processes, and others as needed.

•5.1.3 PLAN SCOPE MANAGEMENT: OUTPUTS
•5.1.3.1 SCOPE MANAGEMENT PLAN
•The scope management plan is a component of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The components of a scope management plan include:
•Process for preparing a project scope statement;
•Process that enables the creation of the WBS from the detailed project scope statement;
•Process that establishes how the scope baseline will be approved and maintained; and
•Process that specifies how formal acceptance of the completed project deliverables will be obtained.
•The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.
•5.1.3.2 REQUIREMENTS MANAGEMENT PLAN
•The requirements management plan is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed. Components of the requirements management plan can include but are not limited to:
•How requirements activities will be planned, tracked, and reported;
•Configuration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes;
•Requirements prioritization process;
•Metrics that will be used and the rationale for using them; and
•Traceability structure that reflects the requirement attributes captured on the traceability matrix.

Loading…

•5.2 COLLECT REQUIREMENTS
•Collect Requirements is the process of determining, documenting, and managing stakeholder needs and requirements to meet objectives. The key benefit of this process is that it provides the basis for defining the product scope and project scope.

•5.2.1 COLLECT REQUIREMENTS: INPUTS
•BUSINESS DOCUMENTS: A business document that can influence the Collect Requirements process is the business case, which can describe required, desired, and optional criteria for meeting the business needs.
•AGREEMENTS: Agreements can contain project and product requirements

•5.2.2 COLLECT REQUIREMENTS: TOOLS AND TECHNIQUES
•5.2.2.2 DATA GATHERING:
•1. Brainstorming: Brainstorming is a technique used to generate and collect multiple ideas related to project and product requirements.
•2. Interviews: An interview is a formal or informal approach to elicit information from stakeholders by talking to them directly. It is typically performed by asking prepared and spontaneous questions and recording the responses. Interviews are often conducted on an individual basis between an interviewer and an interviewee, but may involve multiple interviewers and/or multiple interviewees. Interviewing experienced project participants, sponsors, other executives, and subject matter experts can aid in identifying and defining the features and functions of the desired product deliverables. Interviews are also useful for obtaining confidential information.
•3. Focus groups: Focus groups bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion designed to be more conversational than a one-on-one interview.
•4. Questionnaires and surveys: Questionnaires and surveys are written sets of questions designed to quickly accumulate information from a large number of respondents. Questionnaires and/or surveys are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis could be appropriate.
•5. Benchmarking: Benchmarking involves comparing actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during benchmarking can be internal or external.

•5.2.2.4 DECISION MAKING
•Decision-making techniques that can be used in the Collect Requirements process include but are not limited to:
•Voting. Voting is a collective decision-making technique and an assessment process having multiple alternatives with an expected outcome in the form of future actions. These techniques can be used to generate, classify, and
•prioritize product requirements. Examples of voting techniques include:
•Unanimity. A decision that is reached whereby everyone agrees on a single course of action.
•Majority. A decision that is reached with support obtained from more than 50% of the members of the group. Having a group size with an uneven number of participants can ensure that a decision will be reached, rather than resulting in a tie.
•Plurality. A decision that is reached whereby the largest block in a group decides, even if a majority is not achieved. This method is generally used when the number of options nominated is more than two.
•Autocratic decision making. In this method, one individual takes responsibility for making the decision for the group.
•Multicriteria decision analysis. A technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.

•5.2.2.5 DATA REPRESENTATION
•Data representation techniques that can be used for this process include but are not limited to:
•Affinity diagrams: Affinity diagrams allow large numbers of ideas to be classified into groups for review and analysis.
•Mind mapping: Mind mapping consolidates ideas created through individual brainstorming sessions into a single map to reflect commonality and differences in understanding and to generate new ideas.

•5.2.2.6 INTERPERSONAL AND TEAM SKILLS
•1. Nominal group technique: The nominal group technique enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization. The nominal group technique is a structured form of brainstorming consisting of four steps:
•A question or problem is posed to the group. Each person silently generates and writes down their ideas.
•The moderator writes down the ideas on a flip chart until all ideas are recorded.
•Each recorded idea is discussed until all group members have a clear understanding.
•Individuals vote privately to prioritize the ideas, usually using a scale of 1 – 5, with 1 being the lowest and 5 being the highest. Voting may take place in many rounds to reduce and focus in on ideas. After each round, the votes are tallied and the highest scoring ideas are selected.
•2. Observation/conversation: Observation and conversation provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people who use the product have difficulty or are reluctant to articulate their requirements. Observation is also known as “job shadowing.” It is usually done externally by an observer viewing a business expert performing a job. It can also be done by a “participant observer” who actually performs a process or procedure to experience how it is done to uncover hidden requirements.
•3. Facilitation: is used with focused sessions that bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.

•5.2.2.7 CONTEXT DIAGRAM
•The context diagram is an example of a scope model. Context diagrams visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it (see Figure 5-6). Context diagrams show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.

Loading…

•5.2.2.8 PROTOTYPES
•Prototyping is a method of obtaining early feedback on requirements by providing a model of the expected product before actually building it. Examples of prototypes are small-scale products, computer generated 2D and 3D models, mock-ups, or simulations. Prototypes allow stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements. Prototypes support the concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision. When enough feedback cycles have been performed, the requirements obtained from the prototype are sufficiently complete to move to a design or build phase.

•5.2.3 COLLECT REQUIREMENTS: OUTPUTS
•5.2.3.1 REQUIREMENTS DOCUMENTATION
•Requirements documentation describes how individual requirements meet the business need for the project. Requirements can be grouped into classifications allowing for further refinement and detail as the requirements are elaborated. These classifications include:
•Business requirements. These describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.
•Stakeholder requirements. These describe needs of a stakeholder or stakeholder group.
•Solution requirements. These describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements:
•Functional requirements. Functional requirements describe the behaviors of the product. Examples include actions, processes, data, and interactions that the product should execute.
•Nonfunctional requirements. Nonfunctional requirements supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
•Transition and readiness requirements. These describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the desired future state.
•Project requirements. These describe the actions, processes, or other conditions the project needs to meet. Examples include milestone dates, contractual obligations, constraints, etc.
•Quality requirements. These capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements. Examples include tests, certifications, validations, etc.

•5.2.3.2 REQUIREMENTS TRACEABILITY MATRIX
•The requirements traceability matrix is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a requirements traceability matrix helps ensure that each requirement adds business value by linking it to the business and project objectives.

•5.3 DEFINE SCOPE
•Define Scope is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries and acceptance criteria.

•5.3.3 DEFINE SCOPE: OUTPUTS
•5.3.3.1 PROJECT SCOPE STATEMENT
•The project scope statement is the description of the project scope, major deliverables, assumptions, and constraints. The project scope statement documents the entire scope, including project and product scope. It describes the project’s deliverables in detail.
•The detailed project scope statement, either directly or by reference to other documents, includes the following:
•Product scope description. Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation.
•Deliverables. Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables also include ancillary results, such as project management reports and documentation. These deliverables may be described at a summary level or in great detail.
•Acceptance criteria. A set of conditions that is required to be met before deliverables are accepted.
•Project exclusions. Identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps manage stakeholders’ expectations and can reduce scope creep.

•5.4 CREATE WBS
•Create WBS is the process of subdividing project deliverables and project work into smaller, more manageable components. The key benefit of this process is that it provides a framework of what has to be delivered.
•The WBS is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement.
•The planned work is contained within the lowest level of WBS components, which are called work packages. A work package can be used to group the activities where work is scheduled and estimated, monitored, and controlled.

•5.4.2 CREATE WBS: TOOLS AND TECHNIQUES
•5.4.2.2 DECOMPOSITION
•Decomposition is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of decomposition is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project. Decomposition of the total project work into work packages generally involves the following activities:
•Identifying and analyzing the deliverables and related work,
•Structuring and organizing the WBS,
•Decomposing the upper WBS levels into lower-level detailed components,
•Developing and assigning identification codes to the WBS components, and
•Verifying that the degree of decomposition of the deliverables is appropriate.

•The WBS structure can be represented in a number of forms, such as:
•Using phases of the project life cycle as the second level of decomposition, with the product and project deliverables inserted at the third level, as shown in Figure 5-13;
•Using major deliverables as the second level of decomposition, as shown in Figure 5-14; and
•Incorporating subcomponents that may be developed by organizations outside the project team, such as contracted work. The seller then develops the supporting contract WBS as part of the contracted work.

•5.4.3 CREATE WBS: OUTPUTS
•5.4.3.1 SCOPE BASELINE
•The scope baseline is the approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan. Components of the scope baseline include:
•Project scope statement.
•WBS.
•Work package. The lowest level of the WBS is a work package with a unique identifier. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of accounts. Each work package is part of a control account. A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, though each work package is associated with a single control account.
•Planning package. A control account may include one or more planning packages. A planning package is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.
•WBS dictionary. The WBS dictionary is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The WBS dictionary is a document that supports the WBS. Most of the information included in the WBS dictionary is created by other processes and added to this document at a later stage. Information in the WBS dictionary may include but is not limited to:
•Code of account identifier,
•Description of work,
•Assumptions and constraints,
•Responsible organization,
•Schedule milestones,
•Associated schedule activities,
•Resources required,
•Cost estimates,
•Quality requirements,
•Acceptance criteria,
•Technical references, and
•Agreement information.

•5.5 VALIDATE SCOPE
•Validate Scope is the process of formalizing acceptance of the completed project deliverables. The key benefit of this process is that it brings objectivity to the acceptance process and increases the probability of final product, service, or result acceptance by validating each deliverable.

•5.5.2 VALIDATE SCOPE: TOOLS AND TECHNIQUES
•5.5.2.1 INSPECTION
•Inspection includes activities such as measuring, examining, and validating to determine whether work and deliverables meet requirements and product acceptance criteria. Inspections are sometimes called reviews, product reviews, and walkthroughs. In some application areas, these different terms have unique and specific meanings.

•5.6 CONTROL SCOPE
•Control Scope is the process of monitoring the status of the project and product scope and managing changes to the scope baseline. The key benefit of this process is that the scope baseline is maintained throughout the project.