Lost Signals

How poor communication and other nontechnical issues hampered Arkansas' innovative statewide ERP implementation.

by / January 30, 2003
In the late 1990s, Arkansas started a project to revamp how it carries out accounting, human resources and other core business functions. The state boldly installed an ERP software package for all its agencies, becoming one of the first states in the nation to attempt such a comprehensive implementation.

But in the nearly three years since the state began planning the Arkansas Administrative Statewide Information System (AASIS), the project has been wracked with difficulties that have little to do with technology and everything to do with introducing massive change into a large public-sector organization. The ambitious project has endured political infighting, overly optimistic timelines, poor communication, shifting responsibilities and inadequate staff training. When Arkansas officials threw the switch on the system's accounting module in July 2001, more than 5,000 state employees failed to receive their paychecks.

State officials say progress is being made. Parts of the AASIS human resources module have rolled out to some agencies, and Arkansas plans to deploy pieces of the system's performance-based budgeting module in 2003.

But the project's history paints a stark picture of how nontechnical issues play a central role in the success of IT initiatives.

"We failed to recognize, I believe, that we were changing the accounting system in the state," said Kelly Boyd, technology policy adviser to Arkansas Gov. Mike Huckabee. "We weren't just teaching people how to run computers; we were teaching them accounting all over again. You've got people who understood state government, and we were just taking that all away from them."

Aggressive Schedule
AASIS started innocently enough. Deloitte & Touche completed a needs assessment for the state in 1996, recommending Arkansas consider purchasing a new financial-management system that, at a minimum, would provide five core functions -- accounts payable, accounts receivable, general ledger, budget preparation and budget control.

By October 1999, the state decided it really needed an entire ERP software package and released an RFP seeking bids. After the usual winnowing, SAP won the contract in February 2000.

Once it chose the software, Arkansas set an ambitious schedule -- completion of the system's business blueprints by June 30, 2000, and a "go-live" date of July 2001. This left the state with a scant 16 months to implement the first ERP module across all state agencies.

Cracks quickly appeared. Monthly AASIS status reports began setting off alarms, according to the state's legislative auditor.

The June 2000 status report warned that only half the business blueprints would be turned in on time. It also cautioned that additional state staffing was needed for management of the changeover, human resources and training. July 2000's status report said the state lacked approximately 12 to 20 positions; August 2000's status report again warned that the AASIS project team was not adequately staffed to successfully deploy the software to all participating agencies.

By November 2000, the situation was critical, according to the legislative auditor's special report. That month's status report said the "state's ability to successfully implement and roll out the system to all agencies on July 1 is at risk due to insufficient deployment resources. ? If the deployment team is not fully staffed with qualified individuals by January 1, 2001, the scope of the July 1 rollout must be reduced."

In December 2000, SAP itself urged the state to push back the go-live date, according to the auditor, but Arkansas stuck to the July deadline. Extra staff was made available to the deployment team, but end-user training emerged as the next big problem.

In March 2001, a status report offered a bleak assessment of Arkansas' training situation: "Of the 1,569 seats available in the first session of Overview and Basic Navigation, a prerequisite for all other courses, only 744 were occupied -- a 47 [percent] utilization rate. ? If this trend continues, some employees will not be able to get into the classes they need to take. An urgent message sent to agency liaisons seems to have had little impact; another is forthcoming to agency directors."

More problems surfaced in the April 2001 and May 2001 status reports, both of which questioned whether users would be ready to start conducting business with the new system.

Boyd acknowledged the state's failure to adequately address the mounting trouble signs.

"There is no question red flags were present during development of the project," he said. "Undoubtedly, our ERP would have benefited from improved communications, as is evidenced by the fact that many of these red flags were simply not effectively communicated to individuals with overall project responsibility. Add to this situation the intense political pressure and negative press scrutiny, and you have a project primed for difficulty, as we indeed experienced."

Full Speed Ahead!
Arkansas Sen. Kevin Smith, chairman of both the Senate Technology Committee and the Legislative Joint Audit Committee, attributes most of AASIS' trouble to the aggressive implementation schedule.

