In my last blog post, I looked at how, contrary to popular perception, outsourcing actually reduces your business risks.
But, there are two main models of outsourcing work. One, to outsource a project (or process; something I won’t go into in this blog post) and two, to hire Virtual Employees.
Do both of these models reduce your level of risk equally?
Before I explain why, let me first briefly explain the difference between the two models.
The key characteristic of the project outsourcing business model is that you are no longer in control of your project. This is neither a good nor a bad thing. Whether you should or should not have control over your project depends on your particular circumstances. There are cases where you should and cases where you should not.
However, the key point is that when you outsource a project, you do not project manage it. You tell the vendor what you want, ‘I want ABC’, and the vendor, goes away and creates or builds for you ‘ABC’ on your behalf, within ‘x’ period of time. Project outsourcing is thus bound by time and scope. It is one project that has clearly defined beginning and end points.
In contrast, when you hire a Virtual Employee, the outsourcing company does not project manage your project. This model allows you to retain control over your project. Here the vendor’s responsibility is to provide you with a resource solution, as opposed to a project solution, i.e. here is the manpower you need, (and if the vendor is based offshore you gain by way of a significant cost-saving as well), but what you build with that man-power, is now entirely in your hands. Thus, unlike project outsourcing, Virtual Employees are not time bound. There does not necessarily have to be a defined end point, and VEs can work for you on multiple projects.
In my last blog post, when looking at how outsourcing can reduce your business risk, I shared a video clip from Malcolm Paice (COO of Keystone Employment Group, UK), who explained how hiring Virtual Employees helped to reduce his businesses project risk:
What does Malcolm mean by “removes risk… because you retain control” and “being held to ransom by an external third party”? What Malcolm is referring to here are the ways in which hiring Virtual Employees is a far safer method for building your project than project outsourcing it.
Transferring knowledge is a tricky affair. Putting what you are envisaging and thinking into the mind of another individual certainly is no easy feat.
There are two types of knowledge, explicit knowledge and tacit knowledge. An example of explicit knowledge would be 5 x 5. Explicit knowledge is defined, universal and unambiguous; it remains the same for all of us. And so because it can very easily be verbalized, transferring explicit knowledge is actually very easy.
An example of tacit knowledge would be how to cook ‘Louisiana-style shrimp’. Sure you can give me a set of instructions, but for precisely how long do I stir? What should the dish look like when I stop stirring? It’s hard for you to explain this through the written word and equally hard for me to know. Knowing when to stop ‘stirring’ is just something that comes from experience; you look at how it is done and you just know. This makes articulating this knowledge to another person in a set of written instructions very difficult. It is something that is easier for me to show to you than explain to you.
Hence, when you cook something from a set of instructions, it often doesn’t taste as it should, and secondly, it is also the reason why it is much easier to prepare a meal by watching a cooking show over following a recipe from a cook book.
Thinking from this tacit knowledge perspective, the issues with transferring knowledge when project outsourcing are obvious. When we project outsource, it is primarily undertaken via a project specification, i.e. it is documented. Clients write long and exhaustive specifications detailing what they want. The problem, however, is that:
In short, if the project you are outsourcing is even slightly complex (or has a fair portion of tacit knowledge), your chances of transferring knowledge 100% successfully are slim. Some portion is likely to get lost, misunderstood and/or poorly articulated. If the outsourcing company ends up misunderstands any portion of your project specification, the end result inevitably is not going to be what you desired. What can start out as even just a small misunderstanding, can, as a project continues to pick up momentum, cause further and further deviations from the original vision.
Because you do not collaborate on the project with the vendor, there is no feedback loop. There is no ‘corrective process’ or ‘fail-safe system’ that can quickly intervene and say ‘hey, you misunderstood XYZ and you are doing it all wrong – this is what I actually meant’. When the outsourcing vendor finally submits the end result several weeks, months and or sometimes even years later, you are shocked and aghast at how ‘what you wanted’ and ‘what you have received’ are worlds apart. As Malcolm put it – “end up in a battle with the supplier that hasn’t delivered what you thought.”
You see, the demand that the vendor should deliver what, rightly, was only requested at no extra charge. The outsourcing company, however, has an altogether different take on the matter. They have worked hard and clearly delivered what they believe was stipulated in the project documentation. If you want further changes, the outsourcing company demands that you pay for it. In such scenarios, deadlines are almost always missed and depending on the company you are working with, you might also have to fork out more money or as Malcolm put it, “you might be held to ransom.”
Sometimes, the issue with project outsourcing is not that the work that has been delivered is incorrect, but rather, the fact that the client considers it to be incomplete. A common point of contention between clients and project outsourcing companies is whether a ‘project add on’ is in actual fact an ‘add on’. Clients will often argue that the “additional work” the vendor is alleging, is not in actual fact, additional work at all, but rather work that was covered by the ambit of the original project specification. Vendors claim the opposite.
Again the issue once again is that due to the highly inefficient knowledge transfer process of project outsourcing, there is ambiguity about just what a ‘completed project’ truly looks like, due to the reasons mentioned above. In any case, irrespective of which party is at fault, it can result in missed deadlines and inflated budgets.
If your project has not succumbed to any of the above two pitfalls and your project was delivered as requested, on time and within the budget, there still remains one final pitfall you could be vulnerable to. And, that is of management, maintenance and upgrades (although, it should be mentioned that this generally is only the case with large, complex, software projects).
Say your software took an outsourcing company one year to develop. A hefty amount of work and expertise is tied into that project. But who has all the requisite knowledge and expertise? Yes, it is now all in the hands of the outsourcing company. Should your software need managing, maintain, changing or upgrading, who will do it? It will now be very difficult for you to do so, as you did not build the software.
It is highly impractical for you to turn to any other software company because coders are renowned for not wanting to touch the code of other software developers, (and this is understandable, it is a difficult and tedious undertaking) and so if you do turn to another vendor you could be looking at heavy rates. This leaves you with only one option, the initial company you outsourced the project to.
Now this is not to say that there will be a problem. You may not experience any issues at all. But, all your eggs will now be in ‘one basket’, so to speak. And the outsourcing company of course knows this too. If you thus want to make any changes or additions, (which invariably is the case with large bespoke software projects; as they say hindsight truly is a wonderful thing) you could be ‘held to ransom’. If the vendor ‘ups’ their rates, there really is not a lot you can do about it.
It is for the above reasons, that Malcolm stated that the Virtual Employee model ‘removes risk’. Hiring a Virtual Employee is exactly the same as hiring a local employee. The only difference is that you work with a VE remotely as opposed to face to face. Thus, the key point is that you project manage a Virtual Employee and regularly collaborate with him or her.
Because you directly project manage a VE, any changes, upgrades, modifications you want to make are totally at your discretion. The opportunity for ‘disagreement’ is completely removed from the process. You can move in whatever direction you want. Just imagine that you were working with a local team and were half-way through a project, but one fine day you woke up and simply decided that you wanted to add 5 more features to your end product. Would this be an issue with any of your staff? No, of course not (at the most, they might think it’s a bad idea, but they can’t stop you from implementing any changes). If you decided, randomly, out of the blue, that you want to add more features to your product, of course you can. Your staff will simply merrily continue their work on the project; they of course can’t and won’t turn around and say, “that’s going to cost you an extra ‘$x’.”
Similarly, you would never have any disagreements with your team regarding whether something was or was not there in the original plan, for even if someone did miss something, it makes no difference, you simply identify the misunderstanding and work to correct it on the project.
It’s exactly the same with Virtual Employees, as Malcolm said, with VEs, you “retain control”and by that he means you can take your project in any which direction you wish. This means you cannot “be held to ransom”unlike when project outsourcing.
Secondly, as with local employees, the knowledge transfer process with Virtual Employees is seamless. When you hire an employee, whether based locally or offshore, you, (or a manager) collaborate and communicate with your employee regularly, (maybe daily, maybe weekly). That’s exactly why you hire an employee. Regular collaboration and communication means there is, unlike when project outsourcing a regular feedback loop. The feedback loop is what makes the transfer of tacit knowledge possible.
Let’s go back to the cooking example that I mentioned earlier. Project outsourcing is the equivalent of your writing a recipe for your favourite lasagne, emailing it to me and then I cook it on my own based solely on the instructions you have provided in your email. Hiring an employee, (whether local or offshore) is the equivalent of us both being in the kitchen at the same time. I am making the lasagne and you are baking a chocolate cake, (i.e. as project manager you are also working on your own independent tasks). I still have your instructions with me but,
When you hire employees you interact with them; that is your responsibility as a team lead or manager. This ensures frequent two way communication or feedback and thus if any tacit knowledge has been misinterpreted, it enables it to be quickly corrected. If managers did not ‘check up’ on their team members’ progress for weeks/months on end then the results of in-house teams would be no different to that of project outsourcing vendors.
It is not that the knowledge transfer process does not fail when hiring local or Virtual Employees; no rather it is just that it quickly get corrected and this prevents the project from straying, (and this is why I said ‘seamless knowledge transfer’ above, for what I mean by seamless is that in the VE model tacit knowledge is pragmatically and ultimately, successfully transferred from one individual to another).
An employee may have misunderstood you, but you might nab this misunderstanding at the end of the day or the end of the week. Therefore, if the project goes off track you are very quickly able to bring it back on track within a matter of hours or days. In short misunderstandings only cause‘slight derailments’ and such instances won’t impact your project deadlines/budgets majorly because they are quickly identified and rectified.This is why Malcolm said Virtual Employees ‘reduce your risk.’ Because you are in control, you are able to ensure your project comes in on time and on budget. As Malcolm said of his project, an 18 month recruitment software portal, for which he hired 3 .NET Virtual Employees:
“We got all the functionality we wanted with some more that we didn’t have in our original brief. So we came in on budget, the project was delivered on time, and we successfully took it out to market. So it was a very good experience.”
In contrast, when project outsourcing; a ‘derailment’ might only be picked upon after a period of weeks/months and sometimes even when the project is being delivered! This of course will have catastrophic repercussions for your budget and deadline.
Hiring Virtual Employees is a significantly more secure model than project outsourcing, because, as Larry Spencer, the VP of Application Development at Sceris put it, “the (VE) business model aligns very effectively with what is already known to be an effective development practice. That model of course being that VEs are managed by us just as an employee here, (in the USA) would be.”
When you hire a VE, you are not reinventing the wheel but rather simply doing what you are already highly accustomed to doing. Thus, we can safely conclude that the Virtual Employee model is significantly safer than the project outsourcing model.
So, what about the rewards? While project outsourcing is more risky, if successfully executed, does it offer greater rewards? This shall be the topic of my next blog post: Project Outsourcing vs. Virtual Employees; Which Model Provides the Greatest Rewards?