【Advanced Items】Project overall management, scope management and progress management (top ten management)

【Advanced】Project overall management and scope management

Article directory

insert image description here

1. Overall project management

1.1 Process of overall management

Summary table of processes, inputs, outputs, tools and techniques for overall management:

Overall project management is the process of identifying, defining, integrating, unifying and coordinating the different processes and activities in the project management process group. Overall Management is responsible for managing the requirements, scope, schedule, cost, quality, human resources, communication, risk and procurement of the project ; Cost) People (Human Resources, Stakeholders) Style (Risk) Procurement (Procurement).
There are mainly the following six processes : (Master)
(1) Formulate project charter: the process of writing a formal document, which is the project charter . By issuing the project schedule, the project is formally approved and the project manager is authorized to use organizational resources in project activities.
(2) Develop project management plan: the process of defining, preparing and coordinating all sub-plans , and integrating them into a comprehensive project management plan. Item H management plan includes integrated project vision and sub-plans.
(3) Direct and manage project work: lead and execute the work determined in the project H management plan to achieve project H objectives , and implement the process of approved changes.
(4) Monitor project work: The process of tracking, reviewing, and reporting project progress to achieve the performance objectives identified in the project management plan.
(5) Implement overall change control: the process of reviewing all change requests , approving change management changes to deliverables, organizational process assets, project documents, and project management plans, and communicating the results of change processing.
(6) Close project or phase: Complete all activities of all project management process groups to formally close the process of Item H or phase.

1.2 Developing the project charter (initiation)

What is a project charter?

l. Item H Charter is the document that formally approves the project.
Since the project charter authorizes the project manager to use the organization's resources in project activities , the project manager should be appointed at any time before planning begins, preferably when the project charter is developed.
2. The charter of Item H is issued by the project implementation organization . After the charter is issued by the project, the connection between the project and the daily work of the organization is established. (Master) Do remember that it was not released by the project manager .
3. Contents of the project charter :
@Project purpose or reason for approving the project @Measurable project
goals and related success criteria Question 簦＠Project approval requirements ＠Appointed project manager and its responsibilities and powers. The name and authority of the @丨 sponsor or other person approving the project charter.

How to develop a project charter?

Developing a project charter is the development of a document that formally approves a project or phase ; approval of the project charter marks the formal launch of the project . In a project, the project manager should be identified and appointed as early as possible. Since the project charter will authorize the project manager to use organizational resources in project activities, the project manager should participate in the development of the project charter.
The project charter is approved by someone outside the project , such as the sponsor, the project management office, or the portfolio steering committee.
The project initiator or initiator should have certain authority and be able to provide funds for the project. They prepare the project charter themselves, or authorize the project manager to prepare it for them. The project charter is signed by the initiator, which marks the approval of the project . By developing a project charter, you can link the project to the organization's strategy and day-to-day operations
The statement of work is a text description of the product or service provided by the corresponding project.
For item H, the sponsor or sponsor provides a statement of work based on business needs, product or service requirements. For thousands of places, the statement of work is part of the customer's bidding documents, such as a part of the invitation for proposal, request for information, invitation to bid or contract.
The statement of work refers to the content: ＠Business requirements, ＠Product scope statement, ＠Strategic plan
Business environment factors : [Pay attention to the distinction between organizational process assets, also called enterprise environment factors, which are beyond the control of the project manager and cannot be tailored. General sources outside the organization]
(1) The culture and composition of the organization or company.
( 2 ) Government or industry standards (such as the rules and regulations of management departments, product standards, quality standards and process standards).
(3) Infrastructure (such as existing software and hardware infrastructure).
(4) Existing human resources (eg skills, expertise and knowledge; eg design, development, legal, contracting and procurement).
(5) Personnel management (such as hiring and firing guidelines, employee performance evaluation and training records).
(6) The company's work approval system.
(7) Market conditions.
( 8 ) Risk tolerance of project stakeholders.
(9) Commercial databases (such as standard cost estimation data, industry risk research information and risk databases).
( 10 ) Project management information system
Organizational Process Assets:
(1) Processes and Procedures : Organizational Standards; @Standard Guidelines, Templates, Work Instructions; @Revised Guidelines for Standard Processes to Meet Project Specific Needs; @Organizational Communication Requirements, Reporting System ; ＠Project Closing Guidelines or Requirements; ＠Financial Control Procedures; ＠Problem and Defect
Management Procedures; ＠Change Control Procedures; ＠Risk Control Procedures ; @Process measurement database; @Experience learning system; @Problem and defect management database; @Configuration management knowledge base; @Financial database.
Distinguish between business environment factors and organizational process assets :
＠Those that can be tailored and selected are organizational process assets; those that cannot be selected and can only be adapted are business environment factors
＠Those with systems are generally business environment factors ( For example: work authorization system, project management information system)
@Those with procedures are generally organizational process assets (for example: financial control procedures, change control procedures, risk control procedures)
Financial Aspects
Three main project financial value evaluation methods include net present value analysis, investment income and return on investment analysis . - The calculation of 3 methods must be mastered.
( 1 ) Analysis of net present value (57 on 18)
( 2 ) Analysis of return on investment: ROI is the value obtained by dividing the net income by the investment amount. The bigger the ROI, the better. ROI= (total discounted income - total discounted cost) / discounted cost (18 under 31)
( 3 ) Analysis of investment recovery period - static and dynamic investment recovery period must be calculated
The project kick-off meeting
is organized and held by the project manager. The main purpose of holding the project kick-off meeting is to make the main stakeholders of the project clear the project's goals, scope, needs, background and their respective responsibilities and authorities
Generally speaking, the goal must be quantified and measurable . Project H has the following characteristics:
the goals of the project have different priorities; @project goals have a hierarchy (mastery) and the difference between project characteristics.
When formulating some goals to measure the pros and cons or efficiency of project management, or as a means of motivating project team members, the following points must be paid attention to: (1)
Separate the achievement goal from the constraint goal.
(2) Distinguish between ends and means.
( 3 ) Do not formulate H standards that cannot be quantified or achieved.
(4) Do not divert the efforts of project managers.
Facilitation Techniques : Brainstorming, conflict resolution, problem solving, and meeting management are key techniques that facilitators can use to help teams and individuals complete project activities.

