Outsourcing is a well-established strategy that many IT departments use to accomplish business objectives.

Over the years, we’ve seen companies, regardless of industry size, struggle to outsource software development successfully. Many times, the root cause of issues were not systemic to the process of outsourcing or caused by the outsourcing partner, but rather because of internal factors at the company that ultimately prevented success.

Article originally published on CIO on February 6, 2018. This is part 1 of a 4-part series. Be sure to read: Part 2: Business Risks, Part 3: Management Risks, and Part 4: Technology Risks

As we analyzed company experiences, we’ve seen recurring themes or “warning flags” that, if properly heeded, can help a company proactively remove barriers to successful software outsourcing. These 15 areas of risk fall inside 3 dimensions of software leadership:

1. Business: Not all risks to a software development project lie within the domain of the IT department. Rather, they’re within those areas of the company where business stakeholders reside. These stakeholders see the business opportunity that can be achieved through software solutions. 
2. Management: Risks when management fails to take action to ensure that software development goals are pursued with intentionality, clarity, and healthy team dynamics. 
3. Technology: Finally, see that regardless of the choice of an outsourcing partner, risks are introduced by flawed elements of the technology architecture, tools and framework. 
   
   

Here's how we lay out the 15 key areas of risk.

Business:

• Undefined Metrics. Key players (business and IT) must be clear on “What does success look like?” A project charter or other mission statement should be tied to expected outcomes in the business that can be seen and quantified. The software development objectives should have clear alignment to those metrics.
• Inconsistent Priorities. Which elements (capability, functionality, components) of a software solution matter most? For companies using iterative development and deployment techniques (“Agile Sprints” for example), it’s imperative to have a sequence of work product that’s shaped by priorities the business areas have endorsed.
• Few Executive Champions. Leaders set the tone for their teams and are ultimately the “culture keepers”. If senior managers, don’t reinforce the importance of a system development initiative and / or don’t support the strategy of  outsourcing for software development by words and actions, then it’s foolish to presume their department stakeholders will participate in ways that show commitment. The use of an outsourcing partner may be a new concept to the company - and executives have a particular responsibility to set the stage for success in the strategy.
• Lack of Team Engagement. Sometimes a third party is set up for failure because they aren't engaged by your company employees in ways necessary for accomplishing the tasks they’ve been assigned by you.
  
• No Partnership Contract. Your software outsourcing vendor is an extension of your internal team’s capabilities. Their success is YOUR success. We encourage companies to embrace the mindset of “covenant” versus “contract”. Business partners are in a covenant together - 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’t work for custom software development where requirements are constantly changing.
  
  

Management:

• Unrealistic Expectations. Any leader with experience in contractual relationships has surely had a point disagreement over obligations per the agreement.…the expectations of one party don’t match the actions of the other party. “Well - what was intended by that part of the agreement is…” has been spoken time and time again. The “grey area” of expectations and assumptions” are usually where risk occurs. Reasonable parties working together can usually find a palatable compromise - but UNREALISTIC expectations can derail the relationship.
• Unfocused Leadership. Sometimes the “right” stakeholders - based on knowledge or skill - are assigned to a project, but the assignment does not take into account the need for properly focused attention to the project. Will the leader need some backfill or bandwidth to ensure other business needs are addressed? Have other business priorities been properly factored into what may land on this person’s plate?
• Unclear Milestones. In the glory days of pure Waterfall methodology projects, “Go Live” was single “Big Bang” event. These days, the iterative, continuous deployment, of methodologies like Agile means that milestones need to be extremely clear. Without clear - and clearly communicated milestones - stakeholders and other interested parties might create unneeded confusion if a software release is “missing something” that was never intended for the current release iteration.
• Lack of Team Interaction. Good communication has always been important in software development projects. In an age of iterative development and deployment, multi-geographical teams, multiple time zones, and a pace that can border on frenetic - good communication is an essential core competency of the project team. Processes and collaborative technologies must come together in elegant ways to ensure that the constant back-and-forth handoff between participants is seamless and low-risk.
• Weak Processes. Technology can never overcome bad process in a software development project. In fact, the speed that technology brings will simply choke down a project steeped in bad execution methods - or cause the project to accelerate “into the ditch” at a high rate of speed. The roadmap and methods to be used by the project must be fully understood by the company and the outsourcing vendor - and each side must be fluent and diligent in the use of the methods over the life of the project.
  
  

Technology

• Inadequate Skills. It’s 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.
• Undefined Operations. A driving force behind the emergence of DevOps was the realization of the gap between applications and operations. These two must work well together during development and deployment. Adding a software development outsourcer into the mix is an effective means of getting work done, but it also adds complexity. Who is responsible for hosting? How will the software be certified for the intended target platform - and WHO will do it?
• Ineffective Design. Do the design elements of the system properly address the business goals? It’s 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? Misalignment of design and business objective is a huge risk factor to be avoided.
• No Quality Assurance. The speed of Agile development - and the opportunity to deploy code to production rapidly - may create a temptation to overlook, or minimize the necessity of good quality assurance. Moreover, a software outsourcer may not have proper understanding of what QA steps are expected (or even demanded by policy or government regulation). 
• Technical Debt. Many times we see companies with a large backlog of needs that need to be addressed through technology. This “technical debt” can run the gamut of much-needed functionality to stay competitive, to software version upgrades which are required to keep a critical application capable of being supported. Sometimes the approach to addressing this backlog is “necessary but not sufficient”. The velocity of the planned change will not move the company to a sufficiently better situation. The risk in the form of technical debt must be addressed in radical ways: accelerated change through leveraged outsourcing partners, “leapfrogs” of functionality or technical platforms, for example.
  
  

Conclusion

We encourage every business leader to carefully address your business, management and technology context with a critical eye and be on the alert for these 15 risk areas. Technology is not an expense, but rather an investment for business opportunity. Mitigating or altogether avoiding these 15 risks will help ensure that your investment of time and money in a software outsourcing relationship yields its highest return for your company.

Want a more in-depth analysis of the business, technology and management risks? Check out our software outsourcing series featuring Part 2: Business Risks, Part 3: Management Risks, and Part 4: Technology Risks in our four part software outsourcing series.