Making Your Outsourced Software Development Project a Success, Part 2: Managing Requirement Changes

Outsourcing software development can be a good way to accelerate product development and expedite time to market, but software is different from hardware. Managing software like a hardware outsourcing project can lead to disappointment, delays and increased cost. The first part of the series discussed what you need to be aware of before embarking on the project, as well as the considerations for picking the right development partner. In this second installment, we will look at managing requirement changes in the software development process.

Now that you have selected the development partner and started the project—what can you do to ensure the project stays on track? Experience shows that one of the most common ways for a software project to run into trouble is with continuous or late requirement changes. To avoid hugely disruptive requirements changes during medical software development, while still being able to start development in a reasonable timeframe, a few different strategies should be used.

Why Are Requirements Changes So Disruptive?
A recent Project Management Institute survey found that when projects fail, inaccurate requirements gathering is cited as the primary cause 32 percent of the time. Inaccurate requirements gathering leads to changes in the requirements throughout the project as new information is discovered. Late requirement changes adversely impact the project by adding project and product risk and increase the required schedule and cost for project completion.

Software development, especially for medical applications, tends to be a methodical process that carefully walks through feature implementation with an eye toward reducing the risk of unexpected impacts on existing features. When a requirement changes, implementation details that already have been thought through are altered to fit with the new requirement leaving open the possibility of unintended impacts to existing features. The later this happens in the development schedule, the less time there is to test and fix any issues that may arise, increasing the risk of a schedule slip and the likelihood of issues that make it into customer hands.

Because of the strict documentation, risk management, traceability and testing requirements for medical software, late requirement changes also significantly increase the cost of a project due to the amount of rework required to address the changes. As a project moves through the development phases, requirements are examined for risk, testing of the requirements is planned, and requirement implementation is documented. When a requirement is changed, all of the auxiliary work associated with that requirement is also examined and updated as needed. The later this happens in the development cycle, the more mature the documentation and planning are and the bigger the cost of rework is.

As you either hand off requirements to your development partner or develop requirements with them, understand that there will be an impact if the requirements need to change. However, it is unlikely that there will be no requirement changes throughout your project—sometimes you can’t define functionality in enough detail at the beginning of a project without an excessively long requirements development phase. Therefore, the key is to manage requirement uncertainty to create the least possible disruption to your project.

What Do You Do About It?
If changes are so disruptive, how do you avoid requirement changes for functionality that has already been implemented? This is especially challenging when the development team is not sitting in the cubicle next door. Three of the most effective strategies are prototyping, communication and planning. And they are especially important when working with a partner development team.

1. Prototyping the User Interface
Since software requirements come from two main places—the needed product features and how the user interacts with the software—minimizing expensive changes from one of those places through prototypes is a good investment in project success. When communicating to your partner how you want your product to work, it is very effective to share storyboards and use models in addition to traditional requirements documents to most effectively communicate the product vision. Then, ask your partner to provide an interactive prototype of how they interpret the product vision to make sure it will work. Typically, an iterative effort on this prototype will allow you and your partner to ensure the design intent is clearly understood and the requirements are accurately documented.

This prototype is not expected to be a complicated, functional system but rather a quick, lightweight representation of user interaction through HTML, FLASH or a similar tool. The requirement for the prototype is only that it represents the actual interaction in a way that all parties will understand. Also, when thinking about this prototype user interface, it is important to remember that the user interface is much more than a screen; the user interface includes buttons, sounds, lights and vibration—any aspect of the product that communicates information to the user. As a result, this effort is important even if the device does not contain a screen.
If possible, this effort should occur early in the project so any hidden requirements can be found and documented before development starts in earnest. An early prototype also will enable validation of user assumptions with subject matter experts or actual users early in the design cycle. This will further mitigate the risks of late requirement changes.

2. Communication of Critical Decision Points
As explained in the first part of this series, successful software development projects cannot be treated with a “set it and forget it” mentality. When managing development partners, it is vital to understand when critical decisions are being made by your partners and the impact of those decisions. After requirements definition, typically a software development effort will start by determining the system level architecture that defines the structure of the project, and then builds on top of that architecture to achieve the different levels of functionality needed. It is important to understand which requirements drove the implementation direction, why they drove the direction, and which requirements now will be expensive to change. Knowing this information enables management of expectations within your organization and heads off future expensive changes by addressing incorrect or incomplete requirements before the development team has gone too far in implementation.

Communication of the currently critical requirements can be accomplished in a variety of ways depending on how the development partner is being managed. An effective method could be to hold a review at each software development increment to discuss the requirements that drove the current design and “lock” them moving forward. Another method may be to have the development partner color code the requirements document to show which requirements are already implemented, which are in the process of implementation, and which are yet to be implemented in order to communicate where they are in the development effort.
Whichever method is selected, it is important that the development partner regularly communicates which requirements will be difficult to change moving forward and why those requirements are driving implementation.

3. Planning for Changes to Happen
As much as communication and prototyping can help eliminate expensive changes to the requirements, it would be naïve to assume that you can get through a software project without some changes to the requirements. Fortunately, most changes have signs that they could occur before they impact the project. These changes could be market changes like adding new communication protocol expectations, technological need changes like needing a faster sensor sample rate, or even a user need change like adding an entirely new product mode. Since there will be some visibility that these changes may occur, it is important to communicate the possibility of these changes immediately to your development partner. If the development partner is aware of which requirements may change, they can help determine the potential development impact and the appropriate timing for mitigation. For example, if you become aware that the communication requirements might change to add another communication protocol to a device, the development partner could propose different software architecture to allow easy expansion to meet the possible new requirement with an up-front cost that would be much lower than if the team was blindsided by the feature later. Keeping your development partner informed of possible requirements changes allows for up-front planning rather than late firefighting, leading to a greater chance of project success.

Common techniques for planning for requirements changes include overdesign (as in the example above), delayed implementation and bread boarding high-risk systems. Both delayed implementation and bread boarding deliberately dedicate time to work out outside dependencies and uncertainties before final implementation in the software. Often, a general idea of what will need to be implemented is enough for development to move forward while still working out the details. In all of these cases, collaborative communication with your development partner will ensure that the design is as flexible as possible in the areas that have a high risk for change.

* * *
Employing communication, planning and prototyping will help minimize the disruption of requirements changes on your software project and will help you and your development partner ensure your project is a success. These focus areas will enable you to circumvent the problems inherent in late software requirement changes of increased cost, schedule and risk. The next part of the series will provide guidance on making sure that your project ends in a way that is satisfactory to you and your development partner.