Classic Mistakes Enumerated

Some ineffective development practices have been chosen so often, by so many people,
with such predictable, bad results that they deserve to be called "classic mistakes." Most
of the mistakes have a seductive appeal. Developers, managers, and customers usually
have good reasons for making the decisions they do, and the seductive appeal of the
classic mistakes is part of the reason these mistakes have been made so often. The
common denominator in this list is that you won't necessarily get rapid development if
you avoid the mistake, but you will definitely get slow development if you don't avoid it.
There are four main types of classic problems namely people, process, product, and
technology.

People

Here are some of the people-related classic mistakes.

#1: Undermined motivation: Studies have shown that motivation probably has a larger
effect on productivity and quality than any other factor. This shows that a team which is
lacking motivation will not perform up to its standards. Studies have proved this through
improved results when teams were motivated.

#2: Weak personnel: After motivation, either the individual capabilities of the team
members or their relationship as a team probably has the greatest influence on
productivity. It is the job of the project manager to design a team whose collective
capabilities are always greater then individual capabilities. But this is often overlooked as
it is a classic problem.

#3: Uncontrolled problem employees: Such employees are very dangerous for software
houses as they effect the whole teams performance. There are two main types, one are
those who are problem creators by nature and the other ones are those who have adopted
this nature due to non fair attitude. As a project manager it should be your effort not to let
any grievances take birth in your employee.

To tackle such problem creators you can involve them at the time of setting goals for
them. Like asking them when and what they will do, when will they submit it etc.

#4: Heroics: If some new person enters your organization and performs well then all of
the management suddenly makes him hero of the day. This might create grievances in
your old employees and they might start feeling ignored. The management should always
keep in mind that this world is being run by average people and not by special people and
that no average person shall be ignored.
#5: Adding people to a late project: This problem is created when the people who are
needed by the project are provided to it very late in time ( in emergency). In such cases
results are not that good as they would have been had the same people been added in
time. In Pakistan managers are always short of skilled people and they are not always at
liberty to appoint them at there own will. In such cases this problem can be avoided by
assigning part of your project or work to some other contractor, as appointment in a hurry
could result in you appointing wrong people for your company.

#6: Noisy, crowded offices: As software development is a job which requires a lot of
concentration, so the office environment needs to be good for a good outcome. Also now
a days this is a common practice in software houses that cubical are allotted to developers
instead of rooms, which also plays a part in the lack of concentration.

#7: Friction between developers and customers: Friction between developers and
customers can arise in several ways. Bad behavior of your customers, Customer being
afraid of there office automation due to fears of losing there job or getting exposed as a
bad computer user. Solution of these problems first of all needs good communication
between you and your customer. Also you will need lot of support from the top
management of your client and also you need to assure the end users that automation will
make there life easier rather than difficult.

#8: Unrealistic expectations: One of the most common causes of friction between
developers and their customers or managers is unrealistic expectations. Thinking of a pie-
in-the-sky without having any facts and figures in hand is what creates such problems. To
avoid such problems the software project manager should consider every project as a new
one.

#9: Lack of effective project sponsorship: Question here is that, if there was no project
sponsor then why was the project started? If there was a project sponsor and he is giving
off this project then this clearly indicates lack of professionalism at your end. You either
have not fulfilled his demands or you don’t have strong marketing skills.

#11: Lack of user input: The following all factors can contribute in this problem type

1. You asked for the right information from the wrong person
2. You asked for the right information from the right person but the time wasn’t
right
3. You didn’t ask for the information correctly
4. The person you asked information from was not willing to cooperate with you

#12: Politics: Putting politics over results is fatal to speed-oriented development. If the
company is directive i.e. the procedure of promotions is transparent etc then such things
don’t develop in the company. But its very hard to keep politics away from your
company.

#13: Wishful thinking: Wishful thinking isn't just optimism. It's closing your eyes and
hoping something works when you have no reasonable basis for thinking it will. Wishful
thinking at the beginning of a project leads to big blowups at the end of a project.

Process:

Read and check#14: Overly optimistic schedules. The challenges faced by someone
building a three-month application are quite different than the challenges faced by
someone building a one-year application. Setting an overly optimistic schedule sets a
project up for failure by underscoping the project, undermining effective planning, and
abbreviating critical upstream development activities such as requirements analysis and
design. It also puts excessive pressure on developers, which hurts developer morale and
productivity. This was a major source of problems in Case Study 3-1.

#15: Insufficient risk management: Some mistakes have been made often enough to be
considered classics. Others are unique to specific projects. As with the classic mistakes, if
you don't actively manage risks, only one thing has to go wrong to change your project
from a rapid-development project to a slow-development one. Failure to manage risks is
one of the most common classic mistakes.