Deadline theses
Original Source: Tom DeMarco “Deadline. A novel about project management ”
I tried to squeeze all the “salt” out of a not so bad, in my opinion, book on project management. Spread to the public.
')
1. If a person does not feel safe, he will resist change.
2. Changes are necessary for the manager to succeed.
3. Uncertainty causes a person to avoid risk.
4. Avoiding risk, a person misses all the new opportunities and benefits that could bring him change.
5. Threats - the most inappropriate kind of motivation, if you are concerned about the performance of employees.
6. Whatever you threaten, the task will not be completed anyway, 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. For guidance, we need 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 cause the failure of the project, and not just the final risks.
13. Assess the likelihood and cost of each risk.
14. For each risk, determine the indicator - a symptom by which it can be determined 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 rather by reducing unnecessary effort than by striving to
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 already existing and well-established teams.
20. Leave the teams to work together even after the project is over (if they themselves want it), so that the managers who have replaced you will have fewer problems with badly working teams.
21. Consider that a team that wants to continue to work together in the future 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 are 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 process of work.
25. Discuss these models.
26. Determine the size of each project.
27. Do not be zealous at first with the choice of the unit of measurement - if you later have to work with real data, to begin with, abstract units will also come down.
28. Build complex metrics based on simple (those that are easy to calculate in any software product).
29. Collect archival data to read productivity on already completed projects.
30. Work on formulas for calculating complex synthetic metrics until the results obtained most accurately reflect the relation of abstract units to the amount of work specified in the archived data.
31. Swipe through the entire archive database trend line, which 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 in determining the expected scope of work.
33. Do not forget about the “noise level” on the performance line and use it as an indicator when determining tolerances 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. Attempting to implement more than one improvement in methodology is a bad thing. Programs aimed at improving many of the techniques and skills are likely to lead to the fact that the timing will only increase.
37. The danger of a standardized development process is that, after routine operations, people may not notice an opportunity to save time and effort to develop a project.
38. With regard to excessively large teams, there the standardized process will be strictly followed as long as it allows everyone to feel at work (no matter if the project is beneficial or not).
39. You can not get people to do something differently, if you do not care about them, if you are not interested in them. In order for them to change, you must understand (and appreciate) them themselves, what they are doing and what they are striving for.
40. People do not begin to think faster if the leadership will put pressure on them.
41. The more overtime, the lower the productivity.
42. A little pressure and overwork can help focus on a problem, understand and feel its importance, but long-term pressure is always bad.
43. Perhaps the leadership likes to apply pressure so much because it simply does not know how else to influence the situation, or because alternative solutions seem too complicated to them.
44. Awful guess: pressure and overtime are designed to solve only one problem - to keep a good face on a bad game.
45. The ambiguity of the specification indicates that there are unresolved conflicts between the project participants.
46. The 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 involving several parties is bound to encounter a conflict of interest.
48. The process of creating and distributing software systems is a hotbed for all sorts of conflicts.
49. In most companies where software is created, no one specifically deals with the issue of conflict resolution.
50. Conflict deserves understanding and respect. The 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 this is the case.
52. Difficult to negotiate. It is much easier to mediate.
53. Declare in advance that if the interests of the conflicting parties are completely or partially opposite, then the search for a solution will be shifted to the intermediary.
54. Do not forget: we are on one side of the barricades. On the other side is the problem itself.
55. There are people-catalysts. They help create a healthy team, relationships, morale. Even if they did nothing more (and as a rule, they do much more than that), their role in the project remains one of the most important.
56. It seems to us that the most terrible thing is not to know something. In fact, it is much worse to be sure that you know, when in fact it is not.
57. The terrible assumption: it seems that those teams that do not put tight deadlines, finish the job faster!
58. Meetings should be small. To do this, you need to make sure that people are not afraid to skip unnecessary meetings. 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: in work fear = anger. Those leaders who like to shout at their subordinates and in every way humiliate and insult them, in fact, they are simply very afraid of something.
61. Sometimes waiting is the only way out. Try to wait until the problem resolves on its own or until you find a way to get away from it.
62. Miracles, of course, happen, but it is better not to count on them.
63. Anger and stinginess - this is the formula that those who are responsible for business failures are beginning to apply in bad companies.
64. Anger and stinginess are directly opposed to the true goals of any good company - to be generous and caring towards their employees.
I tried to squeeze all the “salt” out of a not so bad, in my opinion, book on project management. Spread to the public.
')
1. If a person does not feel safe, he will resist change.
2. Changes are necessary for the manager to succeed.
3. Uncertainty causes a person to avoid risk.
4. Avoiding risk, a person misses all the new opportunities and benefits that could bring him change.
5. Threats - the most inappropriate kind of motivation, if you are concerned about the performance of employees.
6. Whatever you threaten, the task will not be completed anyway, 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. For guidance, we need 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 cause the failure of the project, and not just the final risks.
13. Assess the likelihood and cost of each risk.
14. For each risk, determine the indicator - a symptom by which it can be determined 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 rather by reducing unnecessary effort than by striving to
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 already existing and well-established teams.
20. Leave the teams to work together even after the project is over (if they themselves want it), so that the managers who have replaced you will have fewer problems with badly working teams.
21. Consider that a team that wants to continue to work together in the future 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 are 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 process of work.
25. Discuss these models.
26. Determine the size of each project.
27. Do not be zealous at first with the choice of the unit of measurement - if you later have to work with real data, to begin with, abstract units will also come down.
28. Build complex metrics based on simple (those that are easy to calculate in any software product).
29. Collect archival data to read productivity on already completed projects.
30. Work on formulas for calculating complex synthetic metrics until the results obtained most accurately reflect the relation of abstract units to the amount of work specified in the archived data.
31. Swipe through the entire archive database trend line, which 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 in determining the expected scope of work.
33. Do not forget about the “noise level” on the performance line and use it as an indicator when determining tolerances 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. Attempting to implement more than one improvement in methodology is a bad thing. Programs aimed at improving many of the techniques and skills are likely to lead to the fact that the timing will only increase.
37. The danger of a standardized development process is that, after routine operations, people may not notice an opportunity to save time and effort to develop a project.
38. With regard to excessively large teams, there the standardized process will be strictly followed as long as it allows everyone to feel at work (no matter if the project is beneficial or not).
39. You can not get people to do something differently, if you do not care about them, if you are not interested in them. In order for them to change, you must understand (and appreciate) them themselves, what they are doing and what they are striving for.
40. People do not begin to think faster if the leadership will put pressure on them.
41. The more overtime, the lower the productivity.
42. A little pressure and overwork can help focus on a problem, understand and feel its importance, but long-term pressure is always bad.
43. Perhaps the leadership likes to apply pressure so much because it simply does not know how else to influence the situation, or because alternative solutions seem too complicated to them.
44. Awful guess: pressure and overtime are designed to solve only one problem - to keep a good face on a bad game.
45. The ambiguity of the specification indicates that there are unresolved conflicts between the project participants.
46. The 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 involving several parties is bound to encounter a conflict of interest.
48. The process of creating and distributing software systems is a hotbed for all sorts of conflicts.
49. In most companies where software is created, no one specifically deals with the issue of conflict resolution.
50. Conflict deserves understanding and respect. The 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 this is the case.
52. Difficult to negotiate. It is much easier to mediate.
53. Declare in advance that if the interests of the conflicting parties are completely or partially opposite, then the search for a solution will be shifted to the intermediary.
54. Do not forget: we are on one side of the barricades. On the other side is the problem itself.
55. There are people-catalysts. They help create a healthy team, relationships, morale. Even if they did nothing more (and as a rule, they do much more than that), their role in the project remains one of the most important.
56. It seems to us that the most terrible thing is not to know something. In fact, it is much worse to be sure that you know, when in fact it is not.
57. The terrible assumption: it seems that those teams that do not put tight deadlines, finish the job faster!
58. Meetings should be small. To do this, you need to make sure that people are not afraid to skip unnecessary meetings. 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: in work fear = anger. Those leaders who like to shout at their subordinates and in every way humiliate and insult them, in fact, they are simply very afraid of something.
61. Sometimes waiting is the only way out. Try to wait until the problem resolves on its own or until you find a way to get away from it.
62. Miracles, of course, happen, but it is better not to count on them.
63. Anger and stinginess - this is the formula that those who are responsible for business failures are beginning to apply in bad companies.
64. Anger and stinginess are directly opposed to the true goals of any good company - to be generous and caring towards their employees.
Source: https://habr.com/ru/post/159589/
All Articles