Managing major technology implementations is becoming a task that local government managers might face with increasing frequency. Major technology enhancements like an enterprise resource planning (ERP) system continue to be essential for the delivery of services to internal and external customers, while requiring diplomatic skills to deal with competing stakeholder interests.

While implementing ERP or other major systems is not a routine local government task, it can be a hot topic of interest and frustration. Learning how to manage this large investment in time, staff, and financial resources from the experiences of others can be a major help in the implementation process.

From my own experiences, here are six areas of advice that may help other managers avoid some of the typical pitfalls with system implementations:

Create an IT governance structure. Before starting a project, identify an organizational champion for the project who has the authority to make decisions across departmental lines for the good of the organization.

This person needs to be able to bring together all of the participants to identify key service needs and set strategic goals. Making the best decisions for overall organizational needs means understanding that some changes in how business is done will need to occur.

With a set strategy understood by stakeholders, solutions that seem best for a particular department but might not work as well for other programs can be identified and addressed. This will help an organization focus resources on a solution instead of having to maintain a multitude of disparate systems with no logical strategy on how they should function cohesively.

A dedicated project manager directly linked to the organizational champion also will benefit the governance structure. This person should lead the group effort from RFP and selection through implementation and ultimately ongoing upgrades and administration.

Ideally, this person will have the skills and knowledge—and be given the time—to be the link between the selected vendor, the IT staff, and the actual end users who will handle the systems each day to deliver services.

From my experience, a key to success is delegating ultimate authority to a single person who can decide which requirements will take precedence in selecting and implementing a new system and also has the ability to build consensus with key stakeholders.

Determine technology capabilities and needs. An assessment of required service and program needs is best done with a technology assessment that also looks at an organization's capacity and readiness for change.

An outside adviser can be helpful in providing an independent voice for this assessment, validating the organizational capacity to meet ongoing demands of user departments, and identifying their legitimate needs. This adviser also can help a chief information officer determine if staff members have the appropriate skill sets and the in-house expertise needed to realistically meet department demands.

A technology assessment also can assist with documenting actual user needs. System requirements are often set because "we have always done it that way" or based on a reluctance to change established policies and procedures. Make sure system requirements are based on actual needs.

Documenting complete workflows can help determine if all of the systems and processes that are touched by an ERP solution have been addressed. Failure to adequately identify all of the associated processes and systems that will be impacted—for instance, limiting the focus to general ledger and payroll in an ERP—can create problems.

Areas like imaging, customer resource management, printing, utility systems, and cashiering systems should be considered for integration to get the full benefit of new system implementations.

Resist the argument that you are unique. In understanding system capabilities, it is important to make sure everyone understands the differences between configuration and customization.

Software is developed to meet the needs of the many and not the wants of a few. Configuration allows for built-in options where you choose how a process or service will flow without changing the basic programming. Customization requires a change in programming to meet a specific requirement that has not been necessary for other users of the program.

If you find that many items you are requesting from a vendor will require customization, it is best to determine if this is an absolute requirement or just a "want" based on how things have always been done. Customization not only costs for the initial development and implementation, but it also requires significant ongoing costs and testing each time the general software is upgraded or enhanced.

One of the worst mistakes I have seen is actually coding bad practices into a new system through customization. Look for efficiency improvements in systems and processes based on best industry practices before choosing to pursue changes to the implementation products.

An outside implementation team can often help you determine if the unique practices that particular users "cannot live without" are actually outdated practices that can be improved with new software.

Always ask yourself, if changes are so unique that the vendor will not incorporate them into the base software, are you absolutely sure you are willing to plan (and pay) for the future costs and staff efforts to keep those customizations in place. Do not customize if you can find any reasonable alternate solution or practice.

Prepare for staff and advisor transitions. Personnel transitions for both internal staff and external advisers should be considered as you embark on an implementation. Staff often must dedicate significant time to an implementation, as well as complete their normal job assignments. Using change management techniques and being on the lookout for staff burnout can help reduce turnover during implementation.

Consultants also may change between the selection and the completion of implementation. It is not uncommon to have "fit" issues between staff and particular advisers. The contract should define the process for fixing this as quickly as possible when it occurs.

In my first ERP implementation, we hired the project manager near the end of the software selection process. Had he joined the team earlier in the process, his input and knowledge would have made the RFP and the selection process much smoother.

I also asked the winning software vendor to provide part of the implementation team with the third-party vendor to make sure they had "skin in the game." Hindsight showed that this just increased the communication problems and costs for the project.

Plan for the future. It might be easy for managers to get caught up in the excitement of new technology and forget that the goal is not to go live with a new "IT project" but to create a better way to deliver services.

Thinking about how staff members will transition from implementation to on-going maintenance and support also is often overlooked. When the implementation support team is finished, the ongoing maintenance, upgrades, and support will need to be handled by someone for the life of the software.

While "going live" with a project is an accomplishment, it is actually the beginning of life with this new system that requires consistent communication, preparation, and planning for its long-term life and maintenance.

Another issue that we did not address up-front was disaster recovery. What happens if a vendor is holding the software or data and you lose connection, or there is a disaster either locally or at the vendor's site?

Make sure you address how often you will need to back up data, and how you will recover data that might be lost due to unforeseen circumstances.

Communicate with all users. Even with a structure in place that provides regular meetings with all of the key stakeholders, don't forget to communicate with the rest of the organization's members who will be impacted by the new system. End users want to know why decisions are being made, how these decisions will impact them, and what these changes will mean to their customers.

End users can be a major factor in determining the success or failure of an implementation. They also are the people who will help you identify and resolve many of the pitfalls that come with implementation. Consistent communication with this group can provide the linchpin for success.