Approval and Gate Process - This is the critical step where ownership by users is tested, as the evolving functionality and direction of medical devices and hospital procedures is evaluated. The approval of specifications and concepts happens in this step.

Development - the phase where medical devices designers complete their initial models and plans. Built into this step are several review cycles to ensure the medical devices direction is aligning with the users' needs.

Launch - the formal introduction of the medical device or hospital procedures and the support of these development effort by users including those who championed their development during the development phase.

Future Direction - a smaller set of users typically stay together to assist in the setting of future direction for next-generation medical devices or enhancements to hospital procedures..

Change Management Benefits From Project Management

Changing of how people work in conjunction with one another and with the processes they rely on to do their jobs is crucial for any project to be successful. The ability of a project managers to bring together project teams and create a collaborative workgroup is a major benefit of project manager as well.

This aspect of the Gathering System Requirements Process is the most critical of all in defining new medical devices and hospital procedures in that it focuses on how the everyday processes people work on are re-ordered and changed. This is the most costly aspect of any new product development process and accompanying implementation: changing how people work and think about the tasks that comprise their jobs.

Typically a requirements analyst will coordinate with project managers to handle the gathering, analysis, and synthesis of the customers' needs during this phase of the SDLC. In smaller medical devices companies product managers and software engineers also specifically handle this task, working either directly with users and customers, or through marketing managers and sales managers who have responsibility for customers' accounts that need to contribute their specific needs. The requirements analyst and project manager coordinates with these other departments to gain access to the users or customers the applications or solutions they are building are intended to serve. In the most successful approaches to Gathering Systems Requirements Phase, a collaborative approach to developing and completing requirements eventually begins to form between the requirements analysts, project managers, and process experts for hospital procedures on the one hand and the users or customers on the other. This collaboration extends into the prioritization of features and the eventual development of the end application or solution. Clearly the focus on minimizing "scope creep" is critical. Scope creep is defined as when the scope and definition of a project continually changes as the needs of the user or customer change. (Hatler, 20) an expert on SDLC and specifically the gathering of user requirements states that when requirements are volatile consider an incremental development approach. This sequences the development of the application or solution to the highest priority needs of the customer or user, and alleviates the need for scope creep.

Critical to the role of the project manager fulfilling the role of requirements analyst, whether they are from marketing, engineering, development or even service, is that the following key functional areas surrounding the Gathering System Requirements Process need to specifically be addressed:

Aligning the project vision and scope relative to user requirements - Intermediating the needs across several different user constituencies, user groups, and customer groups while keeping the development aligned with the vision and scope of the original project is a critical step in the final definition of an initial release of a product. The person(s) fulfilling the requirement analysis role need to focus on how the evolving needs of the customer base can stay aligned with the original visions of the original project. This takes tact, diplomacy, and a clear sense of what the original product concept entailed, and a strong sense of direction on the part of the requirements analyst to stay focused on "on message" with the original vision and scope. Too many projects are compromised in this area when requirements analysts capitulate and give in to the many requirements of others and lose sight of or worse, compromise project vision and scope.

Finding and growing product champions is critical to change management - This is a critical step also in the Gathering System Requirements Process, and is also essential for the entire change management process defined earlier in this paper. In specific hospital procedures development (Russell, Tippett,...

The more significant the change required from the systems development and process definition, the greater the need for a product champion. In fact for the largest changes need the highest levels of management to be included in them. Is an adjunct part of the Gathering System Requirements Process, and includes the buy-in and endorsement of senior management. This focus on making change permanent through the support of senior management also supports the fact that those affected by the change of processes need to also feel ownership for the changes be recommended as well. (Brynjolfsson, Renshaw, Austin, Van Alstyne, 43, 44) "Theories of ownership, for example, suggest that decentralizing data management can boost quality levels in systems users control themselves." The ability of requirements analysts to inspire product champions at the highest levels of their organizations is critical for change to be lasting.
Requirements Specification, Validation and Management is also critical in the Gathering System Requirements Process - This is also a very critical task in that the feasibility of the project and its vision must be rigorously and thoroughly defined into product and solution concepts that can be transformed into specific application features and solution sets. The progression of turning requirements into specifications, validating them, and managing the requirements in the context of an overall product line strategy is also very critical. The database or repository of requirements must be continually managed and updated to reflect current user and customer unmet needs, with a strong focus on how to translate them into future product directions.

Creating test cases and validation test points is critical in the overall development of the final application or solution. Another aspect of Gathering System Requirements Process is the strong focus on creating test cases to validate not only the overall design and functioning of the medical devices or hospital procedures align to technical performance including scalability, responsiveness, fault recovery and fault tolerance, ability to recover from both fatal and non-fatal errors, and the ability to integrate directly with other devices and processes as well the development of test cases is clearly the collaborative aspect of the Gathering System Requirements Process phase, and underscores the need to have the Voice of the Customer (VoC) be very clear and specific in the overall development of medical devices and hospital procedures.

Comparing Business vs. Technical Needs in the Context of the Gathering Systems Requirements Phase

Pervading the area Business Process Management (BPM) and Business Process Re-engineering (BPR) initiatives that are in turn driving the development of SDLC projects and the need for gathering customer requirements are the many unmet business needs of hospital procedures users and internal "customers" of healthcare facilities. These service needs are in fact dominating the SDLC cycles of many healthcare providers who strive to better serve both their internal and external customers. Business needs are as diverse as the companies initiating and completing systems design projects, yet the broader and more strategic goals are focused first on the financial performance of one business unit or division relative to its own goals, followed by the operational performance of one division relative to another and its own goals. There are also line-of-business objectives that pervade the Gathering Systems Requirements Phase that focus on the payback of taking one operational strategy over another, including the selection of hospital procedures across each key functional area of healthcare providers. The single largest factor in the context of the Gathering Systems Requirements Phase that pervades many business needs however is pricing, and its many aspects and its implications on a project being successfully completed.

The technical requirements of the Gathering System Requirements Process phase are organized into a product functional specification that is transformed into a technical products specification that is used to manage the overall development process. This specific step in the Gathering Systems Requirements process applies to both medical devices and hospital procedures as well. The intent of using this document is to address the technical requirements of the customers for a new medical device or new hospital procedures as captured during the Gathering System Requirements Process phase and specifically include the following:

Performance - a series of performance benchmarks need to be defined and used from the engineering specification stage of n medical devices through development to the finalized design to…