Looking backward to move forward: the best way to avoid future problems is to review the results of past projects and put the lessons learned into practice.

Author:Roque, Rob

Looking 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.


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 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...

To continue reading