billing software primary 100723210 large 700x390 - What business risks can cause software outsourcing to fail

What business risks can cause software outsourcing to fail

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.

We believe there are common “warning flags” that help a company proactively remove barriers to successful software outsourcing. These 15 risk areas can be categorized along three dimensions:

  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 occur when management fails to ensure that software development goals are pursued with intentionality, clarity and healthy team dynamics.
  3. Technology: 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.

In a previous article, we introduced readers to the concept of the 15 areas of risk. In this article we’ll go deeper into the five risks most commonly seen inside the dimension we categorize as “Business.”

What is a business risk?

At a meta-level, business risks are those places of vulnerability that lie outside the technology or the project execution disciplines.

The tie-in between the needs and priorities of the business and the capabilities of the supporting software cannot be overstated: it’s 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 “business and IT alignment.” Yet, in recent years, we have come to the realization that the separation between business and technology is really a false dichotomy. It’s 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.

We also include important aspects of the customer-outsourcing vendor relationship as considerations for business risk mitigation.

Therefore, you’ll introduce risk when you undervalue the importance of business-oriented elements in the composition of an outsourced software development project.

Business risk no. 1: undefined metrics

Peter Drucker – arguably the father of modern business management – famously said: “If you can’t measure it, you can’t improve it.” Key players (business and IT) must be clear on “what does success look like?” Your company must always begin with the business opportunity to deduce the “worth it factor” for investing time and money into developing software. The business opportunity should be quantifiable. For example:

  • Will we gain market share? (What is the revenue impact?)
  • Will we improve operational efficiency (What is the cost savings?)
  • Will we increase transactional velocity (What is the delta?)
  • Will we create higher levels of customer loyalty (How will that be calculated?)

The business objectives should be described in terms that can be quantified – and measured in evaluating the software development outcomes. These objectives become your North Star in navigating a successful project.

Business risk no. 2: inconsistent priorities

Risk will be introduced if you’re unclear or not unified as to 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.

A concept often overlooked in software development, especially with iterative production releases, is the concept of the “Minimum Viable Product” (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 “So what / who cares?” response from users.

Software development is full of compromise and negotiation. Working with an outsourcing partner is no exception. Priorities should be fully understood – and agreed upon by the business community, IT staff and the outsourcing development partner.

Business risk no 3: 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 by words and actions, then it’s foolish to presume their department stakeholders will participate in ways that show commitment.

“Lack of Executive buy-in and sponsorship” 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.  

Business risk no. 4: lack of team engagement

Sometimes a third-party outsourcing partner is set up for failure because they aren’t engaged by your company employees in ways necessary for accomplishing the tasks you’ve 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’ll commit time to the project without assistance to keep non-project commitments on track. Risk is introduced into software development outsourcing projects – or any “IT project” – when the time and energy to achieve success is viewed by business stakeholders as “NMP” (not my problem).

Other times, perhaps the methods and rhythms of collaboration are not clearly understood or, perhaps the default communication method is impractical. Many of us can’t be reached consistently by ad-hoc, unannounced calls to our office phone, but will be very responsive to instant messages or emails.

In agile and other highly iterative software development methods, rapid interaction is doubly important for the project’s success. But, regardless of the development methodology, lack of team engagement equals high risk of failure.

Business risk no. 5: no partnership contract

We encourage companies to embrace the mindset of “covenant” versus “contract” – and “partner” instead of “vendor”. 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.

Partnership 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’s compatible with your own. Sometimes “compatible” means they’re methodical – like you. Sometimes, it means they’re MORE methodical and systematic in their approach, in order to keep you honest.

Business partners need to know and appreciate knowing intimately the project success criteria and potential barriers to project success. Your “win” and their “win” should be the same.

Conclusion: control your own business risks

Developing and deploying application software is complicated. Working with a software outsourcing partner has numerous benefits, but also adds complexity. Don’t allow the potential for failure, or suboptimal completion to creep in by ignoring signs of business risk in your project. Be risk averse – be critically self-aware of these five risk areas and take steps to mitigate or avoid them completely.

This article is published as part of the IDG Contributor Network. Want to Join?