CASE DESCRIPTION

Technology Concerns and Components

The Prime Contractor was tasked with the development of a software program designed to permit total integration of all functions of the acquisition process related to the PMO. The IPPMIS components and processes included as depicted in Table 3.

Table 3: Components and Processes of the IPPMIS

Components	Processes
• Personnel Management	• Requirements Planning
• Fiscal Management	• Systems Engineering
• Logistics Management	• Hardware Development
• Professional Career Development	• Software Development
	• Prototyping
	• Testing and Evaluation
	• Quality Control and Assurance
	• Reengineering
	• Field Testing and Deployment
	• Follow-Up Support

Of the system parts, a new and critical component of the IPPMIS was the use of a Professional Career Development subcomponent, titled Individual Development Plan or IDP. For purposes of this case study, only the Professional Career Development module was selected for illustration. The IDP was a professional development and training element, which permitted the organized distribution of resources to optimize technical development of acquisition personnel within their designated sub-specializations, and to provide the greatest connectivity between professional competencies and functional responsibilities. At the same time, the IDP incorporated an input mechanism to facilitate managerial scheduling of future employee training requirements and served as a budget allocation tool for personnel resources. The IDP was integrated into the IPPMIS through the matching of specific technical skills with project tasks and activities.

The IDP was a real-time integrated information system facilitating access to data and information from a variety of relational database files for use by all acquisition professionals. Input forms within the IDP included:

• Form A—Personal demographics, OPM grade, primary and subsidiary career field designations, job history, security clearance, and, the level of acquisition professional;

• Form B—Short term and long-term career goals;

• Form C—Developmental objectives and activities;

• Form D—Prior professional training both formal and informal education; and,

• Form E—Supervisory review and monitoring of the IDP.

The integrated system provided a means of measuring the degree of congruity between the organization's mission, needs and requirements and the IDPs. The IDP facilitated the assimilation of the PMO's mission with the planned individual staff development activities. The IDP was linked to the four component and ten process modules of the IPPMIS. An OPM approved training course catalog and the Defense Acquisition University (DAU) programs are examples of more than 30 catalogs and programs available through the IDP component. The catalogs and programs represent information islands existing within the database configuration. A supervisory review and approval form (Form E) is related to the mission accomplishment and to the career development resource allocation module. The aggregated IDP files were incorporated into the IPPMIS for the PMO, PEO and higher authorities.

The IPPMIS incorporated the acquisition reform concept of IPPD – Integrated Product and Process Development. The IPPD concept is normally implemented through Integrated Project Teams (IPTs) consisting of cross-functional members. IPPD is a systems engineering concept integrating sound business practices and common sense decision-making. The Department of Defense created the IPPD as an acquisition and logistics management program. This program integrated all activities from product concept through production and field support to simultaneously optimize the product and its manufacturing and sustainment processes. The goal of IPPD is to meet cost and performance objectives for weapons systems acquisition (DAWIA, 1990). The IPPD evolved from concurrent engineering and is sometimes called Integrated Product Development (IPD).

Issue

Limited to no attention was given to the human system. Organizations must undergo profound changes in culture and processes to successfully implement IPPD. Activities focus on the customer and meeting the customer's needs. In DoD, the customer is the end user. Accurately understanding the various levels of users' needs and establishing realistic requirements early in the acquisition cycle is an important function of the systems development process. Trade-off analyses are made among design, performance, production, support, cost, and operational needs to optimize the system (product or service) over its life cycle. In the IPPMIS implementation case study, limited attention was paid to the concurrent design and application of humanware^[1].

The paradox presented in this problem is that the very foundation concept of IPPD was not followed in the design, development and implementation of the IPPMIS. At a deeper level, the part of the process that is the subject of the paper is the lack of attention paid to end user requirements, skills, and their predilection to accept change. The IPPMIS did not plan or account for the system-technological, the individual person, or the social organizational factors—the human triangle (Shouksmith, 1999) that makes up humanware.

