If you are thinking we’ve been discussing Outsourced Product Development (OPD) a lot recently, you would be quite correct. Why?

The answers are simple:

  • It is an important part of what we do at Scio. We have a lot of experiences to share.
  • It is mentioned often by many software development companies, but just as often misunderstood, as a part of the professional disciplines of Software Development.
  • It brings specific methodologies, practices, and skills that can benefit any application development project.
  • It sets clear roles and responsibilities that are important in the planning and execution of projects.
  • It places the client experience; the project costs, effort, and outcomes in perspective for our clients and development teams.
  • It can be successfully outsourced, all or in part, by a nearshore development team like ours.


So before we dive into the issues and benefits of OPD, take a minute to consider the typical backgrounds of clients for this service:

  • Existing Independent Software Vendors (ISVs) that provide software to their clients either on the Internet or through a licensed distribution, generally a downloadable application, to a platform (desktop, server, mobile app, etc.).
    • Some of these ISVs will be extending an existing application or suite while others will be bringing an entirely new application to a new market.
  • New ISVs (startups) with new applications and new markets to break as they scale their client base and operations.

When considering new product development or extending current applications, existing ISVs generally face issues that involve:

  • Maintaining, supporting and operating existing applications and lines of business. Existing business and services must be supported to maintain cash flow, customer base, and brand value.
  • Skilled staff retention and scaling. Staffing in ISVs is generally lean, providing enough resources for operations, maintenance and support, but not enough for larger projects. A new project may create retention issues if it is seen by the existing staff to be a threat to their value and retention. Hiring and bringing a new team up to speed becomes a serious risk that many ISVs cannot easily overcome.
  • Staff skills can become devalued when new projects bring new technologies that the incumbent team is not experienced in handling. This can cause conflict and turnover at a time when increased risk is not something the organization can deal with easily. However, the same staff is of high value because it understands the existing customer base, what has worked and has not, and what drives customers – all critical capabilities for success in planning and developing applications.
  • Changes to existing standard deployment, maintenance updates, applications, and support operations may cause problems with the existing market that supports the ISV.
  • Existing staff may not be skilled in current product development techniques, agile product and software development and product lifecycle management.

New ISVs, while they generally do not have a significant existing team to consider, also faces important issues:

  • Finding a business model and market that will scale successfully without expending more cash and resources than necessary in the search.
  • Staff acquisition, team development, and integration during the beginning phases of business and application development may present more distraction and risk than benefits.
  • Efficient, incremental product development is key to success as a new ISV, but may not be a skill the founding team is experienced with or able to set the standards to fill a development team. Developing the critical features for a market early in the lifecycle is often the most important part of product management, but one of the hardest issues to manage.

Dealing with the Issues

Regardless of the route ISVs take when they come to OPD as a solution, they all face the same issues when picking a vendor and team for their projects:

  • Generally, ISVs bring a straightforward cost/benefit point of view to negotiations rather than considering the product development methodologies and customer experience the vendor provides. These “value-added” benefits are often the difference between project success and failure, but putting a priority on them makes competing for offers harder to prioritize.
  • Individuals or teams often have negative experiences with outsourcing in general that colors their ability to select a vendor and team with them successfully. Instead of collaborating on new ways to solve problems and manage projects, they may double down on constraints and operational rules and restrict options to work creatively.
  • Managing existing applications and projects while developing new or enhanced products is a level of multitasking that requires planning and operational management the ISV may not be entirely ready to jump into. Finding a vendor that can ease into the project, and bring experience into scaling towards product release and operations is not generally on the roadmap, but managing the risk is critical.
  • Communication, coordination, and collaboration are critical issues to overcome in OPD, but they are often the last issues to be dealt with in considering vendors.
  • Experience in OPD, agile, team dynamics, quality assurance, and collaboration are clear indications of successful OPD providers, but difficult to judge in a simple response to a set of product requirements.

What We Have Learned

