Evolving Procurement Products Transform Business Operations
Commercial software aims to comply with unique requirements of military customers.
While blazing a trail on the frontier of paperless contracting, the U.S. Defense Department is discovering that a new set of opportunities and challenges emerges from change in the workplace. As in any formidable military operation, its leaders are striving to complete the mission successfully, while gathering information to share with others who are sure to follow the path to more efficient business practices.
Standardizing hundreds of operations and launching new commercial technology in a team as large and established as the military procurement community is a complicated matter likely to yield unforeseeable problems. However, military officials believe that time and talent invested now will result in considerable savings in the future.
With the Standard Procurement System (SPS) program underway for a little more than two years, the Defense Department is working closely with industry and its own purchasing agents to determine what is working and what needs improvement. At the same time, industry representatives are searching for ways to meet the needs of military procurement offices by instituting communications mechanisms.
The SPS program was initiated to homogenize the assortment of acquisition processes used by numerous Defense Department sectors. An increasing number of business practices, including approximately 76 unique automated information systems, and the Clinton administration’s Defense Reform Initiative that calls for a move to paperless transactions, led Defense Department officials to examine better ways for the military to do business.
To accomplish this task, the department sought a commercial off-the-shelf (COTS) product that could be adapted to meet the specific needs of the military procurement community. A request for information was issued in 1994, and a formal request for proposals was announced a year later. During 1996, a down-select resulted in a closer examination of products offered by two vendors. American Management Systems (AMS), Fairfax, Virginia, was awarded the $240 million, 10-year contract in April 1997.
When completely deployed, the SPS program will be engaged in all services and agencies comprising more than 900 sites with nearly 46,000 users worldwide. Currently, installation of commercial software is complete at more than 350 sites involving a total of approximately 15,000 users. SPS is the first major standard deployment of a COTS software application across the entire Defense Department.
According to Michael F. Dow, vice president, AMS, the baseline product that the company proposed for SPS was developed in 1993. Procurement Desktop-Defense (PD2), the software designed for the Defense Department, is a derivative of a product used by both businesses and government agencies. The firm also refined the primary design for the Canadian government, which was revamping its approach to government business processes. In fact, the Defense Department reviewed Canada’s implementation while assessing the software and determining how it would fit into the U.S. military community.
PD2 is constructed in layers to provide flexibility for diverse Defense Department agencies. It works with a suite of COTS products produced by Microsoft, SYBASE, COGNOS and Lotus. Components of the software are divided into four integrated sections. The procurement application sits on Desktop, a foundation software, and shares data with other Windows-based tools through object linking and embedding (OLE) technology. The next layer, PowerBuilder, enables the development of distributed, component-based applications. The operating system, relational database management system and network make up the remainder of the architecture.
Because procurement divisions feature a wide range of existing components, the selected technology had to accommodate a variety of elements. PD2 supports stand-alone personal computers, large-scale UNIX servers, Novell or Windows NT networks, and other networking protocols. Through OLE technology, the software allows users to save and manage documents from other Windows-based, OLE-2.0-compliant applications. Word processing documents, spreadsheets, scanned images, technical drawings and other files can be stored securely in the database with related procurement documentation. Multiple sites can share information by replicating it to and from heterogeneous hardware and data sources. This enables individual sites to consolidate data into a repository for reporting and decision support. The software is employed throughout the entire procurement cycle including requirement definition, presolicitation, solicitation, source select, award, award administration, acceptance, payment and closeout.
To accommodate changing regulations as well as additional capabilities, updates to the software will be issued quarterly. Version 5.0, which will feature an updated architecture, is scheduled for release late next year.
Because of the magnitude of the task, an incremental approach is being taken in training personnel as well as delivery and implementation of the software. “This is an unprecedented attempt to standardize a large process within a large entity,” Dow says.
Maj. Gen. Alan V. Rogers, USAF (Ret.), vice president at AMS, agrees that this particular customer base presents hurdles unlike other clients the company services. “SPS is for an audience that is very different than we are used to. These are all people who are used to working in contracts and procurement, so we’re finding different challenges from the user and program management side,” he states.
These challenges have developed in a number of different areas. For example, the original list of requested functionalities to be built into the COTS product totaled nearly 1,000. This number was pruned to 299 of the most essential capabilities.
Because the PD2 is being deployed across all services and defense agencies, a wide variety of personnel, technical skill levels and established business procedures exist. PD2 is replacing 12 legacy systems. Some customers have been working in automated procurement processes for several years and have designed procedures that meet their needs. In other locations, acquisition personnel use paper forms and data entry. Some employees have not worked in Windows or other graphical user interface (GUI) environments, so they are unfamiliar with icons or pull-down menus.
In addition, although most procurement centers have computer equipment, some do not have the adequate infrastructure to support the new product. Funding to purchase upgrades is not included within the SPS program budget, leaving infrastructure improvements up to the individual commands and their own budgets.
AMS and Defense Department officials agree that because this is the first time a COTS product has been introduced to such a large customer base it has been a learning experience for both the company and the clients. However, as soon as problems have been identified, both AMS and Defense Department personnel have responded, they say.
Maj. Gen. Timothy P. Malishenko, USAF, identifies two specific issues: functionality and business processes. As the commander for the Defense Contract Management Command and senior procurement executive for the Defense Logistics Agency (DLA), Gen. Malishenko manages the SPS program on the Defense Department side and has identified three communities the program services. The first section, which includes camps, posts and stations, will have 17,800 users by the end of this year. Major weapons systems, the second community, is more complex because of individual differences in procedures, services and platforms. The final community, inventory control points, represents a different kind of acquisition and brings its own set of specialized requirements and processes.
“The strategy of SPS is twofold. First is the use of COTS. We tell them [AMS] what we want but not how, and we will want a script of the business processes that come with the COTS product. What we’re hearing from the field is that there are unique processes in the different places we’re using this,” Malishenko says. The general adds that at some point the Defense Department has to determine how much a COTS product should be modified “because if you go too far, you no longer have a COTS product, you have a development product.”
The second part of the strategy is the incremental deployment. Although this approach is necessary in an initiative of this size, it may have contributed to initial complaints about SPS from users. “In the early part of the mission, only 70 percent of functionality was available and the users were not happy. Then we went to 80 percent and 90 percent of functionality and now up to 95 percent so now they are happier,” Gen. Malishenko offers.
According to Gary J. Thurston, DLA program manager for SPS, the first two years of this implementation involved bridging a gap between AMS and customer expectations of the product. While AMS traditionally takes a service approach in conducting business, this specific deployment requires a more product-oriented method. The product, in this case PD2, being placed in front of the user must be intuitive, and a company cannot be only a service-after-installation firm, he adds. “If it doesn’t work the first time they use it or it isn’t easy or like it was, people say ‘just give me the old system,’” Thurston states.
Rogers agrees with the assessment that both a company and the customers must share the same expectations about a product. “Many people thought that you could just pick this up at CompUSA and plug and play. We have to dispel this. You can’t do that, and we’re not doing that,” he explains. It is important to set expectations as carefully and accurately as possible, he adds.
Problems identified by users in deployed versions of PD2 run the gamut from field sizes that are too small to the inability to generate traditional monthly reports. Some users have called it cumbersome, saying it adds more steps than previous procurement processes required, fails to offer abbreviated forms for small purchases, and lacks the ability to identify certain errors. Search capabilities are also limited. When users brought some of these problems to the attention of on-site AMS personnel, company representatives acknowledged their awareness of them, one user group says.
These types of issues are not insignificant to AMS or the Defense Department. One way to eliminate many inaccurate assumptions is to include users early and constantly throughout product development and deployment, Gen. Malishenko says. “Involve the users from the design through the implementation, use and adjustments. If you involve the user earlier, it goes much smoother,” he explains.
Because SPS standardizes processes that have been individualized by procurement offices, there is some degree of “cultural warfare,” Thurston believes. Experts who have examined enterprise resource planning agree that a certain level of discomfort is created by any change of this magnitude. Payton Smith, manager of strategic studies, Federal Sources Incorporated, McLean, Virginia, believes that both parties in this deployment went into the project without fully understanding what a cultural shock this would be for some users. “They seem to be doing the right things now to help overcome this ... training, briefings and newsletters. As long as they keep doing this, it will work out. They are doing a fair amount of evaluations and will arrive at a tool that can be used. And that’s what this is, a tool,” Smith says.
These changes involve more than just the technology, according to Ray Bjorklund, deputy director of consulting, Federal Sources. Many users can make the transition to GUI technology, but the comfort level of doing business using a standardized system leads to an underlying uneasiness with SPS, he says. One way to overcome this would have been to educate the work force at every level prior to adopting a specific system. However, due to the competitive element involved in choosing a system, this is not possible. At this time, AMS and the Defense Department are taking the right approach by working with the ultimate user rather than a user representative, he believes.
Gen. Malishenko is reluctant to point to the work force and culture shock for the problems SPS has experienced and says that while the product is standard, it has flexibility so services can retain their uniqueness. “We’re not there to force all into one system. We need to be able to adjust it to individual users. We need to listen openly to what comes from the field. We have a responsibility to provide the users in the field with the tools they need,” he says. In fact, some users believe standardizing procurement business processes in all arenas helps a relatively mobile community to operate more efficiently because newcomers to a command would not have to be retrained to follow the unique procedures.
Gen. Malishenko and Thurston agree that one essential key to user acceptance of any new technical system and business process is training. Instruction must immediately precede the installation and use of the product rather than occur weeks before it is deployed, Gen. Malishenko says.
Traditional classroom training might not be a practical answer in some commands, Thurston offers. In many cases, department heads cannot afford to send entire units for training concurrently and may not even be able to send half or even a quarter to a class for an extended period of time. In addition, resistance to change is not eliminated by this teaching method. Instead, Thurston advocates initial classroom training followed by a mentoring approach. “Information technology has become a craft of a journeyman. We need to have this journeyman step. There is an art to building a contract. It’s not just a science. SPS is a tool, and we have to teach its use,” he says.
AMS’s contributions to the educational process are communication vehicles. The company sponsored the first SPS user conference in July, inviting current and future users to hear success stories, learn about current and future plans for PD2, and ask questions of company and Defense Department officials. Attendees could directly speak with help-desk personnel and work on available computers hosting SPS.
Additionally, a joint requirements board now coordinates information from the field about requested functionalities. Capabilities identified by the board as critical improvements will be added to new versions of the software.
The firm also has instituted a customer response team to facilitate communications. The group is responsible for the 24/7 help desk, the SPS World Wide Web site, a knowledge base of user tips and information, and “tiger teams” that address infrastructure issues at diverse sites. The team also sends out regular electronic “infomail” to users to provide them with the most current information about capabilities and refer them to the Web site for product tips. The Defense Department and AMS jointly publish regular newsletters that are both programwide and service-specific.
According to Thurston, this type of cooperative arrangement should be employed whenever possible because it provides many benefits. “We have to change the mindset of competing all the time. We have to build partnerships with companies because when you throw out the old companies, you also throw out the experience you’ve built with the companies. We have to change this mindset and approach,” he offers.
The original deadline for full deployment of SPS was set for September 2001. According to Thurston, the increased number of functionality requirements and the Defense Department’s adaptation of business processes that match a COTS product have caused company and defense officials to move this target date to September 2003.
