Project Pitfalls and Tips

---

1. Project description

• deliverables too vague, need for outline or examples

2. Management and organization

• team did not meet again for some time after initial meeting. Should have organized project so that everyone was involved in all phases
• team members did not show up for meetings so that if an interface had to be changed there were problems
• lack of coordination led to problems in integrating modules/classes, confused class interfaces
• used a "who is going to be the hero for this step?" approach leading to last minute decisions and lack of collaboration
• need for team manager to coordinate and use team members as resources
• need for team leader to facilitate division of labor
• division of responsibilities on a functional basis leads to unfair division of labor
• need for use of RCS (Revision Control System)
• very difficult to organize meetings and to communicate between team members because of other demands on time

3. Project planning

• project too ambitious, early risk analysis not thorough enough
• should have built a basic system first and then added enhancements

4. Risk assessment

• project kept changing and risk analysis was skimped on, leading to later problems that could have been thought out beforehand

5. Evaluation

• reviews: not enough and poorly attended - resulting in inconsistent designs
• not thorough enough, operational problems not uncovered
• prior preparation for reviews was non-existent

6. Defect reporting

• wide variety, how to know which ones to report? Reticence at reporting.

7. Requirements and specifications

• too vague, need for details to ensure consistency between modules.
• customer made drastic changes, such as using a new programming language (Java) late in the game
• lack of good specifications lead to changes being made late in the process
• more detail in O/O requirements analysis would have led to better design and less effort in coding phase

8. Design.

• not thorough enough
• contained undesirable features. Need for more analysis and evaluation.
• detailed design not detailed enough
• need for better class interface design so that objects will support specific kinds of methods that may be needed by other objects, e.g. data access functions
• failure to do a good detailed design of user interface leading to problems like lack of user input error checking and recovery code
• design diagrams not detailed enough and did not adequately describe module interfaces

9. Programming -unfamiliarity with language: Java treatment of files

---

Successes

1. Management and organization

• decide who is best for what kind of activity (e.g. specifications, reports, coding, interface programming, etc.)
• modules were developed and coded in parallel, a team manager oversaw everyone's work to ensure consistency and successful integration
• it helped to use UNIX imake tool

2. Project planning

• planning cut the project down to a reasonable project, and we added some additional desirable features later on

3. Risk assessment

• many of the identified risks were encountered and their having been identified beforehand was very useful. e.g. specification of simpler design for fall back if schedule/time problems occur
• use of risk checklist made it possible to avoid problems
• risk analysis of loss of personnel made it possible to deal with sick team members

4. Evaluation

• design reviews cleaned up questionable design features
• strong unit testing meant modules were very reliable when put together to make the system

5. Defect reporting

6. Requirements and specifications

7. Design

• good design made coding go smoothly
• easier system integration
• initial abstract system model made it possible to consider different possible uses of system
• good design made it possible to add features later on
• thorough design allowed parallel development with collaboration only needed at certain points like integration rather than continuously
• detailed design made coding easy

8. Programming

• use of Java eliminated problems such as third party data types which often do not work
• common background and expertise in C++ made cooperation easier

---