1.3 Develop a project management plan (planning)

What is a project management plan?

The project management plan generally includes:
project scope management plan, schedule management plan, cost management plan, quality management plan, process improvement plan, staffing management plan, communication management plan, risk management plan, procurement management plan and other sub-plans. The project management plan can be detailed, and can be composed of one or more partial plans, as well as other items . The level of detail of each subprogramme and other components is tailored to meet the needs of specific projects .
Other components can include these: milestone lists, resource calendars, schedule baselines, cost baselines, quality baselines, risk registers, etc. (master)
The project management plan records the overall output of each planning sub-process
of the planning process group @ the implementation level of each selected process.
@ A description of the tools and techniques used to implement these processes.
@ Ways and means of using selected processes in managing specific projects, including dependencies and interactions between processes, as well as important evidence and results.
＠The method and method of the work performed in order to achieve the goal of Item H;
＠The method and method of monitoring changes.
@ Ways and methods to implement configuration management.
＠Using the way and method of implementing the effect measurement benchmark and keeping it complete.
＠Communication needs and technologies among project stakeholders. Circle selected project lifecycle and project phases for multi-stage projects.
@Critical review of content, scope, and timing by top management to expedite resolution of outstanding issues and address outstanding decisions.
The difference between the project , the plan includes 13+3 sub-plans

How to develop a project management plan?

When the project H management plan was formulated for the first time , the information in all aspects of Shanqian was not very clear, so the project manager only had to grasp the main management ideas of the project from a macro perspective , and remember to update the project management plan through the overall change control process. Revise.
Complementary principles: participation of all stakeholders (full participation); progressive precision (iterative)
A change control system is the entirety of the formally documented process used to determine the ways and means by which project deliverables and documents are controlled, changed and approved
. A change control system is a subsystem of a configuration management system.

1.4 Direct and manage project execution (execution)

l. Approved change requests may be corrective actions, preventive actions, or defect remediation. include:

♦ ©Corrective measures: make the expected results of project implementation always meet the requirements of the project management plan (for
deviations that have actually occurred);
♦ @Precautionary measures: reduce the possibility of potential negative consequences (for possible deviations in the future);
♦ @ Defect Remediation: Correct product defects found in the quality process (products or product components, defect remedial measures are only for project
quality issues).

2. The project manager's power includes three aspects : authority, influence and knowledge .

