"Classic errors" in software development project management"

Some inefficient management practices are still adopted by many people, resulting in completely predictable bad results. These practices are called "classic errors ". Most "classic errors" have an attractive appearance. Do you need to save a project that lags behind the schedule? Then increase manpower. Do you want to reduce the schedule? Make the schedule more tight. A key person in the team angered the rest of the team? Stir-fry him after the project is over. You have a very urgent project to complete? Let's gather all the available human resources to start work. The sooner the better!

Developers, administrators, and customers usually have good reasons to explain what they do. So the tempting appearance of these "classic errors" is also the reason why they repeatedly make such errors. However, because the "classic error" has already happened many times, its results are predictable. These results are obviously different from the expected ones.

This chapter lists 36 "classic errors". I have met each error at least once, and many of them have also been committed by myself. You will identify these errors from Case Study 3-1.

The common cause of these errors is that if you want to avoid them, your software project cannot be developed quickly. But if you don't want to avoid them, you are doomed to slow development.

If you are familiar with some mistakes, you may have made them too. Don't worry. Cheer up. Because many people make the same mistakes, and once you understand the impact of these errors on your development speed, you can control risks when making a plan.

Some errors will be discussed in the corresponding sections of this book, and some will not be further discussed. For easy access, these "classic errors" are classified into four aspects: Personnel, process, product, and technology.

Personnel

Here are some typical personnel-related errors.

#1: uncertain incentives

Countless research shows that incentives are likely to be the most effective measure to increase product output and quality (Boehm 1981 ). In Case Analysis 3-1, the implementation of management is filled with uncertain incentives. At the beginning, it was an excited conversation with false intentions. In the middle, employees were asked to work overtime, and the managers finally enjoyed a long vacation, while employees had to continue working during the holidays, it's just a small bonus.

#2: Poor Personnel Management

After the incentive, the impact on product production is not determined by the individual abilities of the team members, but by the relationship between the team members (Boehm 1981, Lakhanpal 1993 ). Recruiting the least qualified employees will threaten the company's efforts for rapid development. In the case study, the criteria for personnel selection are who can be found as quickly as possible, and who will be admitted, rather than taking the criteria based on who has the strongest ability. Although this approach enables the project to be quickly launched, it cannot be completed quickly.

#3: employees with uncontrolled Problems

If the problem is not handled properly, the employee's working speed will also be affected. This type of error was widely understood by managers after Geral weberger published the book computer programming psychology in 1971. Unhandled problem employees are often the most common reason why team members complain about their leadership (Larson and lafasto 1989 ). In Case Analysis 3-1, the entire team knew that chip was not a good guy, but the team leader turned a blind eye. The result -- redo the chip job -- is foreseeable.

#4: heroism

Some software developers think that it is very important to emphasize heroism in project development and think that heroism is very beneficial (Bach 1995 ). However, in my opinion, to emphasize heroism in any form, there are often more disadvantages than advantages. In the case study, middle-level managers have given higher rewards to those who think they can do as long as they can, but those who pay attention to stability and long-term success have received lower rewards. The result is that the marginal policy implemented in the work did not discover and understand the urgent problems faced by the Organization until the last minute, and report it to the superiors. A small development team has mastered the company's killing power because they do not want to admit that they cannot finish the task on schedule. The emphasis on heroism promotes a trend of great risk, which weakens the cooperation between stakeholders in the software development process.

When some managers overemphasize the "can do it successfully" attitude, they will produce actions that emphasize heroism. When a project manager reports a higher attitude than a precise status report, they do not fully utilize their capabilities to take the right measures. They do not even think they need to take the right measures until the loss has been caused. As Tom Demarco said, the "can be done successfully" attitude magnified originally a small obstacle into a real disaster.

#5: Add manpower to the project to be expired

This is perhaps the most common "classic error. When a project lags behind and progresses, it is not necessary to work out the existing team members, but to increase production by increasing manpower. Fred Brooks compared this behavior to "adding fuel to the fire" (Brooks 1975 ).

#6: noisy and crowded offices

Most developers are not satisfied with their work environments. About 60% of people think that their work environment is neither quiet nor private enough (DeMarco and Lister 1987 ). Staff with quiet and private workplaces will be better at performance than those in noisy and crowded places. A noisy and crowded environment will delay the work schedule.