We have based our practice of agile product development on our capabilities as a nearshore provider of application development services. Over the years, we have continuously improved our processes and methodologies by focusing on quality and the total customer experience of working with our teams. From our experience, there are some key issues your prospective vendor needs to be able to address clearly for you:

  • For product development and current OPD practices, real-time communication with the whole development team is critical. Timezones and language cannot be allowed to be a barrier to success.
  • Small agile teams are better at coordinating, managing deliverables and communication than larger teams. There is a direct correlation between team size, total effort, cost, and outcomes. Adding more personnel to a team doesn’t automatically add up to faster releases and less elapsed time to release. In fact, adding more people quite often results in the reverse – more people just require more management and communication overhead.
  • The Total Cost of Engagement (TCE) – the cost of successful, efficient project outcomes, is always different than hourly rates. Concentrating on beating down hourly rates can easily result in higher total cost because of rework, efficiency, overhead, and risk.  A nearshore team may be more on an hourly basis than a team based more than six to eight time zones away, but the overhead involved to reach successful project completion can be very high, especially if travel to the remote site where the development team is located is included.
  • The client product manager/team and the development team need to be available when they are needed to answer questions and work through issues. Waiting a working day or over a weekend will result in wrong assumptions being made and wasted effort.
  • Adding layers of organizational overhead and procedures will not lower risk by themselves. They may be necessary evils in certain cases, but without a commitment to collaboration, an understanding of critical outcomes and clear, open lines of communication, more administration will only result in greater effort and longer communication cycles.
  • Cultural fit, at both organizational and personal levels matters. If members of the client team or the development team do not understand the cultural and organizational hierarchy involved in the project from the outset, the project will suffer. Nearshore teams generally have a better chance from the start because of basic shared understanding, but even so, teams need to have a plan to ensure the normal norming and forming team dynamics are worked through successfully.
  • A successful outsourcing relationship is a partnership where both sides have enough at risk to be focused on project success.
  • The “iron triangle” of project management exists. Both sides of the outsourcing relationship have to pay attention to scope, resources and schedule while maintaining quality and outcomes.
  • Shared processes, commitments and goals that tie the entire team together work better than handing responsibilities off between the two sides of the relationship.
  • Team dynamics and motivations throughout the project are critical to understand and manage to maintain productivity and commitment.
  • What does it take to visit your team or for members of your team to visit your team? Does it take too much time? Are visas relatively easy to get? What restrictions would you face? Would language barriers, costs, and other issues be worth overcoming? Face to face meetings are very valuable. They put a face and a personality on the names you have heard. They give you context and build the joint team.

Without question, all these points revolve around basic issues of communication and collaboration. With proper management, dealing with these issues will by itself build trust, understanding and shared goals between the teams in the relationship.

Questions for Prospective Software Development Outsourcing Partners

So can we suggest a list of questions, beyond hourly costs and resources, that a prospective OPD vendor should be able to answer? We can:

    • How do you handle communications between your development team and the client team? What applications and tools do you use? What hours do your teams work?
    • What development methodology do you use? If it is agile and scrum-based, what involvement will the client team have in daily status meetings, scrum planning, retrospectives, etc?
    • What kind of projects do you typically do? Enterprise IT or product development? What do you think are the main differences between them?
    • How do you envision the quality assurance process will work?
    • What is your experience with release cycles and maintenance windows for applications? Does it fit in this case?
    • How is your infrastructure set up? Do you have an IT group? What will you do if there is a power outage, Internet failure, server failure or local disaster?
    • What is your process for putting together a new team? What involvement do you expect from your client?
    • Will the entire team be able to speak, read and write English well enough for documentation and open discussion?
    • Is there someone who will monitor and actively discuss team dynamics for the entire team? An account manager? Who will help resolve issues as they arise?
    • What is the average size and make up of your teams? How many project teams are you running at one time?
    • What is the longest period you have maintained a team for a client?
    • Do clients visit your site? What are the barriers to having team members visit client offices?
    • How long will it take to bring together a team once you have project requirements? How long do you imagine it will take for them to be productive?
  • Do you have references from clients that I can speak to?

Yes, these questions are somewhat generic, so take them as a base and make them more specific to your organization and project. If the answers do not satisfy your needs, consider the time and effort it will take to modify embedded processes and procedures on both sides. It is part of the cost of doing business and project success but hopefully, your vendor will be ready with answers and have enough flexibility to meet your needs without significant problems.