November 21, 2012 at 11:45Deadline Abstracts
Source: Tom DeMarco “Deadline. A novel about project management ”
I tried to squeeze all the“ salt ”out of the not-so-bad, in my opinion, book on project management. I post it to the public.
1. If a person does not feel that he is safe, he will resist change.
2. Change is necessary for the leader to work successfully.
3. Uncertainty makes a person avoid risk.
4. Avoiding risk, a person misses all the new opportunities and benefits that could bring him change.
5. Threats are the most inappropriate kind of motivation if you care about employee productivity.
6. No matter what you threaten, the task will still not be completed if from the very beginning you took too little time to complete it.
7. Moreover, if people fail, you will have to fulfill your promises.
8. Leadership needs heart, gut, soul, and scent.
9. Listen more, speak less.
10. To manage a project, it is enough to manage its risks.
11. Create a risk list for each project.
12. Track the risks that are causing the project to fail, not just the ultimate risks.
13. Assess the likelihood and cost of each risk.
14. For each risk, define an indicator - a symptom by which you can determine that the risk turns into a problem.
15. Create accessible (possibly anonymous) channels for reporting bad news to management.
16. Reduce losses.
17. The success of the project can be achieved by reducing unnecessary efforts rather than striving for
new victories.
18. The sooner you stop unnecessary work, the better for the entire project.
19. Do not try to create new teams unnecessarily; Look in the team for the already formed and worked out teams.
20. Leave the teams to work together even after the end of the project (if they themselves want it), so that the leaders who replaced you have less problems with badly working teams.
21. Consider that a team that wants to continue to work together further is one of the main goals of any project.
22. The day we lose at the beginning of the project means as much as the day lost at the end.
23. There is a thousand and one ways to spend a day in vain and not one to bring this day back.
24. Model your assumptions and guesses about how the work process will go.
25. Discuss these models.
26. Define the size of each project.
27. Do not at first be zealous with the choice of the unit of measure - if later you have to work with real data, abstract units will come down to begin with.
28. Build complex metrics based on simple ones (those that are easy to calculate in any software product).
29. Collect historical data to calculate labor productivity for already completed projects.
30. Work on the formulas for calculating complex synthetic metrics until the results obtained most accurately reflect the ratio of abstract units to the amount of work indicated in the archive data.
31. Draw a trend line through the entire archive database that will show the expected amount of work in the form of a ratio of the values of complex synthetic metrics.
32. Now for each new project it will be enough to calculate the value of the synthetic metric and use it to determine the expected amount of work.
33. Do not forget about the “level of interference” on the performance line and use it as an indicator in determining the permissible deviations from the general trajectory.
34. A good development process and its continuous improvement are very worthy goals.
35. But there are still working goals and objectives.
36. An attempt to introduce more than one methodological improvement is a disastrous business. Programs aimed at improving many techniques and skills are likely to lead to the fact that the terms will only increase.
37. The danger of a standardized development process is that during routine operations, people may not notice the opportunity to save time and effort in developing a project.
38. With regard to excessively large teams, the standardized process will be strictly followed there as long as it allows everyone to feel at work (it does not matter whether it is useful for the project or not).
39. You can’t get people to do things differently if you don’t care about them, if you are not interested in them. For them to change, you must understand (and value) themselves, what they do and what they strive for.
40. People will not begin to think faster if management will put pressure on them.
41. The more overtime, the lower the productivity.
42. A little pressure and overtime can help focus on the problem, understand and feel its importance, but long-term pressure is always bad.
43. Perhaps management is so fond of applying pressure because it simply does not know how else to influence the situation, or because alternative solutions seem too complicated to them.
44. A terrible hunch: pressure and overtime work are designed to solve only one problem - to maintain a good face in a bad game.
45. Unclear specifications indicate that there are unresolved conflicts between project participants.
46. A specification in which there is no list of types of incoming and outgoing information should not even be taken into consideration. This means that it simply does not specify anything.
47. A project in which several parties are involved will necessarily face a conflict of interest.
48. The process of creating and distributing software systems is a hotbed of all kinds of conflicts.
49. In most companies where software is created, no one specifically deals with conflict resolution.
50. Conflict deserves understanding and respect. Conflict has nothing to do with unprofessional behavior.
51. Report to everyone that you will try to take into account the interests of all participants, and make sure that it is so.
52. It’s hard to negotiate. It is much easier to mediate.
53. Announce in advance that if the interests of the conflicting parties are completely or partially opposed, then the search for a solution will be shifted to an intermediary.
54. Do not forget: we are on one side of the barricades. On the other side is the problem itself.
55. There are human catalysts. They help create a healthy team, relationships, fighting spirit. Even if they didn’t do anything else (and as a rule, they do so much), their role in the project remains one of the most important.
56. It seems to us that the worst thing is not to know something. Actually, it’s much worse to be sure that you know when it’s actually not.
57. A terrible assumption: it seems that those teams that are not set tight deadlines finish work faster!
58. Meetings should be small. To do this, you need to make sure that people are not afraid to miss meetings that they do not need. The easiest way is to publish the agenda in advance, and then always strictly adhere to it.
59. Protect people from insults and abuse of the Authorities.
60. Remember: fear = anger in work. Those leaders who like to yell at their subordinates and in every possible way humiliate and insult them, are really just afraid of something.
61. Sometimes the only way out of the situation is waiting. Try to wait until the problem resolves on its own or until you find a way to get away from it.
62. Miracles do happen, of course, but it's better not to count on them.
63. Anger and stinginess - this is the formula that those who are responsible for business failures are starting to apply in bad companies.
64. Anger and stinginess are directly opposite to the true goals of any good company - to be generous and caring in relation to their employees.
I tried to squeeze all the“ salt ”out of the not-so-bad, in my opinion, book on project management. I post it to the public.
1. If a person does not feel that he is safe, he will resist change.
2. Change is necessary for the leader to work successfully.
3. Uncertainty makes a person avoid risk.
4. Avoiding risk, a person misses all the new opportunities and benefits that could bring him change.
5. Threats are the most inappropriate kind of motivation if you care about employee productivity.
6. No matter what you threaten, the task will still not be completed if from the very beginning you took too little time to complete it.
7. Moreover, if people fail, you will have to fulfill your promises.
8. Leadership needs heart, gut, soul, and scent.
9. Listen more, speak less.
10. To manage a project, it is enough to manage its risks.
11. Create a risk list for each project.
12. Track the risks that are causing the project to fail, not just the ultimate risks.
13. Assess the likelihood and cost of each risk.
14. For each risk, define an indicator - a symptom by which you can determine that the risk turns into a problem.
15. Create accessible (possibly anonymous) channels for reporting bad news to management.
16. Reduce losses.
17. The success of the project can be achieved by reducing unnecessary efforts rather than striving for
new victories.
18. The sooner you stop unnecessary work, the better for the entire project.
19. Do not try to create new teams unnecessarily; Look in the team for the already formed and worked out teams.
20. Leave the teams to work together even after the end of the project (if they themselves want it), so that the leaders who replaced you have less problems with badly working teams.
21. Consider that a team that wants to continue to work together further is one of the main goals of any project.
22. The day we lose at the beginning of the project means as much as the day lost at the end.
23. There is a thousand and one ways to spend a day in vain and not one to bring this day back.
24. Model your assumptions and guesses about how the work process will go.
25. Discuss these models.
26. Define the size of each project.
27. Do not at first be zealous with the choice of the unit of measure - if later you have to work with real data, abstract units will come down to begin with.
28. Build complex metrics based on simple ones (those that are easy to calculate in any software product).
29. Collect historical data to calculate labor productivity for already completed projects.
30. Work on the formulas for calculating complex synthetic metrics until the results obtained most accurately reflect the ratio of abstract units to the amount of work indicated in the archive data.
31. Draw a trend line through the entire archive database that will show the expected amount of work in the form of a ratio of the values of complex synthetic metrics.
32. Now for each new project it will be enough to calculate the value of the synthetic metric and use it to determine the expected amount of work.
33. Do not forget about the “level of interference” on the performance line and use it as an indicator in determining the permissible deviations from the general trajectory.
34. A good development process and its continuous improvement are very worthy goals.
35. But there are still working goals and objectives.
36. An attempt to introduce more than one methodological improvement is a disastrous business. Programs aimed at improving many techniques and skills are likely to lead to the fact that the terms will only increase.
37. The danger of a standardized development process is that during routine operations, people may not notice the opportunity to save time and effort in developing a project.
38. With regard to excessively large teams, the standardized process will be strictly followed there as long as it allows everyone to feel at work (it does not matter whether it is useful for the project or not).
39. You can’t get people to do things differently if you don’t care about them, if you are not interested in them. For them to change, you must understand (and value) themselves, what they do and what they strive for.
40. People will not begin to think faster if management will put pressure on them.
41. The more overtime, the lower the productivity.
42. A little pressure and overtime can help focus on the problem, understand and feel its importance, but long-term pressure is always bad.
43. Perhaps management is so fond of applying pressure because it simply does not know how else to influence the situation, or because alternative solutions seem too complicated to them.
44. A terrible hunch: pressure and overtime work are designed to solve only one problem - to maintain a good face in a bad game.
45. Unclear specifications indicate that there are unresolved conflicts between project participants.
46. A specification in which there is no list of types of incoming and outgoing information should not even be taken into consideration. This means that it simply does not specify anything.
47. A project in which several parties are involved will necessarily face a conflict of interest.
48. The process of creating and distributing software systems is a hotbed of all kinds of conflicts.
49. In most companies where software is created, no one specifically deals with conflict resolution.
50. Conflict deserves understanding and respect. Conflict has nothing to do with unprofessional behavior.
51. Report to everyone that you will try to take into account the interests of all participants, and make sure that it is so.
52. It’s hard to negotiate. It is much easier to mediate.
53. Announce in advance that if the interests of the conflicting parties are completely or partially opposed, then the search for a solution will be shifted to an intermediary.
54. Do not forget: we are on one side of the barricades. On the other side is the problem itself.
55. There are human catalysts. They help create a healthy team, relationships, fighting spirit. Even if they didn’t do anything else (and as a rule, they do so much), their role in the project remains one of the most important.
56. It seems to us that the worst thing is not to know something. Actually, it’s much worse to be sure that you know when it’s actually not.
57. A terrible assumption: it seems that those teams that are not set tight deadlines finish work faster!
58. Meetings should be small. To do this, you need to make sure that people are not afraid to miss meetings that they do not need. The easiest way is to publish the agenda in advance, and then always strictly adhere to it.
59. Protect people from insults and abuse of the Authorities.
60. Remember: fear = anger in work. Those leaders who like to yell at their subordinates and in every possible way humiliate and insult them, are really just afraid of something.
61. Sometimes the only way out of the situation is waiting. Try to wait until the problem resolves on its own or until you find a way to get away from it.
62. Miracles do happen, of course, but it's better not to count on them.
63. Anger and stinginess - this is the formula that those who are responsible for business failures are starting to apply in bad companies.
64. Anger and stinginess are directly opposite to the true goals of any good company - to be generous and caring in relation to their employees.