Colleague project summary: "Harmony Theory" of workload"

I switched from my colleague H's project summary to my own experiences and thoughts on workload, and put forward my own suggestions for readers to think about.

--------------------------------------------

Scenario:

This article does not discuss the workload before project initiation, but the problems that may occur when the project initiation is complete and the overall workload is set. Project Manager H has gone through project a's workload change project. According to the original requirements, the system has been put into normal use after the function is completed. However, in terms of interface and functional logic, the customer wants to make some modifications and is willing to accept the workload of the changes. The Project Manager H analyzes the workload required for each stage of each task based on the requirement change content and specific functional points. For example, it is the workload list of one module.

(For the time being, due to a system error in the blog image, make a picture after the system is normal)

Project Manager H sorted out all the requirements for changes, with a total workload of 120 person-days. Business personnel l communicates with the customer with these documents. The owner's representative g saw the functional points and workload list, and thought that the list contained some "moisture", and the business personnel l requested to reduce the total workload by 15 person-days. The owner's representative G has a close relationship with the project manager h and the developer Company L. In this regard, the business personnel l discussed with the project manager h to determine whether the workload of the 15 person-days can be "harmonious. Although the project manager H thinks that the workload list he has listed is clear and reasonable, he has to accept the "harmonious" Outcome of the workload. In the end, the three parties reached a consensus. According to the customer representative g, the total workload was reduced to 105 person-days.

Thoughts:

In view of Project A above, we can't help but reflect on the handling of other workloads beyond the total workload of the project.

StandingProject Manager's perspectiveYou do not want to delay the workload of your project to the next project or other projects, because it is not controllable. Of course, we do not want the project workload to be "harmonious" relentlessly.

Business personnel's positionIn addition, we hope that the project team's workload will be recognized and rewarded as appropriate. However, when the workload is not large, it is imperative to accept the "harmonious" workload in order to deal with the relationship with the customer.

Owner's client perspectiveIn general, it is not easy to covet the workload with business personnel and project managers. There are two reasons why they want to take "harmonious" measures:First, it is necessary to implement the operational requirements for changesTo apply for a new change process. From their perspective, they do not want a project to go through these processes several times, regardless of procedures, work efficiency, and operability.Second, the customer believes that the workload proposed by the Project Manager contains "water"Is not a real workload.

Therefore, in view of the above three roles, the existing project's handling process and handling methods will inevitably lead to the customer's desire for a "harmonious" workload.

Suggestion:

1. When a Project contract is signed, developers and users reach a consensus and reserve a certain amount of work, which may be the workload for future project changes. If the project is well completed, there is no need to spend that part of the workload, which has no impact on both parties. If there is a workload, you can use that part of the workload to handle it, there will not be any dispute over the workload.

Of course, the biggest beneficiary of the reserved workload should be the developer, because the reserved workload ensures that the additional workload of the Project is rewarded. The main benefit for users is to avoid the need to change the process and apply for a new workload. Therefore, as developers,Users should be guided as much as possible to let them know what the reserved workload means to them and what it means to us.To minimize project disputes caused by workload.

2. When handling the workload, the project manager must be clear, clear, realistic, and reasonable. For example, when a module needs to be changed, the functional points of the module must be clearly listed and the workload required to break down each functional point. When dealing with the workload of each demand point, you must constantly question yourself, whether the customer will question this demand point, and whether they can provide a basis for support.First, I had my own questions, and then I accepted the questions from the customer..

 

The desire is always beautiful. Specific implementation is requiredJoint efforts of business personnel and project managersTo allow users to understand and accept the reserved workload measures; the project manager should try to achieve clear and reasonable workload decomposition, so that the customer can accept it. Although we need to build a "harmonious" society today, we should not make the effort of the project team "harmonious.