Accommodating for all the hidden parts in a project’s Total Cost of Ownership

When you scope a solution that requires expertise with technical teams, you typically get powerful responses like: “We could build this solution the Vendor offers in 6 weeks!” This reaction makes sense, as you have inquisitive minds and a focus on performance when you build out your team, so when they rise to the challenge.

But then, once your team starts progressing, all of the previously hidden blockers start showing themselves. When evaluating either Building or Buying a solution, the typical focus is on the direct project costs against the price tag of the managed solution. While it provides a tidy comparison, it also glosses over many common hurdles that exist naturally when working as a team or supporting long-term solutions.

Let’s review additional questions you should ask yourself during project scoping so you and your team don’t waste months heading toward a dead-end.

Opportunity Cost

First up is Opportunity Cost: What will be lost in the time it takes to produce a solution? It’s typical to see your team’s time building a solution as an investment, but categorizing it that way will trigger a sink-cost fallacy when you evaluate your project’s effectiveness. Instead, compare the timelines your team scopes to your Vendor's implementation timeline and determine what could be gained in the time difference between the two. Let’s say you calculate that the Vendor will have you activated six months before your team can deliver. How much will your client or consumer spend will grow during that time with the solution in place? What insights can you gather in 6 months to better understand if continued investment in the solution is worth it? What other mission-critical solutions could your team focus on during that time?

Maintenance Cost

Next is Maintenance Cost: What will go into supporting this solution in the long run? While there will be considerations for the cost of operating the solution, it’s easy to gloss over how that cost grows with the success of the solution. If your project is successful, it will come with wider adoption and use-case expansion. Ensure you’re factoring into your plans how much ongoing work will be if you succeed with your project. What goes into scaling the solution and ensuring it’s always available if the total amount of usage doubles in a year? What security concerns or vulnerabilities will you need to look for as adoption increases? How do you continue to document and provide training materials to ensure all users can succeed with the solution?

The Cost of Expertise

Finally, we have the Cost of Expertise: What resources will it take to ensure your team can always be the ones to own the solution? Building a new solution will always involve learning since your team is building the expertise needed to craft it. It will require more diligence to build a solution and place new responsibilities on your team that need to either migrate or be accommodated. When you build your project timeline, make sure to accommodate the following considerations: Does your timeline have a buffer for both the discovery your team expects as well as time to face the unknowns? What is your team’s availability during this time, both for planned vacation and unexpected leave? How will any individual team member transfer their knowledge if they move out of your team?

It’s not all managed sunshine and rainbows

While plenty is overlooked when calculating the Total Cost of Ownership for building a solution in-house, there are hidden parts of a Vendor-managed solution as well that can be glossed over.

Loss of Expertise - Will your team be less effective in integrating the solution if they don’t understand how it works? How will your team be able to grow the solution into future needs?
Cost of Quality - Will the team that delivers the solution be able to provide the quality your organization needs, or will it defy the expectations set for the clients or consumers that would interact with it?
Cost of Migration - If the solution is wildly successful, when would you need to adopt in-house ownership? How would you handle continued usage if you migrated from one solution to another?

Conclusion