Small project managers do not need too much project management knowledge and project management skills training. However, once the scale of the project becomes larger, these formal management processes and skills are essential for project managers. Although different project management methodologies organize and illustrate these project management processes in different ways, we would like to emphasize the 10 most basic processes:
1. Define Project scope
2. Development of a work plan
3. Management work plan
4. Problem Management
5. Scope Management
6. Risk Management
7. Communication Management
8. Document Management
9. Quality Management
10. Measurement Management
Generally speaking, if you can master these 10 areas of knowledge, you will be able to achieve most of the project management success. For small projects, you may not need to worry about documentation or metrics management, but the bigger your project, the more you need to focus on managing these 10 processes.
You may have noticed that the 10 management processes we listed did not include analysis, design, testing, or deployment. Those who have some project work experience may know that a project usually includes the analysis and testing process. There are, however, significant differences in these processes. The analysis and testing process is part of the actual project process, also known as the project lifecycle. The project lifecycle contains different phases as the project type changes. If your project is a complete lifecycle project, you may perform the entire process of analyzing, designing, building, testing, and deploying. In other types of projects, you may only be involved in some of these phases. For example, if your project is a research project, you will not be involved in deployment issues. If you are doing a study, after completing the analysis phase of the task, the project may be over.
You see what else we missed?
There are two management processes that are sometimes part of the basic project management process: Personnel management, contract and procurement management. Staff management is a very important skill for the project manager, but it is not required for project management. After all, there is a need to involve people management in any management of subordinates. The difference is that people management is a skill that project "managers" need, not the skills required for project "management."
Contract and procurement management are not included in the list of our 10 project management processes. In most organizations, project managers need to understand the management of contracts and vendors, but they are not responsible for this. The legal department and/or the procurement department are usually responsible for contract and supplier management.
Sequence of schedules and procedures
In addition to the first and second categories-defining project scope and developing a work plan-these 10 major project management areas are not a sequential process. From process 3 to process 10, you can do it in any order. And, in fact, they are parallel throughout the project and are ongoing from the start of the project to the end of the project. For example, if an important issue arises in a project, you must ignore the other processes of project management that you use before, during, or after the problem, and immediately use the problem management process. Let's take a closer look at every management process.
Note: You can download the pdf file from here.
#1: Define project scope
As a project manager, you must determine that the project's work is easy to understand before the project starts and has been agreed by the project sponsors and key project stakeholders. You need to discuss these with sponsors and project stakeholders to ensure that the project team and the customer have an understanding of the project deliverables, the time of project completion, the cost of the project, the project execution team, the way the project is completed, and the benefits that ultimately derive.
From the top of the project management perspective, the purpose of defining project work includes:
-Understand project objectives, deliverables, scope, risks, costs, methodologies, and reach agreement. This is the most important part of defining a project's work, and most of the time will be spent on agreeing.
– Determine if the initial business case is still correct. For example, a project that takes 10,000 of hours of work can be commercially significant. However, if the process of defining the work is too detailed, it can result in more than 20,000 hours of accurate estimate time, so that the project may no longer be feasible.
– Make sure that the resources you need are available when you need them.
– Develop a high-level project baseline. Depending on the baseline, project-related personnel can compare the performance of each process and control the scope of the project.
– Agree with the customer on the management process used in this project.
The effort needed to define a project's work depends on how much information is needed to understand and document the people involved in the project. The time it takes to define a project's work depends on how long it takes to understand and document the information, and how long it will take to get the customer's consent and approval.
For large and complex projects, it may be difficult to define the final deliverable accurately, and it is also difficult to estimate the total cost of the project and the final delivery date. If you are managing a large and complex project, you can divide the project into smaller projects. In these small projects, small projects that need to be done first should make it easier to define their work. Small projects that need to be completed in the future can be defined in detail as soon as they are executed.
At the end of the definition project scope, you should work out a definition of the project. This document defines all of the project's expectations in terms of project objectives, deliverables, scope, risks, delivery dates, and project personnel roles. This document should be formally approved by the project sponsors and other key stakeholders before the project team starts executing the project.
#2: Developing a work plan
When you define a project, you want to make sure that you agree with the project sponsor on all the work that the project should do. At the stage of developing a work plan, you will determine how to do it. This requires the development of the project plan. Depending on the size of the project, you have to take a different approach. For example, a work plan for a small project can use a Project management toolkit, spreadsheet software, or even a piece of paper, such as Microsoft Project.
If you don't have a work plan template available when you start planning, you can use the work breakdown structure (WBS). A WBS is a technique that breaks down work from a high-level project to a smaller part until the project manager gets a complete view of the project's work. The entire project team works together on this basis. I recommend that you break down the work to a lower level, break it down to a time of not more than 80 hours to complete each activity that is no longer decomposed, and that the resources needed to complete the activity are clear.
Once you have decomposed all your work into activities, you can order and determine the dependencies between these activities. At this point, the WBS is transformed into a network diagram (receptacle Diagram).
Then, you need to add resources (that is, workers) to each activity. If you know the exact names of certain resources, you can add them by name. If you don't know, you can use the generic name to occupy the place. Next, you need to add work and start and end dates for each activity.
Now, your work plan is ready. You can get a clear picture of what you want to accomplish (the definition of the project) and how you are going to do it (the project plan).
Relationship between project definition and project plan
You will find that if you do not start arranging the whole project plan, you will not be able to define the definition of the project in its entirety. In many cases, you need to process both deliverables synchronously. When you collect information about scope and deliverables, you need to develop a schedule to get the estimated work hours and deadlines. When you define deliverables, scope, assumptions, and methodologies, you get enough information to make a project plan to estimate budget, work hours, and deadlines. Then you can use them to complete the definition of the project.
#3: Management Plan
At this point, you have completed the project definition and project plan. Major deliverables the project definition and project plan are ready. Some project managers believe that the completion of the project definition and project plan means that the hardest part of project management is done. In fact, this is clearly not the case.
You will never be a successful project manager if you can't keep updating the project plan. Remember, the project plan is just a deliverable. The project plan describes the work that needs to be done, the order of the work, the number of hours required, and the person in charge, but the project plan is just the best predictor of how you can complete the remaining work at a specific point in time for your project.
The more complex your project is, the more places the project plan needs to be updated as time goes on. As a project manager, you have to evaluate the project plan on a constantly changing basis (perhaps once a week) to determine the current status of the project.
In the weekly review, you will update the current status of the completed and ongoing work in the project plan. You need to evaluate the remaining work to see if the project can be completed in accordance with the estimated hours, costs, and deadlines of the initial plan. If the result of the assessment is that the project can be completed according to the initial plan, then your project is in good condition. Instead, you must implement corrective action.
Management work plans may be the most basic of all the skills in managing a project. Depending on the actual situation of the project, you may have to use your experience and creativity to make the project work as expected. Your project may still be on schedule this week. Next week, you may have a task extension and other problems.
If an activity on a critical path has been postponed for a week, you can't sit around and watch the whole project go for a week. Instead, you must evaluate the available resources and possible options to get the project back on track. If you are good at managing your work plan, it will be one of the most challenging and rewarding tasks in project management. If you don't like the meticulous work you need to do, you'll find it too difficult to achieve success.
#4: Problem Management
"Problems" arise when a problem hinders the execution of a project. Without outside help, the project manager and project team cannot solve the problem. If there is a serious problem, you have no choice but to solve it. The only question is whether you can proactively use problem management, overcome indecision, and not be able to determine how to solve the problem.
Problem management consists of two important parts. The first step is to go through a survey problem, determine the impact of the problem on the project, consider alternative solutions, and lead the team to make the best decisions in this situation. All of these project management steps should be defined in advance and agreed upon. These steps ensure that problems can be organized and resolved as quickly as possible.
The second part of problem management is the use of specific problem-solving techniques. This includes techniques that are familiar to us, such as Fishbone maps (Fishbone diagrams), histograms (Pareto Sponsor), and root cause analysis. You may be familiar with one or more of these techniques that will allow you and your team to understand the nature and causes of the problem, what solutions are available, and which solution is the best choice.
A very important fact that all project managers realize is that it takes a process to solve the problem, but that doesn't mean you will successfully solve every problem. Sometimes, there are many ways to solve problems, and your job is to help find out which one is the best. Sometimes a big problem doesn't have a good solution, and your best bet is to pick out a solution that has the least harm or that it's the best in other, worse scenarios. However, problem-solving processes and problem-solving techniques will allow you to determine which options are available so that you know at least what the consequences are.
#5: Scope Management
The scope of the project describes the boundaries of the project, defines the content of the project deliverables, the data that is needed, and the affected organization. Given a set of resources and time, you can deliver unlimited things.
Scope Change management begins with the definition of scope change. If the project manager does not do a scope definition, it will be difficult to manage the scope during project execution. The purpose of scope change management is to protect the viability of the currently approved project definition. Once the project is defined, a certain expectation of the project is set up, resulting in a corresponding cost and schedule. When the project definition is submitted and approved, you and the project sponsor keep these expectations in mind.
During project execution, there may be requirements that differ from or are not included in the initial project definition. This situation can be foreseen. If it does happen, customers should not expect these requirements to be delivered under previously approved resources and time limits. If new requirements need to be included in the project definition, the project team will analyze these new requirements to determine their impact on the project. The information is then approved by the project sponsors.
Remember, the project sponsor is the person who approved the project start-up fund. Therefore, he or she should also be the person who approves any changes to the definition of the project. If the commercial value of the change is high enough, the sponsor should approve the new requirements to be added to the project, while increasing the budget and time required to complete the work. Then, each person involved agrees and sets the project's expectations.
Of course, sometimes things don't go so well. The following problems generally occur:
– Out of scope: Large scale changes are easy to see. However, when the changes are very small, sometimes you will find that you have not figured out these changes to include them in the project. "Out of range" means that you accept small changes, and the resulting small changes that eventually accumulate have a significant impact on the project. You and your entire team must be careful with the project scope changes, regardless of whether the changes are large or small.
-End user acceptance of scope: the project sponsor is the person who pays for the project. However, once the project begins, the project team spends more time on the grassroots and end users. Some project team members believe that the end user approves the scope change. That is not the case. Unless the initiator has expressly granted the right of approval to the end user, they are not authorized to approve the scope change. They can make requests for scope changes, but only sponsors with financial privileges can approve additional work.
– Team members do not understand their responsibilities: one common cause of failure to finish the project on schedule is that project team members eventually do more work than they actually need. For example, a team member is required to complete a report. When he or she is writing a report, the client asks for new content. The team member tried to satisfy the customer, so the work was postponed at last. This generally happens when team members think only the project manager needs to worry about scope changes. Team members must understand that it is everyone's responsibility to control the scope change.
The root cause analysis of many unsuccessful projects is that their scope change control is worse. Effectively defining and managing the scope will increase your project's chances of meeting expectations.
#6: Risk Management
Risk refers to situations or environments that are not under the control of the project team or if they appear to adversely affect the project. In other words, the problem is the trouble that must be dealt with at the moment, and the risk is a potential hassle. The passive project manager solves the problem when the problem arises. Proactively project managers to identify and solve potential problems before problems arise. Risk management is both science and art.
Because small projects typically have shorter cycles, there is less likelihood of problems. Large projects often have hidden risks. Risk management involves identifying the potential risks of all projects, determining their likelihood of occurrence, and clearly understanding the impact on the project if they occur.
Based on this information, the project team is able to determine which risks need to be proactively managed. For example, it is important to proactively manage those risks that appear to have high probability and impact on the project, while ignoring the risk of high probability but little impact on the project.
Once you identify the risks that need to be proactively managed, you can use the following five common practices:
-Leave it alone. If you think that a risk does not have a significant impact on your project, or that there is no way to eliminate a risk, or that you are willing to gamble that a risk does not appear, then leave it alone.
– Monitor risk. In this case, you don't have to take the initiative to reduce the risk, but you have to monitor it to see if the likelihood of it happening increases or decreases over time. If the likelihood of some kind of risk increases later, then the team must find a way to eliminate it.
– Avoid risk. Avoiding risk means eliminating the conditions that cause trouble. For example, a risk associated with a particular vendor may be avoided after selecting another vendor.
– Transfer risk. In some cases, the responsibility for managing risks may be transferred from the project team to other entities or to third-party institutions.
– Reduce risk. In most cases, this should be done. If you have identified a risk or are concerned about a risk, you should make an active plan to ensure that it does not happen.
As with scope changes, a project cannot be without risk. Customers will not expect a project to be free of risk. The problem is the response of project management to risk. Projects are more likely to succeed if risk identification is undertaken and risk is proactively managed. If you ignore the risks that may arise, the project can only be passively affected if the risk turns into a problem. At this point, there may be few solutions to avoid the impact of the project.
#7: Communication Management
In a project, proper communication is critical to managing customers and stakeholders. If customers and stakeholders are not informed about the progress of the project in time, they may increase the likelihood of project problems and difficulties due to the different expectations they have for the project. In fact, in many cases, conflicts arise not because of actual problems, but because customers and managers do not know beforehand.
There are two levels of communication in the project. First, all projects should be communicated. Second, if your project is bigger, more complex, or politically relevant, the communication you're going to make is usually more advanced and complex, so you need to develop a communication plan.
Project status meetings and project status reports
All projects need to be communicated effectively, from the project team to the project manager, or from the project manager to other stakeholders. Project status reports and project status meetings are not only used to report the normal progress of the project, but there are other things to do. From project status reports and project status meetings you can learn everything you need to know about the project. You need to communicate adherence to the project budget and schedule, to communicate the work accomplished during the most recent reporting period, to communicate the work planned for the next reporting period, new risks, current issues, and current scope change requests.
Your audience must be taken into account in conveying messages and speeches. Therefore, you'd better have a project status meeting with your project team weekly, and the meeting should include some very detailed discussions. The status reports you send to sponsors and management stakeholders must be brief and highly summarized.
Communication plan
Major decisions, especially those that require organizational change, must include a comprehensive communication plan that will take many forms of communication. The process of developing communication plans involves identifying all stakeholders, identifying the project information they need to get, brainstorming how to distribute the information, and communicating with as many project stakeholders as possible with the full utilization of resources.
According to the audience, communication generally takes one of the following three ways:
– Mandatory: Includes project status reports, project budget reports, and approved requirements.
– Reference: Provide further information to relevant personnel. For example, a document library, a FAQ list, and a project site that contains information about the project.
– Marketing: This type of communication is designed to increase enthusiasm for the project. For example, publish project success experience, establish positive image, distribute management recommendation and use Project identification.
The project manager must actively control the communication activities and must consciously plan and execute the communication activities. If your communication behavior is both effective and active, you will find that the whole project will operate more smoothly and will encounter fewer conflicts and obstacles.
#8: Document Management
Many project managers believe that document management is required only if there are hundreds of documents in the project. In fact, a better approach is to anticipate the number of documents that you think the project itself and the project management might produce, establish a set of appropriate processes and rules for organizing the document, and document management during the project to ensure that the document is not out of control.
Project managers for small projects do not need to think too much about document management issues. As the scale of the project becomes larger, the project manager must proactively manage the documentation in the project. The most common problem that you may encounter when managing a document is that the document is missing or difficult to find so that it is written back at the end of the project. The worst case scenario is that the version of the document is out of control, the updated date of the document is expired, lost, confused, or uncertain.
Document management is one aspect of project management, and you can use tools such as document libraries. However, using tools can only complicate the problem if the document is stored without the proper technology to easily access the document.