Malinda Elien, Stratos Product Development 11.13.13
Outsourcing software development is different than outsourcing mechanical part and electronic board design. Unlike hardware fabrication with defined specifications to compare the end product to, software development is more open to interpretation and often evolves as the project progresses. As a result, software outsourcing requires a few extra steps for ensuring project success. In the first part of this series, we discussed how to select the outsourcing partner that best fits your needs—both technically and from a project management perspective. The second part of the series explored ways to keep your project on track by minimizing or avoiding unnecessary requirement changes. For the last part of the series, we will discuss how to ensure that the end of the project is as smooth as the beginning and results in a software release that meets your needs and expectations.
Finishing Cleanly
As the end of your software development project nears, it is important to make sure the deliverable provided to you by your partner meets your project’s needs. All too often, miscommunication or unstated assumptions can lead to disappointment in the deliverable or disagreement as to when the project is considered complete. With physical parts (such as mechanical parts or electronics boards) it is fairly simple to determine if the part meets the specifications. Unfortunately, software deliverables often are very complex and intangible. Therefore, different metrics for your software program should be agreed upon for completion and acceptance of a software deliverable. In this article, we will explore some considerations in determining your project endpoint and provide some suggestions as to how to define them.
It All Starts With Planning
As we discussed in the first part of the series (in the July/August issue of Medical Product Outsourcing), outsourcing software development does not allow you to skip the planning phase of your project. During the planning and partner selection phase, you should define the endpoint of the project based on the project’s needs. Some typical endpoints for a medical software release are “completion of software verification testing (SVT) with no test failures,” “release ready for SVT and completed dry runs with no critical test failures,” or “major features ready for SVT with no expected test failures.” These definitions provide a general understanding of the expected quality of the software release for both parties and will allow both you and your development partner to divide responsibilities and work items to efficiently get to the agreed upon endpoint. However, throughout the project, this endpoint needs to be further refined, discussed and documented so it is clear to all parties what “major features” or “critical test failures” means in concrete terms.
It is unrealistic to expect a software release to be delivered with no issues. Early in development, define the critical features that must work flawlessly to set expectations appropriately for the end of a project. For example, you may have specified a screen refresh rate of 24 Hz since that is standard for the display technology chosen. However, the software team may have been able to achieve a refresh rate of 21 Hz with the current system architecture. Knowing that refresh rate is not the most important aspect of the device they are developing will allow them to focus on more important functionality first and resolve the refresh rate if time allows later. Communicating which elements are critical for project success allows your partner to more effectively manage his or her time from the beginning of the project. Highlighting and documenting the critical areas of functionality during planning and requirements development will align your partner’s efforts with your expectations, resulting in a final product that will meet your needs.
Finally, understanding and agreeing on how issue tracking will be handled will allow for better communication with fewer missed expectations. You may decide that all issues found during ad-hoc testing after a certain release must be placed in the issue database. Alternately, it may be reasonable to log and track only issues that block the main functioning of the device. Discussing with your development partner early in the project what issues will be logged and when to begin logging will avoid surprises and disappointment late in the project. Also, communicate your desired involvement in issue tracking—hold periodic meetings to discuss the issues and the priority in which they should be fixed to further allow you to help prioritize the work of your development partner and gain a better understanding of project progress.
Testing? What Do You Mean Testing?
Software testing comes in many forms and clearly identifying what testing is required by whom, where and when will greatly assist in a smooth project completion. Beyond verification testing, software releases sometimes are required to show that unit and integration testing have been completed. Software-level testing that goes beyond the typical black-box testing of verification often is considered best practice even in non-regulated environments. Additionally, ad-hoc testing of the software by the development team or by your internal team is useful to find usability issues and general problems that need to be fixed prior to formal testing.
Determining and communicating what testing you expect from the beginning of the project and when you would like software for internal testing will prevent surprises down the road, ensure releases meet your quality expectations, and enable your development partner to plan his or her work accordingly.
In addition to the software-only testing already discussed, it is likely that intermediate software releases will be needed to support other types of testing. For example, with the U.S. Food and Drug Administration’s increased emphasis on human factors engineering, usability testing may need to be performed at intermediate points in the project. These special test releases likely will require a specific subset of the overall project’s functionality that may not be planned for implementation at the necessary time without prior discussion. Communication with your development partner as to all the software and system testing you are planning to perform will enable them to best support your needs with the least impact to overall project schedule and budget. Although it may be tempting to isolate your development partner from the other aspects of the project so he or she can retain focus on specific deliverables, not allowing your partner to see his or her effort within the larger context of the project and its associated testing will lead to incorrect prioritization of work as plans are shifted and pulled throughout development.
When discussing required testing and the level of documentation needed, it is critical to have knowledge of the regulatory requirements that will guide your specific project. You then will be able to discuss what is required for regulatory submittal, what is required to meet your internal quality standards, and what testing or documentation is not necessary for your project. Your internal expert also will be able to review the test plans and protocols your partner generates and determine what testing is appropriate to perform in house rather than with the partner.
What Happens Next?
Communicate your post-project expectations with your partner early in the program. When the end of your project approaches, your development partner is probably starting to think about the next project. If you are expecting key team members to be around for the transition back into your company, to support the software in the long term, or to be available during FDA submittal, you may be disappointed if you have not clearly communicated your post-project expectations with your partner.
At least a few months before your project is complete, discuss your expectations for future support with your development partner. When having this discussion, consider what your internal team will be able to pick up, how customer support issues will be handled, and who you want to develop the next version of the software. You need to understand if you need training and transition time to transfer knowledge to your internal team, or if you will need an ongoing support arrangement so someone is available to troubleshoot customer issues. This knowledge will allow you and your development partner to plan for an appropriate end-of-project transition and enable the development project wrap-up to go smoothly with everyone’s needs being met.
The end of a project often is most prone to miscommunication leading to disappointment if deliverables are provided that do not meet the expectations of the client. By communicating end of project expectations early and refining the deliverable definition as the project progresses you will ensure success. Communicating clearly about quality and testing expectations will allow the partnership with your development partner to continue to be collaborative. Finally, understanding and communicating what you will need from your development partner after the software package is complete will prevent misunderstandings. By understanding these items, you will have set up the end of your project to be a positive experience for all parties and lead to greater project success.
During this series, we first discussed how to set up your outsourced software development project for success by planning your project and then finding the development partner. Key selection considerations are management style, software maturity required and technical competence. Next, we discussed how avoiding disruptive requirement changes through user-interface prototyping, flexible system design and communication of implemented requirements will go a long way toward staying within the budget and time expectations that were initially agreed upon. Finally, we outlined that cleanly ending the project requires early and frequent communication of output expectations, a clear understanding of testing needs and planning for what happens next.
With these considerations in mind as you delve into outsourcing your next software project, you will be able to set your project up to meet the needs of your company and have a positive experience with your development partner.
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 undergraduate and graduate degrees in Aeronautics and Astronautics from the Massachusetts Institute of Technology. She can be reached at melien@stratos.com.
Finishing Cleanly
As the end of your software development project nears, it is important to make sure the deliverable provided to you by your partner meets your project’s needs. All too often, miscommunication or unstated assumptions can lead to disappointment in the deliverable or disagreement as to when the project is considered complete. With physical parts (such as mechanical parts or electronics boards) it is fairly simple to determine if the part meets the specifications. Unfortunately, software deliverables often are very complex and intangible. Therefore, different metrics for your software program should be agreed upon for completion and acceptance of a software deliverable. In this article, we will explore some considerations in determining your project endpoint and provide some suggestions as to how to define them.
It All Starts With Planning
As we discussed in the first part of the series (in the July/August issue of Medical Product Outsourcing), outsourcing software development does not allow you to skip the planning phase of your project. During the planning and partner selection phase, you should define the endpoint of the project based on the project’s needs. Some typical endpoints for a medical software release are “completion of software verification testing (SVT) with no test failures,” “release ready for SVT and completed dry runs with no critical test failures,” or “major features ready for SVT with no expected test failures.” These definitions provide a general understanding of the expected quality of the software release for both parties and will allow both you and your development partner to divide responsibilities and work items to efficiently get to the agreed upon endpoint. However, throughout the project, this endpoint needs to be further refined, discussed and documented so it is clear to all parties what “major features” or “critical test failures” means in concrete terms.
It is unrealistic to expect a software release to be delivered with no issues. Early in development, define the critical features that must work flawlessly to set expectations appropriately for the end of a project. For example, you may have specified a screen refresh rate of 24 Hz since that is standard for the display technology chosen. However, the software team may have been able to achieve a refresh rate of 21 Hz with the current system architecture. Knowing that refresh rate is not the most important aspect of the device they are developing will allow them to focus on more important functionality first and resolve the refresh rate if time allows later. Communicating which elements are critical for project success allows your partner to more effectively manage his or her time from the beginning of the project. Highlighting and documenting the critical areas of functionality during planning and requirements development will align your partner’s efforts with your expectations, resulting in a final product that will meet your needs.
Finally, understanding and agreeing on how issue tracking will be handled will allow for better communication with fewer missed expectations. You may decide that all issues found during ad-hoc testing after a certain release must be placed in the issue database. Alternately, it may be reasonable to log and track only issues that block the main functioning of the device. Discussing with your development partner early in the project what issues will be logged and when to begin logging will avoid surprises and disappointment late in the project. Also, communicate your desired involvement in issue tracking—hold periodic meetings to discuss the issues and the priority in which they should be fixed to further allow you to help prioritize the work of your development partner and gain a better understanding of project progress.
Testing? What Do You Mean Testing?
Software testing comes in many forms and clearly identifying what testing is required by whom, where and when will greatly assist in a smooth project completion. Beyond verification testing, software releases sometimes are required to show that unit and integration testing have been completed. Software-level testing that goes beyond the typical black-box testing of verification often is considered best practice even in non-regulated environments. Additionally, ad-hoc testing of the software by the development team or by your internal team is useful to find usability issues and general problems that need to be fixed prior to formal testing.
Determining and communicating what testing you expect from the beginning of the project and when you would like software for internal testing will prevent surprises down the road, ensure releases meet your quality expectations, and enable your development partner to plan his or her work accordingly.
In addition to the software-only testing already discussed, it is likely that intermediate software releases will be needed to support other types of testing. For example, with the U.S. Food and Drug Administration’s increased emphasis on human factors engineering, usability testing may need to be performed at intermediate points in the project. These special test releases likely will require a specific subset of the overall project’s functionality that may not be planned for implementation at the necessary time without prior discussion. Communication with your development partner as to all the software and system testing you are planning to perform will enable them to best support your needs with the least impact to overall project schedule and budget. Although it may be tempting to isolate your development partner from the other aspects of the project so he or she can retain focus on specific deliverables, not allowing your partner to see his or her effort within the larger context of the project and its associated testing will lead to incorrect prioritization of work as plans are shifted and pulled throughout development.
When discussing required testing and the level of documentation needed, it is critical to have knowledge of the regulatory requirements that will guide your specific project. You then will be able to discuss what is required for regulatory submittal, what is required to meet your internal quality standards, and what testing or documentation is not necessary for your project. Your internal expert also will be able to review the test plans and protocols your partner generates and determine what testing is appropriate to perform in house rather than with the partner.
What Happens Next?
Communicate your post-project expectations with your partner early in the program. When the end of your project approaches, your development partner is probably starting to think about the next project. If you are expecting key team members to be around for the transition back into your company, to support the software in the long term, or to be available during FDA submittal, you may be disappointed if you have not clearly communicated your post-project expectations with your partner.
At least a few months before your project is complete, discuss your expectations for future support with your development partner. When having this discussion, consider what your internal team will be able to pick up, how customer support issues will be handled, and who you want to develop the next version of the software. You need to understand if you need training and transition time to transfer knowledge to your internal team, or if you will need an ongoing support arrangement so someone is available to troubleshoot customer issues. This knowledge will allow you and your development partner to plan for an appropriate end-of-project transition and enable the development project wrap-up to go smoothly with everyone’s needs being met.
The end of a project often is most prone to miscommunication leading to disappointment if deliverables are provided that do not meet the expectations of the client. By communicating end of project expectations early and refining the deliverable definition as the project progresses you will ensure success. Communicating clearly about quality and testing expectations will allow the partnership with your development partner to continue to be collaborative. Finally, understanding and communicating what you will need from your development partner after the software package is complete will prevent misunderstandings. By understanding these items, you will have set up the end of your project to be a positive experience for all parties and lead to greater project success.
During this series, we first discussed how to set up your outsourced software development project for success by planning your project and then finding the development partner. Key selection considerations are management style, software maturity required and technical competence. Next, we discussed how avoiding disruptive requirement changes through user-interface prototyping, flexible system design and communication of implemented requirements will go a long way toward staying within the budget and time expectations that were initially agreed upon. Finally, we outlined that cleanly ending the project requires early and frequent communication of output expectations, a clear understanding of testing needs and planning for what happens next.
With these considerations in mind as you delve into outsourcing your next software project, you will be able to set your project up to meet the needs of your company and have a positive experience with your development partner.
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 undergraduate and graduate degrees in Aeronautics and Astronautics from the Massachusetts Institute of Technology. She can be reached at melien@stratos.com.
