IT took three weeks to read the “IT Project Manager Growth Notes”, during which I reviewed each chapter in order to write a blog, which made my memory more profound and was conducive to reference and application in practical work.
1. Scope specification
The purpose of the project Scope Statement is to document in detail the deliverables of the project and the work that must be done to deliver those deliverables. With the Scope Statement, the project team can plan in more detail and assess whether change requests are additional work.
The Work Breakdown Structure (WBS) is the most important part of the Scope Statement. WBS breaks the project deliverables down into manageable elements layer by layer, structurally defining the scope of the project. Each subdivision of WBS is a more detailed description of the project elements, which are called work details, of which the lowest work details are called work packages.
2. Planning process
After the scope of work is determined, a detailed work plan needs to be made according to the standardized process, which is the “plan” of making the plan.
- Develop a list of activities according to WBS.
- Determine the dependencies between activities and map the network.
- The resource allocation of each group is determined according to the dependency of the network diagram and the time limit requirement. Adjust and balance the schedule and resource plan according to the resource situation.
- Develop project budget according to resource and schedule.
3. Configure resources
There are two methods of resource allocation: resource first and duration first.
- If the resources are limited and the construction period is not strict, the construction period shall be calculated according to the actual capacity according to the principle of resource priority.
- If the resources are sufficient, or the construction period is strict, according to the principle of the construction period first, set the construction period, and then calculate the resources needed, and try to obtain the resources.
The core of the process of resource allocation is to coordinate the relationship between workload, resources and construction period:
- Effort refers to the amount of labor needed to complete an activity, usually in man-hours, man-days and man-months. For example, a demand analysis work needs 100 man-days.
- Resource refers to the human and other resources invested in completing an activity.
- Duration: How long it takes to complete an activity.
4. Project budget
The project budgeting process can be divided into two parts: estimation and budget. The purpose of estimation is to estimate the total cost and margin of error of a project, while the purpose of budgeting is to allocate the total cost of a project to various work items.
Estimates include labor costs, expenses, equipment, raw materials, labor and outsourcing costs, etc. In IT projects, the labor cost accounts for a large proportion, which needs to be calculated according to the unit cost of personnel and the amount of work invested.
Cost budgeting is the decomposition process after determining the total cost. Decomposition is mainly to do two aspects of the work: one is to apportion the cost according to the work package, so that you can check the cost of each work, deviation can determine which work out of the problem; The second is to apportion the cost according to the construction period, the budget cost apportion to each period of the construction period. The benefit of this is that deviations can be checked at any time and cost performance evaluated, avoiding the misconception that “as long as it doesn’t exceed the total budgeted cost, it’s ok.”
5. Risk management
Four major risks of the project:
| risk | Coping strategies |
|---|---|
| Project may be delayed | Strengthen schedule management |
| Project may overspend | Strengthen cost management |
| Quality may not be up to par | Improve delivery quality |
| Projects can get out of control | Strengthen change management |
The process of risk management is simple, including risk identification, risk analysis, risk planning and risk monitoring.
5.1 Identifying risks
- Technical risk
If the project uses complex or high technology, or unconventional methods, there are potential problems. If the technical goal is too high, technical standards change can also cause technical risks.
- To manage risk
For example, the schedule and resource allocation is not reasonable; Sloppy and poor quality planning; Improper use of basic principles of project management can create management risks.
- Organizational risk
Common is that there is no agreement on goals within the organization; Lack of attention from senior management to the project, insufficient funding or resource conflict with other projects are potential organizational risks.
- External risk
Such as changes in laws and regulations; The situation of the interface side of the project changes, and these things are often out of your control.
5.2 Risk Analysis
The analysis is divided into three dimensions: first, the possibility of risk occurrence; Second, the impact on the project, including the scope of work, time, cost and quality of the project; The third is the time distance from the current time to the expected occurrence period of risk events.
Since “possibility” and “influence” are both qualitative factors, we can refer to the table of qualitative analysis in order to avoid different caliber. Probability and influence are graded on five scales, with coefficients, verbal descriptions and numerical probabilities, respectively.
5.3 Risk Plan
According to the risk management process, different countermeasures can be adopted for different types of risks. Some recognize, some avoid, and some prepare in advance, which is the basis of risk planning. Coping strategies fall into the following categories:
- avoid
Protect objectives from impact by changing the project plan to eliminate risks or trigger conditions for risks. This is a risk management strategy in advance. For example, adopting more familiar working methods; Clarify unclear requirements; Increase resources and time; Reducing the scope of project work; Avoid unfamiliar subcontractors, etc. An avoidance strategy can basically avoid risk, so it won’t happen again.
- transfer
Risk is not eliminated, but the outcome of the project risk is transferred to a third party along with the authority to respond. (The third party should know this is a risk and be able to bear it). This is also an ex ante coping strategy, such as signing a different kind of contract, or signing a compensatory contract. A diversion strategy ensures that this happens and it’s not my problem. If we adopt this strategy, we can sign a monthly contract, and the delay won’t cause us any loss.
- weakening
Reduce the probability or impact of a risk event to an acceptable level. For example, choose a simpler process; Conduct more experiments; Build prototype systems; Add backup design; Reserve more resources for emergencies, etc. The weakening strategy can ensure that the risk can be dealt with even if it happens. Although it has a certain impact, it is acceptable.
- accept
Don’t change the project plan (or don’t have a strategy in place to deal with the risk) and think about what to do if it happens. For example, develop contingency plans or retreat plans; Or even just have emergency reserves and monitoring, and be prepared when things happen. The acceptance strategy is basically just wait until it happens.
5.4 Risk Monitoring
Risk monitoring has three purposes: one is to monitor the status of risks, such as whether risks have occurred, still exist or have disappeared; Initiate a response plan for the risks that have occurred. Second, check whether the risk response plan is effective and whether the monitoring mechanism is in operation. Third, constantly identify new risks and formulate countermeasures, and constantly update the status of identified risks. Generally, as time approaches, the probability of risk occurrence will increase, and the level of risk may change. Common risk monitoring methods in projects are as follows:
- The audit risk
Special personnel shall check the monitoring mechanism and conduct risk review regularly. In addition to the weekly review, a comprehensive risk identification and analysis should be conducted once milestones are reached, and a new response plan should be developed.
- Deviation analysis
Analyze cost and time deviations against the baseline plan. For example, missing deadlines and going over budget are potential problems.
- Technical indicators
There is serious difference between original technical index and actual technical index. For example, the tests did not meet performance requirements, the number of defects was much higher than expected, and so on.
6. Requirements change
Change is a common challenge in IT projects, but change control is not about making change difficult, IT’s about making change orderly, or IT can have disastrous consequences.
There are four important control points in the change control process: authorization, review, evaluation and confirmation. Only by understanding the role of each control point and making correct judgment in the implementation process, can we avoid the situation that customers are not satisfied with all changes.
- authorization
It is stipulated in the change process that it must be clear which personnel of the authorized client have the right to apply for the change and which personnel of the project team have the right to accept the change, and there is a requirement on the number of both parties.
- audit
The change review process requires prioritization of changes. Not all changes need to be changed, and not all changes need to be changed immediately. The purpose of the review is to determine which changes need to be made immediately and which changes need to be improved gradually.
- assessment
Change comes at a cost, and you should evaluate the impact of change on time, cost, quality, etc., so that senior leaders can make decisions.
- determine
The evaluation results must be known to the customer, and confirm whether to accept the cost of modification. The confirmation process has gained the opportunity to negotiate with the customer. If the customer accepts the cost of the change, even if there is no additional payment in the future, the project team knows that the project team has worked hard, and the project team has suffered a loss.
The implementation of change control should be audited during the project and any violations should be dealt with seriously so that the process does not gradually fail.