Printer Friendly

Making your outsourced software development project a success, part one.

When outsourcing a software development project, special re is needed in order to avoid a tumultuous project with disappointing results. When a company is not experienced in software development, additional understanding of the unwritten expectations that a software development partner will bring to the table becomes critical for success. The following three-part series will explore some ways to help ensure a successful project by choosing the right partner, managing the changes during development and finishing the project cleanly with your expectations met.

Outsourcing software development can be a good way to accelerate product development and expedite time to market. However, software development is different from hardware, and managing it like a hardware outsourcing project often will lead to disappointment. In this first part of the series, we will discuss what you need to be aware of before embarking on the project, and what to consider when you pick the team that will be tight for your project and company.

We Still Need to Plan?

Often, when companies consider outsourcing a project, it is because internal teams don't have time to do the work or internal processes are so burdensome that outsourcing seemingly will allow circumvention of the processes. However, it is a mistake to believe that outsourcing is a "set it and forget it" way to accelerate development. Particularly for medical product development, it is critical to set the project up for success by outlining early expectations on quality system documentation, coding standards and testing. Requirements documents are essential for communicating expectations and thus need to be better defined and more thoroughly thought out than during internal development. Communication also is critical for project success, so define significant milestones, map out the timeline and be sure the internal team will have enough time to properly support the project.

Understanding your true project needs is crucial before talking to possible outsourcing partners. When planning, be sure you understand what the software will be used for immediately--and in the future--so you can properly communicate the work that needs to be performed. For example, if you are in the feasibility development stage for a new product, you only may need a quick prototype of how a software application will work, which won't require risk management activities, formal design reviews or verification testing. If you expect to be able to leverage that work into the actual project, however, you may need to consider developing the initial application under a more formal process that will comply with U.S. Food and Drug Administration (FDA) and/or ISO design control requirements.

Another important aspect of planning your outsourced project is deciding what you will add to the development effort. It is possible that there is an existing code base that you would like to use in the new project that needs to be considered in your search for a partner. How the software that you outsource will work with your quality system also is important. Defining who will be responsible for risk analysis activities, architecture activities, verification testing and other aspects of software development that is not writing code are important aspects to decide as you plan the project.

Finally, as part of the planning effort, it is important that there is a point person in your company who understands the regulatory requirements surrounding software development for medical applications. Even if you outsource the development, eventually your company will be the manufacturer of record and have the responsibility for the software. Without understanding what is required for your particular project, you will need to rely on your partner (who does not have the complete understanding of your market that you do, or the same motivations) to interpret the regulatory requirements. During development, tradeoffs will need to be made about regulatory strategies, risk management, features and development time and you need to provide a knowledgeable voice at the table to make these critical decisions.

Who is the Right Fit?

Once planning your development effort is complete, you need to start the task of choosing the correct development partner. Choosing your development partner depends on many things, including your management style, the technology needs of the project and the maturity needs of the software. Understanding how these factors influence the project will lead you to choose the team that best fits your needs.

1. Managing Your Partner. The first thing that needs to be considered is how you would like to manage your partner. Will you feel more comfortable mostly communicating in person, over the phone or via email? This may influence how far away your development partner can be and the level of maturity in your requirements. You will need to be able to hold meetings during the productive hours of all of the participants if the meetings need to be "working meetings" instead of "status meetings."

Another aspect of managing communication is that additional management complexity will come into play if you would like your development partner to work with an existing software team. If the work can easily be split and the interfaces well defined up front, then the two teams may not need to be in close communication. However, if the work they are doing is more intertwined, then a solid interface document, collaborative discussions and in-person meetings will accelerate your project and reduce project risk. If your company has expectations for reporting and information exchange during projects, you need to communicate this need to possible development partners. If your company culture requires formal weekly written reports, selecting a development partner that gives brief daily email updates will require additional project management by your team to effectively communicate the information back through your company.

Finally, do you expect the partnership to be short term for just this project, or a multi-year partnership where the development partner helps with support activities? Different partners will handle these partnerships differently and evaluating the partner with these goals in mind will help avoid disappointments later. All of these business considerations should be weighed in order to select a partner who will lead to a successful project and relationship.

2. Technology Background Fit. The second consideration for choosing the right partner is technology background fit for your project. Just like you wouldn't hire a metal machining company to fabricate a complicated plastic injection molding part, hiring software consultants who primarily work on PC applications to develop your embedded project won't set you up for success. Outside of making sure that the company has completed software projects that match your needs, other technical aspects also need to be considered. Make sure to ask potential partners about their design and code review process, experience with issue tracking and fixing, formal unit and integration testing experience, and verification testing experience. All of these aspects are needed to meet FDA requirements, so your partner needs to be able to support your expectations in these areas. Furthermore, determining if their systems are flexible enough to easily be integrated into your quality system after project completion, or if they will need to operate within your quality system from the beginning, are important considerations for setting the correct expectations at both companies.

3. Matching Maturity Needs and Expectations. Even though the above considerations are important, it is equally important to match the maturity needs of your software to the maturity expectations of your partner. Even if your partner can deliver full service documentation and testing of the software, communicating that you just need a quick application for internal review will allow them to adjust their effort to match. This often will save time, cost and complexity for your project. However, if you partner with a company that is used to the "quick and dirty" application model and expect them to deliver a verified software package with complete documentation, your project likely will hit some big bumps along the way. Matching the development partner to the software maturity needs is critical for success.

With these areas to watch for, you should be able to plan your project and select a partner who will lead to a successful project. There are many considerations in the selection, including technology compatibility, quality and maturity expectations, and matching management and business needs. Correctly understanding and matching these features of your partner to your project is far more important than the hourly rate they charge. A company that is experienced in what your project needs will deliver software that meets your expectations most efficiently. Planning your project and company expectations before looking for your partner will allow you to objectively match the strengths of your partner to the needs of your project.

This article explored some of the considerations when planning and choosing a partner for your software development project. For a successful project, you cannot skip the planning effort; that is the basis for getting the information to make an informed partner selection. Selecting the partner not only should be a proven technology fit, but also fit the culture of your company and the maturity needs of the software project you have planned. In the next part of the series, we will explore how requirements definition early in the project will help prevent the project from going off the rails.

Malinda Elien, PMP, is a project manager at Stratos Product Development in Seattle, Wash. She has 14 years of experience in product development, project management and mechanical engineering. Elien previously worked for Microscan Systems designing optical scanning systems for medical environments. She has undergrad and graduate degrees in Aeronautics and Astronautics from the Massachusetts Institute of Technology. She can be reached at
COPYRIGHT 2013 Rodman Publishing
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2013 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:Software Development
Author:Elien, Malinda
Publication:Medical Product Outsourcing
Date:Jul 1, 2013
Previous Article:Renewed hope (again) for device tax repeal.
Next Article:Avoiding your medical device tsunami: managing supply chain risks.

Terms of use | Privacy policy | Copyright © 2020 Farlex, Inc. | Feedback | For webmasters