I have been working as a project manager for many years, i feel that the most important thing to do this work is to understand what is adapted to local conditions, according to the situation, only the most appropriate, nothing is called right, what is wrong, the most taboo project manager is the perfectionist tendency, especially as a technician, like to find standard answers, delay the progress of the work, but also confused themselves. the following are some of my personal experiences in doing projects, written out for everyone's guidance, and jointly improved the level in the process of discussion.
the project start phase is one of the most important phases. when taking over a new project, the project manager must first try to understand as much as possible about the project from various aspects, such as:
1. What project is this project, what exactly is being done, who proposed it, and what problem is the purpose of solving.
In the case that many customers in china are very immature, do not imagine the goal of the project according to the name of the project. a project called "office automation" is likely to find out a month after you enter the market that the customer actually needs a computer production management auxiliary information system. the more detailed the work of understanding the situation in the early stages, the less surprises there are later and the less risky the project.
2. What aspects of the project are involved.
Such as investors, specific business stakeholders, operators after the completion of the project, technical supervisors, etc., in many projects, in addition to the complex structure of the owner unit, there are some other units that will also be involved, such as the project supervision company, the owner's industry authority, etc. project managers need to understand what people in everyone's outlook and expectations are for the project. knowing the views and expectations of various aspects in advance allows you to analyze who will support you in what way and who will oppose you for what purpose when you encounter problems with the project, so that you can prepare in advance to unite friends against the enemy and let things go in the direction you want. there are no eternal friends, no eternal enemies, only consistent interests, this sentence as a project manager must be remembered.
3. After basically understanding the customer's situation.
The following thing is to understand the views of all aspects of your company on this project. the first is whether the senior leadership attaches importance to it, which determines whether the company will provide the strongest support according to your requirements when you need resources. what you need to do is understand the company's actual expectations of the project, do you want to make the project bigger and bigger or want to make money? whether you want to do model engineering or simply want to be perfunctory, the attitude of the company leaders to the project determines your strategy for doing this project, and this strategic policy will have a direct impact on your project plan.
4. Before making an overall project plan.
You should also roughly calculate the resources you have. the first is time, which is now highly competitive and often many projects are required to be completed in almost impossible time frames. for this, you should fully consider the risk control plan of the project. the second is the personnel, according to the project budget and past experience, roughly calculate how many roles there are in the future project team, whether each role is currently owned by the company, whether it can be fully used by the project, whether it needs to recruit some additional personnel, and the preparation for recruitment should start as soon as possible. finally, the preparation of some equipment, the large key equipment required for the project should be booked as soon as possible, and no matter whether the equipment and other equipment or people and other equipment occur in the future, what is wasted is your time.
5. Now is the time to do the project description.
A good project brochure not only describes what to do very clearly (mainly about what to do, not how to do it), but also explains how to check it very thoroughly. in other words, it not only explains what to do, but also lets the customer's business people (who generally do not understand technology) know what the project will be completed. simply put, the project specification describes what the project does and to what extent each thing is done and how to check each result.
6. Is it time to make the overall plan?
No, you now know the client's goals and the resources at hand, so before making a plan, you also need to fully communicate the resource issues with your manager and the client. because many resources are unclear, you'll need to write a report that analyzes the risks of the project in detail and the demand for resources. what happens if some problems are not solved. if there are not enough resources, it is necessary to change the strategy at the top and increase the investment in the project. even when conditions permit, some companies will abandon the project. in short, no one can complete an impossible task, and if the project manager cannot detect the risk as early as possible, then he can only go to be a martyr.
7. Knowing what to do and the chips you have in hand and your overall strategy for doing the project.
It's time to set up a project team. Many project managers don't have the right to choose their own team members, so try to use your influence to find the people you want. The composition of the members varies greatly according to the project, it is difficult to have any specific requirements, but there must be people who are proficient in the customer's business, many small projects, this person is the project manager himself, and the large project will be equipped with industry experts (Industry experts), so that communication with customers will not be chicken and duck, and both sides can understand each other. What I often see is that our technicians talk to customers with technical jargon that confuses them and, in turn, accuses them of not being technical. In fact, customers who understand what they want to do are already very good customers, do not know what they want to do, and do not know how to do it and point fingers at customers everywhere, but understand that it is the customer who chooses you, not the customer, with the customer you have a salary, calm and calm.
for customers whose needs change every day, you must make good rules in advance:
first, unified contact, the customer designated a person and the project team to communicate, can not zhang leader, wang leader to say a few words, if they disagree, then you only have to offend the leader's choice. therefore, the first step of the project is to set the rules, my project team only recognizes one opinion, what is the requirement that you first unify internally and then talk to me, i do not want to get involved in the contradiction between your internal business departments.
second, all requirements changes must be written, this point should be remembered! the benefits of this are many:
there is written evidence, and he wants to change it later, and you have the evidence he asked for before, tell him: you used to say this.
it is convenient for demand change management, and the history of how requirements have slowly evolved can be seen clearly, so as to have a deeper understanding of the customer's purpose.
for the customer, the mouth is the most convenient, anyway, you do, do not spend his resources, so whether the requirements are reasonable, whether it is consistent with the purpose of the project, he is irresponsible. but if he were to write a written request, and also sign and seal it, he would be much more cautious, and as soon as he wrote something, his thoughts would go deeper, and many unreasonable demands would be stillborn.
8. now you have to face three groups of people:
Your leader, your team members and your customers, and communicate with these people to let them know what you plan to do and when to prepare them, and these things will be your main job. since communication is so important, it is also very important to define the principles of communication in advance. many communication principles are unspoken rules, and if you've been in a department for a long time, the use of these rules is a matter of course. however, you are now facing multiple departments or even multiple units, and if you do not explain the rules of communication clearly, you will suffer losses in the future. the following thing seems boring, but it actually works: the first is to prescribe how and how information flows and the medium, whether to push or pull. push means that the project manager will proactively release information, whether by phone, email or in writing, to ensure that the information is communicated to everyone. this situation is suitable for small projects and there are few people.
What ra means is that the project manager is a web server, and you need any information you need to ask him. of course, no project manager makes himself so tired, he will use the way to publish information to the public media to publish information, simple is a whiteboard, a little more complex is the project's public information interaction area, the unspoken rule is that i sent you not to see do not say that i did not tell you. it seems boring to say this, but in fact, it involves the responsibility for incomplete information transmission. of course, these refer to the general way, and do not absolutize, in general, active communication and passive access are present at the same time, especially for leaders, project managers should take the initiative to communicate with leaders. the second problem is the documentation problem, many people are afraid to write documents, but the project manager must keep in mind the truth that "good memorability is not as good as bad writing". why is it sometimes unclear that there is a reason?
it's because there's no evidence. therefore, the project manager must clearly explain to the customer that some documents must be signed, such as the project manager's project log, at least let the customer sign every week, and all the things that reach consensus, such as meeting minutes, and even the leader's speech records, must be written into documents, signed by both sides, so that when they are torn off in the future, they can be documented.
Remember: what is said is the same as what is not said, and it is only after writing it down that everyone signs it. there are also some problems, such as the report you submit, to the leader (including the leader of the party and the customer leader) to do a multiple choice question, the result of the leader suppressed the approval, so that you are at a loss, the result is to delay the progress. at this time, you can wait, but pay attention to keeping a record of whose responsibility it is; in addition, if you agree with the leader at the beginning stage: if you do not get a reply from the leader after three days of submission, you will take the initiative a lot.
Another example is the approval process of different events: what level of things are recorded in the project log, what level of things need to be signed by the project managers of both sides, what level of things need to be signed by the leaders of both sides to sign the contract attachments, and so on. the more thoughtful you think in advance, the more proactive you will be in your future work.
9. Okay, a lot of upfront work has been done.
Some rules of the game have been defined, and now it's time to sit down and plan. In this section, any project management book will be better than me, so I will write less and say something about my own experience. The first is to find a few key team members, such as customer business experts, system analysts, etc., to do the project module division work. The project is divided into several blocks to do, what is done in each block, how the information between the modules is exchanged, and so on. Requirements define the question of what to do, and here we are talking about how to do it. It's important to emphasize here: there are many ways to accomplish a goal, and you have to choose the one you know best, rather than looking perfect, which will reduce a lot of risk for your project. Sometimes the customer will be impressed by some kind of new technology, insisting that you adopt that new technology, you should tell him: you choose me to do this project, you should allow me to do things in my favorite way, the new technology is tempting, because there are not many people who suffer losses, and I don't want you to be the first victim. Adopting a plan will make your work more clear, such as with Microsoft's Project software, after you fill out the form, you can know how many things to do in the project, what resources are needed for each thing, what the relationship between them is, how long it takes, what signs are there after completion, etc. All the results end up in a form called a Gantt chart.
Once you've done this table, you'll be surprised to find that the end time of the project on the Gantt chart will be far behind your planned end time (the person who signed the contract will never ask for your opinion first). Of course, people who have studied project management will talk a lot about WBS, optimizing paths, and so on, but my experience is that you can't optimize these things until the end of the planned time. If you don't have this problem, before I congratulate you on picking an easy job, please make sure you list all the things to do and the time it takes to properly assess them. At this point, you have to consider sacrificing the time (which also means quality) of some tasks. According to what criteria to sacrifice? The strategy of this project! The strategy we mentioned in section III. My experience is that if you catch up with everything, the result may be that you don't do a good job of ten things, think about how much failure. So, invest resources on things that you are familiar with and are sure of, and the final result is ten things, you have three things made into a boutique, three completed, and four delayed for some reason, is the report card a lot more beautiful? Strategy determines priorities, and the right prioritization of things is the main embodiment of a project manager's ability.
10. Okay, now that the project has completed the preliminary work.
Understand the objectives of the project, figure out the resources at hand, formulate the project strategy, and then prepare the overall plan of the project, the project has entered the implementation stage.
Entering this stage is the time when the project manager is more idle, unlike the early days when the project manager has to contact different people like a reporter, figure out what they are talking about, try to guess what they are thinking and their real purpose, that is the most tiring thing. Of course, the project manager of a small project is often a resource himself, and he has to do a lot of things, which is more bitter than anyone else. The main job of the project manager during this time is to maintain communication with the customer leader and his own leader. When communicating with customer leaders, pay special attention, unless you need the other party to give you support, then you need to be specific, otherwise, tell him that everything is normal, and the attitude should be positive, do not say some details that the leader does not understand, such as: "Director Wang, the recent progress of the project is quite normal, that is, the JVM often has some memory leaks..." Director Wang: "(*&$@@@". And their own leadership report should also pay attention to this problem, unless he is a technical master, you need his technical experience, otherwise generally report whether the progress is normal and when there is a problem, your countermeasures and plans can be, some need his support, such as resource calls need to say a little more detailed.
In addition to some project progress tracking meetings, there are many seminars that require everyone to use brainstorming methods to solve problems. Many of the participants are technicians, who are characterized by attention to detail, lack of big picture view, a bit of negativity and pessimism, and strong self-esteem (if the summary is not correct, everyone is welcome to clap the bricks), so as long as you are responsible for asking questions and recording their views, you must not be the role of judge. A problem, there are many aspects, from different points of view, the phenomenon is completely different, think of the story of the blind man touching the elephant.
These technologists, who are often well versed in one aspect, express their opinions on their own perspective, and unless there are some very specific cases, you should think that the program they propose is the most reasonable from their point of view. Your strength is to grasp the priorities of things and assess the priorities of various aspects in order to come up with a suitable (rather than the right) plan based on their opinions. Therefore, in the meeting, you must fully respect everyone and his opinion, praise those who have a better opinion, and never bring the meeting into endless arguments (you want to let everyone know that things are not black and white, but pluralistic, alas, the disaster of our education... ）.
After the meeting, you write your own documentation and make a decision. At the meeting, everyone's face is taken care of, the resistance to their own implementation is small, if there is still an opinion, you will talk to him privately, if you can't convince him, you have to let him understand, because you are responsible for this project, you take the risk, so this priority should be judged by you. The top level of the organization is not necessarily higher than that of the average member, but he has to bear the risk of the organization, coupled with the asymmetry of information, so the judgment of the priority of things is definitely better than that of subordinates.
the final deliverable must be able to be checked, for example, [interface requirements: beautiful, concise and bright], this requirement i do not know how to check. so, when assigning tasks to the development team, you have to think about how to check the results, for example, i have seen a plan, there is a task [developers are familiar with ejb programming], this task, in addition to letting these people go to some professional certification exams, otherwise, the results are difficult to check. therefore, always consider how to check the results, how to deliver to the customer is the project manager has always been concerned about the thing, i heard that some old project managers get the project is inverted plan, that is, first look at how to accept and acceptance criteria, and then decide the work plan. many projects have been started for a long time, and they do not know how to accept them, so the possibility of problems in this project is very large. doing projects is for acceptance, our role is not to be a research institute, our purpose is to get results after paying so much labor.
in addition, i will interject: i am extremely not advocating customer site development. in particular, a large group of technical personnel communicate directly with customers, which can easily cause conflicts and contradictions (determined by the nature of technical personnel). my approach is for project managers and project implementer to be on site, and software developers are still doing projects in the company. the project implementer is the junior project manager, they know their own products, understand some of the customer's business, the key is that they have good communication skills, commonly known as "thick skin". they are a bridge between customers and r&d personnel, and their career direction is also very flexible, and they can have many directions to turn in the future, which is much wider than the developer's path.
11. next, let's talk about the most vexing issue of requirements change.
There are usually two kinds of changes: one is that the original goal is partially changed, that is, the requirements change; the other is that the goal has not been changed, but the customer is not satisfied with the current implementation method, from the implementation of the process to the layout of the interface. this situation is difficult to avoid, mainly due to insufficient communication in advance and the client slowly figured out the problem and changed the previous thinking as the project progressed. at this point, if you need to change and your strategy allows this to happen, note the following:
make sure that the previous document is the thing that records the previous conclusion, whether the customer has signed, if not, quickly stop your work, quickly confirm your plan with the customer himself, and then let him sign to avoid speaking without credentials later;
sit down with the client and discuss what the fundamental purpose of his revision is, and is there a choice that can achieve the same purpose but come at a lower cost to you?
(the initial work of the project) to clarify the change process, generally the customer designates a person to sign (otherwise each customer leader has the right to insert a lever, you are abolished), submitted to you in the form of a formal project document, and then, you do an assessment analysis, analyze the impact on cost and schedule, after your leader agrees, issue a corresponding opinion, mainly to explain the reasons for the change of design and point out the uncertain consequences (this thing is written out first, and if it really happens later, at least it is not your fault). then ask the customer to sign on it. ever seen a hospital waiver that allows family members to sign before operating on a patient? yes, just learn that and make everyone realize that any change has a cost and a cost.
12. after the end of the system development.
It will enter the customer training, system acceptance stage, at this stage, i will generally pay attention to the following problems:
first, before training customers, pay more attention to some superficial efforts. many programmers believe that whether the logical core of the system is correct is the key, as for how the interface is, whether the words on the interface are accurate, it is an irrelevant issue, and the training is also handy, thinking of where to say where, the following people who listen to the lecture do not know what to do, cloud mountain fog cover, the training effect can naturally be imagined. my experience is that in the version of training for customers, if you are still not sure whether the logic is correct after doing many tests, then you should at least spend a little more effort on the interface. pay attention to the layout of each interface, the wording, the correctness of the links, etc., in short, do not let the customer see something that he should not see. for documentation, prepare at least two documents:
User manuals and training manuals. much of the content of the two documents is consistent, but the angles are completely different. the user manual is often from the perspective of the system designer, according to their own ideas, sub-modules to explain the operation and function of the system; and the training manual, must stand in the customer's business personnel's point of view, according to each role to face the handling of different business, how to achieve the goal by using a series of functions of the system. therefore, before the first training, whether the system interface is complete and correct, whether the training documentation is complete are very critical factors, the first shot does not sound, and there will be a lot of trouble later
as a project manager, you actually have a few things in mind: what to do, to what extent, how to deliver, the resources on hand, and the priorities of each thing. the so-called fast and good province is the dream of human beings, these four aspects are contradictory, belonging to the typical type of wanting horses to run and horses not to eat grass. consider the priority of the problem, often put the fast in the first place, the leaders of all parties will give you the deadline, so the progress is the first; the province is the second, the fundamental purpose of the enterprise is to make a profit, if the income can not increase, at least the cost should be controlled; good is the third, no way, who wants to keep improving, but, there is no strong resource guarantee, the quality has to be sacrificed first; finally more, the customer's requirements are endless, how to reduce the customer's expectations, getting them from their ideals back to reality is also the job of the project manager.
before acceptance, in addition to doing a good job of documentation and delivering results, it is important to spend more time figuring out the customer's process of doing things, which has been mentioned earlier, and will not be said here.
My biggest experience with acceptance is the issue of proof. that is, don't make customers think: you must have evidence that your system is fine. so you're out of the way, microsoft has so many geniuses, made xp and patched every day, and your program is fine, neither possible nor can you come up with evidence. you want to let the customer understand that the so-called acceptance, that is, i run through the test cases according to the test documents, the results and the expected results should be counted as passed, and some small errors are allowed to be corrected after acceptance, and he can give comments on the test cases.
Therefore, before acceptance, both parties should confirm the test plan and test cases. if he believes that the system does not meet the requirements, then he should prove that the system deviates from the original design. therefore, with reference to legal concepts, do not invert the evidence. in addition, the idea that the system is perfect to accept is also wrong, the software development contract must indicate the cost of the maintenance period after acceptance, otherwise, the customer is worried that once the acceptance will not get your support, naturally do not cooperate with the acceptance, then, your project manager will be difficult to pay homework.
No comments:
Post a Comment