Scope management of product project management system

As a product person, you need to keep yourself hungry, operations, data analysis, project management, etc., all need to be involved. the latest fascination with the study of project management, i will take my own current project management skills system, to make a simple sharing.

 the iron triangle of project management

before learning project management, first understand the famous iron triangle concept of project management, and the project iron triangle is relatively advanced in project management, and it needs to be considered first. the iron triangle has three very critical elements: scope, time, and cost. the three basic elements influence each other and are highly correlated.


for example:

• increased scope, either time increases or cost increases;
• shorten the time, either the scope is reduced, or the cost increases;
• costs shrink, either time increases or scope decreases;
• wait a minute...

these are all things that we will appear in real scenes, such as the leadership requirements of the scope is not moved, time, cost three items must be reduced, there will be a reduction in product quality. therefore, in the project management process, different choices will be decided, and it may be necessary to adjust the time or adjust the cost. so how to adjust the quality? it depends on customer satisfaction, in the case of customer satisfaction, to ensure that the quality of the project is as good as possible.

scope management

scope management is the top ten areas of our knowledge that need to be thought about before it is managed.

why manage the scope?

the scope of the project is not easy to control, and the scope of the project will change frequently, so many people often complain that "the plan cannot catch up with the change". in the actual work, it is often seen that the company's products are still under development, but the market, users, resources and other factors change from time to time, and even after the product is listed, the current users of the product are different from the target users originally set up, and the changes in these factors will lead to changes in project positioning, demand, direction and other elements. of course, project management is not just about telling you that "the plan can't keep up with the change".


then if you don't make a plan, you won't be out of the situation where "the plan can't catch up with the changes".


people who understand understand know that the more the plan cannot catch up with the changes, the more they must strengthen the formulation of the plan, and they should recognize that the greater the risk of not making a plan. then the premise of the plan, we must first clarify the scope of the project, what work should be done in the project process, and what should not be done. if you don't even know what to do and what not to do in the project from the beginning, then the probability of success of the project is very small.


therefore, the importance of project scope management lies in the fact that we are delineating the scope of our work content to ensure that our staff and people related to the project are doing things within this range, ensuring that the relevant personnel are doing things within the scope, and avoiding doing half a day of work that is not related to the project, which wastes everyone's time and wastes the company's resources.


project management is characterized by a very goal-oriented management model, it is originally temporary, is to complete a goal temporarily in the short term, only when we put all our attention and resources into the goal-related things can be the fastest and best to complete this goal, do not do other things that are not related to the goal.

1. collect demand

so where does the demand come from?

common sources of demand:

• in-house (boss/other departments)
• product manager (planning/mining)
• external (user/customer)
• in practical work, according to the project charter and the analysis of project stakeholders, we will find that the needs of bosses, relevant regulatory departments, and different functional departments account for the majority.

therefore, in the process of collecting requirements, we need to collect the needs of all stakeholders, and then analyze which requirements are feasible and which requirements are not feasible from these requirements, which is the first step in delineating the scope of the project.

a common way to collect requirements, qualitative to quantitative, is a process:



the four most common data analysis methods are user interviews, questionnaires, data analysis, and usability testing, this article mainly explains the project management system, and will not analyze each collection requirements method in detail.

2. scope of definition

when we have done a good job of collecting requirements, the next step is to define the scope of the project, and the scope of the project is to ensure what should be done and what should not be done.

when defining the scope, we need to analyze the requirements collected in the previous step, which needs are what we should do now, can do, what we can't do or do later, record it in black and white, we know that the demand does not prove our last workload, in fact, the problem of demand solution is what we have to deliver last. by identifying the list of requirements with all stakeholders, we can define well what we should do and what we should not do in the scope of the project.


in defining the scope of the project, we first have to figure out the products we want to deliver.

product structure - product decomposition

to split the entire product into sub-products, what work each sub-product has to do. define a product relative to defining each subproduct, so make a list of products. usually the product list will be composed of different modules, and the product list does not have a unique template. as shown in the following figure, the decomposition of the car.



for an it project, it is necessary to define a clear scope and explain what the product output and delivery are.