"The original sin of the AASIS experiment, in my opinion, was when Gov. Huckabee set a deadline and said we will fully implement AASIS by July 2001," Smith said. "When he said that, he set in motion all the other problems because [the state] was trying to rush to make that deadline."

The self-imposed deadline spawned a host of nontechnical problems that severely hampered efforts to roll out the first piece of AASIS -- the accounting module, he said. In particular, project management, training, budgeting, planning and communications were hurt by the tight timeline, he said.

Another problem that concerned Smith was the seemingly musical chairs approach to managing AASIS. "If you keep switching who's in charge, you're never sure who's actually accountable," he said. "That's a bureaucratic game that bureaucrats have known for years. That's what's been happening here: As long as we don't know who's in charge, we don't know who to hold accountable."

The accountability issue triggered friction between then-state CIO Randall Bradford and the Huckabee administration. Huckabee hired Bradford for the newly created CIO position in October 2001, in part to lead the AASIS project. In a press release announcing Bradford's hiring, the governor's office said the new state CIO would serve as a "technology czar," coordinating IT efforts of state agencies.

The AASIS Support Center soon emerged as a bone of contention. The support center, which other agencies called for help with implementation problems, was critical to the AASIS project. Yet control of the center was transferred back and forth between the CIO and the Arkansas Department of Information Systems (DIS), according to Bradford's testimony before the Arkansas Joint Legislative Council at a special hearing in July 2002.

Bradford testified that Huckabee gave him control of the support center in October 2001, but shifted control to DIS in March 2002. The change created an unnecessary division of labor, Bradford said. It also hampered management of the project because it put the support center under daily operational control of DIS, while the CIO was responsible for the overall success of the AASIS project.

The Huckabee administration, however, said the changes simply reflected the project's evolving nature and that AASIS had just two project managers throughout its implementation.

"AASIS started out in the Department of Finance and Administration because, quite frankly, it started out as an accounting solution," Boyd said. "As it moved into the broader scale project, and as that move coincided with the fact that we brought on a new CIO, we decided the effective way to handle AASIS was to make the CIO responsible for it."

That situation changed again as Bradford ironed out the early problems, Boyd said. Once enterprise problems associated with AASIS were resolved, the state had to decide if Bradford should continue to directly manage the AASIS project, or address broader issues as the state's CIO, he said. Ultimately, responsibility for AASIS' day-to-day operations was shifted to the Arkansas Department of Information Systems because the organization was best suited to respond, Boyd said.

"We tried to define AASIS within the best location for it, which turned out to be the Department of Information Systems," Boyd said. "But if I, today, had a problem with AASIS, I would call the CIO's office and let them get me to the right person; get me to the right solution. We had to get AASIS to the right spot for it to function the best, and for people to work on it the best."

Arkansas continues to assess how best to manage the project, he said.

Communication Breakdown
As the management issue played out, Bradford released to Arkansas newspapers a series of damning internal e-mails from Huckabee's staff, causing a major hullabaloo in the midst of an election year. When he left office in mid-June 2002, Bradford said he released the e-mails because he was being made a scapegoat for problems with AASIS. In part, the e-mails appear to show the governor's staff instructed Bradford to neither work with Legislature, nor share information on the status of AASIS with Legislature or the local press.

The alleged attempt to shut off communication signaled a major problem, said Sen. Smith.

"Randall Bradford and [former Chief Security Officer] Mike Miller actually established credibility with the Legislature, and did so by admitting to some of the problems; how they were solving those problems; following through; and all those kinds of things you try to do as a program manager," Smith said.

"You can't implement a sophisticated enterprise project without good, clear lines of communication; open communication with all stakeholders involved, and even then, it's going to be a challenge," he added. "When you have that kind of communication problem brought on by political considerations, which is what that is, it's almost impossible."

Although Boyd couldn't comment on the e-mails directly due to pending litigation, he acknowledged communication was perhaps the single biggest problem for AASIS throughout its implementation.

"Communication is difficult in any large project, and we highlighted that with this project," he said. "I don't believe we effectively communicated to people -- I'm talking about agencies, the administration, the AASIS Support Center, all of us -- the depth, the breadth and the importance of this project."

