Avoid potholes, U-turns, and detours: the road to a successful software program.

When the program executive officer, enterprise information systems (PEO EIS) formally accepted the leadership baton from the Defense Contract Management Agency (DCMA) for the standard procurement system (SPS) on Oct. 1, 2003, it gained more than just another information technology (IT) program under its PEO umbrella. As the first and only department-wide standard business solution, SPS is a model for other departments seeking end-to-end business solutions.

But more important, the move is a validation that SPS is a solid program, and as such, has valuable lessons learned to share with program managers (PMs) grappling with IT programs that cross office, agency, or Service boundaries.

Program with a Purpose

SPS began in the last decade as an automated contract-writing system, the most efficient way to use technology to streamline an everyday task. The concept in 1996 was to computerize the basic procurement functions across the military services and agencies--one system for the Army, Navy, Air Force, and 13 Department of Defense (DoD) agencies and three related communities. In the ensuing seven years, SPS evolved from theory to reality: a fully operational system that handled $44.4 billion in goods and services purchased in FY02 alone. In fact, more than 65 percent of all DoD procurement purchases now flow through SPS.

As a key element supporting the goals of the DoD's business management modernization program (BMMP)--to establish common enterprise architecture requirements for all DoD IT systems in the acquisition, logistics, and financial management arenas--SPS features adaptive technology that allows DoD to cull data from logistics, financial management, and other related business systems to boost business intelligence. In the real world, it means officials can identify logistical needs earlier, use strategic purchasing patterns for better business decisions, and audit the Department's checkbook to provide more timely and accurate payments to contractors.

"You have to credit those people who started out recognizing that some standardization and use of technology was a good thing," says Deidre A. Lee, director of defense procurement and acquisition policy. "As the technology grew, so did our realization of what it could do for us," she adds. "Does it generate our business arrangements? Yes. Is it how we document those arrangements, including the terms and conditions and how we'll pay, how we track the money? Yes. But it's more than that: it's the foundation of our business intelligence system that will lead to better business deals and stewardship of our taxpayers' dollars."

Not Always Smooth Sailing for SPS

Yet in 2001, SPS wasn't exactly the technology darling of the Government Accounting Office (GAO). "I must tell you, when I first came on board, I didn't know where SPS was headed," admits Michael Wynne, under secretary of defense (acquisition, technology, and logistics).

