Comic Chinese Style Project Management

Chapter 4 Project Planning

2.1 Progressive Clarity of Projects

We discussed a topic before, what should you do when there are serious technical problems in the middle of the project?
However, in actual projects, I emphasize even more that this situation should not occur at all.

Because many times, if the so-called "serious problems" appear in the middle of the project, you have nothing to do.

At the beginning of the project, the risks and uncertainties are high, but the management cost of the project is the lowest.

"Let's try changing a technical solution?" No problem, we can have a discussion.

When the project is in the middle and late stages, the certainty will be strengthened and the risk will be reduced, but the management cost will become very high.

"Let's try changing a technical solution?" You must be talking nonsense.

If you go into execution with a lot of uncertainty, you're going to have nightmares.

At the beginning of the project, you must be willing to spend time in argumentation and planning, communicate with all stakeholders tirelessly, and be able to withstand the pressure to clarify ambiguous issues.

2.2 Milestone nodes are more important than acceptance nodes

It is the engineer who keeps his eye on the details.

It is the boss who keeps his eyes on the result.

It is the project manager who keeps his eyes on the process.

It's not that the result is unimportant, but the result is guaranteed by the process.For project control, milestones are the most effective means of process control.

The pressure brought by the acceptance node belongs to the "hard" pressure, and there is no room for maneuver, while the "milestone node" is sometimes "soft" and does not belong to the "urgent".But ignoring the milestones of the project is a process of accumulating pressure and realizing risks.

As project manager:

During the planning process, milestone nodes should be reasonably planned to make them feasible and have acceptance value.

During the execution process, it is necessary to arrange work around each milestone and find the "rhythm" of the project.

In the communication process, the pressure of milestones should be passed on to everyone in the project.

What I want to emphasize here is that when others don't pay attention to milestone nodes, you must pay attention to them, and you must use the highest volume and the greatest influence to ask others to pay as much attention to them as you do.

"Milestone achievement rate" is an important basis for project manager performance appraisal.

2.3 Project planning should be very realistic
When the project plan is delayed, you often have a lot of reasons to prove that you are "powerless":

Customers change their needs all the time...

Staff can't arrive in time...

Process approvals delayed...

But is this really the case?Is the project planning itself really reasonable, effective and controllable?
The project planning process is a very "realistic" process, don't fool yourself with "ideal" assumptions.

"If user acceptance isn't too demanding, we should be able to..."

"Normally ... this process will not take more than 3 weeks."

"The ×× function should not be the most concerned by customers."

"At that time, the testing department should not be particularly busy, and there will be no problem with resources."

Are there too many "ideal" assumptions when we plan?
The project manager must implement every detail very realistically and consider all possible factors, which requires a lot of time.

When everyone is forcing you to start as soon as possible, you must be able to withstand the pressure and communicate with a large number of people...

You must be able to think of it when others don't think of it, and you must pay great attention to it when others think it doesn't matter.

A simple example:

Ideally, 5 people for 10 days... what do you want?
Is 5 people enough?What skills are needed?Experienced need 10 days, inexperienced?
You have 5 experienced people, but do they have the time?What other work arrangements do they have in these 10 days?
2.4 Resource Conflicts in Project Plans
Case
You plan to conduct system joint debugging in the first week of June, which requires the cooperation of several relevant departments.

You call the manager of the testing department, "Do you have time in the first week of June?" He answers you very readily, "No problem, I will arrange someone for you then."

At the beginning of June, 6 days before the start of the testing work, you approached the test manager to implement the personnel, but he told you that another important project of the company had a problem, and he had no manpower to devote to your testing project in the short term.

Where is the problem?
Resource conflicts are very common in all projects.Someone asked me, how can I avoid resource conflicts in my project?Frankly speaking, this is a false proposition. If an enterprise has unlimited resources, does it still need a project manager?

The two key points are:

1 During the project planning phase, resources are "officially" committed to people (sometimes a nuisance).

2 Anticipate possible resource conflicts in advance.

Take regular meetings (weeks) to discuss work for the next few weeks.Sometimes a casual "chat" after a meeting can be very rewarding, and maybe someone will mention:

"Another project of the company has a big problem. Do you think someone from the testing department will come to test us in June?"

It is impossible to completely avoid resource conflicts, but there is always a way if you can catch problems in advance.If you don't know until the end of the day, it depends on your luck.

2.5 Resources are to be fought for
The project manager must be able to "grab" resources. Grabbing does not mean being unreasonable, but a kind of "vigor".

Nothing is absolutely impossible, and nothing is definitely "should", the most important thing is your efforts.

