Today, what we are going to share is: as project manager, how to effectively develop a good schedule plan and manage, monitor the project schedule according to the plan, and finally finish the project smoothly.
We all know that, a project schedule plan recognized by client, leaders and team members is essentially important. In brief, a good plan is to tell all stakeholders what the project is going to do, when to do, how long it takes and who’s going to do it. Those are the questions most project manager would encounter and also are the aspects which clients care about most during the project execution.
Here is a practical case.
Mike was a project manager in charge of air-traffic system project. His company was one of those functional organization. The project was to develop the air-traffic software system, procure hardware and perform system integration. The project team consisted of members who’s from four different departments and two third-party companies. The leader’s expectation was to achieve the project in six month, and meet the qualification of running online. But at that time Mike was not very familiar with the air-traffic industry, and did not know very much about what needed to be done or the details about those functional departments.
Mike tried to get some information from other project managers. Most of them replied that most of the team members were part-time and engaged in many projects, which had leaded to significant delays in many projects. Under this circumstance, Mike encountered a huge issue when developing and following a schedule plan. After a period of time, all anticipatory problems had happened as Mike expected, problems like;
Based on the policy of company, all detailed technical parameters and quantity of hardware equipment should be provided and confirmed by equipment department before procurement. When Mike talked to members of equipment department, he replied that he first needed the genre of equipment provided by technical department, in order to give detailed parameters and quantity. But the technician of technical department was coincidently on a business trip at the time, which caused the procurement of the equipment was belayed by a few days.
How did Mike solve the equipment procurement problem?
First, Mike communicated with the members of equipment department and technical department. After aligned the information with both departments, Mike asked the technician of technical department to confirm the required equipments.
Second, Mike reviewed all relevant WBS, activities and sequence of activities, to avoid the same problem from happening again.
Now we can review the procurement case and analyze the situation again. Most project managers have encounter similar problems, which we called “buck-passing”.
Based on the upper case, let’s think deep about the following questions:
1. Based on the company’s policy, equipment’s parameters should be provided by equipment department. But why the equipment department ask Mike to find technical department when he’s asking them?
2. Is that a problem of company’s policy? Or it’s just equipment department did not take their responsibility? Or is it Mike’s mistake to find equipment department in the first place?
3. After solving the problem, why did Mike especially review all relevent WBS work packages and activities?
With these questions, we again dive deep into the case.
First, the procurement requirement of hardware equipment. Since the requirement of equipment had already sorted out and proposed by the project team, why is there still a problem?
I believed that most project manager may encounter the same problem. When asking the equipment department to provide the technical requirement of the hardware, we had ignored what they needed to do first and what its lead activity was. In this case, in order for equipment department to develop the detailed technical requirement of the equipment, what they needed first is the confirmation from technical department of the equipment genre. Due to the lack of the information, equipment department would be unable to develop the detailed technical parameters.
This actually has answered the second question mentioned above: is there something wrong with the company’s policy? Or is it just equipment department pushing way their work? Apparently not, they just needed some pre-confirmed information from the other department first, that’s all.
The essential cause of the problem would be Mike had found the wrong person. Because Mike had ignored the lead activity of developing hardware detailed technical requirement, which is confirmation of the hardware genre. Speaking of which, we can go back to the PMBOK and find a technical term called “Define Activities”. According to PMBOK, define activities is the process of identifying and documenting the specific actions to be performed to produce the project deliverables. In short, it is not only to know what others should do, but also to know how others should do it.
In other words, while developing project schedule plan, except for sorting out the scope, we also need to define activities. If not, problems like, being unaware of what to do before developing procurement requirement in the upper case, will happen. And these problems would affect the schedule.
First, define activities, of which the key output is activity list. We than sequence the activities based on the list. Only knowing what to do is not enough, as project manager, we would also have to sort out all the logical relationships between different activities. The project manager and the team members would have to come to a common agreement on what should be done first, what next, and what activities can be done simultaneously. Only by this way, a clear project schedule network diagram can be generated. Otherwise, problems like in the upper case would happen and cause delay to the project schedule.
Sure, you also can do what Mike did: When encounter a problem, communicate effectively, and sort out all WBS work packages, activity list, and schedule network diagram. Take precaution to prevent the similar problems from happening again.
In summary, the most important lesson can be learned from the case is: developing a logical and detailed project schedule network diagram is essential for project manager to achieve the project smoothly.