Software development outsourcing is a strategy known to all IT departments and embraced by many. When we meet with business and IT leaders, we find that some companies have attempted to use outsourcing as a software development strategy, but the results were dissatisfying (and sometimes disastrous). We dug deeper into low-performance software outsourcing and found that the root cause of issues was not caused by the outsourcing partner. The surprising conclusion was: internal factors at the client company ultimately prevented success.\nWe believe there are common \u201cwarning flags\u201d that help a company proactively remove barriers to successful software outsourcing. These 15 risk areas can be categorized along three dimensions:\n\nBusiness: Not all risks to a software development project lie within the domain of the IT department. Rather, they\u2019re within those areas of the company where business stakeholders reside. These stakeholders see the business opportunity that can be achieved through software solutions.\nManagement: Risks occur 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\nIn a previous article, we introduced readers to the concept of the 15 areas of risk. In this article we\u2019ll go deeper into the five risks most commonly seen inside the dimension we categorize as \u201cBusiness.\u201d\nWhat is a business risk?\nAt a meta-level, business risks are those places of vulnerability that lie outside the technology or the project execution disciplines.\nThe tie-in between the needs and priorities of the business and the capabilities of the supporting software cannot be overstated: it\u2019s critical, essential, non-negotiable. For years, IT leaders attended conferences and read dozens of articles (often forwarded to them by business executives) on the topic of \u201cbusiness and IT alignment.\u201d Yet, in recent years, we have come to the realization that the separation between business and technology is really a false dichotomy. It\u2019s as silly to talk about aligning IT as it is to talk about aligning a leg or arm with the rest of the body. IT is an integral part of a healthy, functioning business just as operations, sales, and logistics are critical.\nWe also include important aspects of the customer-outsourcing vendor relationship as considerations for business risk mitigation.\nTherefore, you\u2019ll introduce risk when you undervalue the importance of business-oriented elements in the composition of an outsourced software development project.\nBusiness risk no. 1: undefined metrics\nPeter Drucker \u2013 arguably the father of modern business management \u2013 famously said: \u201cIf you can\u2019t measure it, you can\u2019t improve it.\u201d Key players (business and IT) must be clear on \u201cwhat does success look like?\u201d Your company must always begin with the business opportunity to deduce the \u201cworth it factor\u201d for investing time and money into developing software. The business opportunity should be quantifiable. For example:\n\nWill we gain market share? (What is the revenue impact?)\nWill we improve operational efficiency (What is the cost savings?)\nWill we increase transactional velocity (What is the delta?)\nWill we create higher levels of customer loyalty (How will that be calculated?)\n\nThe business objectives should be described in terms that can be quantified \u2013 and measured in evaluating the software development outcomes. These objectives become your North Star in navigating a successful project.\nBusiness risk no. 2: inconsistent priorities\nRisk will be introduced if you\u2019re unclear or not unified as to which elements (capability, functionality, components) of a software solution matter most.\nFor companies using iterative development and deployment techniques (\u201cAgile Sprints\u201d for example), it\u2019s imperative to have a sequence of work product that\u2019s shaped by priorities the business areas have endorsed.\nA concept often overlooked in software development, especially with iterative production releases, is the concept of the \u201cMinimum Viable Product\u201d (MVP). Companies should be highly attuned to what the end-users value most in features and capabilities of a software solution. Too many software releases (including commercial software) have been met with a \u201cSo what \/ who cares?\u201d response from users.\nSoftware development is full of compromise and negotiation. Working with an outsourcing partner is no exception. Priorities should be fully understood \u2013 and agreed upon by the business community, IT staff and the outsourcing development partner.\nBusiness risk no 3: few executive champions\nLeaders set the tone for their teams and are ultimately the \u201cculture keepers.\u201d If senior managers, don\u2019t reinforce the importance of a system development initiative by words and actions, then it\u2019s foolish to presume their department stakeholders will participate in ways that show commitment.\n\u201cLack of Executive buy-in and sponsorship\u201d long ago was identified as a key reason for enterprise system project failure. Executive sponsors are irreplaceable in their necessary roles in change management decisions, goal affirmation, and conflict resolution.\u00a0\u00a0\nBusiness risk no. 4: lack of team engagement\nSometimes a third-party outsourcing partner is set up for failure because they aren\u2019t engaged by your company employees in ways necessary for accomplishing the tasks you\u2019ve assigned them. Key business stakeholders, such as subject matter experts (SMEs) are essential for healthy software development outsourcing. Too often, a key person is tapped for the project with little-or-no consideration given to how they\u2019ll commit time to the project without assistance to keep non-project commitments on track. Risk is introduced into software development outsourcing projects \u2013 or any \u201cIT project\u201d \u2013 when the time and energy to achieve success is viewed by business stakeholders as \u201cNMP\u201d (not my problem).\nOther times, perhaps the methods and rhythms of collaboration are not clearly understood or, perhaps the default communication method is impractical. Many of us can\u2019t be reached consistently by ad-hoc, unannounced calls to our office phone, but will be very responsive to instant messages or emails.\nIn agile and other highly iterative software development methods, rapid interaction is doubly important for the project\u2019s success. But, regardless of the development methodology, lack of team engagement equals high risk of failure.\nBusiness risk no. 5: no partnership contract\nWe encourage companies to embrace the mindset of \u201ccovenant\u201d versus \u201ccontract\u201d \u2013 and \u201cpartner\u201d instead of \u201cvendor\u201d. Business partners are in a covenant together \u2013 striving for a common goal. In contrast, third party vendors are simply expected to ship goods or provide a service for a predetermined price. That doesn\u2019t work for custom software development where requirements are constantly changing.\nPartnership begins with selecting the right outsourcing firm to partner with. Of course, they need the right technical skills. But, they also need to demonstrate a style that\u2019s compatible with your own. Sometimes \u201ccompatible\u201d means they\u2019re methodical \u2013 like you. Sometimes, it means they\u2019re MORE methodical and systematic in their approach, in order to keep you honest.\nBusiness partners need to know and appreciate knowing intimately the project success criteria and potential barriers to project success. Your \u201cwin\u201d and their \u201cwin\u201d should be the same.\nConclusion: control your own business risks\nDeveloping and deploying application software is complicated. Working with a software outsourcing partner has numerous benefits, but also adds complexity. Don\u2019t allow the potential for failure, or suboptimal completion to creep in by ignoring signs of business risk in your project. Be risk averse \u2013 be critically self-aware of these five risk areas and take steps to mitigate or avoid them completely.