such as:

The number of places for overseas training, the time of important experts, the working hours of the development team, and even important equipment, limited funds, etc.

Maybe the chance is small, but why not fight for it?If you don't fight for it, it will be impossible (of course, if you have the capital of "fighting father", it's another matter). If you fight for it, maybe the opportunity will be yours.

More importantly, you have to let everyone in the project team see that you are trying to get resources for everyone, otherwise you will lose your prestige little by little.

A good project manager can sometimes appear "strong" because you are always fighting for resources.Of course, "strong" does not mean "tough", we must learn to master the method and the heat.

In most cases, resources are in the hands of department managers and senior managers. You must learn to deal with people who have resources, not just when you need resources, but always maintain good communication with them.

2.6 Do you think it is correct or everyone thinks it is correct
As a project manager, you always have to project a high level of confidence.

But "self-confidence" and "conceit" are not the same thing. True self-confidence is often reflected in self-reflection.Learn to value each distinct voice.

There are two possibilities for different sounds:
1 The other party sees the problem from a different angle than you.

2 The starting point of the other party's interests is different from yours.

For the first case, there is no doubt that you need to listen carefully. This is a matter of basic quality, and the key is the second case.

The other party has different interests than yours.The same is overtime, some people are unpaid (fixed salary), while others have overtime pay (calculated by working hours), your idea is always supported by some people and opposed.

Even within the company, the interests of departments often restrict each other.The sales department hopes to lower prices and increase sales, while the financial department's assessment indicator is profit margin.Project managers want strict execution of project plans, while business units want flexibility.

Absolute consensus is impossible, but in the planning stage of the project, seeking "compromise" and reaching "relative consensus" are important skills of the project manager.

How can this be done?The first thing you have to consider is the "interest" of the other party, not the "position".In other words, what is the core motivation of the other party?Why does he insist on a different view?This is the superficial and deep reason we have discussed.

The "relative consensus" after compromise may not be what you are most satisfied with, but it is often more feasible.

2.7 The plan should be concise

Please believe me an absolute "experience", long-winded documents are not read.

As a project manager, you must learn to write planning documents concisely. If you have to write a lot, then at least write the content of the first page in a high-level summary. When customers (or bosses) read it, they can Choose to see only the first page.

There was once a project manager who gave me a stack of documents and talked to me about the Gantt chart for 30 minutes before I suddenly realized why he divided an uncomplicated job into three stages.His idea is not unreasonable, but if something needs to be explained for half an hour before people can understand it, it is difficult to advance in reality.

1 First of all, if the return of increasing the complexity of the plan is not obvious, I would rather choose a relatively simple plan, which is easier to promote and less risky.

For example, in the above example, a job is divided into several stages, the purpose is to use some scattered time of the development team, which seems to save costs, but management and coordination are too difficult, and problems are too prone to occur, and the risk cost is far greater than the savings. those development costs.

2 Be good at using the shortest time and the smallest space to let the customer (boss) and all relevant people understand your intentions.

We strongly emphasize that the plan should be meticulous, the so-called details determine success or failure, but it must not require you to use a thick stack of documents for communication.Documents to customers (bosses) must be concise and focused.But when discussing in depth, you must have enough details to support your point of view.

2.8 Risk control must be implemented in the plan
What is the implementation of risk control?
I'm sure you must have written a risk control plan. Sometimes this kind of document is for bosses and customers.But as a project manager, you really need to implement the project risk response into the plan, which is the safest for yourself.

A real example: The project adopts a new subcontractor (development outsourcing) and uses new technology. There are subcontractor risks and uncertainties in new technologies. communication".

Such wording is a typical risk document of "dealing with the boss", because it is completely inoperable, and "strengthening communication" must not be a measurable process.There must be something tangible that can be done in the planning document.

Each risk response method must be a specific and implementable work item in the project plan.

For example: For old subcontractors, a regular meeting is held every 2 weeks.

For new subcontractors, a regular meeting is held once a week.

For old subcontractors, technical tests are only carried out at milestone nodes.

For new subcontractors, a verification test is carried out after each module is completed.

If new technology is a risk item, what is the countermeasure?staff training?Okay, so personnel training, as a measure of risk control, needs to be a work item in the project plan (WBS), with time in the schedule plan and budget in the cost plan. This kind of "response means" is real and reliable .

The basis of project risk control is good risk planning. Sometimes it is not your ingenuity or even your experience that guarantees your safe completion of the project, but a seemingly rigid, but real, and well-implemented risk control plan.

(End of this chapter)