According to Bob Parillo, SPS user satisfaction manager, user discontent was widespread as a result of software deficiencies, missing functionality, and cumbersome work-arounds (functionality points that weren't encompassed in the software and had to be worked around either manually or by using different automated solutions to arrive at the same destination). The problems spurred Wynne to put the program, along with a host of other IT programs, on notice. SPS was put on a "strategic pause," which essentially stopped the program until SPS and Department leaders could either come up with fixes, or they decided to end the program.

"If SPS was going to survive, we knew we had to develop a get-well plan to show to senior leaders," explains Army Col. Jacob Haynes, SPS PM. "We had a huge user population, coupled with a desire from senior leadership to make this thing work. So we had the basis for success. We just needed to pinpoint the processes that were causing user dissatisfaction."

"It seemed the GAO had the program on its hit list, and they kept citing dissatisfied users as a reason for their investigations," remembers Wynne. Of course SPS wasn't alone: a number of technology-related programs in the DoD needed to be put under the microscope, he says. But the far-reaching potential of SPS put it near the top of the priority list.

[ILLUSTRATION OMITTED]

To compound the problem, one person's complaint was another person's positive. "You can cut a purchase order a hundred different ways, depending on the buyer," points out Gino Magnifico, SPS deputy PM. Layer in work-arounds and technical issues like varying response times based on a user's particular hardware platform, and the results looked like an insurmountable challenge.

A Program Management Solution: Identify Crucial Practices for Success

"The changes weren't as simple as just finding some lines of code, or adding more people to answer the phones," Wynne admits. "The answer lay in the very processes the program had relied upon for years, processes that may have worked fine just a few years ago."

Rather than tear immediately into the guts of SPS, program leaders assessed five crucial practices needed to assure success:

Ensure buy-in from the top -- The team was in good shape in this category. Because DoD has made modernizing the nation's military a top priority, replacing the myriad legacy systems DoD used for procurement activities was obviously an integral part of that modernization. As a result, officials at the very top of DoD were aware early on that over the long haul, SPS would save the military millions of dollars at the same time as it streamlined the acquisition process.

Use the "voice of the users" committee as a centralized point for implementing user suggestions and complaints -- Again, the team was in a good position. DoD had already established a joint requirements board (JRB) to allow the Army, Navy, Air Force, Defense Finance and Accounting Service (DFAS), DCMA, Defense Logistics Agency (DLA), and other Defense agencies to give input into SPS functionality. Without this centralized committee to coordinate input, DoD would have had a difficult time meeting the diverse needs of its thousands of procurement and contracting offices. Under Haynes' proposed changes, this group would need to fill an expanded role.

Develop spirally -- This approach had been embraced by SPS from the start. How else do you ensure that the latest technological bells and whistles are included in new versions of your software without introducing costly risks? SPS uses spiral development, which allows the program to manage requirements through fixed sets and immediate development rather than a single, extensive lifecycle in which requirements are changed during the development period. Instead, developers constantly incorporate new technology into the latest version of the software.

Implement continuous comprehensive evaluation (CCE) standards -- Unlike the previous three practices, CCE was new to SPS. By taking users' feedback from live testing situations and sending it to developers in real time, changes could be made to the product by continually feeding ideas and suggestions into the software development process. While one version is fielded, the next is already in development, and a third is being fitted for requirements. All three steps incorporate users' feedback immediately to improve subsequent releases.

Design a change management strategy that works -- SPS has the unfortunate distinction of being a good example of what happens when you don't address change management before deployment begins. "Not only did users never fully understand why they were being told to use a new system, but the new system was sometimes more time consuming than their old way of doing things," recalls Army Brig. Gen. Edward Harrington, director, DCMA. "Users didn't know that the changes the system enforced were to ensure regulatory compliance and standardized work processes across the Department. They couldn't see the big picture, in part because we, as a program, didn't effectively communicate it to them. So they understandably became disenchanted with the software."

The Nuts & Bolts: Engineering a Program Turnaround

#1: Requirements

Haynes began re-engineering the program by centralizing the requirements process to ensure that users' suggestions are heard and acted upon. When Haynes entered the picture, he had the JRB review and prioritize over 600 deficiencies and enhancement requests to ensure that limited resources were spent on the issues most important to SPS users.

Once requirements were prioritized, a strict configuration management program was instituted to track every item. The new procedure begins by entering each suggestion into a configuration management database of requirements that serves as a central, up-to-date repository accessible to all levels of players. One of the most involved players is the JRB, which prioritizes deficiency corrections and change suggestions based on industry standards. The effective collaboration of stakeholders from across DoD ensures the software meets the needs of its users and the Department as a whole.

#2: Testing

The testing process was next in line for an overhaul. Under Haynes, the JRB was given authority to review, approve, and if necessary, write the test criteria used for government acceptance of the software. Parillo notes that the validity of the testing has been greatly improved by having some of the very same JRB personnel who wrote the functional requirements, approve the test criteria designed to insure those requirements have been met.

By 2002, SPS had incorporated yet another significant change in the process: an independent validation and verification (IV & V) company observing the developer's testing process prior to code cut off.

After resolving issues at the developer level, the software is tested directly by end users and JPMO personnel on "new" databases (that is, fresh installs with no pre-existing data) and "actual" databases (that is, real-world production databases with legacy data). The independent oversight ensures that the application meets its functional and technical requirements before deployment.

#3 Deployment

The third process to go under the knife was the deployment process. As a result, the average deployment schedule dropped from 4.8 to 2.3 days, a move that saved the program $15 million.

Quality training is a key element to help ensure smooth deployments. The answer is a multi-faceted training approach, including formal training classes supplemented with computer-based training (CBT) and a sophisticated step-by-step on-line help capability. Magnifico offers this advice: incorporate into the developer's contract a flexible, customized training approach that gives the government the rights to use screen shots and other proprietary information to create user guides that are tailored to a specific agency or activity. A complete training strategy should also include the option to develop government trainers.

Perhaps the most critical aspect of software training is timing. "Early in our program, training wasn't integrated with deployment," recalls Parillo. "In some cases, users received classroom training six months or more before they ever saw the software on their desktops. Just-In-Time training should be the goal."

#4: Communication

Effective communications are crucial to a successful program. Haynes put his muscle behind a communications strategy that includes producing a monthly newsletter, establishing a dedicated user satisfaction manager position, and participating in periodic users' conferences.

In all of his communications materials, Haynes steps up to the plate with the good and the bad news, including software release notes that accurately describe which features are new, which are changed, which have any known bugs. Such honesty helps keep users clued in to the program and ensures they don't suffer any unpleasant surprises. "A comprehensive configuration management process is the engine that drives our ability to stay on top of and to communicate the latest developments so users know what to expect," says Haynes.

The Results

After the changes in the requirements, testing, and deployment processes were implemented, in early 2002, SPS began deploying v4.2 Increment 1 and is currently deploying v4.2 Increment 2. (Increment 3 is beginning development and is slated for testing in 2005.) Thanks to the CCE strategy, when a new SPS increment is deployed, another increment moves into development, and planning begins for yet another. The factory-belt approach accomplishes two goals: first, SPS is constantly evaluated and refined; and second and more important, it provides users with the knowledge that SPS is "fluid." The users know, even expect, that future upgrades are in development.

Today the user community enthusiastically embraces SPS. In fact, after participating in joint testing of v4.2, Air Force users petitioned leaders to deploy it ASAP--the first time in the program's history that end users actively petitioned leadership with such a request instead of waiting for top-down mandates.

"SPS is a great example of why strategic pauses work," Wynne says. "The pause gave us the latitude of time to look at the program through critical eyes and pinpoint areas to change."

A Continuing Evolution: Enter PEO EIS

With the strategic pause lifted in early 2003, SPS now interfaces with 32 systems across DoD; when SPS reaches full operational capability (FOC), it will replace more than 76 procurement legacy systems. Financial gurus estimate this area alone will account for $403.3 million in cost-avoidance savings.

Still, Harrington considers SPS an information-sharing tool, and an impetus to more competition. "It will serve our American citizens better through vastly improved electronic access to our government, and obviously our government will benefit by being able to buy things more efficiently and in a more competitive environment," he points out. "I think Col. Haynes' leadership in forcing stability in the program, the users' confidence in it, and the fact that it functions well are the strong points of SPS right now."

This is the reason Harrington engineered the program's move, with Haynes still at the helm as its PM, from its former home with DCMA to EIS. "An informational technology program manager would have the wherewithal as far as staff, technical help, and business management support to grow SPS for the future," Harrington explains. Kevin Carroll, the PEO at EIS, agrees wholeheartedly. "A fair number of information systems are conceived and developed within an organizational headquarters," he says, "but over time, people start to realize they might not want to manage it from there, [which is why] it is often [moved to] an organization that does program management as its core business function." Carroll continues, "I believe moving SPS under PEO EIS stems in part from our reputation for delivering results to include DoD systems and our customer focus in helping to integrate key information systems ... We expect to bring our experiences in these areas to help DoD more effectively integrate SPS with [related] systems." Ditto computer infrastructure consolidation, a move to ensure still more cost savings from SPS.

More Program Management Challenges Ahead

"A lot of people automatically assume technology makes their job a snap. SPS won't always make contracting people's job easier," Lee says bluntly. "We're now asking people to put more information in a usable methodology, and because we pass the data, it adds a level of complexity to the generation of that document. In my day, if I made a mistake writing a contract, I'd ink the change and initial it. In SPS, you must go back into the system and correct the data at all levels."

Nor is SPS a substitute for procurement knowledge. "I get very upset when I hear somebody say. 'The computer gave me the clauses in this contract,'" Lee continues. "The expectation that you'll just get into the system, request a cost-type contract and 'bingo!' it populates it for you won't happen. You still think through the terms and conditions, then put them in the document in a manner where the data can be passed."

Such human misunderstandings only remind officials that now is not the time to slack on communication efforts. "We continually need to explain to people why they are providing the information in this way," she adds. "Most of them will comply when you put it that way."

"Communication is key," adds Haynes, who plans to employ a stepped-up communications plan around v4.2.3. This version of the software holds a web-based, formless capability for SPS, allowing users to post solicitations, write awards, and manage contracts over the Internet.

If there is one overarching lesson resulting from the SPS program, it's that success requires the program management office, user representatives, and the contractor's developers and programmers to work as one team with one focus--the users who are depending on the software to accomplish their mission.

Editor's note: Comments and questions may be addressed to the author at [e-mail].

Polonsky-Hillmer is president of CorpComm Inc., a woman-owned small business specializing in communicating the business of government. She has worked with SPS since the program's inception.