Last week, the Office of the City Auditor of Portland, Oregon, published an interesting report (here in PDF) regarding an originally planned $14 million, 14-month implementation SAP Financial and HR/Payroll system project that ended up costing the city some $47 million and taking 30-months instead. 

In addition to being late and over-budget, the audit report also stated that when completed, the delivered system did not have all the functionality originally promised nor did the city eliminate nearly as many of the 200 identified shadow financial and HR/payroll-related IT systems as expected. Their elimination was touted as being one of the major benefits of (and justifications for) the new system.

The main reasons the auditors gave for the problems centered on poor project planning and inadequate leadership on the part of the City of Portland’s executive management from the beginning of the project. For example, the report noted that:

 "When the project began, City managers based the initial budget of $14.2 million on an independent estimate to procure and implement an ERP system. The City later realized that the estimate did not include certain costs, such as computer hardware needed to support the new software and any City employee costs. However, we noted that the independent estimate clearly stated that it did not include these items."

Thus, from the very start, "over-budget" and "late" were baked into the project's final outcome. 

The project became later and more costly in some of the usual ways: for instance, the city was warned repeatedly from different sources that the 14-month project schedule they set in December 2006 was too aggressive, but those warnings were blithely ignored.

In addition, the original project functional requirements and their implementation implications and risks were not well thought out. As the report states:

 "The project included designing a new accounting chart of accounts in order to improve consistency across the City for recording, tracking, and obtaining financial information. In order to convert financial data from the old software into the new SAP software, the City had to develop and program a crosswalk between the two charts of accounts. This process was more complex and time-consuming than expected."

The original project development company - before it was fired and a new one hired (which added to the project's delay) - also apparently routinely agreed to city employee-suggested requirements changes without thinking through their impact on the development budget, schedule or system functionality.  The development company, the auditors additionally noted, also lacked some necessary skills required to manage and implement the project they were contracted to deliver, which may explain why it helped torpedo its own contract.

Furthermore, project decision-making was decentralized because of the large number of stakeholders involved. The result?

 "According to one City project leader, the project’s organizational structure caused more time to make a decision than if a single individual had decision-making authority."

This could be seen, the report indicated, by the fact that the independent quality assurance (QA) contractor raised several "red" issues in its monthly reports - meaning they "required the immediate attention of Executive management and the Project Manager" - for months on end without any resolution.

However, the report also noted disagreement with the project leader's statement above. The report says that "... the City’s Chief Administrative Officer has indicated that he had single decision-making authority for key issues."

Given the project's outcome, I don't think I would be touting that fact too loudly.

Well, Portland's SAP Financial and HR/Payroll system is now delivered, although not everyone is happy with it. Turns out the employee training required for using the system wasn't all it could be either. The auditors recommended in their report that additional resources be budgeted to training City of Portland employees on the system.

One final note. The true cost of developing the system is at least $47 million, but its final cost will likely never be known. As the auditors state:

 "The reported final project costs of $47.4 million do not include all project costs incurred by the City. Reported costs do not include the payroll and benefits costs for many city employees formally assigned to the project full-time and working at the project office. Reported costs also do not include most city personnel working part-time on the project."

If I were a Portland taxpayer, I might be curious about exactly which government accounts those city employees working on the project actually charged their time against over the past couple of years. Might prove enlightening.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}