Mobile Edition
Print
Get the Mag
Weekly UpdatesLooking to the past can be difficult because it forces us to reassess accomplishments and, often, start second-guessing ourselves. Nonetheless, many successes are achieved by reviewing past results, which is why post-project assessment is often cited as a best practice in project management. To make process improvements, organizations need to catalog what went well with previous projects and what did not, and then regularly review these results and adapt the lessons learned to future endeavors. This article will describe common pitfalls from public-sector enterprise solution projects, prescribe some remedies that have been developed as a result of reviewing past efforts, and describe the process of completing a post-project audit.
COMMON PROBLEM AREAS
Implementing an enterprise resource planning (ERP) system is a major consideration for many organizations in the public sector. It is a significant undertaking, since ERP software is designed to run most business processes in a single, integrated package. And as might be expected, these complex projects generate quite a few lessons learned. Problems identified frequently include:
Unattainable scope. When the scope of a project is too ambitious, the timetable often gets roiled back. The budget, however, stays the same, leading to insufficient resources to complete the project.
Lack of input. Constituents of the project do not feel they had enough opportunities to provide input into the design and development process, and that as a result, project expectations were not met.
Overly ambitious scheduling. Rollout schedules are often too ambitious, or they are not logical. An example would be a mayor who promises that a 311 system and all supporting functions will be installed by the next election without checking with the project team to see if this vision is realistic.
Misaligned staffing assumptions. Managers assume that staff members who are assigned to the new project can still do their old jobs at the same time, and that those employees can return to their old jobs when the project is completed.
Confusion over post-implementation governance. In one common example, the technology department had supported the legacy applications, but there are multiple "owners" of the new system, leading to a lot of finger pointing.
Less-than-stellar consulting. The organization asked for the consultant's "A" team but got the "C" team. As a result, the system is not configured well, and closing the system and producing proper financial reports is difficult at best.
Inadequate transfer of knowledge. If the consultants do not teach staff how to take over a new system, the organization can become dependent on expensive consultants.
THE VALUE OF LESSONS LEARNED
The pitfalls mentioned above have all been cited by public-sector organizations as problems that could probably have been avoided through a lessons-learned exercise. Before any project is undertaken, project managers should make a special effort to review similar projects. This includes looking at other projects that have been completed or are currently underway within the organization. The following examples describe how other governments have applied lessons learned to current projects.
After assessing other internal projects and identifying inadequate staffing as a potential stumbling block, one large county government is spending almost a year prior to implementation of a new ERP system to train or hire backfill positions. After coming to a similar conclusion, another midsized county government started identifying funding before hiring ERP consultants. When managers realized they could not stretch existing personnel resources to adequately complete the project, the project leader contacted other governments that were implementing similar software and asked them about potential independent contractors, which have less overhead and are therefore less expensive than permanent staff. By recognizing past concerns and dealing with them from the outset, these governments were able to head off problems that could have had severe repercussions on their projects.
Another county government looked at previous problems with contract enforcement and realized it needed to make changes to its request for proposals (RFP) process. The government had been using the RFP response as the statement of work (SOW), which is usually a negotiated part of the contract. As might be expected, the contract was only as good as the quality of the RFP and the initial RFP response. This government is now working to change the procedure, developing the SOW as a result of a procurement process that includes the RFP response, software demonstrations and interviews, and reference checks.
One successful ERP project, which consisted of multiple task orders, defined lessons learned as a deliverable. When a task order was concluded, the contractor was required to gather the stakeholders for a lessons-learned meeting and to document the results. The remedies identified during the meetings were often applied during negotiations for future task orders. For example, one remedy was to alternate key consultants and client staff with key activities on each task order. This enabled the contractor and the client to plan overlapping task orders while minimizing the impact on key resources and activities.
A smaller government implementing a complex ERP package used its study of previous implementations to become less dependent on consultants in a relatively short period of time. This jurisdiction learned that successful knowledge transfer in ERP projects is associated with limiting the number of customizations, emphasis on training of the project team, and tightly managing scope. As a result, the government was able to save money by upgrading its system with minimal help from consultants.
SOME REMEDIES
Any government can improve planned projects by looking at what other organizations have done. Several common characteristics emerge from a review of highly successful ERP projects.
Most ERP implementation problems are the result of ignoring one of the three basic "Cs"--commit, communicate, and compare. No project is likely to succeed if there are no committed resources, which are defined as leadership, personnel, and financing. In addition, the most successful projects convey information effectively to all stakeholders. And finally, the most successful projects often conduct research on peer projects to obtain successful practices.
Poorly written contracts are another frequent problem. Organizations need to negotiate strong license and services contracts, including detailed SOWs. The contract typically covers the terms and conditions and other legal requirements, while the SOW defines the deliverables, outlines the expectations, and delineates the roles and responsibilities of a vendor. A project manager can almost rely upon the SOW alone, if it is written properly Revisiting the contract portion of a services agreement or software license during a project, however, is considered a play of last resort since it may lead to project delays and cost overruns.
Project planning is crucial. There are countless resources available on project management, but they assume the reader is implementing a new project with a tidy beginning and ending. In reality, major technology projects such as ERP implementations have multiple phases, and they do not end; instead, they morph into post-implementation projects. Successful initiatives account for the gaps between phases and the effort required to maintain these systems after implementation.
Keeping in mind that ERP projects never end, previous successes show that organizations should always be looking for ways to enhance their systems and identify implementation opportunities. For example, a major security enhancement may be installed while the system is being upgraded. Most information technology (IT) departments do a fine job of this, from a technical perspective. On the other hand, users of the system become very comfortable with what was originally implemented, even if it was a workaround. Unless a major upgrade is being planned, items such as chart of account design or business process designs are seldom reconsidered.
Because governments tend to fall into the trap of assuming that ERP and other major technology projects are one-time financial events, they often fail to prepare ongoing budgets for the systems they implement. Because these projects always require ongoing maintenance, upgrades, and enhancements, governments should prepare technology portfolio strategies that take into account prioritized needs, funding sources, and schedules.
Organizational planning is another key area governments tend to overlook when implementing an ERP system. Questions usually arise as to who owns the system: The IT department claims ownership because it is a software project, and IT therefore assumes all the risk; the controller claims ownership because it is viewed as the official system of record; and so on. But the system is actually owned by the entire organization, not by any single department or division. Governments that set up separate ERP management groups typically have the least conflict, so long as those groups are empowered to make decisions. When creating a separate organization is not feasible, governments have housed ERP management within a central service department in technology, central administration offices, and even operations departments such as purchasing. The key is that the department supporting the ERP system views itself as a service department to the rest of the organization and is willing to subscribe to the three Cs mentioned above.
THE PROCESS OF LOOKING BACKWARD
The following steps outline a process for completing a post-project audit. The first process describes a method for analyzing other projects. The second process addresses a post-project audit as part of the project closing.
FEED