Legislators grew frustrated when they held committee meetings and never got a firm grasp on AASIS' status or the project's progression, Smith said.

"We had meeting after meeting after meeting in my committee; at one end of the table were all the suits from the Department of Finance and Administration, from the Department of Information Systems, the consultants and one bearded guy in blue jeans from SAP," he said. "He was the only one who knew what the hell we were talking about. Every time someone from the committee asked a question, all the suits would look at each other in puzzlement until, finally, they all looked at the guy with the beard. He would say something that nobody understood, and we'd just say, 'Ok, whatever' and go on."

The lack of communication influenced just about all things AASIS related, Smith said, including training, expectations and implementation plans.

Radical Transformation
An unfortunate byproduct of the poor communication, Smith said, was that front-line employees had no confidence in AASIS, had a hard time figuring out how to use it and couldn't get their questions answered.

Yet employee confidence was a critical factor in the system's success because AASIS was forcing the state to change how it did business. Besides learning completely new software, agencies struggled to digest a new accounting method as Arkansas shifted from cash to accrual accounting -- a radical shift that fundamentally altered tasks state workers had performed for the last 25 or 30 years.

Boyd said Arkansas underestimated both the magnitude of training and the changeover management needed to make that shift smoothly.

"We should have understood what we were doing with respect to the scope of the project, developed our training accordingly, and then had a way to ensure people were trained before we let them go live," Boyd said. "We didn't. Our test was when we went live, and we didn't get a very good grade."

Industry sources said Arkansas isn't alone in struggling with these challenges. Many public-sector organizations have difficulty spending money to address nontechnical issues, such as helping end-users adjust to changes, said Mark Lippard, a principal with Deloitte Consulting.

"You've got $8 million, $32 million or $82 million to spend, and you're going to spend it in three years. [So] you tend to focus on what is the hard thing I'm spending it on, as opposed to, 'We're going to spend 15 percent, 10 percent or 8 percent of this total on helping the organization adapt to the change,'" he said. "That's a real good way to spend money, but an elected official may have some difficulty spending taxpayer money on helping someone accommodate a change."

Lippard, who's been involved in a number of public-sector and private-sector ERP implementations, said these projects must be approached as an organization-wide change initiative instead of a discrete software implementation. Unfortunately, government organizations often view such projects as a one-time event.

"If you're going to really get the return out of a business transformation, one piece of which is an ERP implementation, you've got to view it as an ongoing endeavor that's going to require, on the part of the institution, an ongoing investment," Lippard said. "That's not really consistent with the way a public-sector institution views money. Everything is a discrete budget. This is a discrete project; so there are n dollars, and they watch those dollars very, very carefully -- and there are no more dollars."

This funding approach encourages jurisdictions to attempt to accomplish everything during the implementation -- and may prompt them to bite off more than they can chew. Indeed, Arkansas decided to reverse certain business processes that Deloitte implemented, Lippard said, even though the state agreed those business processes were correct. The problem was that making those particular transitions within the state's implementation deadlines was simply too big a task.

The original implementation plan called for 30 weeks of final preparation. In actuality, the legislative auditor's report found the state was left with a mere 11 weeks of final preparation -- which included system testing, end-user training, system management, agency implementation and changeover activities.

Another crucial difference between private-sector and public-sector ERP implementations is the development of a business case, Lippard added. Private businesses demand evidence that an IT project will produce enough benefit to justify the investment, but governments often do not. One reason is the business case may expose some potentially uncomfortable issues for the public organizations.

"It's possible that business transformation could result in major staff changes, and possibly staff reductions," he said. "It may be that you don't want to get into that up front. You may just want to deal with that when it happens."

Some public-sector organizations do prepare a business case, he said, but Arkansas didn't create one for AASIS.

"In the public-sector, I find frequently there are issues the organization just doesn't want to deal with," Lippard said. "The reason is they can't enforce them; they're going to be unpopular; they don't want to tell other people over whom they don't have authority that they're going to have to make an investment; they don't want to recognize or accept that the cost is more than they planned -- there's sometimes less of a willingness to actually come to grips with some of the very hard decisions."

Shane Peterson Associate Editor