#7: Conflicts between developers and customers

Such conflicts may come from many aspects. When a developer is unwilling to sign a project schedule set by the customer or fails to fulfill their commitments, the customer may think that the developer is not cooperative enough. The developer may think that the customer is too unreasonable to adhere to the unrealistic project progress or modify the clearly defined requirements. Therefore, personal attacks or slander may occur between the two groups.

The main impact of such conflicts is the lack of communication and communication, which includes a lack of understanding of the needs and unsatisfactory user interface design, even worse, Customers refuse to accept products that have been completed. On average, conflicts between customers and software developers often result in a serious breach of the contract between the two parties to cancel project development (Jones 1994 ). This kind of conflict is very time-consuming and will attract both parties from their real work.

#8: unrealistic expectations

One of the most likely causes of conflicts between developers and consumers or managers is unrealistic expectations. In Case Analysis 3-1, if not for the company, Bill has no reason to believe that the giga-quote project may be developed within six months. Mike's failure to correct this unrealistic expectation is the main source of the problem. In other cases, the Project Manager or developer applies for project funds based on an overly optimistic Project Schedule estimate. Sometimes they make promises that cannot be guaranteed. Although unrealistic expectations do not spontaneously increase the project schedule, they still create the illusion that development takes too long, which can make things very bad. A Standish Group survey shows that expectations that are close to reality are one of the five main factors to ensure the success of commercial software development projects (Standish Group 1994 ).

#9: lack of effective project sponsorship

High Level project sponsors can ensure efficient project development in many aspects, including real-world planning, permission change control, and new development implementation operations. Without such an effective project sponsorship, other higher-level personnel management forces you to accept unrealistic deadlines in the Organization, or be forced to accept changes in some reduction projects. Australian consultant Rob thomsett said the lack of effective project sponsorship is actually doomed to a project failure (thomsett 1995 ).

#10: lack of stakeholder involvement

All major members of software development must join the project, including execution sponsors, team leaders, team members, marketing departments, end users, consumers, and all other stakeholders. Close cooperation only occurs when all stakeholders join the group, thus ensuring the smooth development of the project.

#11: lack of user participation

Standish Group survey shows that the main reason for the success of the is project is that its users are actively involved in the development of the project (Standish Group 1994 ).

#12: putting power on the essence of www. myp

Larry Constantine reported on the four teams and said they had four power centers (Constantine 1995a ). "Political" teams tend to "manage up", that is, they pay more attention to the relationship with their upper-level leaders. The research team focuses on reconnaissance and information collection. "Isolated" teams are self-centered and draw boundaries with non-team members. The "general-purpose" team does everything: they have a good relationship with their superiors, conduct research and collect information, and coordinate with other teams in the work process. Constantine reported that the "political" and "general-purpose" teams were initially valued by superior leaders, but after a year and a half, the "political" team was beaten into the cold Palace. Therefore, putting power above results is fatal for efficient development.

#13: wishful thinking Project Management Forum

I was surprised why many problems in software development were ultimately attributed to wishful thinking. You have heard the following statements several times:

"No member in the team thinks they can complete the task on schedule, but they think that if everyone works hard, nothing will go wrong, plus a few lucky vacations, I believe they can complete the task smoothly."

"Our team hasn't integrated several parts of the product yet, but we will communicate effectively in other posts, and the interfaces between these parts are relatively simple, therefore, it takes only one or two days to fix the problem."

"We signed a database subsystem contract with them in a way that falsely reported a low price, and to complete these tasks, we need considerable human resources, which is very difficult for them, because they do not have qualifications in this field, they may be able to use more energy to make up for experience shortcomings. Maybe they can finish the task on time ."

"We don't need to show customersProgramI'm sure this is what they want ."

"The team said they would work very hard to complete the task on schedule. Although they had been delayed for a few days at the first critical time point, I believe they could do it on time ."

wishful thinking is not optimistic, but close your eyes to expect something that has no reason to believe in its existence. This idea will cause great trouble in the final stage of the project. It not only weakens meaningful plans, but it is likely that this software project has more and more complex problems.