20 secrets of successful project management

The secret of successful project management is difficult to manage software projects under the best circumstances. Unfortunately, many new project managers are essentially not trained on their posts. There are 20 successful management experiences for the project manager's reference.

1. Define criteria for successful projects(Note: Both parties should communicate with each other in a clear and consistent manner)
At the beginning of the project, it is necessary to ensure that risk owners have a unified understanding of how they determine whether the project is successful. Often, meeting a predefined schedule is the only obvious success factor, but there must be other factors, such as increasing market share and obtaining a specified sales volume or sales volume, obtain the satisfaction of a specific user, eliminate a legacy system with high maintenance requirements, obtain a specific transaction processing volume, and ensure correctness.

2. Identify project drivers, constraints, and Degrees of Freedom
Every project needs to balance itsFunctionality,Personnel,Budget,ProgressAndQuality Objectives. We define every aspect of the above five projects as a constraint. You must operate on the constraint or define the driver corresponding to the project success, or define the degree of freedom to pass to success. You can adjust it within a specified range. For more information, see Chapter 2 in my creating a Software Engineering Culture (Dorset House, 1996.

3. Define product release standards(This standard should be determined with the customer, which can be clearly measured and signed by both parties)
In the early stage of the project, determine the criteria used to determine whether the product is ready for release. You can set the release standard based on the number of high-priority defects, performance metrics, and specific functions that can be fully applied, or other aspects that indicate that the project has achieved its purpose. No matter what standard you choose, it should beMeasurable and documentedAndConsistent with the "quality" that your customers refer.

4. Communication commitment although there is pressure to commit events that are impossible, never make a commitment that you know you cannot guarantee.
Communicate with the customer and management personnel about what can be actually obtained, and have a good reputation. Data from any of your previous projects will help you make convincing arguments, although this does not really defend against unreasonable people.

5. Write a plan(Note: the plan needs to be modified and confirmed after being communicated with the responsible person)
Some people think that it is better to spend time writing a plan.CodeBut I don't think so. The difficult part is not writing a plan. The difficult part is to make this plan --Think, communicate, weigh, communicate, ask and listen. The time it takes you to analyze and solve the problem will reduce the project's future surprises.

6. Split the task into small circular stones in inches.
An inch-sized round stone is a milestone for narrowing down. Breaking up large tasks into multiple small tasks helps you estimate them more accurately and expose work activities that you might not think of in other situations, it also ensures more accurate and fine-grained status tracking.

7. A common large task Development Plan Worksheet (Document and standardize knowledge)
If your group often undertakes certain general tasks, such as implementing a new object class, you need to developActivity check list and schedule Worksheet. Each check list should include all the steps that may be required by this large task. These checklists and worksheets help the team members determine and evaluate the workload associated with each instance of the big task they/She must handle.

8. modifications should be made after the quality control activities in the plan(The essence of Quality Management: how to write, How to Write)
Almost all quality control activities, such as tests and technical reviews, will discover defects or other possibilities for improvement. Your project progress or work breakdown,The modifications made after each quality control activity should be included as a separate task.. If you don't actually need to make any changes, it's good that you are already in front of the plan for this task. But don't count on it.

9. Schedule for process improvement(There is a line: writing code is a kind of work, and debugging code is also an art)
Your team members have been drowned in their current project,If you want to upgrade your group to a higher level of software engineering capability, you must invest some time in process improvement.. Set aside some time from your project progress because software project activities should include process improvements that can help your next project be more successful. Don't invest 100% of the time your project members can use in project tasks, and be surprised why they are not making any progress in active improvement.

10. Manage project risks
If you do not identify and control risks, they will control you.. Spend some time in project planning to discuss possible risk factors, assess their potential hazards, and decide how you can mitigate or prevent them. For a brief guide to software risk management, see myArticle"Know your enemy: Software Risk Management" (Oct. 1998 ).

11. Estimate based on the work plan rather than calendar
People usually use calendar time for estimation,I tend to estimate the number of Work Plans associated with tasks (in person-hours),Then convert the work plan to the calendar time estimation.. This conversion is based on how many hours I have spent on project tasks every day. I may encounter any interruptions or sudden adjustment requests, meetings, and all other places that will make time disappear.

12. Do not schedule more than 80% of their time(There are already a lot of 80% users. It is recommended that the number of skilled users be no more than 70%, and that the number of new users be lower)
It is surprising to track the average number of hours your team members actually spend on the specified work in the project per week. AndThe overhead of task switching related to many activities that we are requested to do significantly reduces our work efficiency.. Don't just assume that someone spends 10 hours a week on a particular job. Assume that he or she can do four of these jobs right away. If he or she can finish three jobs, you are lucky.

13. Put the training time in the plan to determine your team members
How much time is spent on training each year, and deduct it from the available time for the team members to work on the specified project task. You may have earlier lost the vacation time, illness time, and other time in the average value. You must also handle the training time.

14. Record your estimation and how you achieved the estimation
When you are about to estimate your work, record them and record how you complete each task..Understanding the assumptions and methods used to create estimates makes it easier to guard against and adjust them when necessary, and it will help you improve your estimation..

15. Record estimation and use estimation tools
There are many commercial tools that can help you estimate the entire project. Based on the huge database of their real project experience, these tools can give you a possible schedule and staffing options. They can also help you avoid entering the "impossible Area", that is, the product size, group size, and schedule. If they are combined, there is no known project success. The estimate pro of software producticentre (www. SPC. ca) is a good tool.

16. Follow the learning curve

If you try a new process, tool, or technology for the first time in a project, you must acknowledge the cost of reducing productivity in the short term. Do not expect amazing benefits from the first attempt of the new software engineering method, and consider the inevitable learning curve in the schedule.

17. Unexpected buffering considerations(As the saying goes: the plan cannot catch up with changes)
Things won't be as accurate as your project plan, so your budget and schedule should include unexpected buffering at the end of the main phase to adapt to unexpected events. Unfortunately, your manager or customer may use the buffer as a filler, rather than wisely admitting that this is true. It indicates some unpleasant accidents of the previous project to illustrate your foresight.

18. record the actual situation and Estimation
If you do not record the actual working time spent on each task and compare it with your estimation, you will never be able to improve your estimation capability. Your estimation will always be a guess.

19. The task is considered completed only when task 100% is completed.(The West man said: the end is the beginning; the ancients said 90 steps and a half)

One benefit of using an inch-sized xiaoyushi is that you can differentiate whether each small task is completed or not completed, this is much more than the estimated percentage of a large task completed at a specific time. Do not let people simply ignore the completion status of their tasks; Use clear standards to determine whether a step is actually completed.

20. Publicly and fairly track the project statusTo put it simply, ensure that someone reports bad news in a timely and real manner without any harm.
Create a good atmosphere, so that project members are safe to accurately report the status of the project.. Efforts should be made to allow projects to run on an accurate, data-based basis, rather than a misunderstanding of optimism arising from fear of reporting bad news. Use the project status information to perform corrective operations when necessary,And give praise when conditions permit. These tips cannot guarantee your success, but they will help you to gain a solid lead in your project, make sure that you have done everything you can to make the project succeed in this crazy world.