Software development outsourcing is a strategy known to all IT departments \u2013 and embraced by many. In our discussions with business and IT leaders, we find that some companies have attempted to use outsourced software development, but the results were dissatisfying and \u2013 sometime disastrous. We found the root cause of the issues were not systemic to the decision to outsource nor caused by the outsourcing partner, but rather caused by internal company factors that ultimately prevented success.\nWe believe there are common \u201cwarning flags\u201d that, if properly heeded, can help a company proactively remove barriers to successful software outsourcing. These 15 risk areas can be categorized along three dimensions:\n\nBusiness: There are risks, not in the domain of the IT department, but rather where business stakeholders reside. Business stakeholders see the business opportunity that can be achieved through software solutions.\nManagement: Risk is introduced when management fails to ensure that software development goals are pursued with intentionality, clarity and healthy team dynamics.\nTechnology: Finally, we see that regardless of the choice of an outsourcing partner, risks are introduced by flawed elements of the technology architecture, tools and framework.\n\nEach of these three dimensions has five key risks - for a total of 15 key areas of risk. In a previous article, we introduced readers to this concept of 15 areas of risk, followed by articles on \u201cBusiness\u201d and \u201cManagement\u201d risks, respectively. In this article we\u2019ll examine the five risks most commonly seen inside the \u201cTechnology\u201d dimension of a software development project, or any technology project.\nWhat is a technology risk?\nA technology risk is a risk introduced into an outsourced software development project, which stems from tools, methods, and approaches that the IT team must uniquely control. These risks are uniquely different from risks which arise from circumstances inside the business area or general management of the project. In our experience with customers, we\u2019ve seen five risks of technology that occur the most often.\nTechnology risk no. 1: Inadequate skills\nIt\u2019s surprising how many times we find that an outsourcing partner has not been properly vetted: confirming that the project team has the requisite skills and experience to be successful. Certifications, ongoing training, industry and functional experience are all dimensions that should be part of your companies due-diligence before going to contract.\nDo outsourced partner team members have the right technical skills? There should be clear work experience \u2013 and references \u2013 provided to demonstrate that the languages and tools needed are part of the third party\u2019s core competency.\nIs industry or vertical experience part of the necessary skill set you need from a partner? Make sure that your chosen software outsourcing partner has experience with developing solutions that reasonably match your business context. Each project circumstance is unique. The software development vendor should be able to explain why their experiences match up well to your situation.\n\u201cAdequate skills\u201d also means sufficient bench strength. A company that sells software development services will have competing priorities. It\u2019s important that the success of your project doesn\u2019t hinge on a single, niche talent. The best outsourcing partners can demonstrate a culture of continuous education, cross-training, and recertification.\nTechnology risk no. 2: Defined operations\nA driving force behind the emergence of devops was the recognized gap between applications and operations (or IT infrastructure \u2013 if you prefer). These two must work well together during development and deployment. When you add a software development outsourcer into the mix, it\u2019s an effective way to get work done, however it also adds a level of complexity to the project.\nWho is responsible for hosting? Is pre-production and production managed by the same group? It\u2019s imperative that the architecture, release levels, etc. of the \u201cdev,\u201d \u201ctest\u201d and \u201cproduction\u201d environments are equivalent.\nHow will the software be certified for the intended target platform \u2013 and who will do it? Make sure both you and your outsourcing partner understand the mutual responsibilities for testing the software.\nTechnology risk no. 3: Effective design\nDo the design elements of the system properly address the business goals? It\u2019s surprising how often we find that insufficient consideration has been taken to ensure that alignment exists. For example, will this beautiful new web application be a bust on day 2 of go-live when users try to launch it on mobile devices? Or does the solution require so many pages of data entry that shoppers will become frustrated and abandon the purchase?\n\u201cForm must follow function\u201d \u2013 as the saying goes. Said differently, the design must drive the solution to achieve the core business goals. Misalignment of design and business objective is a huge risk factor to be avoided.\nTechnology risk no. 4: Quality assurance\nThe speed of Agile development \u2013 and the opportunity to deploy code to production rapidly - may create a temptation to overlook, or minimize, the need for adequate quality assurance.\nAre QA procedures in place and understood by both parties? Are they robust enough? Are the standards for the software clearly understood? A software outsourcer may not have proper understanding of what QA steps are expected or even demanded (by policy or government regulation).\nIt\u2019s very important that expectations for quality assurance practices are established in advance, and you as the customer have the acceptable responsibility to set those expectations.\nTechnology risk no. 5: Technical debt\nMany times, we see companies with a large backlog of software development or other technology needs. This \u201ctechnical debt\u201d can run the gamut of much-needed functionality to stay competitive in the market and for software version upgrades which are required to keep a critical application capable of being supported.\nCompanies sometimes find that their attempts to incrementally reduce their backlog can be described as \u201cnecessary but not sufficient.\u201d The velocity of the planned change will not move the company to a sufficiently better situation. In these cases, technical debt must be addressed in radical ways: accelerating change through leveraged outsourcing partners, \u201cleapfrogs\u201d of functionality or technical platforms, for example.\nExamine carefully your company\u2019s technical backlog. Is there a threshold for an acceptable level of technical debt? Is there a process in place to pay it off? We challenge you to ask yourself \u201cIs this development project really going make an impact in paying back our technical debt?\u201d\nBe risk averse\nThe process of developing and deploying application software is complicated. Although working with a software outsourcing partner has numerous benefits, it also adds complexity to the project. Don\u2019t allow the potential for failure, or suboptimal completion to creep in by ignoring signs of technology risk in your project.\nBe risk averse! Be critically self-aware of these five risk areas and take steps to mitigate the risks or avoid them completely.