Something clients and colleagues ask me from time to time is, “how can we ensure that when we outsource a project we obtain the same or better result than if we ran it ourselves?”

Having been at both ends of the outsourcing rope (a supplier and a consumer), I tell them that if some basic principles are followed and respected, the results can be excellent.

So what’s the secret? Below I give a few pointers I’ve learned from experience. They are mostly common sense, but common sense makes more sense when we see it as a list, so here it goes:


1. Shop around


There are software developers of all sizes and backgrounds and choosing one can be difficult. Ask for recommendations from peers (LinkedIn is great for that), call a few suppliers and ask them about their past experience. Have they done work for companies similar to yours? Or with similar requirements? Can they name clients that would be prepared to provide a reference in confidence? Look at the strategic importance of your project and try to choose according to that. Cheap will not always be appropriate.

[Bargain: a transaction in which each party thinks he has cheated the other – popular joke]


2. Big is not always better


Throughout my more than 25 years working in the field, I have dealt with large consultancies at various levels. They very obviously have a fundamental place and might be the only ones capable of delivering certain kinds of projects on time and within guidelines, but they are not for all kinds of projects, regardless of the size of your organization.

I have seen very good and very bad work done by large consultancies. I have seen them suffering from some of the same issues that are supposed to come with outsourcing to smaller suppliers: loss of knowledge when staff leave, insufficient level of skill, difficulty to temporarily replace a fundamental resource, etc. These are not problems inherent to large consultancies, it is simply the nature of the industry, but I just want to point out that size is no insurance per-se.

I would say that experience in your field of need and length of time providing services might be a better indication of ability to deliver, especially in short to medium project duration.

[“Your clients aren’t important to your business; they are your only business” – this and other good advice for consultants here]


3. Make sure you formalize the requirements


Vague or incomplete statement of requirements has to be the main cause of projects failing or coming close to failing.

There is really no option; you have to make all efforts to make it clear to you, your team, and the supplier; what you want done, and within which parameters. If you or someone in your team don’t have the time to document what you want in full detail, get another external resource to do it, whether a third party or even someone provided by the supplier. Interpreting and documenting requirements is part art, part science and a good challenge.

Here I don’t necessarily mean a formal requirement specification, but some form of documented evidence of what you expect to obtain. It is up to you how detailed you make it, but be willing to accept that the gaps will be filled by someone else in the supplier side; hopefully someone with the right skill and experience.

What if you don’t know in full detail the full extent of your requirements? You can make a provision for this in the contract and embed discovery activities in the plan, or you can split your project and run a pre-project with the purpose of discovering and documenting the requirements.

[“I do not always know what I want, but I do know what I don’t want” – Stanley Kubrick]

Once you formalize the requirement, make sure you also follow principle number 4 below.


4. Do not add last minute requirements


On behalf of my fellow developers, contractors and freelancers I beg you: do not add last minute requirements. Professional project managers and developers will strive to prevent scope/feature creep, and you must respect this. If you just missed an essential feature, by all means do your best to negotiate, but accept it if its inclusion causes additional time or fees. Scope creep is another regular cause for project failure.

This said, it is important to distinguish between scope creep [sad face] and scope discovery [happy face]. As mentioned in the previous tip, the project may include activities intended to discover the requirements or their detail, and that’s ok [like].


5. Keep in touch with your supplier throughout the life of the project


Communication is important. Demand progress reports and constant show-and-tell sessions. Frequent evaluation will make sure the project stays on track and that the solution being built actually addresses your requirements.

The level and method of communication will vary greatly depending on the complexity and duration of the project, how much control you have – perhaps the project manager is a member of your staff, the methodology of the supplier and more.

[Side note: property developers in Australia provide a great example of how a project should be communicated; if you’ve bought an empty lot and got one of the large builders to build you a house you will know what I mean. Expect the same from your project supplier]


6. Manage risks


A focused project planning period and constant communications will help you and your supplier identify possible risks. Having a plan in case something goes wrong will save headaches and minimize the risk of delays or budget overruns [The sooner you fall behind, the more time you’ll have to catch up – project management joke]

Some project managers and consultants are particularly good at lateral-thinking and problem solving [ahem, ahem]. Beware of workarounds that amount to corner cutting though. Ideal risk management removes the risk or its impact on the project, and doesn’t create new bigger risks.


7. Test, test, test


You are not meant to be a professional tester, and even if you have a QA team, your supplier HAS to include factory acceptance testing (verification that the solution does what it is meant to at the supplier’s premises) as part of their delivery plan. When you get a deliverable, it should be reasonably free of bugs. I’m being cautious here, nobody is perfect, but you are not meant to be trapping bugs on behalf of your supplier, unless that was the arrangement.

Once you have the solution in your hands, conduct a detailed and formal site acceptance test, involving as many of the likely users and stakeholders as you can. This is mostly intended to verify that the solution built fully and correctly satisfies each and every requirement as stated at the start.

Make sure the contract includes a reasonable bug-removal period.

[“that’s not a bug, that’s a feature” – unattributed one-liner]

There are other many principles that will make it possible to run successful outsourced projects. Things can get more “fun” when the outsourcing is done to a company that resides out of your country: coming soon Adventures in Offshoring!