I'm just a victim.
In 1956, I predicted that Fortran would not last for three years, but this was the first of the many major mistakes I made in my career. Let me tell you how I almost made another big mistake.
Difference between failure and success
When I worked at IBM's system R & D center in 1961, I led a group of students to study software development projects that had declared failures. One project manager interviewed by the students sums up all the factors that cause the failure of each project. After studying these factors carefully, I found that the only thing they have in common is bad luck. Such as flood in the computer center, popular colds, resignation of leading employees at critical moments, blizzard attacks, damage to original program files, and even a huge earthquake. Obviously, all these project managers are victims of natural law.
The student wrote a report to record this amazing and frustrating discovery. I made some changes, added my own views, and made several phone calls to the editors of the magazine for their opinions. An editor asked me why I didn't need to speak in a positive tone about the common factors of all successful projects.
「 We have not studied any successful projects .」 I said.
「 So, how do you know that those projects are not lucky ?」 (Click)
That "click" is a disconnection of his phone. After 1‰ seconds, my brain turned to me. We immediately pulled back the report and found a group of students to perform a similar survey on successful projects. Each of these projects, in the same way, has encountered some natural disasters, but they have completely different results.
In particular, after the computer center is also attacked by fire, the two institutions have completely different responses. If one project is declared as a complete failure, but other projects can be recovered, the difference lies in the different disposal methods:
1. backup of all original programs has already been stored somewhere outside the company, so it is not affected by the fire. However, even if the project fails to be backed up, it is not regularly executed as required.
2. The hardware uses a standard architecture, so the damaged part can be replaced without consideration. However, failed projects use close to standard hardware to save thousands of dollars.
3. All members of the project are willing and capable of working overtime to deal with the aftermath, file replies, and organize project documents. However, in a failed project, about two employees took the fire as an opportunity and excuse for another job.
4. Since everything had to be restarted in any case, the successful project took the opportunity to seek help from consultants and use the fire as an opportunity for restructuring. However, the only opportunity you can see in a failed project is to push the failure responsibilities that everyone considered difficult to remove before the fire to the fire.
In short, it is not the event itself that produces different results, but their response to the event. The response of a successful project is to acknowledge that you are taking bad luck and then take responsibility for recovery, and even seize the opportunity to take advantage of some of the advantages brought by this disaster. On the other hand, a failed project will seize the opportunity to make itself a victim. As a manager said, "What can I do? The entire office is burned to ashes .」
Victim's tone
Since that time, I have never taken over the case of another computer center's advisor, but of course there are still many projects that have encountered other troubles to help me. During these cases, I always pay attention to hearing the voice of the victim in the manager's mouth. If I hear anything, I will create an effect map with these self-declared victims and clearly mark all time points that may require human control.
A typical victim tone is that a manager will say, "I can't do anything if the project is lagging behind, because Brooks' Law says it's impossible for me to increase manpower rather than lag the project any more .」 Let's examine and see how to turn the voice of the victim into the voice of the controller.
As a project manager, she found that the project began to lag behind after the addition of staff. At this time, edera can continue to send staff, but this will create a positive feedback loop. If there is no management intervention, such a loop will not appear, as we can see in Figure 6-4. When they asked me for help, the first thing I did was to explain to edella why the decision she made was the culprit of making the situation worse. This practice convinced her not to add more personnel, but I want to express it more than that.
Figure 8-2 (Note: Figure omitted) shows how I re-plot Figure 6-4 (Note: Figure omitted, let her use it to emphasize that in some places it is controlled by her.
Manually determining the time point is to find a way to increase manpower without interfering with the work of experienced employees or increasing the burden of coordination. It is the responsibility of edera to find such a method, but it is still an easy solution. Once she realizes that she is not actually a helpless victim, she takes some steps to control the effect of "number of new recruits" on "completed productive work. First, she assigned some new recruits:
Review design and program code
Modify project files
Design Test Cases
When other staff need help
In this way, although she continues to add new users (this is based on her own choice, as shown in the gray square in 8-3 (Note: Figure omitted ), however, she makes the effect of the new employee positive (represented by the white human control block in 8-3 (Note: Figure omitted ). At the same time, she added some work burden to experienced staff, but she had control over this. She issued strict commands, it is stipulated that no one may go to experienced persons to discuss the issue without her consent. This partial control of the effect of the number of new recruits on the total amount of work to be completed is shown in Figure 8-3 (Note: Figure omitted) it is represented by the gray and gray symbols.
In short, edera is responsible for "creating your own law", represented by the new effect chart in the 8-3 diagram. In contrast, if you prefer the determination of natural laws, I can recommend a law related to human behavior, which also has the natural predictability. Whenever you say
"I can't do that." What you said will always be right. But the trouble is that sometimes you become a useless victim.
I don't want to hear any negative things.
Even if managers are willing to take full responsibility for the control actions they take, they will still not be able to do well unless they have the correct observation results and are able to take actions. Correct observation won't happen without any reason. It can only be achieved through painstaking efforts to make decisions by the management class.
Peter is a software development manager. On the surface, he still knows about the software development process, but when dealing with the crisis caused by poor program quality, he keeps making improper interventions. After investigating several of Peter's projects, we found that the cause of his improper decisions was not his poor judgment, but his information related to the true state of software quality, this can easily lead to incorrect interpretations.
What causes poor information quality? When a project begins to experience quality problems, people would rather take actions that undermine the correctness of the report because they are afraid of making the problem truthful and report unmeasurable consequences. For example, the test engineer solves the problem on the spot, instead of reporting the problem through the formal pipeline. Second, the person in charge of the test team will revise the severity of the problem downward when categorizing the problem. Third, after the programmer corrected several program errors, he wrote in the report that many software functions were abnormal due to a program error. The director of the program design team will try to classify many abnormal software phenomena as "Incorrect customer interpretation of documents" or "faults in the operating system 」. Such classification will distract people from focusing on the program design team. Finally, the project manager will "adjust" the software fault report to explain in the "most favorable" direction.
These practices generate a bunch of reports that mislead others. No controller can make intelligent interventions based on such reports. To show Peter what we think is true, we plot the positive feedback loop in Figure 8-4.
|
Figure 8-4. Fear of the potential consequences of Truthfully reporting bad news will lead to deliberate distortion of software fault reporting, making it unlikely for managers to take meaningful interventions. This leads to a positive feedback loop for poor quality. |
When Peter saw this effect chart, his response was in the voice of the victim: "Well, if this is the real situation, I am helpless. You see, there is no manual point in time in this loop. When there are a lot of problems, the average person will naturally fear the truth and report the truth. In addition, if they are really scared, they will always find a way to make things look better. If the report I got is incorrect, and there is nothing I can do to show my excellence. If I was not a good manager, quality Problems will inevitably emerge one by one. Therefore, according to your own model, I stuck it in a positive feedback loop .」
Peter also said part of the truth. If Figure 8-4 is a complete dynamic graph, it cannot be saved. However, a manager can always add something to the system to create a brand new graph. The two of us work together to figure out the effect diagram shown in the figure 8-5, which adds a possibility that managers (maybe accidentally) those who provide correct measurement data for quality problems will be punished, and such feedback will be called "negative statement 」. This practice will create another feedback loop, that is, to reinforce the inherent fear of "handing over a report that seems bad.
|
Figure 8-5. A possible response from the Manager to the quality issue report is to punish the reporter. The other difference is to reward the right report. This may not eliminate the fear, but it helps to control the fear. |
Although the second feedback loop seems to make things worse, it does provide a time point that is manually determined to make things "worse" or "better" controllable. Managers do not have to punish those who provide "correct but unpleasant information. If the punishment is imposed on the reporter, it will lead to paralysis of the Information System. Why not take some steps to reverse this effect and reward the correct report? Reversing the effects of such punishments will create a stable negative feedback loop, which not only prevents the natural fear of correct reporting, but also prevents the situation from being completely out of control.
I hope I can report to readers that Peter has corrected the error immediately, but how can he do it? As we have seen, non-linear conditions like this are not easily reversed. It takes many years to build trust, but it takes only a moment to destroy it. Peter really launched a management training program with a special focus on communication skills. He was the first to sign up and set up a good example.
I worked as a consultant at Peter's company for a long time, long enough to hear that he had changed his strong language, however, it is not enough to see whether he has succeeded in removing Mode 2 "depending on negative statement as taboo. In all cases where fear is the main variable, preventive work is naturally sixteen times easier than treatment. It is easy for people to fall into the fear of making the worst response to their superiors. Therefore, they do not need powerful dynamic graphs to trigger this fear.
In the following chapters, we will give many examples to illustrate that such unintentional or non-deep-knowledge management decision-making methods will create a positive feedback loop, and thus lead to irreparable productivity. More importantly, we will also see how managers who can make conscious and deep-knowledge decisions can create negative feedback loops, and finally restore the original productivity-it may also prevent the same situation from happening again.