People support what they help to create (Winslow, 1998, 1992) and in this case the end users were not involved in any phase of the Systems Development Lifecycle (SDLC) after requirements planning and prior to final system deployment. The PMO personnel who would ultimately be the end users took limited ownership (minimal support) for a system that was mandated by acquisition reform. Hence, there was limited contact between Prime Contractor and the PMO except for periodic required project audits. The government failed to recognize and support the human side of systems development and the contractor paid little or no attention to anything other than the hardware/software technical requirements. Neither the contractor nor the government recognized that this project reflected the essence of IPPD and hence the essence of acquisition reform. Even technology-oriented end users, such as those in this case, will not support something that they have little or no part creating, testing and deploying. Human factors are at least as important as the structure of the system. In a comparison of technical issues in system's development, humanware is more technically challenging than hardware or software.

Given the application of human factors issues and context of this less than optimal MIS design and implementation, what alternatives or options were available that might have resulted in a different outcome? How can humanware be built into the hardware and software to have a complete system?

There are numerous human factors that were overlooked in this implementation. Table 4 provides a partial list of human factors that were missing, organized by the human systems triangle—system-technology, individual person, and social-organizational factors.

Table 4: Human Factors in Technology

System-Technological Factors	Individual Person Factors	Social Organizational Factors
System Ergonomics	Personalities	Governing Politics
Relationships Between End Users And Designers	Expectations	Organizational Politics
Transaction Volume	Feedback	User Involvement    Proactive    Supportive    Reactive
Needs Analysis	End User Enthusiasm	User Management Involvement
Social Engineering	Education	Project Planning And Management
Technology Trust	Training And Development	Organizational Culture
Planning	Interpersonal Trust	Management Commitment
Business Planning	User Satisfaction	Cooperative Environments
Project Characteristics	Improved Productivity	Rewards And Incentives
Project Management	Interpersonal Communications	Open Communications
Human (end user) Design Features	End User Attitude	Trust Between Individuals And Organizations
	Interest	Organizational Change
		Interdependencies
		Job Design
		Resistance
		End User Diversity    Work Force Age/Seniority
		Power
		Implementation Timing

As an example of one of the system technology factors (system ergonomics), the IPPMIS was a sophisticated program consisting of numerous modules and interfaces spanning diverse weapons systems acquisition functions. The completed IPPMIS required technical knowledge, content knowledge, database manipulation skills, limited programming skills, high navigation interpretation, a high tolerance for ambiguity and individual work-arounds to facilitate system utilization. Specific psychometric properties of display were given limited consideration during the IPPMIS design process. Examples of shortcomings in display and navigation (operation) in the IDP module include:

• Screen Design—each screen had a different layout as well as limited use of white space;

• Text Design—conventional text design principles were not followed for text layout, type sizes, spacing of text, colors, and use of section titles;

• Activity Sequencing—not organized consistent with end user data entry sequencing;

• Navigation bars—placed in the bottom left hand corner on the main screen and moved to different locations on subsequent screens;

• Icons—non-standard graphical icons were used on the navigation bars. Such icons did not include a tool tip or help option. Icon functionality was determined through a trial and error protocol;

• Keyboard shortcuts—many typical Windows based keyboard shortcuts such as Ctrl C to copy and Ctrl V to paste were not active;

• Function keys—were included but some function keys had dual functionality; e.g. the same icon was used both to edit a record and to save a record;

• Feedback messages—all feedback messages appeared in the top right hand corner of the screen and generally consisted of three to five words;

• Menu bars—used non-standard formats;

• Input buttons—input button names were labeled as Form A, Form B, Form C, Form D, and Form E. Nominal descriptions were disregarded; and,

• Report generation—required the user to remember from which part, Form A – Form E, the requested information was located.

Final system specifications included features that were non-intuitive, non-standard, not well-labeled or disregarded conventional design principles. When the end user was queried regarding utilization, the perceived lack of systems reliability was stated as one of the issues of concern. End users also reported difficulties in information access, results consolidation and report generation. Many of these psychometric shortcomings resulted in end user cognitive overload which further deteriorated an already resistant workforce to IPPMIS adoption.