what exactly does it mean to produce a system? such as crm system, what is called crm system, behind the system is a collection.


when the crm system is delivered for decomposition, there may be software, hardware, user manuals, training courseware tutorials. the crm system of different enterprises will also be different, some of which have sales operation reports, some of which have user lists, and so on. therefore, each point can be decomposed layer by layer, so as not to fall things. in fact, i have encountered that the operation activity is about to go online, and then it is said that there is no warm-up; the product is online only to find the lack of product logs and so on.




therefore, the early product decomposition, the clearer the decomposition, the less things will fall. therefore, if you can't define the product to be delivered at the beginning, it will cause a lot of trouble later.


once you have a project breakdown, you want to define a project scope specification with:

• project scope description (which products we want to deliver)
• product acceptance criteria (acceptance criteria and acceptors)
• project deliverables
• exclusion of liability for the project (in which cases something is wrong and irresponsible, such as some hypothetical conditions that are uncontrollable, the person in charge is not responsible)
• project constraints
• constraints are states, characteristics, or feelings that are subject to a given act or omission. it can be from within or outside the project and can affect the performance of the project or process. constraints already exist objectively, and often restrict and constrain the scope, cost, schedule, time, resources and other aspects of the project.

for example, any restrictions or constraints imposed on the progress of a project that affect the scheduling of schedule activities are constraints on progress and are generally manifested as fixed mandatory dates. if the project is implemented under a contract, then the terms of the contract are also often a constraint.


just like the scale of china's automotive aftermarket has approached 967.6 billion yuan, but it is not compatible with the rapid growth of the vehicle market, and to a certain extent, it restricts the development of china's automotive industry, and the constraints are as follows: the overall quality of the market is not high, the market concentration is not high, the service level is low, the industry statistics are not in place, and the foreign-funded enterprises are expanding rapidly. that was the constraint of the project.

project assumptions

it is a concept of the future, that is, things have not yet happened, and no one knows what will happen. but in project management, you make assumptions about your current project, assume that something will affect your project, and then prepare in advance to reduce unnecessary losses. for example, if an outdoor activity is scheduled for saturday and there is a stormy weather on saturday, then in fact, you must prepare the roof and other things before the project starts.

3. CREATE A WBS (CORE)

1. CREATE A WORK BREAKDOWN STRUCTURE – WBS.

when we define the scope, we sort out what we want to deliver in the early stage, and then understand what we need to do, and understand what we want to do through the decomposition of work.

"
decomposition structure wbs, not only project management, can be used in other areas, when people find a thing very difficult to do and do not know how to do, often because everyone will be disorganized and mix irrelevant things with the core work and lead to difficult things. when everyone does not sort out the order of work and ideas, it separates the original called a job, the more it is decomposed, the clearer the content of the work, and when the work is decomposed to a certain age, the work can be implemented to the person responsible for the work. by breaking it down into different levels and different particle sizes, we can better shut down the work. therefore, it is difficult to manage the project without decomposing the structural work."

2. WHAT IS WBS?

a hierarchical decomposition of project work oriented toward deliverables.

• define the entire scope of the project, the finer the granularity of the scope, the better, so that there is no longer a need to go beyond the scope.
• break down project work into smaller, easy-to-manage multiple jobs. the difficulty of management usually depends on the complexity of the work to be managed, and the smaller the breakdown, the better it is to manage. it's like a person managing a whole bunch of things and a person managing one or two things, and the latter is certainly easier to manage.

the next level of each decomposition represents a more detailed definition of the project.
the finer the breakdown, the more you know about the project. it's like analyzing a requirement layer by layer to think of many other features that involve that requirement. so the more detailed the decomposition, the more we can analyze the understanding of user needs and implementation requirements again.

3. common decomposition dimensions

decomposition by stage: first divide the project work into different stages according to the life cycle, and then decompose what to do in each stage.


If you intend to iterate the development of a social product V4.0, the requirements collection stage> the detailed design stage> the construction development stage> the integration measures stage. At each stage, there is work that needs to be done. Benefits: You can see which deliverables should be completed at this stage, which is conducive to phased control.


