This is a great question and I'm sure a lot of debate out there regarding approach. Let's use this blog post to begin a discussion thread!
First, here are my thoughts (and it really applies to any project)...
Project Management - I always prefer to manage the project internally. This is because an internal resource cares the most about the final outcome and understands the company's concerns. If you pass management to an outside resource or partner, you then need to manage them and convey information, point them to the proper resource, explain implications and business impacts, etc. The internal resource would likely have this knowledge already.
Technical Resources - This one is debatable and really depends on your implementation and how you've structured support. If you have an internal support staff which includes a database/system administrator and developers, then taking care of the work internally makes sense. We have an internal staff, but we are a small team. Specifically for the 2012 R1 to R3 upgrade - it is very complex, so we've engaged our implementation partner to advise and assist with the upgrade process. We also have a large customization that our partner developed and supports, so of course we will need to contract them to assist with this as well. We also have some of our own development and we will take care of this ourselves. However we'll use our partner for some general advise.
Functional Resources - With any upgrade (and as I stated in my earlier post "The beginning of an upgrade journey"), you should (1) review release notes for new features - do they replace any customizations or affect any business process implemented and (2) review customizations - are they still needed. Then of course, you need to test every business process to insure they still function as designed or if they need modification due to changes in the upgraded software. This, in my opinion, is primarily done by internal staff. This could be done by your partner, if you have your processes clearly defined with every scenario documented with the expected outcome. Then you could engage a partner to perform the testing, but likely most companies don't have documentation this detailed.
The Project - Create a project plan with a work breakdown structure, who is responsible, time duration, dependencies, and timeline. Be sure you have clearly defined project roles and everyone involved is aware of their responsibilities. I spoke about this at the 2015 AXUG Summit in the CUG07 - The Theory of Evolution In Successful Project Management.
So some questions to ask yourself as you begin to plan a project:
- How much control do you want?
- Do you have internal resources and do they have the expertise and knowledge?
- Do you have a budget and if so, how much can you afford?
- Do you have a partner that understand your business and your concerns?
You can't get completely out of project, but you can farm out as much work as you like. If you farm the work, be sure to assess the risk of how well you communicated your requirements and concerns to a partner, and that they fully understood and you trust their work. Put a process in place to check in, follow progress, understand issues and impacts.
Also in the end, you have to decide how much internal knowledge, expertise, and understanding you want to retain internally when the project is over. The more you pass off, the less you'll know.
Please share your comments and I'll moderate a discussion!