(1) Authorities are those held by project managers due to their position in the organization . The extent to which the authority is recognized by others is limited, and
the influence on the behavior of others is generally not great.
(2) Influencing influence is based on personal knowledge, experience, personality and charisma . Project managers can use this
kind of power to influence people who are not directly involved in the project but want to cooperate with them.
( 3 ) Knowledge is more important. "Without investigation, there is no right to speak." A comprehensive, timely and accurate grasp of all
aspects of project H (or information) is the basis for judging, making decisions and guiding project work. I

1.5 Monitor Project Work and Implement Integrated Change Control (Monitoring)

Implement Integrated Change Control

l. The overall change control process runs through the whole project. Rarely are Shanqian projects carried out exactly according to the project management plan, so change control is essential. (master)
Many times, the overall change control process includes a change control board responsible for approving or rejecting change requests. Change requests are reviewed and evaluated by the project manager and approved or rejected by the CCB.
2. Configuration management activities include: @configuration identification; @configuration status record; @configuration verification and audit

1.6 Closing a project or phase (closing)

l. Closing a project or phase is the process of completing all activities of all project management process groups to formally end the project or phase
. The main effect of this process is to draw lessons learned, formally close project work, and free organizational resources for new work.
2. At the end of the project, the project manager needs to review the closing information of the previous stages to ensure that all items H have been completed and the project objectives have been achieved. If the project is terminated early before completion, the Close Project or Phase process also requires procedures to investigate and document the reasons for the early termination. To achieve the above objectives, the project manager should invite all appropriate stakeholders to participate in this process. ( master)

Contents of Project Closure: Management Closure, Contract Closure

(1) Management closing: Do a good job of document classification, declare to the outside that the project has ended and can be transferred to the maintenance period, and summarize the experience and
lessons. (2) Contract closing: formal acceptance, product acceptance, according to the contract, the project team and the owner will check to check whether all the requirements of the contract have been completed and whether the project can be completed;
Acceptance stage work content: acceptance test, system trial operation, system document acceptance and project final inspection : system inspection
For 5 system integration projects, the documents involved should include:
① system integration project introduction, ② system integration project final report, ③ information system instruction manual, ④ information system maintenance manual, ⑤ software and hardware product manual, quality assurance certificate

2. Project scope management

2.1 What is scope management?

The management of the project scope is realized through six management processes:
(1) Planning scope management: describe the process of how to define, confirm and control the project scope.
(2) Gather requirements: In order to achieve the goal of item H, the process of clarifying and recording the relevant requirements of project stakeholders.
(3) Define the scope: describe the product scope and project scope in detail, and prepare the project scope statement as the basis for future project decisions.
(4) Create WBS: Decompose the entire project H work into smaller, easy-to-manage components to form a top-down decomposition structure.
(5) Scope of Confirmation: Formal acceptance of completed deliverables.
(6) Scope control: monitor the scope status of projects and products, and manage scope baseline changes.

The concept of project scope management

1. Project scope management needs to do the following three aspects of work :
1. Clear project boundaries, 2. Monitor project execution, 3. Prevent project scope from spreading.
2. Product scope and project scope :
(1) The product scope refers to the functions that the product or service should contain, and the project scope refers to the work that the project must do in order to be able to deliver the product.
(2) The product scope is the basis of the project scope . The definition of the product scope is the description of the product requirements, and the definition of the project scope is the basis for generating the project management plan . There are differences in the application of the two scopes.
3) The scope baseline of the project is the approved project scope statement, WBS and WBS code . Judging whether the project scope is complete or not is measured against the scope benchmarks. The completion of the product range is judged according to whether the product meets the product description .
(4) The product scope description is an important part of the project scope statement. Therefore, after the product scope is changed, the scope of the project is first affected

2.2 How to manage project scope? (planning)

1. Planning scope management