broken down by outcome: his first layer is not in the phase dimension, but in different types of deliverables. then in order to complete a certain type of deliverable, i need to complete which decomposed deliverables. if we decompose the compatible equipment of the product, we can divide the basic compatible equipment, the special compatible equipment, and the refined level of the compatible equipment. benefits: it guarantees that we will not leave the deliverables behind, and the first layer that should be broken down for us is the type of deliverables.

4. work package

WHEN WE DO WBS, WHEN WE BREAK EVERYTHING DOWN TO THE BOTTOM, WE FORM A CONCEPT - WORK PACKAGE, ALSO CALLED WORK BREAKDOWN.

the purpose of defining a work package is to find the right person to take on the responsibility of completing this part of the work package.

when it's called the end, we can monitor the progress, estimate the cost and resources, and then we can package it into a work package. and when it comes to finding a suitable person to take on, then this thing can be called a work package.

5. WBS DECOMPOSITION

WBS DECOMPOSITION - THE MOST BASIC DISTAL SIDE


100% division principle, all work in the project must be wbs division, all project work is withdrawn in wbs, if there is an omission found in the later stage, there is no 100% division, even if it is beyond the scope of the project.



when decomposing to the level of the work package, someone must take on the responsibility, and the responsible person will decide the resources needed to complete the work.

• there can not be only one decomposition of each layer, it is common for one to decompose into multiple, and one decomposition is not a decomposition.
• to describe the status of qualified deliverables, especially after the product work package, the status of the work package should be clearly described so that the responsible person can clearly understand the status of the work package.

WBS - PRINCIPLES OF BEST PRACTICE NATURE

based on the deliverable and the desired state (the desired state refers to: the state of the development phase, the state of the testing phase...). ) to decompose.

focus on outputs rather than actions. output refers to the fact that each element decomposed by the wbs is preferably a noun, not an action. when we decompose wbs, the elements decomposed from each layer must be nouns, such as contracts, instructions, contract upload functions, contract approval functions; actions: create contract upload functions, create contract approval functions, and create a description of a business process. why should we pay attention to output, we should do the project focus on the output, not the action, the action is the process of the output, such as printing photos, photos are output, printing is action. some project managers break down a lot of actions, such as analyzing xx requirements, developing xx software, etc., all of which are in place, but the deliverables are left behind. what is important for us to do projects is to be able to produce outputs after the action. so the same is true for wbs decomposition, wbs we define a range, if we define a product, then in fact the goal of our definition is that we get a certain output to be completed.



each layer should not decompose more than 9, more than 9 are difficult to control, 3-7 are recommended.

each element can only designate one person in charge, especially in our country, and assigning it to multiple people is basically no one. the person in charge assigns some co-workers. when a burden falls on a few people, several people will feel that it is not their own business.


each layer level as far as possible to do 100% decomposition, and then decompose the next layer, common mistakes after decomposing a layer, seize a point to decompose deeply, and then decompose other layers, so it is easy to appear, after a line is decomposed, and then decompose another line with the same level of dimensions will be different.

6. WBS REPRESENTATIONS - HIERARCHY DIAGRAM AND ALIASED LIST

graphical expression: very intuitive, so that everyone can see the relationship between the levels at once, but it occupies a large area.
zigzag list: usually not intuitive, but can be displayed in a sheet of paper.

7. WBS DICTIONARY

when we sort out our main deliveries and work through wbs, we also need to build a wbs dictionary, which is a detailed description of the work and technical documents of each work breakdown structure element, and the document form is developed according to our own needs.

USUALLY THERE ARE 11 CONTENTS IN THE WBS DICTIONARY:

• Decomposing code: A project's WBS may break down thousands of different tasks, which can cause confusion if not coded. At the same time, coding can also help us identify the relationships of each decomposed task.
• job description: decomposed work description, such as the development of a certain function, what functions are mainly implemented in this development, including what is the development language? negative not responsible for testing? wait
• responsible for the organization: each decomposed task is assigned to the relevant person in charge and the responsible department.
• milestone list: identify several key milestones so we know where the task is progressing and whether progress is fast or slow.
• progress activity: progress needs to have a description.
• resources required: what resources are required.
• cost estimation: time cost, development cost, money cost, etc
• quality requirements: what degree is completed, to what extent is the test counted as passing, etc
• acceptance criteria: after each work is completed, who will accept and how to accept.
• references: some activities require reference to different documents, and you need to write out which documents to refer to.
• contract information: some projects need to be outsourced and relevant contracts need to be signed.

