So you didn't outsource the work/component, but you outsourced the learning it sounds like.
Yeah, that's a good way of putting it. Personally, once I have something that works it's much easier to go back and understand the entire system. It's just time consuming getting to that point.
Here's an example: I needed to control an arduino board in Java, I didn't know how to do it, I had the rest of the application to build and I was pressed for time.
Instead of outsourcing the entire project I outsourced the creation of a unit test, it was described something like this:
"When I run the unit test, with a board hooked up to the computer it should send a signal that will flip an LED on or off. You should use this spec (ref to Arduino site). Include all jars and install instructions."
I got it back, it did what I asked them to do and I threw all the code away. Basically I took what they did as a 'working start' and rebuilt it into the existing application. I didn't ask them to match our code style, patterns or framework, that was all my job after the fact. It worked great and saved me a few days of research.
This is the most successful way I've been able to manage outsourcing. Everything else - from detailed specs to UI diagrams to daily check-ins has had complications.
If you can reduce down to just the hard things that need to be done, and then describe them in under 20 words, and then force a unit test into the equation you'll have a higher degree of success.
YMMV