l. Prepare a scope management plan , describe in writing the process of how to define, confirm and control the scope of the project , and provide guidance and direction on how to manage the scope throughout the project. The scope management plan requires the participation of all members of the project management team. (master)
2. The content of the scope management plan: how to formulate the project scope statement .
＠How to create WBS according to the scope statement.
＠How to maintain and approve WBS.
@ How to confirm and formally accept the completed project H deliverables.
＠How to deal with the change of the project scope statement, this work is directly related to the implementation of the overall change control process.
For example, the preparation guidelines for WBS may include (but not limited to) the following content:
(1) Determine that WBS meets the requirements of functions and projects, including replacement and non-replacement costs.
(2) Check whether the WBS provides a logical breakdown for all item H work.
( 3 ) Guarantee that the total cost of each specific layer is equal to the sum of the cost of the constituent elements of the next layer.
(4) Examine the WBS from the point of view of overall adaptation and continuity.
( 5 ) All job responsibilities need to be assigned to individuals or organizational units.
3. The scope management plan describes how to manage the project scope , how the scope of item H can be changed to be consistent with the project requirements, etc., so it should also evaluate the expected stability of the project scope such as how to change, how often to change, and how much to change . The scope management plan should also include a clear description of how the scope of the change will be determined and what category the change should fall into.
The project scope management plan may be included in the project management plan or may be a separate item . Depending on the project, it may be detailed or general, formal or informal. .
If there is no scope management plan, the project team will lack an action guideline when faced with problems arising from scope management, such as "unexpected" situations such as changes in requirements and errors in design. The scope management plan is a guide for project scope management.
4. Requirements management runs through the entire process, and its most basic task is to clarify requirements and make the project team and users reach a consensus, that is, establish a requirements baseline. In addition, it is necessary to establish a chain of requirements tracking capabilities to ensure that all user requirements are correctly applied, and when the requirements change, the scope of influence can be completely controlled, and the consistency of products and requirements can always be maintained. (Master)
5. The requirements management plan describes how to analyze, record and manage requirements throughout the project life cycle
6. Contents of the requirements management plan:
how to plan, track and report various requirements activities, resources needed for requirements management, ＠Training plan, ＠Strategies for involving thousands of people in requirements management, ＠Criteria and corrective procedures for judging the inconsistency between project scope and requirements, ＠Requirement tracking structure, ＠Configuration management activities (mastery)
7. Only requirements that are clear (measurable and testable), traceable, complete, coordinated, and willing to be recognized by key stakeholders can be used as benchmarks,

2. Collect requirements

Requirements include :
.•@Business Requirements: High-level needs of the entire organization.
.• @Stakeholder Requirements: Refers to the needs of stakeholders or stakeholder groups. ＠Solution Requirements
• ＠Transition Requirements: Temporary capabilities needed to transition from the current state to the future state, such as data conversion and training needs.
• @Project requirements: Actions, processes or other conditions to be met by the project.
• @Quality Requirements: Any conditions or criteria used to confirm the successful completion of project deliverables or the fulfillment of other project requirements. QFD subdivides quality requirements into basic requirements, expected requirements and unexpected requirements.
2. The tools and techniques for collecting requirements mainly include:
interviews, focus groups, guided seminars, group innovation techniques, group decision-making techniques, questionnaire surveys, observation, prototyping, benchmarking, system interaction diagrams, and file analysis
@Interview : Formal or informal methods of obtaining information through direct conversations with stakeholders are the most basic means of gathering requests ♦ @Focus Group : Bring together pre-selected stakeholders and subject matter Expectations and attitudes about the proposed product, service or outcome. A trained moderator leads an interactive discussion. Focus groups tend to be more intense than one-on-one interviews. It is a group interview rather than one-on-one and can involve 6-10 interviewees. Aiming at the questions raised by the interviewers, the interviewees carry out active discussions among the interviewees in order to obtain more valuable opinions. ♦ @Guided Seminar : Concentrated discussion and definition of product requirements. Workshops are an important technique for quickly defining cross-functional requirements and reconciling differences among thousands of stakeholders. Due to the characteristics of group interaction, effectively guided seminars help build trust, promote relationships, improve communication, and thus facilitate consensus among participants. ♦ @Group Innovation Technology : Refers to organizing some group activities to identify project and product requirements, including brainstorming, nominal group technology, Delphi technology, concept/mind map, affinity map and multi-criteria decision analysis, etc. (20 under 30) • Brainstorming method: share ideas and brainstorm ideas • Nominal group technique: Rank the most useful ideas by voting for further brainstorming or prioritization. It is a deepened application of the brainstorming method, and it is a more structured brainstorming method; ( 19 under 30) ( 21 under 30)

