I was talking to a CIO last week about his desire to “tune” his IT Operating Model. I asked about the symptoms he was observing that he’d like to see eliminated through the Operating Model tuning. His answer was one I’d heard many times – but that did not lessen the passion that came across in the dialog:
When we have a project run by one of our outsource partners, it generally comes in on-time, within budget, and meets the specifications we requested. When we take on a project internally, none of those conditions are typically met! I’d like to see our internal resources as capable at delivery as the outsourced partners!”
The Secrets to Outsourcer Success
I’ve found that there are several reasons for the gap between outsourced and internal project performance – some obvious, others more subtle:
1. Outsourcers live and die by their performance – it’s their business. They are paid for results. This leads to several typical characteristics:
- Results are articulated very clearly – and are rigorously managed to.
- People are held accountable for results. Failure to deliver has real consequences.
- Scope – and the client – are carefully and skillfully managed. If the scope changes, so does the project schedule, cost and performance expectations.
Compare these characteristics with those of the typical internal resource. Results are often vague and unstable. The old cartoon comes to mind of the project leader leaving a room of programmers, looking over her shoulder and saying, “I’ll go up and find out what they want – the rest of you start coding!” A caricature, of course, but one earned deservedly! People are generally not held accountable in any real sense. HR policies and fear of depressing morale and engagement render most managers impotent when it comes to accountability and consequences. And scope often changes frequently as business clients discover more about their real needs and constraints. Nothing inherently wrong with that, but schedule and cost should have been renegotiated but typically are not – unless there’s an outsourcer running the project!
2. Outcourcers typically dedicate resources to a project – internal resources in an IT organization typically work on many projects at the same time. Even worse, they are often expected to simultaneously perform project work and service delivery work, which is often hard to predict and frequently requires an urgent response.
The productivity and quality cost of this type of multi-tasking has been demonstrated time and time again. Ever since the Coding War Games, led by Tom DeMarco and Timothy Lister (see their wonderful book, “Peopleware: Productive Projects and Teams“) in the late 1970s, key factors that impact project productivity have been studied, illuminated and verified. There’s a plentiful supply of data about how long it takes a project team member to “re-engage” with his project, and the consequent productivity loss of this type of multitasking behavior.
3. Outsourcers typically have projects managed by very seasoned Project Managers working to a consistently practiced and proven project methodology.
Yes, I know this is supposedly the case with in-house resources, but from my experience, it often does not hold up in practice. Just about anyone can acquire the title “Project Manager“, whether or not they actually have the skills. Certifications such as PMP theoretically mitigate this, but I’ve seen PMP-qualified resources somehow forget everything they learned about project management once they get into the heat of battle – presumably due to the effects of 1. and 2. above.
What To Do to Improve Inside Project Performance?
There is no magic to this:
- Articulate clear expected results.
- Hold people accountable, and ensure that consequences are made real – both for excellent performers (e.g., promotion, recognition, added responsibility to train and coach others) and for poor performers (e.g., performance related intervention, demotion or reassignment, termination.)
- Manage scope. This does not mean forcing the business client to live with a spec that may be unacceptable – but it does mean renegotiating cost and schedule when performance needs change.
- Recognize that most project work is a full time role – dedicate project resources and isolate them from the day-to-day demands of service delivery.
So, why don’t these things happen? I don’t know – you tell me!



I agree that there’s a perception that this phenomenon to exist… outsourcers tending to deliver project scope on schedule, and budget, and (perhaps) at the quality level expected – when they have a proven project methodology. What’s not clear to me, is if in fact in-house resources fail to meet similar expectations particularly when given the same constraints. Indeed, they seem to meet or exceed realistic expectations.
For example, I’m in the market to execute an ERP migration, and I have two options. One is to go out and get bids for the project, and the other is to look at in-house resources to execute the same project. The outsourced partners all have proven project methodologies that they use to execute these type of migrations, month -in, and month-out… because it’s their core business. They have deep technical expertise in the areas that matter, and my reasonable expectation is for them to deliver the project to the design that I bought. Now, my alternative is to utilize in-house resources to execute such a ERP migration. My in-house team has an excellent track record of delivering project success where we’ve invested in building a project methodology. However, in the case of an ERP migration they simply do not have the “applied” or operational experience with all components of the ERP stack. When I ask them to build a scope, schedule, and budget – what data are they using to derive that? The answer is, they’re not using any data…. they’re throwing darts at a wall based on their decade of infrastructure experience, and they’re guessing at their ability to deliver the solution. They have no possible idea what challenges they’re going to run into, because they don’t know the stack. On the other hand, if they’re delivering a virtualization stack to a client where we have a solid methodology – they’re able to deliver (irrespective of the level of project management experience being brought to bear ).
How do you improve performance with in-house resources executing work outside of their core competency?
Absolutely… articulate clear expectations, hold them accountable, manage scope, and recognize that most project work is a full-time role (great one, by the way). But in addition to that, I think you start with realistic expectations. Your infrastructure team doesn’t know your ERP environment, and will invariably fail to deliver the scope, on schedule/budget/quality if they’re doing little more than throwing darts at a wall when they set the expectation.
(Perhaps an ERP upgrade was not the best example, given that I’ve yet to see any ERP migration that has been a resounding success, irrespective of the platform, partner, or industry).
Nick, this is an excellent comment, thank you! You are raising multiple points – all valid and well taken. I really did not mean to imply that in-house resources cannot or should not be used. I’m actually generally skeptical about outsourcing – I’ve often seen a very long and painful transition period while the client and their outsource partner “learn” to work with each other. The real point I was trying to make was that we often set up our in-house capabilities to fail – with all the context switching, and to the point you made, unrealistic expectations.
Thanks again for broadening and enriching this discussion with a specific example and the pros and cons of making the in-house-outsource decision!
Vaughan, oh agreed… IT in general does have a tendency to setup in-house resources for failure and agree that context switching is big contributing factor when there is a failure.
In terms of outsourcing – in my business, the issue of context-switching is amplified as my resources are both on externally facing projects and service contracts, as well as providing in-house services. Where I make decisions to outsource, it’s on a project basis and not on any meaningful long-term partnership basis. Large in-house projects (such as ERP migrations) are particularly challenging to handle in-house both due to the lack of deep experience in what amounts to a 1-off technology stack (unless we build a practice around it), as well as handling client-facing priorities. When I have had success at doing this, is when I’ve given in-house resources the focused attention necessary to succeed. And achieving this bubble of focused attention for a long-term project requires off-loading projects, relationships, and contracts to other resources… which tends to be set of high-friction tasks.
So it’s challenging and there’s some lag time and risk involved in order to make it happen and it’s not necessarily an easy call when you attempt to quantify outsourced vs. in-house on a project basis. In other words, if an oursourced project will have an apparent cost of $100k, and my in-house resource has an apparent project cost of $30k, that $30k really needs to take into account both the opportunity cost, and the risk associated with juggling my revenue stream stream around to create the focused attention necessary for my in-house resource to deliver. And even then, such a decision may create a still larger impact, as the juggling directly impacts margin across multiple projects.
I may have broadened the conversation well beyond the intent of your original post… but it was a timely post.
And a timely broadening/deepening of the conversation! Thanks again!