Conventional wisdom says that when a software project is in trouble, adding resources will only make it later.  In many situations, though, that’s just not true.

We’ve found that there are specific patterns where help from outside can make a dramatic positive difference in a project.  Here are three such patterns:

• Missing key skills or experience. Sometimes the current project team is “figuring things out as they go.”  If it’s your own folks, then you will often (though not always) know this ahead of time and have planned for it.  Where things go sideways is when an outside vendor doesn’t staff your project appropriately; worst, you may not know until a good ways into the project.  The good news is that in this situation, bringing in people who’ve “been there, done that”  can get you headed in the right direction quickly.  In some cases the properly-skilled team can work alongside the existing team, preserving continuity; in other cases it’s more appropriate to have the new folks take over entirely.  What you want to look for here: a) the right expertise, obviously; b) humility and collaborativeness, as evidenced by lack of NIH; c) creativity, to leverage as much as possible of what’s already been done; and d) the honesty to tell you which parts can’t be salvaged.
• Subdivide and offload. Take a look at the activities your team is doing.  Are the most time-consuming tasks also the most valuable?  If not, check whether these time-consuming tasks are difficult to offload to someone else.   For example: one company’s developers and testers were spending a lot of time debugging false-positive test failures.  There was a medium-term fix, which was to stabilize the test suite for reproducibility (see the next pattern), but while that was in progress there was a need for a couple of engineers who could separate the real bugs from the test artifacts, ideally overnight (so offshore time zone was an advantage, not an impediment).  Spinning up that activity immediately gave the core team 40% of their time back.  In some ways this pattern is the opposite of the missing-skills pattern.  For missing-skills you bring in help for the hardest parts of the project (or at least the parts that are hardest for your current team, because of their experience gap), while for subdivide-and-offload the help is often for the easier or less interesting parts of the work.  What you need here: a) a team that has a well-oiled process for Knowledge Transfer (KT); b) a a time-consuming activity that your team really needs to offload.
• Technical debt. In the example above, the unreliable test suite was a textbook case of technical debt.  Technical debt is all the stuff that slows your team down relative to how fast you could go if you had done it.  Some types of tech debt reduction can be hard to parallelize – for example, a pent-up need for refactoring.  But other types of tech debt can absolutely be addressed by additional resources working in parallel with your core team.  Tooling and automation of all sorts.  Test backlog – stabilizing the environment, automating manual cases, adding coverage.  Bug backlog.  Static analysis warnings.  When a project get late these sort of hygiene activities often get sacrificed, which creates a vicious cycle that ends up making you even more late.  Getting help from outside can keep things from getting worse.  What you want here: a) ideally, a shop with expertise in tech debt reduction; b) at minimum, strong capabilities in tooling and automation; c) good communication skills, to understand your existing system and start adding value quickly.

When a project is going badly it’s tough to decide whether to power through with the existing approach or make a change.  As in other areas of software engineering, we’ve found that patterns – like the above – can help.