If the methodology is poor or non-existent, you should be able to reduce development time by improving the methodology being used.

If code reuse is bad, you may be able to decrease development time by improving either. Repeated code is much more more expensive to maintain (even during development) and highly fragile (often one copy gets missed in the patching). Identifying and refactoring reused code when a bug is being repaired limits the overhead for existing code, and quickly gets you to one copy of problematic repeated code.

Using existing frameworks and libraries rather than developing the functionality in-house can also decrease development time.

Adding resources can be counter productive. I managed one project where additional developers were added in attempt to meet a deadline. This was highly unhelpful as new developers weren't productive, and existing developers ended up spending a lot of time helping them instead of developing. Removing the new developers was the solution.

As other have noted, all other things being equal you are stuck with the iron triangle. Consider these options:

• develop the minimal usable system by the original schedule (reduce scope).
• remove or reassign the least productive team members  (reduce communications overhead).
• buy part of the solution (frameworks and libraries mentioned above count)
• overtime or time shifting (getting some key components developed at the right time may pay off). Regular overtime tends to be counter-productive.
• identify and remove blockers. The best project managers I have worked with ensured solutions were provided as soon as possible. Identifying and removing future blockers helps even more.

If tihe methodology is poor or non-existent, you should be able to reduce development time by improving the methodology being used.

If code reuse is bad, you may be able to decrease development time by improving either. Repeated code is much more more expensive to maintain (even during development) and highly fragile (often one copy gets missed in the patching). Identifying and refactoring reused code when a bug is being repaired limits the overhead for existing code, and quickly gets you to one copy of problematic repeated code.

Using existing frameworks and libraries rather than developing the functionality in-house can also decrease development time. This can reduce both development and testing time.

Adding resources can be counter productive. I managed one project where additional developers were imposed in attempt to meet a deadline. This was highly unproductive as new developers weren't productive, and existing developers ended up spending a lot of time helping them instead of developing. The new developers were quickly assigned to other projects.

As other have noted, all other things being equal you are stuck with the iron triangle. Consider these options:

• develop the minimal usable system by the original schedule (reduce scope).
• remove or reassign the least productive team members. (Reduce/reassign costs.) This reduces communications overhead and may speed up development.
• buy part of the solution. (Increase cost.) Frameworks and libraries mentioned above count.
• overtime or time shifting (Increase cost.) Getting some key components developed at the right time may pay off. Regular overtime tends to be counter-productive so don't rely on it.
• identify and remove blockers. (Increase immediate cost.) The best project managers I have worked with ensured solutions were provided as soon as possible. Identifying and removing future blockers helps even more.
• add appropriate tools. (Increase cost.). I am constantly amazed that managers don't invest in productivity enhancing tools.
• add a wiki, or other communication tool. This can improve communication and consistency across the project. It can take some work to convince all the team members that the wiki documentation belongs to the project and not the author. Everyone should feel free to update the project documentation there. '