• Delphi technology: Anonymous or back-to-back methods are used to provide several rounds of feedback during the forecasting process, so that experts' opinions gradually converge, which helps to reduce data bias and prevent any individual from having an inappropriate influence on the results.
• Mind map, also known as mind map: connect the ideas obtained from brainstorming with a simple picture to reflect the commonalities and differences between these ideas, thereby leading to new ideas.
• Affinity diagram is also known as KJ method: It is to fully collect various language and text data such as experience, knowledge, ideas and opinions for a certain problem, summarize them graphically, and summarize and organize these data according to their mutual affinity , to make the problem clear, seek a unified understanding, and a method to solve it with benefits.
• Multi-criteria decision analysis: It is a technique to evaluate and rank many schemes by means of a decision matrix and using a systematic analysis method to establish various criteria such as risk level, uncertainty, and value benefit.
♦ @Group Decision-Making : Evaluate multiple future action plans in order to achieve a certain desired result. Group decision-making techniques can be used to develop product requirements, as well as to categorize and prioritize product requirements. The methods to achieve group decision-making are: @—unanimous agreement, @majority principle, @relative majority principle, @dictatorship—
@) unanimous agreement: everyone agrees to a certain course of action.
— @) Majority Principle: A decision can be made with the support of more than 50% of the people in the group.
— Constant) Relative majority principle: decisions are made based on the opinions of the relative majority in the group, even if it fails to obtain
the support of some people. This principle is usually used when there are more than two candidates, for example, there are 3 realization
schemes for the function of a certain software component (marked as A, B, C).
If 35% of the people agree with plan C and 25% agree with plan C, then plan A is finally decided.
— @) Dictatorship: A single person (eg, project manager) makes decisions for the group.
♦ @Benchmarking : Comparing actual or planned practices with those of other similar organizations (eg, processes, operating procedures, etc.)
in order to identify best practices, generate ideas for improvement, and provide a basis for performance measurement.
The outputs of the Gather Requirements process are the Requirements Document and the Requirements Traceability Matrix .
A requirements document describes how various individual requirements will satisfy the business requirements associated with the project . A requirements document can be a simple document listing all requirements by stakeholder and priority, or a detailed document including an executive summary, detailed description, and attachments.
The content of the requirements document includes: _Business requirements, @requirements of stakeholders, @solution requirements, @project requirements, @excessive requirements, @assumptions, dependencies and constraints related to requirements
Requirements management
includes all activities to maintain consistency and accuracy of requirements during product development, including controlling requirements baselines, keeping item H plans consistent with requirements, controlling versions of individual requirements and requirements documents, and managing links between requirements and linkage chains. Link, or manage, dependencies between individual requirements and other deliverables of the project, tracking the status of requirements in the baseline.
Traceability is the establishment and tracking of dependencies and logical connections between individual requirements and other elements. The requirements of each configuration item must have bidirectional traceability
to the requirements of its related products (or components) . The so-called two-way tracking includes forward tracking and reverse tracking: forward tracking refers to checking whether each requirement in Requirement 1 is found in the "Following" work section (results) to find the correspondence (to prevent the requirement from being missed, Doing bias) Reverse tracking is also called reverse tracking, which refers to checking whether the design documents, product components, test documents and other work results can find the source in the requirements file. (Check the source of the requirement to understand why this requirement is made, the source background and why)
Specifically, there are five types of requirements tracking , as shown in the figure, the arrow represents the relationship chain of requirements tracking capabilities, which can track the entire cycle of requirements usage, that is, the whole process from requirements proposal to delivery. (master)
Requirements Traceability Matrix The most common way to represent chains of linkages between requirements and other product elements is by using a requirements traceability (capability) matrix, which is a table that links product requirements from their sources to the deliverables that will satisfy them .

3. Define the scope

4. Create a Work Breakdown Structure (WBS)