All end users were contacted to participate in the system prototype, test, and evaluation. Approximately 10% of the user population (five employees) participated during the requirements generation, design and prototyping phases. End user attention toward understanding the various system elements during prototyping was lax and was directed toward completion of daily functional activities.

The user population identified prototyping as a ‘necessary evil’ and a ‘waste of time.’ Early prototyping results produced high failure rates. Although the Prime Contractor eventually remedied these initial failures, a underlying perception of technology distrust emerged (Lippert, 2001). The distrust was geared toward not only the developer, the Prime Contractor, but toward the information system itself. The various levels of limited trust (Adams & Sasse, 1999) generated increasing resistance to system use.

Technical problems were overcome through individual procedural work-arounds. These modifications enabled knowledgeable users the ability to ‘work’ the system while excluding less capable individuals from solving these technical issues.

The cultural norm was that professional development, including increasing familiarity with integrated technology, took a back seat to mission accomplishment. The Prime Contractor offered limited help desk support and virtually no system training.

Managerial and Organizational Concerns

Technical system integration was not a management concern. Development costs were limited. System development occurred inside of an existing line item budget for administrative support, which posed a management problem. The Prime Contractor developed a unique system for the PMO and did not make use of Commercial Off-The-Shelf products (COTS). Several managers expressed a concern for a perceived loss of power through relinquishing their discretionary decision-making authority to the IPPMIS.

The IPPMIS failed during the operational implementation phase primarily because of a cognitive overload on the human system and personnel resistance to a complex integrated system. Specifically, the end users found the system to be complicated, difficult to navigate, and often-unreliable leading to adaptation and acceptance resistance. The IPPMIS was perceived as disempowering by its users. It is suspected that part of the system failure was a result of lack of system acceptance and use (Hilson, 2001). "The human element has become the critical determinate of IS success" (Martinsons & Chong, 1999).

Although the new system was designed to integrate the PMO cross-functional elements, many managers perceived the actual system configuration to reinforce stovepipe structures. The various functional system components were well integrated. However, locating and accessing the various components was often a challenge. Users overtly expressed resentment toward the system. Within small user groups, individuals discussed the waste of time and resources associated with the system procurement process. Management was not privy to some of these discussions. Senior individuals at the end of their careers were reluctant to learn and accept a new information system. The speed of implementation coupled with the complexity of the system overloaded the late career stage end users. These concerns and issues made it difficult for the Prime Contractor to implement the IPPMIS.

The Prime Contractor engineered the system with numerous proprietary components. The PMO was compelled to use the Prime Contractor for maintenance, upgrades and future enhancements.

Managers in the extended line of authority expressed a concern that the development costs exceeded the final system value. The perceived loss of employee productivity was problematic given the required human investment in time and energy necessary to learn and operate the new system. Limited training was available due to budget constraints and because the culture was one where individuals were expected to learn on their own.

Cultural Issues

PMO GOV, as an organizational entity, operated in a highly bureaucratic and politically charged environment under constant Congressional oversight. The organizational entity is an integration of military and civilian personnel. As typical with many government agencies, military personnel rotate in and out of their job positions on predetermined schedules. Civilian personnel rotated less frequently. There was an underlying sense of frustration within the civilian ranks that mission loyalty was stronger due to longer-term tenures within the organization.

Organizational Philosophies

Within government circles, there is a funding axiom of "use-it" or "loss-it." Budget allocations are used or returned to Congress at year's end. Defense contractors are often considered second-class citizens. There are multiple reviews throughout the contract life cycles by Congressional oversight groups including the U.S. General Accounting Office (GAO) and internal Department of Defense auditors. Internal acquisition personnel consider weapons systems development and acquisition one of the most important functions of the DoD.

^[1]The notion of humanware originated from a case study of the Ambrake Corporation (Gupta, Holladay, & Mahoney, 2000).