Deliver late or less: best options for a behind-schedule project?

Delivering late: a viable option for behind-schedule projects?
(photo credit: marcp_dmoz)

Projects that are behind schedule are usually faced with the following options:
1. Add more staff to the project
2. Work longer hours, including doing overtime and burning weekends (Ouch...)
3. Work people harder, expect more out of the same number of hours.  Employees might do this by reducing interaction time with other employees, or some might cut corners, like do less documentation, testing.
4. Cut scope, i.e. deliver less
5. Do nothing and deliver late

A poll of 50+ mid-career professionals showed that in their workplaces, the preference is for option #1, #2 and #3.

However, research into this area showed that option #1-3 generate negative "side effects" that can develop into vicious cycles having major impacts on the project.  For example, by adding more staff, the average experience of the team is diluted, lowering the productivity of the team and also causing more errors in work done.

The key though is the vicious cycle, or in technical speak, feedback loops.  Continuing on the earlier example, the generated errors can create more errors downstream, for example think of the situation when software is implemented based on erroneous requirements.  Consequently, though there are more people in the team, the team gets less work done than before.  Similar arguments apply for the other two options.

Model showing "side effects" of various approaches to catch up on late schedules
Credit: Professor James M. Lyneis

Does this mean option #4 and #5 are the best options? i.e.  deliver the project late or deliver it with less scope?  Not always so, but my key thought is we need to give those options more considerations.  And to educate our project stakeholders that those are not cop-out options, especially when we bear in mind all the vicious cycle side effects presented earlier.