Talking about the things in the project: Planning and change

Author: ghner Source: blog time:

What do we fear most in IT projects?

Project terminated? No, because "Project suspension" is rare for us who do our best. It may be a financial crisis, maybe the necessity of the project no longer exists, or just an indefinite delay.

So here we will discuss something that is being executed in a normal project process.

For project execution and managers, what we fear most is "change". If anyone cheers at "I will embrace change happily", we are welcome, he's right. He's dragging everyone into the quagmire.

This is true, but even if we don't like it any more, the reality is that we have to accept some changes. People are always in a turbulent environment, but they are often unaware of it. Floods, earthquakes, SARS, H1N1, Iraq, North Korea nuclear power, oil prices, housing prices, stock markets, and old and ill deaths all come in unpredictable or unpredictable ways and deeply influence us. One is known unknown, and the other is unknown. No matter which kind of unknown change happens, it will impact our lives.

From some point of view, we are lucky to be working with IT projects, especially software projects. We will not leave our families worried about the construction sites in Iraq, Sudan, and Afghanistan. We sat in the bright Office, facing thinkpad coding, and there was a coffee at hand. Indeed, from this perspective, we should be calm at our own changes.

To cope with these changes, we will take many measures to enhance our project security. Planning is the final means.

　　Project Manager:

Looking at WBS: will it make us think things are quite clear? This is a perfect task.

Looking at the crosstab chart, we will sigh again that things are proceeding in an orderly manner.

Looking at the resource Load Diagram and holding the resource balance table, although it is a headache, it is not as bad as you think!

　　Technical Manager:

Well, all of them are based on the original architecture. It takes only three months to hand over the work.

In fact, these two people do not live in anxiety. They know that all stakeholders are thinking about how to make changes so that they can have a face on their faces and make money less desirable; in order to reflect the value of my project.

From the perspective of suppliers and customers: both Party A and Party B will have their own project owners, either east wind or west wind, or the west wind will overwhelm the east wind. We are generally Party B and often overwhelmed.

Therefore, our plan is always modified and adjusted after baseline adjustment. The stress increases daily, and we even need to assign a special scheduler to make the plan.

In essence, I hate planning, because it is the emergence of a plan that makes me feel the pain of changes in advance. Although there is no plan, the change will crush the project for the last time, but I really hate planning. In the past, when I was working on a project, I always put my head on my head and endured the grief of looking at the progress and looking at the percentage of completion that I could hardly believe. I have been tortured by the plan. I am wrong. It should be because I have been tortured by the Plan and change. I am full of doubts about the reality. Unfortunately, I am not a philosopher, not a scientist.

At one time, I fell into a misunderstanding and hoped to develop a flexible plan to make it less changing. The result is that I can't do anything except write the project name and completion date on the top node of WBS. It's really flexible. Fortunately, I am not so stupid as to the extent that I dare to give this stuff to BOSS and customers, so I also avoided the fate of being fired. This was a long time ago, and now I have worked in another position, barely getting rid of the project's nightmare.
Facing the blank Project 2003, after some painstaking thoughts, I came to the conclusion that the root cause of the change is that it is beyond the plan. The plan and change are like the two of them. Maybe they are more like a mirror. They belong to both ends of the mirror, and the plan can always reflect the change in the mirror; changes can also make out-of-the-mirror plans more beautiful and reasonable.

From this, we can see that I am really stupid.

PMP tells us that risk management is very important. To deal with known unknown, we need to use emergency reserves; To deal with unknown, we need to use management reserves. But he didn't tell us how to identify and handle changes. At least in my opinion, those decision trees, scatter plots, and seven-point laws are too scientific. They are not suitable for China's national conditions that "do not follow the rules. So I want to discuss from a more emotional perspective:

　　1. boldly reject customer requirements

If your contract has been signed, if the customer forces you too much, if you really think this is a change that should not be accepted, then you will reject it boldly. And tell your BOSS that you have rejected the customer, so that he can be prepared: the customer wants to ask him for trouble and reports his own blacklist. If you want to be confident, you have to do this. If you change to another person, you do this for the benefit of others. You are absolutely not selfish. If he is a good BOSS, he should help you withstand the pressure of the other party. After all, you not only have credit, but also have a hard time.

　　2. Block your mouth with standard

It's not for you to be fooled. In many cases, the customer's requirements are against their corporate standards, so you kindly advise him: Sorry, you have to modify it, please modify your enterprise standards first, otherwise we will not be able to handle this in future acceptance! Therefore, it is very important to find out the foundation of the other party when you are working on a project, especially those that are common, but are very likely to affect the project decision-making.

　　3. Take care of your company's face for requests that you can't do.

Currently, large software projects are rarely developed from scratch. When bidding, we often say what platforms are based on and then customize them. You must emphasize the customization during project creation. What should I do if the project team cannot handle the problem that the company cannot solve? We recommend that you do not directly say NO. Rather, the words "I have already submitted to the R & D department" should not be added with the words like what is being solved. I should not add one more word. Because you honestly say everything you know.

　　4. Project Phase II

Some demands cannot be rejected by you, especially those that require enhanced system performance. They are also included in the scope of projects included in the contract, you also think that these requirements are not too good, but you do not have to spend any time or resources to solve them. The project must be closed and the final payment is required. You say NO is too difficult for the customer to face, it is better to say: "We will do it in the second phase of the project." if it is not a big leader, they will accept it in a vague manner.

　　5. Tell the team members, especially the developers, if they want to change.

A lot of changes are actually generated internally. You need a chicken and the result is a dog. Why? The dog throws the chicken. The developer told you why it was so difficult to design it. Then I feel like a genius. To be honest, I am not opposed to genius, but can you tell me about your idea of genius before you come up with the result of a genius. You stand in a local perspective, I stand in the project perspective, and the boss stand in the company's perspective. I often discuss projects with my boss. Why don't you discuss design with me.

　6. UI in the team should be clarified

The interface is not refreshing, so everyone is easy to work out, so developers will be concerned about the architecture design and take the initiative to change part of the architecture. Although the Team's organization is flexible and there are not many rules, the division of the work interface is the foundation of tacit collaboration. Otherwise, no one knows who to look; people who don't know who to look for, but who have a sense of responsibility, will handle it on their own. The problem arises. Although I have no objection to mutual assistance in some cases, the primary and secondary tasks always exist, and the owner always exists, all people you know should be notified.