What to Expect When You’re Expecting… Delivery of Your Outsourced Software

​As a consulting CTO I work with companies at all stages of software product development.  Startups with scarcely more than a PDF mock-up.  Multi-million dollar businesses refining their umpteenth software version.

But there is one stage in the evolution of a software company at which they disproportionately reach out to somebody like me — when they’re about to take delivery of new software from a software contractor.

Like expecting a baby, you might think the imminent delivery of outsourced software would be a time of excitement and high spirits, but it is just as often a time of panic and confusion.

I believe this consternation results from a couple of common misconceptions that non-technical executives become aware of as delivery day approaches.  After all of the effort to conceive the idea, define and (maybe) validate a minimal viable product, weigh in-house versus outsourced development, shop for and choose a contractor, fund and schedule the software development, a software product owner’s attention finally turns to crossing the finish line — taking delivery of the software.

​Misconception #1:
​​Delivery of the software is the finish line.

Delivery of the software is actually the starting line.

As a client of an outsourced software contractor, chances are close to zero that you will be fully satisfied with the software you’re about to receive.  Chances are pretty good, in fact, that you won’t even want to launch what’s delivered until you make some changes.  That’s not because software contractors are incompetent (they’re no more or less competent than any other trade), or because outsourcing software is an inherently futile endeavor (famous outsourcing success stories include Skype, Slack, and Alibaba).

Software is complex (even simple interfaces hide great complexity underneath).  User behavior is notoriously difficult to predict.  And the creative process for most human beings is iterative and trial-and-error.  Mozart would have nailed his outsourced software on the first try.  You, my friend, will have to address the following:

• The difference between the software you receive and what you originally wanted.  It’s hard enough for an experienced product management professional to anticipate and define all of the nuances of user interaction that go into a software product.  For the newbie trying to intuit his or her way through the process, it’s downright impossible.  The more functionality you’re seeing for the first time in your “final” delivery, the more deviation you can expect from your original product vision.
• The difference between the software you originally wanted and what you NOW want. I’ve delivered new products and features to product owners dozens, if not hundreds, of times (including a few times wearing the product owner hat myself).  A product owner never fails to see something that needs to be changed after seeing fully functioning software for the first time. Even Mozart tinkered with his draft compositions.
• The difference between the software you now want and what your USERS want.  I don’t mean to discredit your skills as a product visionary, but until your software launches, your product vision has been merely a guess as to what your users want.  If you validated your assumptions with a minimal viable product, it’s an educated guess.  Only by launching production software can you observe, measure, and ultimately react to what your users actually want (or don’t).

Delivery of your outsourced software doesn’t represent the finish line.  It represents the start of multiple rounds of software changes to home in on a version of Version 1 that works with real users.  And that’s not even taking into account whatever technology roadmap you’ve been cooking up in the meantime.

OK.  Whatever software your contractor delivers, you will want to change it.  Let’s put that aside for a moment and imagine that you are in fact the Mozart of software.  You composed the perfect software definition, and it’s about to be delivered exactly as specified.  Surely, then, you can have your contractor launch your software and be done with it.  Right?

​Misconception #2:
I don’t need to know how to deploy or operate the software (my contractor can take care of that).

​If you’ve outsourced your software development, chances are good your knowledge of how to deploy and operate production software is the same now as when you started this process: negligible.  Maybe you’re optimistic that you can just let the software run, or that you can ask your contractor to run it for you at minimal cost.  Maybe your baby will change its own diaper.

• There’s no such thing as deploy-and-forget software.  Bugs, which are found in virtually all software, become apparent over time.  Not all bugs need to be fixed, but many do.  Even if your software were bug-free, its environment will change (e.g., mobile OS or browser updates) or occasionally fail.  Security patches will need to be applied.  Your software will need to be monitored and maintained.
• Perhaps your relationship with your contractor survived the contracting process (congratulations!) and you have decided to retain them to maintain your software.  I have managed hundreds of software engineers (and am one myself) and can tell you: Engineers build software because they like to.  They maintain software because they have to (if they do it at all).  From an engineer’s perspective, one of the advantages of contract work is that it tends to be focused on building software, not maintaining software.  Conscientious maintenance of software (like maintenance of your home or anything else) requires a sense of ownership that is rare in a contract relationship.
• Perhaps your contractor is unusually invested in your software and you trust them to maintain it as if it were their own.  You’re still at the mercy of contractor-based events you don’t control, such as:
  • They shift their attention to other clients, which can happen for a variety of reasons (business growth opportunity for the contractor; putting out another client’s fires; the distraction of more interesting work).
  • They lose the staff that worked on and knows your software.  The average job tenure of software engineers is notoriously short.  A contractor’s staff is likely to be even more itinerant.
  • Businesses sometimes go out of business.  Maybe your contractor…

Taking Delivery

OK.  After I take delivery of my software, I will need to monitor and maintain it, I’m going to want to change it, and I can’t just rely on my contractor to do all of this for me.  What am I supposed to do?

Your most empowered stance is to operate, maintain, and update your software in-house.  Whether or not that is practical or desirable, you still want to take delivery of your software in such a way that you could manage it in-house.  That keeps all of your options open (current contractor, different contractor, in-house, hybrid approach) while maximizing your leverage with your current contractor, should you continue to work with them.

These are the two things you should ensure are included in your contract software delivery:

1. Every software artifact necessary for anybody (not just your contractor) to maintain, build, and deploy your software from scratch.  This includes source code and other digital assets. such as images; it might also include third-party software libraries and licenses.
2. Documentation sufficient for any engineer familiar with your software stack (the languages, frameworks, and other technologies employed by your contractor) to build and deploy your specific software application.

Many outsourced-software clients lack sufficient technical knowledge to know what specifically to ask for, how to physically take possession of your software (such as creating a code repository), or how to evaluate your contract software delivery against the above requirements.  If that describes your situation, consider having an independent evaluation done by another, impartial contractor (such as a consulting CTO like me).

Whatever resources you bring to bear, the success of your software will depend on your capability to make changes based on user feedback and business requirements, and to operate and maintain the software. By properly taking delivery of your new software application and the documentation necessary to manage it, you preserve all of your options and set up your technical team — whether your current contractor, a different contractor, or in-house resources — for success.

Also published on CTO Craft and CTO Vision