We know that project requirements are the goal and basis for all project construction work. in the construction process, any point of adjustment will have a certain impact on the subsequent work progress, software quality and project cost, and the closer the time of adjustment to the end of the project, the greater the scope of adjustment, the greater the impact on the project.
Therefore, in order to reduce the impact of demand adjustment on project construction work, party a's project manager should make decisions and manage the formulation and change of requirements based on the actual situation of the project construction work and the definition of "completion" of the project, which is called project demand management.
For the project manager of party a, the project demand management work is mainly around the business needs, and its goals are mainly the following two aspects:
One is to ensure that the business needs can meet the needs of the project construction; the other is to control the scope and timing of the demand change to reduce the impact on the project construction work. in general, demand management work includes the following aspects: demand plan management, demand quality management, and requirements change management. among them, the demand change management work is the focus of party a's project manager in the requirements management work.
13.1. requirements plan management
requirements planning refers to the documentation plan formulated to ensure that the relevant work is traceable and manageable when preparing or adjusting the business requirements document, and the main content includes the preparation of relevant work items, completion dates and responsible persons. among them, the common work items are demand communication, demand confirmation, requirements writing, requirements review and other aspects.
when party a's project manager manages the demand plan, its work mainly includes the following two aspects: one is to ensure that the demand plan is reasonable and feasible, and at the same time to meet the requirements of the overall work plan; the other aspect is that party a's project manager must ensure that the project requirements preparation work can be carried out as planned through various project management means.
13.2. Demand quality management
in this article, the quality of requirements mainly refers to the judgment of the completion of the project requirements document from the aspects of readability, accuracy and completeness. typically, high-quality requirements have the following attributes: clear completion goals, intuitive business processes, clear functional descriptions, easy to understand text content, clear document structure, and reasonable use of diagrams. it should be noted here that the requirements document is the main way for party b's team to understand and master the project construction requirements, and its quality has a direct and non-negligible impact on the quality of software products and the progress of project construction. therefore, in order to ensure that the project requirements document can clearly, accurately and comprehensively convey the construction requirements to the team members of party b, the project manager of party a needs to manage the quality of the requirements accordingly.
According to the author's personal experience, when the project manager of party a manages the quality of requirements, he can start from the following three aspects: first, provide requirements templates. it can refer to the documents of other projects to prepare the requirements document template, so as to clarify the document structure and writing requirements, which is conducive to the preparation of high-quality documents by business personnel; the second is the explanation of requirements.
The requirements writer explains the content of the requirement to the relevant personnel and answers the questions that exist. the purpose of this is to determine whether the document can provide clear and accurate project construction information from the perspective of the requirements user; the third is the requirements review. party a's project manager organizes relevant business experts, colleagues, etc. to form a special review committee to review the requirements document from a professional point of view to ensure that its content can meet the requirements of the project construction.
13.3. requirements change management
a change in requirements is the process of adjusting a finalized business requirement for some reason, primarily for changes, cancellations, or additions to functional or non-functional requirements. in my experience, it usually occurs in the middle and late stages of a project. for party a's project manager, in order to avoid the risks of schedule, quality, cost and other aspects caused by changes in requirements, it is necessary to manage the scope and timing of demand changes based on the actual situation of project construction work and combined with the definition of "completion" of the project.
1. Risk of changes in requirements
we know that most of the work on project construction revolves around business requirements, so once the requirements change, there is a high probability that the reviewed implementation, product design or completed functions will be adjusted accordingly. these adjustments will not only add a lot of additional workload to the project construction work, but also have a considerable impact on the overall structure of the software, the logic before and after the completed code, and the integrity of the functional design, technical solutions, test cases and other related documents generated based on the requirements, which not only greatly increases the probability of quality problems, but also inevitably leads to an increase in project construction time and construction costs. it can be said that changes in requirements will bring risks to the project construction work in many aspects such as schedule, quality, and cost:
1) Schedule risk.
For requirements changes, it usually requires corresponding adjustments to the project documentation, functional design, technical solutions, work plans, and software code related to them. however, it should be noted that since these adjustments do not belong to the predetermined work plan, when these work is carried out, on the one hand, it will add a lot of additional work to the project construction, and on the other hand, it will make it impossible to progress as planned. for party a's project manager, if these unplanned work cannot be properly handled, it may lead to the overall work of the project not being completed within the scheduled time, thus causing progress risks to the project construction work;
2) Quality risk.
In most cases, in order to meet the changed business needs, we adjust the relevant documentation, the overall structure of the code, the logical relationships, and the functional properties accordingly. and these adjustment work will bring quality risks to the project construction work, mainly reflected in the following aspects: first, the documents involved in the adjustment work mainly include requirements specifications, implementation plans, product designs and test cases, etc., if they cannot be adjusted in a timely and comprehensive manner, it may lead to quality risks in the documentation; second, when adjusting the relevant business functions, if all the functions associated with them cannot be adjusted synchronously, it may lead to function-related risks third, the adjustment work may change the existing product architecture or code structure of the software, thereby breaking the original stable structure of the software, which may lead to the quality risks related to stability; fourth, when realizing the changed requirements, the team members of party b may cause quality risks due to problems in coding ability, demand understanding, work communication, insufficient testing, etc.;
3) cost risk.
Since the adjustment work corresponding to the vast majority of requirements changes is usually not within the scope of the work plan, in order to ensure that these tasks are completed, the team b needs to invest more personnel or time in addition to the existing resources. for party a's project manager, the new resources added by
team will lead to an increase in the overall workload of the project, and these workloads will eventually be reflected in the cost of the project. therefore, when the increased workload of the demand change accumulates to a certain extent, the total cost of the project may exceed the budget, which in turn will cause the project cost risk.
2. Change management principles
for the project manager of party a, when managing the demand change, it can not only focus on the requirements that have changed, but also need to prevent and control the demand change through the corresponding management means, so that it can better promote the development of the project construction work.
According to the author's personal experience, in the specific project construction work, the project manager of party a can divide the change management principles of different stages into the following three aspects according to the pre-project construction, middle and late stages: pre-prevention, medium-term control, and late-stage decision-making. among them, pre-prevention refers to the early stage of project construction, when the demand has not yet passed the review and finalization, through full research, simulation roadshow, internal discussion and other means to maximize the discovery of the deficiencies in the demand, in order to reduce the risk of adjustment of demand after the finalization; medium-term control refers to the development and construction process after the demand is finalized, through the division of priorities, impact analysis, centralized adjustment and other means to control the frequency and scope of demand adjustment, in order to reduce the impact of demand changes on the project construction work in order to avoid the impact of the demand change on the completed work and completion time at the end of the project construction, the project manager of party a needs to conduct a comprehensive analysis of the change requirements in combination with the specific change content, the actual situation of the project and the definition of "completion" to decide whether to accept all, partially accept or postpone the processing.
3. Requirements change management
for the project manager of party a, the goal of its requirements change management work is mainly to ensure the definition of "completion" of the project, combined with the specific conditions of the project work, to maximize the realization of the change requirements proposed by the business party. in order to achieve the corresponding management objectives, party a's project manager should follow the following disposal principles when managing requirements changes: first, ensure that the core items of the project "completed" will not be affected by the requirements changes. if the core item is time, then in order to ensure that the project can be completed on schedule, too many requirements changes cannot be accepted; the second is to grade the change requirements. since the additional manpower, time and other resources that the project team can add are limited, in order to avoid the limited resources being occupied by non-critical and non-important change requirements, party a's project manager should grade the project according to the importance of the change requirements to the project to prioritize the higher level of needs; the third is to avoid the impact on the completed functions. when the project manager of party a works with party b's team to develop a solution for the change requirements, he should try not to change the completed functions to reduce the impact of the change requirements on the software product.
As we know, the requirement change is the adjustment of the scope corresponding to the definition of "completion" of the project, so when the project manager of party a manages the demand change, in order to ensure that the quality, time, cost and other elements will not be affected by the scope change, it should first clarify the following two aspects of the information: first, the amount of demand change that party b's team can accept. in order to avoid the situation that the project fee exceeds the contract amount due to the change of requirements, we will generally specify in the business contract of the project the amount of demand change that party b's team should accept free of charge. at the same time, due to risk control, auditing, supervision and other reasons, party a's project usually does not increase the project-related budget during the construction process. therefore, for party a's project manager, the total amount of demand changes that party b's team can accept is the amount of changes specified in the contract, and the amount of demand changes it can bear is equal to the total amount of changes minus the amount of changes that have been completed; the second is to clarify the remaining construction time of the project. typically, the remaining construction time of a project is primarily the sum of all working days between the current date and the completion date.
However, it should be noted here that when calculating the remaining construction time of the project, the project manager of party a should first determine whether the construction completion time of the project can be adjusted, if it can be adjusted, how large the scope of the adjustment is, and then calculate the remaining construction time of the project according to the completion time of the project construction.
After clarifying the above information, the project manager of party a can carry out specific management work on the requirements of the change, mainly in the following aspects: one is to determine the scope of acceptance of the requirements, full acceptance, partial acceptance or non-acceptance; second, review the disposal plan submitted by partyteam; third, adjust the project work plan and track the implementation of party team. it should be noted here that the scope of demand acceptance and the solution of party team are mutually influencing and restrictive. according to the author's personal experience, when managing the change of requirements, the following steps can be adopted:
1) change requirements.
For change requirements, party a's project manager should, on the one hand, grasp and understand the specific requirements through communication with the requirements of the personnel; on the other hand, through document learning, personnel communication, demand talk and other methods, to ensure that party b's team can fully and accurately grasp the relevant content of the change requirements;
2) change work sorting.
The project manager shall require party b's team to sort out all relevant work on the basis of understanding the change requirements, mainly including the following: impact analysis, implementation plan, list of modified or new functions, investment time, estimated workload, input personnel, list of documents to be adjusted, etc.;
3) requirements change management.
Project manager shall determine whether the change work can meet the project construction requirements according to the specific situation of the "completion" definition and construction of the project, combined with the content of party b's team's combing of the change work, and if it can be met, the next step of the work, if not, it is necessary to adjust the scope, time, cost, quality and implementation plan related to the demand change until the change work can meet the corresponding construction requirements.
If the core item of "completion" is time, when the change work cannot be completed within the specified time, then the method of narrowing the scope of the change requirements, reducing the quality of the software, increasing the construction cost or optimizing the solution should be used to ensure that the change work will not affect the final completion time of the project. among them, there are several common treatment scenarios for this situation:
First, the requirements change is graded, and the high priority change is prioritized. for other changes, it can be not processed or left to be processed separately after the completion of the project; the second is to adjust the scope of change or implementation requirements, so as to reduce the workload of the change and make it meet the acceptable range; the third is to adjust the implementation plan, using a simplified implementation plan or a partially realized plan to reduce the required workload; the fourth is to discard the unimportant part of the original demand, so as to leave enough workload space; fifth, it requires party project team to increase personnel, thereby increasing the assignable workload;
4) formulate a disposal plan.
The team shall formulate the corresponding disposal plan based on the finalized change requirements and solutions, mainly including: work impact analysis, solution, work plan and workload;
5) program review.
The party project manager reviews the feasibility and rationality of the disposal plan submitted by party b's team based on the actual situation of the project and combined with the definition of "completion" of the project. under normal circumstances, the following evaluation criteria can be used: one is to solve the requirements put forward in the change of requirements; the second is to modify as little as possible, do not affect other functions other than the change requirements; third, do not over-design the change requirements, and realize that the solution just covers the change requirements; fourth, the solution should be as concise as possible when it is implemented. if the disposal plan cannot meet the requirements, party b should be required to return to step 4 and reformulate the disposal plan;
6) program implementation.
Team carries out specific implementation work in accordance with the approved disposal plan.
13.4. common requirements problems
in this section, according to his own work experience, the author has sorted out the demand problems that often occur in the project construction process, mainly in several aspects such as unclear requirements and untimely update of requirements documents, and the author will also give corresponding solutions and precautions based on personal experience. the details are as follows:
1. Requirements are unclear
Unclear requirements mainly refer to the vague, ambiguous or inconsistent descriptions of specific business requirements such as construction objectives, business functions, and operational processes in the requirements document. on the one hand, it will make the project construction requirements unable to accurately and comprehensively pass on to the relevant personnel; on the other hand, it will cause serious quality problems in the project construction work, which in turn will lead to the work not being carried out as planned.
When disposing of this type of problem, the project manager of party a can follow the following disposal principles: clarify the identifiable needs, block the needs that cannot be determined, and strictly prohibit the relevant personnel from guessing the meaning of the uncertain requirements according to their own understanding. When disposing of a specific problem, party a's project manager needs to give specific solutions after in-depth analysis of the reasons for unclear demand, combined with the actual situation of project construction and personal work experience. in general, we will divide the causes of unclear demand into two categories, namely human and non-human causes.
Among them, human causes refer to the unclear expression caused by the personal ability of the requirements writer in the case of clear business, such as the incomplete understanding of the business by the requirements writers, the coordination problems when multiple people write or the insufficient personal expression ability of the requirements writers; non-human reasons refer to the unclear demand caused by the uncontrollable external conditions on which the business depends, such as policies or systems that cannot be determined. this kind of problem is often not controlled by the requirements writer and can have a significant impact on the project when it occurs.
For the two different types of problem causes, party a's project manager's treatment plan is also slightly different. for the demand caused by human reasons is not clear, the first thing to do is to require the demand personnel to rewrite or complete the unclear part of the demand, and then the modified part of the organizational personnel should be explained and reviewed, and finally in order to prevent similar problems from happening again, measures such as improving the quality of personnel and strengthening the demand review should be taken; for the demand for non-human reasons, the main reason for the problem comes from external uncontrollable factors.
Therefore, for this type of demand problem, the first thing to do is to determine the scope of the uncertainty and the degree of impact on the existing demand, followed by the analysis of the affected demand, for the parts that can be clear, it is supplemented and perfected, and for the parts that cannot be clear, no more processing should be done after it is identified, until the external conditions associated with it are clear.
2. requirements documentation is not updated in a timely manner
The requirements document is not updated in a timely manner, mainly refers to the situation that after the business changes, in the case that the corresponding software has been adjusted, the corresponding requirements document has not been adjusted in time, resulting in inconsistencies between the project software and the requirements document. since most project work, such as software design, development, testing, etc., relies on the requirements document, so the requirements document is not updated in time, which can easily lead to the risk of requirements implementation and verification due to the lack of accurate and unified dependency foundation.
Under normal circumstances, there are two main reasons why the requirements document is not updated in time: first, the project time is more urgent, in order to ensure the construction progress of the project, in the case of the approval of the project participants, the update of the requirements document is postponed to an agreed time; the second is the reason for the requirements writer himself, who failed to update the document in time.
When dealing with this type of problem, the project manager of party a needs to deal with the situation according to the cause of the problem: for the situation that the document is not updated due to the problem of the demand writer himself, he should first agree with the time of completion of the document and formulate a writing plan, and then track and manage the writing work according to the plan to ensure that the requirements document can be completed as planned; for the situation that the document is not updated due to the project schedule.
The demand personnel should first be required to provide other forms of demand change instructions other than the requirements document.
Such as demand change orders, demand change emails or demand change communication meetings, etc., to ensure that the changed requirements can be accurately communicated to each member of the project team; second, the relevant personnel are required to conduct demand counter-talk to determine that their understanding of the changed requirements is correct; and finally, the requirements writing plan is formulated to clarify the time and work arrangement for the completion of the requirements document update.
No comments:
Post a Comment