Private Lessons for Public Sector IT Departments

Privatization has forced those of us in the public sector to reevaluate, redefine and in some cases, reorganize IT departments. Traditionally, public sector IT organizations have enjoyed the luxury of a captive customer base for their services. State and local government organizations have provided services to their constituents, and in turn, IT departments have provided the necessary data processing services to their government organizations. Yet this situation is quickly changing.

Privatization is simply the hiring of private sector vendors to provide IT services traditionally offered by in-house public sector IT departments. The concept of privatization has spawned the growth of outsourcing.

Outsourcing IT services is not a new concept. It goes back to 1989, when Eastman Kodak and Enron signed multimillion-dollar contracts with outside vendors to provide their nonstrategic IT services. More recently, state and local governments nationwide have been closely watching the highly publicized outsourcing initiatives by San Diego County and Fairfax County, Va. These two counties have embarked on multimillion-dollar, long-term strategic plans to privatize and outsource most if not all of their IT functions.

Outsourcing has further evolved into an entirely new industry of ASPs that provide outsourced services for specific applications via the Internet. As the attractiveness of privatization gains momentum, those of us in the public sector need to understand how it will affect our organizations.

The appeal of outsourcing IT services in the public sector boils down to three factors: the cost of implementing technology, the cost of upgrading technology and the cost of maintaining staff. Shrinking budgets and constituents’ demanding the most from every tax dollar are forcing elected officials to seek alternative methods of providing necessary support services. As new technologies emerge, traditional public sector IT departments are hard-pressed to provide the services these technologies afford.

Traditional state and local IT organizations are set up as departments with corresponding levels of management and coordination capabilities. Outsourcing, however, requires high-level IT management and coordination. This management group is responsible for setting a company’s IT direction and reporting to the CEO the needs and expectations of various departments. This type of structure prohibits the purchase and disbursement of rogue applications and systems without regard to a company’s overall direction or strategy. It also facilitates better usage and coordination of financial and IT resources.

Public sector IT management must begin to think of themselves and their departments as the consultancy of choice for their government entity. They must strive to establish themselves as the place to go when department heads are considering IT services, even if they are incapable of providing those services. When dealing with outside vendors, they want to be sitting on the purchasing department’s side of the negotiating table. As IT professionals, not only do we need to be present in these situations, we must also be prepared.

An outsourcing deal requires a contract with the vendor, and there are several things to keep in mind throughout the life of these contracts. For starters, managing the relationship of the contract is essential. Service-level agreements, compliance responsibilities, performance reporting, and vendor and client approval rights are important elements of an outsourcing contract that IT administrators must enforce for successful post-contract management.

If we are?as we should be?in the middle of negotiations between user departments and outside vendors, the user will hold us responsible for the success or failure of the contract. Therefore, we must have a governing body that meets regularly to monitor and report on vendor compliance. The contract should be structured to levy fines for vendor noncompliance, which is more likely to get the attention of upper-level vendor management and is less time-consuming than getting contract concessions for noncompliance issues. If vendor service or compliance is unsatisfactory, we must have an established avenue of complaint resolution that directly involves upper-level vendor management.

Finally, the contract should have a clause ensuring that the personnel initially assigned will remain on the project for its duration or for a mutually agreed on length of time. That prevents vendors from bringing in their best people at the beginning of a project and then slowly removing this expertise once the project is under way.

As public demands for more services with fewer tax dollars increase, public sector service providers need to continually explore new ways to meet the challenge. Because the cost-cutting benefits will continue to be attractive, outsourcing is here to stay.

As new technologies emerge, traditional public sector IT departments are hard-pressed to provide the services these technologies afford.

Don’t Install- Implement

By James Vick

Ruffin Veal III is the IS associate manager for Ramsey County in St. Paul, Minn.

after several experiences with ERP during the past 20 years, I have found two typical outcomes. An ERP installation merely puts the software on the hardware. But an implementation results in a new system that drives profits by improving productivity and organizational effectiveness.

Given this distinction, most CIOs would prefer to oversee a successful ERP implementation instead of a successful ERP installation. The characteristics of wasteful installations are many.

Strong Project Managers

Weak project leadership is always going to result in a mere installation. All too often, a project manager is selected on the basis of expendability from whatever that person was doing before. You know a strong project manager when you see one. A good project manager understands the difference between why the software is being installed and why the system is being implemented. The project manager can deal with all levels of the organization and possesses tremendous political skills, but can be ruthless when required.

The well-suited project manager has a broad background with a focus on operations. The more diverse the background, the greater the ability to consider optimal solutions to the hundreds of constraints and conflicts that are germane to ERP projects. If the project manager’s background is narrow, these issues could slip through the cracks, only to appear after the software is installed.

Steering Committee Leadership

If the steering committee members lean back in their chairs during the monthly review meetings and yawn a great deal, you would be better off canceling the project and continuing with whatever legacy system is in place. All too often, the steering committee consists of executives who have excelled at their discipline but are not integrated managers.

An integrated manager knows both the numbers and values that the organization provides to the marketplace. For example, the controller knows the numbers but may be clueless about the values if he never sold the product to the customer. The marketing vice president knows the values but does not know the numbers unless she worked in the accounting department.

So the steering committee should be composed of thinkers from several departments who can combine their backgrounds and provide a level of integration that’s required for a successful implementation.

It is important for the project manager to understand the steering committee and force it to make timely decisions. Steering committees tend to have a member who is either integrating efforts across departments or is attempting to do so. This person is the informal leader and de facto decision maker regardless of his position in the organization. Often, the president or the highest-ranking person on the corporate pecking order has final authority over all decisions. Without a single decision maker, meetings often conclude with a call for more analysis. This is not something that lends itself to successful software implementations.

Keeping Tabs and Educating Users

Always maintain an attendance log for team meetings, project meetings and steering committee meetings. Whenever an individual team member’s attendance falls below 80 percent, go to the steering committee and request a replacement. Few organizations maintain this discipline or philosophy, but it’s necessary for a successful implementation. You are looking for people who can make things happen.

Don’t underestimate the importance of education and training. What’s the difference between the two? Training provides specific knowledge about the software and hardware, and focuses more on the “how to” aspect of the project. Education is an expansion of the software’s and hardware’s mechanics and philosophy, and its focus is more on why an organization is undertaking the project.

In 1996, a client asked me to implement an ERP system. I wanted to budget time and money for a one-day educational class. Since the client had already had three major systems projects in the past 25 years, the steering committee deemed education unnecessary. I then asked committee members to solve a simple gross-to-net calculation I wrote on a blackboard. When only one member came up with the correct answer, the steering committee immediately approved the class.

To determine the level of education required, create a test for members of the steering committee and project team. Ask them 10 questions or so; if the average score is less than 75, it’s time to establish an education budget.

Objectives, Objectives, Objectives

Never lose sight of why you are implementing a new system: to increase profits. Always plan a post-implementation audit to verify that the objectives are achieved. Remind everyone that this audit will reveal how well the job was done.

A high-level project plan should be the same at the end of the project as it was at the beginning. This is the primary communications device with the steering committee?the project manager will have a copy of this on his pillow. However, as the project matures, action items in the plan begin to grow exponentially, and as many as half of all assigned tasks are slated for completion in the last 10 percent to 15 percent of the time allotted for the project.

These are the major characteristics that lead to a successful ERP implementation. Follow them, and you and your organization are well on the way to triumph.

James Vick, who formerly worked for a company specializing in lean manufacturing and ERP implementations, is general manager of Engine Masters, a Delco Remy International company in Dallas.