Controlling User Requirement ChangesControlling User Requirement Changes

Originally Published MDDI October 2003

Product Development Insight

Procedures for managing changes in specifications should be flexible enough to allow useful improvements, but rigorous enough to prevent feature creep and other product development snags.

David Warburton

While many medical device companies have excellent new-product development processes, they often lack one fundamental element: a controlled system to change the user requirements. The development process protocol may tightly control the way design drawings are changed, but it often allows changes to the product's user requirements without an adequate paper trail, or even a formal signoff process. Interestingly enough, the best example I have seen of a user requirement change control process came not from the medical device industry, but from the commercial software industry.

For a while I was program manager for a fast-paced software company with a wacky, visionary leader; a daily game of Ultimate Frisbee; and a real need for control in its new-product development process. The new features planned into each scheduled release of the application inevitably expanded as the project progressed—until about two weeks before the purported release date.

At that point, everyone from senior management on down realized (or admitted) that the project was late—really late. They now knew that nothing would ship unless some features were dropped. Days of crisis meetings followed. The result was a product shipped three months late with an arbitrary set of new features based more on what worked than what was needed, and a collective bafflement about how all this could have happened.

As much as the organization disliked “process,” the company's new-product development team belatedly recognized that a process protocol was needed to prevent uncontrolled changes to user requirements during development. So the team began looking for a solution. This article examines some of the issues we faced.

Fixing the Process

The team started by trying to find the problem. It identified three main issues that the new written procedure had to address.

First, the procedure would need to acknowledge that user requirements evolve throughout the product development cycle. The desired solution was not to prevent change, but manage it. The specifications had been created at the beginning of the process. But at that point, marketing and engineering knew very little of what they would come to know about both customer needs and technical challenges. The specifications needed to evolve in tandem with marketing's and engineering's conception of the market and product. 

Second, the procedure would need to facilitate communication of specification changes. The most disruptive changes to the specifications had been the ones that were not communicated to the entire group. Communications failures typically occurred when engineers either dropped a feature or changed a performance requirement without telling the rest of the team. Too often, sales would close a major deal with a customer contingent on a feature that engineering had dropped from the release a month before.

Third, the procedure would need to control feature creep. Feature creep had been a constant challenge for marketing and engineering. In every project, someone (known as “the feature creep”) in either department had just enough political clout to inject some new feature into the product—usually just days before product launch.

Medical device companies must face a fourth issue that we did not. Since the user requirements are part of the controlled document set that makes up the design history file, the change process has to be both auditable and traceable.

Solutions

Once the team had identified the main issues, it began to explore possible solutions.

Simply freezing the user requirements at an early point in the development process was quickly ruled out as a solution. This was, after all, the official policy already in place at this company, and experience over many projects had demonstrated that the policy was virtually impossible to enforce. It simply did not address reality. Both the market for a product and the engineering approach to the design evolve during the life of the project. (This is especially true for medical devices, where development projects can span years.) 

In a well-managed project, the number and scope of changes to the requirements diminish rapidly as the project reaches the later stages of the design effort, but the changes never entirely stop until product release. So the team ruled out a requirements freeze as a solution.

Someone suggested we look at our engineering change order (ECO) process, an existing change process that might also be used to change user requirements. The ECO process was already in place and worked well. Everyone was familiar with it, so no training would be required. 
Superficially, it seemed like a good fit. The ECO process had many features that we had identified as important in a requirements control process. One was traceability. Like most ECO systems, our system required numbered ECOs that listed each change to a document. Thus, any change to the document over time could be traced by following the path of ECOs.

Another feature was that the ECO system required that the change be justified. The Reason for Change section of our ECO process forced the originator to justify and describe the change, again providing a useful historical record.

The ECO process provided a useful guideline as to how the requirements change process should be structured, but on closer examination, we realized that it also had a few inadequacies. The ECO process was optimized for changing drawings and other production documentation. The ECO form did not have all of the information required by a specification change process. More importantly, the people required to sign an ECO were not necessarily the right ones to approve a change to a new- product development specification. We saw that we needed a process modeled on the existing ECO process, but tailored specifically to changing the user requirements. 

The Requirements Change Process

The process we developed began with a sequentially numbered specification change form consisting of four parts: 

• The description of the change.
• The justification for the change.
• The cost of the change.
• The approval for the change.

The Description of Change section was a carryover from our ECO process. It required that all proposed changes to the requirements document be delineated.

The Justification for Change section was the place to describe the business reasons for the change. If there was a request to add a new feature to the product or to enhance an existing specification, this section provided a place to describe the business or customer opportunity and provide as much hard data as possible on the revenue impact of the change. If a feature had to be dropped or a specification downgraded, this section provided a chance to explain which particular law of physics had been violated by the original specification, and then to detail the effect of the change on the marketability of the product. 

In the case of a medical device, the Justification for Change section would also be the place where a change to the performance requirements would be justified on scientific grounds. For example, if the design specifications required the device to give a glucose reading within 1% of a certain range, this section could be used to justify a widening of the specification to 5% based on clinical data.

The Cost of Change section described the economic effects (costs or savings) the change would have on the project and the ultimate product. This section would detail

• Changes to the schedule. 
• Changes to the development costs or staffing.
• Changes to the validation or clinical trial plan.
• Changes to the unit cost of the product.

The first three parts of the form yielded an auditable, traceable, freestanding description of the proposed change to the requirements, the reasons for making the change, and the cost of the change.

The Escalation Clause

What made this requirements change process unique was the last of the four sections, the Approval section. The approval system we developed grew out of senior management's desire to approve major changes to a new product. The team felt that involving senior managers in every change would slow the process down and make it burdensome. Thus, the process needed to allow senior management to approve major changes, while allowing the team to approve minor ones. Yet, no one could agree on a working definition of major and minor.

The result was a two-tiered approval system. The first level was the product development team level, which consisted of the team members from each functional group. Any change to the requirements, no matter how large, could be made at this level. This approval section required signatures from all major functional groups on the development team, including program management, engineering, marketing, quality, and manufacturing. 

However, if any one of the development team signatories did not agree with the proposed change, or felt that the change was major rather than minor, that person could invoke the escalation clause. This forced the approval to go to the senior management level. The escalation clause worked because it allowed the team to handle most changes at the team level, where everyone was close to the project and decisions could be made quickly. But each team member could choose to escalate the decision to senior management if warranted.

This clause provided an interesting psychological aid to resolving conflict. Because all of the team members knew they had the authority to move the decision into the hands of senior management, the clause worked something like the threat of a filibuster. It gave the minority enough leverage to assure them that their concerns would be addressed. Consequently, the clause was rarely invoked.

Making the Change

Once a change was approved, user requirements were updated and a formal notification of the change was made by e-mail. This addressed the need for communicating the change.

The requirements change process brought increased control to the product development process. Changes to the requirements received formal review. When serious trade-offs between features, performance, or development schedule had to be made, the decision was made by senior management, where it belonged. And finally, changes to the specification were communicated formally and broadly, so everyone in the organization was aware of them. It all meant a little less chaos, and a little more time to play Ultimate Frisbee. 

Copyright ©2003 Medical Device & Diagnostic Industry