l. A milestone marks the formal completion of a deliverable or phase . Important checkpoints are milestones, important milestones are baselines
2. Work packages should be easily and completely assigned to different people or organizational units . The work package should be very specific so that the undertaker is clear about his or her tasks, what to strive for, and the responsibilities to be assumed . As a rule of thumb, the 8/80 rule (the 80-hour rule) recommends that the size of the work package should take at least 8 hours to complete, and that the total completion time should not exceed 80 hours (mastery)
3. The control account is a management control point .
At this control point, scope, budget (resource plan), actual cost, and schedule are integrated and compared to earned value to measure performance.
The control account is an element at a certain level of WBS, which can be a work package or an element at a higher level than the work package . In the latter case, a control account includes several work packages, but a work package belongs to only one control account. Item H The management team assesses the implementation of item H on the control account, that is, under the corresponding elements of the control account, compares the project implementation with the plan to evaluate the implementation and discover and correct deviations.
4. The planning package refers to the WBS component under the control account, the work content is known but the detailed schedule activities are not yet available .
Planning packages are WBS elements below the control account and above the work packages. The planning package is temporarily used for planning. As the situation becomes clearer, the planning package will eventually be decomposed into work packages and corresponding specific activities.
5. The WBS dictionary includes account code identification , job descriptions, assumptions and constraints, responsible persons or organizational units, schedule milestones, related schedule activities, required resources, cost estimates, quality requirements, acceptance criteria, technical references, agreements information. (Master) ( The WBS dictionary is actually equivalent to the Xinhua dictionary, which is the description of each element in the WBS)
6. Decomposition is a technique for breaking down project deliverables and project work into smaller, more manageable components.
7. To decompose the entire project work into work packages, the following activities are usually required:
@Identify and analyze deliverables and related work.
@Determine the structure and layout of WBS.
＠Decomposition layer by layer from top to bottom.
@Develop and assign identification codes for WBS components.
@ Verify that the degree of decomposition of deliverables is appropriate.
8. The principles of work division when creating a WBS include:
@Functional or technical principles: When creating a WBS, it is necessary to consider separating the work of different personnel.
@Organizational structure: For a multi-functional project organization, WBS should also adapt to the organizational structure of the project
@System or subsystem: The overall system is divided into several main subsystems, and then the first subsystem is decomposed.
The method of WBS decomposition:
＠) The stages of the project life cycle are used as the second level of decomposition, and the products and project deliverables are placed on the third level
＠The main deliverables are used as the second level of decomposition
＠Integration may be done by someone other than the project team Various components implemented by the organization (for example, outsourcing work), and then as
part of the outsourcing work, the seller needs to prepare the corresponding contract WBS
WBS is not the responsibility of a project team member, it should be completed and unanimously confirmed by all project team members, users and project stakeholders
). WBS li!t of the tree structure diagram: :me, zhiru and jieyeguai, but it is not easy to repair, and it is difficult to show the whole picture of the project (small project) for large, , ^, and hengme. The intuitiveness of the table form is relatively poor, but it can reflect all the work elements of the project
WBS decomposition pays attention to 8 aspects :
@WBS must be deliverable-oriented: the sum of all lower-level elements must represent 100% of the upper-level elements.
@WBS must fit within the scope of the project. The WBS must include, and only include, the activities required to complete the project's deliverables.
The bottom layer of the WBS should support planning and control. WBS is the bridge between the project management plan and the project scope.
The bottom layer of WBS not only supports the project management plan, but also enables the management to monitor and control the project schedule and budget.
Elements in @WBS must be owned by one and only one person, although in reality there may be more than one person involved.
According to the guidance of @WBS, WBS should be controlled within Danbi~ o Of course, large projects can have more than 6 layers.
@WBS should include project management work (since management is part of the project specific work) as well as subcontracted work.
The development of a @WBS requires the participation of all (primary) project stakeholders, including project team members.
@WBS is not set in stone. In the work after the WBS is completed, it may still be necessary to modify the WBS.
When the WBS decomposition of a project is completed, the project department should confirm the completed WBS and reach a consensus on it. The purpose and use of WBS are mainly reflected in the following eight aspects:
(1) Clearly and accurately describe the scope of the project, so that project H team members can clearly understand the nature of the task and the direction of efforts.
( 2 ) Clearly define the boundary of the project
( 3 ) Assign personnel to each independent unit, specify the responsibilities of these personnel, and determine the technical and human resources required to complete Item H.
( 4 ) Estimate the time, cost and resource demand for independent units to improve the accuracy of the estimation.
( 5 ) Lay a common foundation for plan, budget, schedule arrangement and cost control, and determine the benchmark of project progress and control.
( 6 ) Link the item H work with the financial accounts of the project.
(7) Determine the work content and work order, decompose the project into specific work tasks, and implement item H according to the logical order of work tasks.
(8) Helps prevent demand creep.

2.3 Scope of validation and control (monitoring)

5. Confirm the scope