through the task activities after the wbs decomposition, if there is no such annotation and interpretation, it is easy to produce various annotations and misunderstandings, and different people's understanding of the annotations of the activities is not the same, so the wbs dictionary is produced to ensure that everyone's understanding of the annotations is consistent.

4. scope of verification

usually before the project is officially implemented, the baseline needs to be defined, and this baseline defines what work the project needs to complete to be completed. in the future, when the project evaluation and performance appraisal are carried out, the output project will be compared with the defined baseline and wbs dictionary to determine how much deviation there is. the greater the deviation, the more the project has deviated from the scope.



to verify whether the product is within the scope, first of all, through the [demand tracking matrix] to maintain customer contact, to determine that the product range has not changed, to ensure that the [requirements document] is up-to-date, use it to verify the scope of the "confirmed quality product" [confirmed deliverables], verify that there is no problem to accept the product; if there is a problem, submit a change request. note that in the verification and control process is still used requirements documents, rather than using scope specifications, because the scope specification is relatively rough compared to the requirements documents.

In the actual enterprise, the preliminary work is not so complicated, just list the key tasks and key activities in the project process and make a plan, but such a plan is inaccurate. Because in the usual sense, we need to break down the WBS to the bottom and find the right person before making a plan. The most feared thing is that the project WBS is not decomposed clearly and the task owner is not looking for it, so it will start to make a plan, which will lead to the implementation of the plan, and the process will always be adjusted, resulting in such a situation because the plan was not clear at the beginning.

• Failure to make the plan clear will also lead to easy misunderstandings between departments/members, for example, the understanding of the sales department and the understanding of the operation department are different, we often say that "there are a thousand Hamlets in the eyes of a thousand people" is in this truth.
• So in order to avoid the needs of the process being adjusted all the time, the plan is constantly adjusted, the project at the beginning of the WBS will be decomposed to the lowest level, decomposed clearly, and each decomposed work package or element can have an accurate definition, and the whole team can reach a consensus on this, the scope of the project will not be easily changed.

when the project is implemented, the project manager needs to check that the actual scope of work and the results of the actual output are consistent with the scope benchmark. scope verification is required, which is the process of formally accepting the completed deliverables of a project. in this process, the project manager has to organize the right person to accept, usually the project manager to accept the acceptance will be more risky, such as how to accept the code of the project manager who does not understand the code?

5. scope of control

deviation analysis

deviation analysis is a technique that determines the degree and cause of the difference between actual performance and benchmark, and can be used to assess the degree of deviation from the range benchmark from the project performance measurement results. used to control the causes and extent to which a project deviates from the scope benchmark and to determine whether corrective and preventive actions are required.



scope control is supervisory work, in the process of work, the work that should be done is not done, the work that should not be done is done, and the deviation is deviated from doing, so this stage needs to be analyzed by deviation. constantly compare, the actual work done now is not within the scope of the benchmark work, if there is an error with the range benchmark, then we should stop and make adjustments. the scope of common it projects is constantly changing, especially the business departments are not particularly clear about the deliverables of the project, they will constantly adjust the deliverables. if the deliverables proposed by the business unit are significantly different from the original deliverables, it is necessary to redefine the baseline and re-plan to avoid errors in results, costs, resources, etc. between the actual deliverables and the later adjustments.


so range control and range verification are not exactly the same, they are complementary states,

• participants: verify that the customer must participate, and the controlling customer does not have to participate
• time point: verify the completion point in the key stage, control the whole process of project execution
• contents: verification focuses only on the final deliverables, and controls the output of all executions
• scope verification and control scope are complementary, scope verification is concerned with the outcome, and control scope is concerned with the process.