Outsourced Product Development (OPD) is the business practice of using outside providers to develop products and services at one or several stages of product development from ideation all the way through to implementation. In an increasingly competitive,  global marketplace, it is used by companies from startups through to international enterprises. It could be thought of as hiring a development team “in the cloud” – in the same way, we virtualize a lot of systems and processes currently.

The short article in Technopedia above has a bulleted list of key recommendations – that are widely used – but I would like to modify with bias toward outsourced application development specifically:

  • Full development team operation during the working hours of the client team. There can be some hours difference in the workday hours but generally, a difference of more than four hours becomes problematic, especially in early phases of a project or when bringing on a new team. The same time zone as the client team or a couple of hours on either side, earlier or later, is generally considered to be in the optimum zone. A simple overlay of “key team members” during client team working hours not enough because, invariably, someone will have to explain to someone decisions and changes made during the overlap and communication fidelity will be lost.
  • Testing is done concurrently with software development. The original list recommended testing be done “in evening hours.” This is too long to wait for issues to be surfaced and cleared in software development. It means lost effort and that many assumptions and decisions made during the development process may have to be backed away from and reconsidered causing considerable delay to insure that all levels of the code that might be impacted are checked. Automated testing with continuous integration testing is a key value especially in larger or longer projects.
  • Outsourcing to locations north and south of the client’s key stakeholders and product management team to minimize time zone variances. In the case of software development in particular, we generally refer to this practice as nearshoring.
  • Dedicated team members are always available, equipped and knowledgeable.

    Recruiting and hiring high-quality team members. Distance should never detract from innovation. Add to that recommendation the simple but critical notion that the development team should have OPD experience under their belt. They should have a clear understanding of how to plan, organize and execute an OPD project and be able to integrate that expertise seamlessly into new projects.

  • Small teams are more effective than large teams. For effective communication, coordination and collaboration this is always true. Multiple small teams may be useful when the project can broken up into clearly separate applications, but a burden of integration planning also comes with that idea. Agile and scrum methodologies reinforce this vital concept and are a big part of successful OPD projects. It is wise to remember the old saying: “Using nine women will not allow you to produce a baby in one month.” In other words, throwing more resources at a project will not produce enough efficiency to finish with the same amount of total effort. In fact, because of the increased overhead in coordination and communication, it is quite the opposite.
  • Intellectual property (IP) costs are part of doing business. If IP considerations are not enforced, it can be costly and time-consuming issue to recover from.

So, stepping away from the Technopedia list to more depth from to our own experience, what issues would an experienced product manager would also consider or think about a little more deeply before engaging an OPD vendor?

  • Is IP security sufficiently covered in both national laws and treaties? Is it covered in the standard contractual language found in the vendor’s agreements? Do the vendor’s internal development practices reflect the difference between “best practices” – common base elements in code development and outright code copying between customer projects?
  • Is the vendor really aware of product development disciplines, aware of best practices as they are applied to software products, and able to work collaboratively with your the in-house team? More than that, can the vendor approach the project collaboratively using agile techniques so that results can be seen early and judged before the project goes too far off track? This applies across the entire product development cycle. Agile techniques provide early prototyping, clear identification of in-house “product owners” and validation of concepts at points where they can be assessed against the product requirements and roadmap.
  • Is the vendor’s team stable, experienced and available? Can you interview proposed team members? Are their language skills and understanding of your business culture up to your standards? Many times proposals are sent with a pile of “representative resumes” which may or may not actually represent the team offered when the contract is signed. Can you specify a dedicated team that will be available for on-going work, enhancements, bug fixes, and maintenance? Switching team members in mid-stream is sometimes more difficult to hand with remote teams than it is with in-house.
  • What is their QA and release system? If the vendor is handling several projects – test and release may be a very busy asset in the company that is quite separate from development. Understanding the differences between various types of business models (licensed, downloadable, on-demand, etc) and the impact of releases on each is critical in ongoing maintenance of products. How are bugs handled? How transparent are their results? Is their testing cycle concurrent with full coverage of the code base?
  • Outsourced Product DevelopmentIs collaboration a core value within the team? Does the vendor have the tools, practices and procedures in place to provide the platform necessary for good collaboration?
  • How will collaboration actually play out? Typically, offshore teams, that are several time zones away, will say, “we are working while you are sleeping” which indicates a 24 hour working cycle. But how is collaboration between the remote team and the in-house team really taking place? If it is limited to emails and voice mails, the messages can easily end up in a frustrating cycle of cross communication. Many offshore vendors will provide a project manager with overlapping hours for both the in-house team and the remote team. This can still lead to a “telephone game” syndrome where the remote team is never completely “in the loop.” Bringing the remote team or project manager on site for a period of time can be difficult and costly if they are several time zones away, which lowers the value of an outsourced solution. Consideration of a regional or nearshore provider should be part of the list to evaluate the approaches to this issue. Scio is a nearshore provider to North America, but is important planning consideration for our clients none the less. Throwing critical product development work “over the wall” is a difficult process to manage well regardless, so any improvements to the collaboration process that can be made are worth evaluating.
  • And in line with that evaluation – does the vendor offer a range of engagement options that allow you to both look at your needs in project as goes along and evaluate the team, the approach and deliverables in a way that you can avoid biting off more than you can chew? If the first response back from a vendor is an end-to-end proposal – are there ways to do shorter, tighter engagements that will allow you to see how the team works and judge if it is a good match? Well-defined, short engagements that will still give you useful deliverables a good way to “move the ball ahead,” avoid risk and to get a feeling for what you are getting into.
  • Is the development environment open and flexible? If you want your developers to work “side-by-side” with the remote team, can they work and share a common environment and code base? Even if you are not a developer by trade, is the work assignment system open and clear so you can understand what is currently in work and what is in the queue?
  • How well versed is the vendor team in the technologies you need to employ? Can they offer a range of approaches with clear value cases for each? If your project involves collaboration with your in-house team, it is critical that the technologies and environments used leverage your teams knowledge base. A good prospect will be clear about their domain and will place boundaries around what is in their sphere and will take more time to work with. Limited experience may not always be a disqualifying factor if the team is aware of their limitations and can take appropriate measures to remediate, but simply indicating “we can do anything” can be dangerous.
  • How much attention will your project get from your OPD vendor? If your project requires a team of five or ten, will it be considered a priority with a vendor that has more than 1,000 staff members? Feeling comfortable with the level of interaction you’re going to have with your vendor has a lot to do with how important your project is to them in the “big scheme of things.” If typical team sizes range increments of 10′s or 100′s you have to be concerned about how dedicated your team will actually be.

So – with that insight, is OPD for everyone? No. Does it have any more or less risk than other outsourcing? No. If you understand the risks, you can deal with them by both planning projects properly and selecting the right partner. And in the end, that is the point. An OPD vendor needs to be a team you feel comfortable approaching as a partner. There are many companies today that have only a handful of direct staff members who do quite well with an end-to-end OPD team. They concentrate on their market, sales, customer satisfaction and the leadership of their product development teams – regardless of where they are. They have learned to work fully with product development “in the cloud.”