l. Confirming the scope is the process of formally accepting the completed deliverables of the project . This includes reviewing the deliverables with the client or sponsor to ensure that they have been satisfactorily completed and formally accepted by the client or sponsor. ( learn)
2. The main tools and techniques for confirming scope are inspection and group decision-making techniques .
Inspection, also known as review, review, audit, walkthrough, inspection, test, etc., refers to activities such as measurement, review, and confirmation to determine whether the work and deliverables meet the requirements and product acceptance criteria. (master)
3. Confirm the scope should run through the project from beginning to end.
4. General steps to confirm the scope: Determine when the scope confirmation needs to be carried out ＠Identify what inputs are required for the scope confirmation ＠Determine the criteria and elements for the formal acceptance of the scope ＠Determine the organizational steps of the scope confirmation meeting ＠Organize the scope confirmation meeting
Stakeholder Concerns: (Master)
(1) Management: The scope of the project concerned refers to the impact of the scope on the progress, funds and resources of the project. rationality. (20 under 31) (21 under 31) l
(2) Customers: they are concerned about the scope of the product, and whether the deliverables of item H are sufficient to complete the product or service. {2 1 on 31)
(3) Project managers: focus on whether the deliverables are sufficient and must be completed, whether time, funds and resources are sufficient, major potential risks and preparatory solutions.
( 4 ) Project team members: care about the elements they participate in and responsible elements in the project scope, check whether their working hours are sufficient by defining the time in the scope, whether they have multiple jobs in the scope of project H, and these jobs are where there is conflict
6. In projects, customers and project team members often have the willingness to add all functions and features in the current version, which is a potential risk for thousands of projects and will bring harm and loss to the organization and customers. If there are omissions or errors in the project scope statement and WBS found in the work of confirming the scope, it is necessary to clearly point out the wrong content to the project team and give suggestions for correction. The project team needs to revise the project scope statement and WBS according to the revised opinions. Scope change requests may also appear during the scope confirmation process. If these scope change requests are approved, the project scope statement and WBS will also be revised.
7. The verification of the product is aimed at whether the product is completed. At the end of the project (or phase), the initiator or customer will verify it, emphasizing whether the product is complete; the confirmation scope is aimed at the project deliverables, and the customer or the initiator will confirm in the dirty section acceptance process.
The difference between the scope of validation and quality control is
: (1) The scope of validation mainly emphasizes that the deliverables are accepted by the customer or sponsor; standard).
( 2 ) Quality control is generally carried out before the scope is confirmed, and it can also be carried out at the same time; the scope of confirmation is carried out at the end of the stage, and quality control is not necessarily carried out at the end of the stage.
( 3 ) Quality control is an internal inspection, which is carried out by the corresponding quality department of the executive organization; the scope of confirmation is the inspection and acceptance of the project deliverables by external stakeholders (customers or sponsors).
The difference between confirming the scope and project closing is :
(1) Although both confirming the scope and project closing work are not carried out in the stage, but confirming the scope emphasizes on verifying and accepting the deliverables
, while project closing emphasizes on ending the project (or stage) the process work to be done.
( 2 ) Both the scope of confirmation and the end of the project have acceptance work, the scope of confirmation emphasizes the acceptance of project deliverables, and the end of the project emphasizes the acceptance of products.

6. Range of control

Controlling scope is the process of monitoring the scope status of projects and products, managing changes to the scope baseline , and its main role is to maintain the scope baseline throughout the project.
Controlling the scope of the project must ensure that all requested changes, recommended corrective actions, or preventive actions are addressed by the Implement Integrated Change Control process. When changes actually occur, the scope control process is also used to manage these changes.
The main reason for the change of the project scope is that the external environment of Project H has changed, for example: (Understanding)
(1) Government policy issues.
( 2 ) The planning of the project scope is not thorough and detailed, and there are certain errors or omissions.
(3) A new technology, new method or new scheme appears in the market or the designer puts forward.
(4) The project implementation organization itself changes.
(5) The customer's requirements for item H, project products or services change
Uncontrolled expansion of product or project scope (without adjustments for time, cost, and resources) is called scope creep. [Customers keep asking and changing, and the final deliverables do not meet the requirements!
Gold plating: project implementers are often willing to try new technologies or add to information system projects] Change is inevitable, and the control scope process depends on scope change control System, scope change control refers to the process of controlling and approving changes to the scope of the project, including written documents, tracking systems, and approval levels necessary to authorize changes
The work of scope change control:
(1) Affect the factors that lead to scope changes, and try to make these factors develop in a favorable direction.
( 2 ) Determine whether a scope change has occurred.
( 3 ) Manage actual changes when scope changes occur, and ensure that all requested changes are handled in accordance with the project's overall change control process

3. Progress management (time management)

Schedule Management is the 7th course at 667-4343-644. This is the process of establishing a management schedule, including planning, defining activities, sequencing, estimating resources, estimating duration, establishing schedules, and controlling schedules.

3.1 Planning Progress Management (Planning)

