10 Ways To Insure Project Failure

Take a look at the excelent 10 Ways To Insure Project Failure

1. Set Unrealistic Goals
2. Staff Up Quickly
3. The More Documentation The Better
4. You Can Always Make Up a Schedule Slip Later in the Project
5. Relax Your Standards To Shorten the Schedule
6. Micromanage
7. Call a Daily Project Status Meetings
8. Threaten Team Members to Motivate Them
9. Bring In More Programmers
10. Set Your Plan in Stone

Amazingly well written and extraordinarily common, I lost the count of projects I've seen making several of these mistakes at once. Some even managed to get them wrong all at once!

The most terrible projects had 150 analysts and outsourced the design and the coding to Argentina.

Back to the doomed project:

• Groups of up to 5 analysts drawing UML instead of writing use cases. That should be clearly a sign of trouble.
• The screen mockups and the database model are not embedded in the use cases.
• The coding and the design is not iterative, which means designers wait for all the analysis to be finished before sending the design back.
• Standards? Who needs that?

Another doomed project:

• Daily status meeting taking full 5 hours for just 11 developers. That leaves you with 4 hours to do your work and the next day explain you didn't have the time because of these meetings.
• Crappy computers for everyone. Tomcat takes 15 minutes to start up.
• New hires don't go through an screening process that included a test that measured their actual Java skills. People who can't reverse an String are hired.
• No source control.
• No continuous build.
• No machine to test the system.
• Unclear goals.
• Having 2 bosses with different projects asking you to work on different stuff and dividing your day in 5 minute increments for diffrent projects.
• Fixing stuff from other projects which were totally unheard of, at least 3 different each day.
• One of the bosses goes out on vacation so you think you are going to become really productive now, but now his 2 bosses came asking stuff directly to you, so now you have 3 bosses at once (courtesy of matrix management).

Another doomed project:

• The company is CMMI certified, which means you have to write a lot of documents before doing any change to the code. Some people take a look at the documents and they correct only the looks, since they don't understand what the project is about.
• The quality of the overall project in actually much worse than before it was vertified, since the company is concentrating on the wrong goals like passing the new certification and having pretty documents.
• The manager is changed because the project is late and the new manager begins to replace everyone under his supervision.
• Some modules of the project are working, but the new manager requires that all modules be rewritten from scratch.