Many software projects commit suicide. How? Here are a few gruesome ways.
- Not enough calendar time is allocated. High-quality software takes time. Throwing lots of people at the problem may get the project done faster but there will be many rough edges in the final software. Will customers accept that?
- The team is understaffed. This forces team members to wear many hats and perform jobs they either don’t like or aren’t good at. Quality will suffer as a result. Is that a price you are willing to pay?
- The budget is too small. Lack of funding will force the team to cut corners. This will cause a variety of headaches. The scope must align with the budget. Small budget, small scope.
- The wrong people are assigned to the project. Often a project team is cobbled together based on who happens to be available. The resulting software will have a cobbled together look and feel to it.
- The toolset is not up to the task. Skimping on tools is as bad as skimping on people. Enterprise-scale applications require enterprise-scale tools. That includes configuration management and automated test tools.
- Compromising on quality in order to meet time, scope or budget goals. Some managers deny that quality is a variable. It is and it should be tightly controlled.
- The process is overbearing. The process should fit the project. Subjecting a departmental project to the overhead and discipline of a major enterprise project will overburden the team and slow everyone down.
These problems aren’t easy to avoid. If you find yourself facing project suicide, you have to find negotiating room. For example, if calendar time is fixed, try to get scope flexibility. If the scope is fixed, try to get added funding. If the people mix is wrong, try to get training or coaching help.
Have you been on a suicide project? Tell me about it.