Combined with the project management plan, look at the plans and approval requirements set by the high-level executives in the palm process , specify the various processes of project time management, methods and tools for planning progress , and determine the format and guidelines.

3.2 Define activities (planning)

Split activities and milestones on scope baselines. It is to define exactly what to do .
Find the WBS first, and in [Scope Benchmarks], remember to need the scope benchmarks. It’s not enough to have something as thick as the scope specification. Each specific activity (activity list], the more specific the better, each small activity should not be too complicated, otherwise continue to divide, and finally add a description to each activity (activity attribute], and then set a checkpoint ( Milestone list], the things to do now are very specific.
Tools and techniques: expert judgment, analysis of alternatives, published estimate data, bottom-up estimation

3.3 Sequence activities (planning)

If the activities have priority, they need to be prioritized. It is easiest to arrange the [Activity List into [Activity Attributes] and [Milestone List] just now, because different products have different characteristics, and consider soft logic and hard logic. (For example, to build a house, the field must be cultivated first), so let him read the [scope specification]
After understanding it, I started to arrange the order. How to arrange it? Use (Progress Network Diagram) to arrange, draw circles, fill in the name of the activity, and use arrows to connect. It is conceivable that there are more activities, and the drawing is like a spider web (Progress Network Diagram) 】.
Tools and Techniques: Sequential Mapping (FS/FF/SS/SF), Determining Dependencies, Leads and Lags

3.4 Estimating Activity Resources (Planning)

Determine how many people, and items (both can be procured) will be used for each activity. Refer to the resource calendar to tag activities with resources . Arranging the order of the relationship between activities requires you to know what things are about, but it is estimated that resources are not needed . Look at each specific thing itself [Activity List] [Activity Attributes] and you will know who will be assigned. Of course, check the [Resource Calendar] to confirm Do you have time? If you don’t have time, it’s fine.
You have to look up the output of "estimated cost" [activity cost estimate], and then look up [risk register], and finally compile a list, including who will do each activity and what will be used . This is ( activity Resource Requirements ], but also the allocated resource category (Resource Breakdown Structure RBS], which is very intuitive and easy to manage.
Tools and techniques: expert judgment, analysis of alternatives, published estimate data, bottom-up estimation

3.5 Estimating Activity Duration (Planning)

Refer to scope statements and resource calendars to mark resource needs. Determine how long each activity takes to do.
Still the same, find out the activity list and attribute table [Activity List Enter [Activity Attributes], for example, "Login Webpage Design" is designed by Zhang San, how is Zhang San's level, you have to go to [Resource Calendar] to see , it turns out that I am a junior engineer, so I should be able to do it slowly, so I will set a longer time, but it is indicated from the [Scope Statement] that this is very important. The estimated time is added after the attribute table (Estimated activity duration]
Tools and techniques: expert judgment, analogical estimation, parameter estimation, three-point estimation, group decision-making techniques (including consensus (Delphi technique), majority principle, relative majority principle, dictatorship), reserve analysis

3.6 Develop a schedule (planning)

Summarize all previous documents to determine the schedule.
Choose a tool and progress model (such as microsoft project and gantt chart), and start drawing the progress.
Enter all the things that have been worked out before, including [activity list into [activity attributes], [schedule network diagram into] [activity resource requirements into] [resource breakdown structure into] [resource calendar into] [activity duration estimation into] [project personnel assignment into] [Risk Register], and then check [Scope Statement] to see if there is anything that has not been taken into account, and if all of them are entered, you will get (Progress Plan), and an assessment document that is standardized from the progress plan is (Progress Specification], and at the same time Progress data, project calendars are also formed.
Tools and Techniques: Critical Path Method, Critical Chain Method, Resource Optimization Techniques: Resource Balancing and Resource Smoothing, Schedule Compression: Crashing and Fast Tracking

3.7 Control progress (monitoring)

Monitor the progress status of the project in real time, judge the status, and predict the progress according to the current actual situation to see if it can be carried out according to the plan.
This is the same as the scope of control. Comparing the [work performance data] and [schedule plan] and "progress benchmark" generated by the guidance and implementation work collected every day, you will know. Why can't you see the "progress benchmark", which is originally hidden in [Project management plan], finally get (work performance information], and propose amendments if problems are found (change request]
Tools and Techniques: Performance Review (Trend Analysis, Critical Path Method, Critical Chain, Earned Value Management), Resource Optimization Techniques: Resource Leveling and Resource Smoothing, Leads and Lags, Schedule Compression: Crashing and Tracking