In 2003, city leaders initiated an effort to update and modernize New York City’s payroll system for local government employees. The project, aptly named CityTime, started with a budget of $63 million.
In 2011, NYC mayor Michael Bloomberg demanded that the systems integrator at the helm of the project reimburse more than $600 million to the city. This request came soon after the project manager, software designer, and members of a subcontracting team faced criminal charges connected to their involvement in the project.
What can you learn from the CityTime ERP failure as you launch your own enterprise software initiative? Today, we’re taking a look at what went wrong and how you can avoid similar mistakes.
A Government Entity's Failed Implementation
Behind the CityTime ERP Failure: What Happened?
To understand how the CityTime ERP project ultimately failed, let’s start by looking at how it began.
First planned in 1998, it was scheduled to take a total of five years to complete. During that time, a brand-new commercial payroll system would be built. The system would replace the paper timesheets and hand scanners that were currently in use.
Why did the city choose to build a system from scratch rather than purchasing a pre-built solution? It’s because the city planned to sell the CityTime system to other city and state governments that wanted to emulate the NYC model. Project leaders estimated that the software would sell for around $200,000 plus user fees.
When it was time to initiate the project, the city spared no expense, especially in terms of third-party resources. In 2003, the city hired Science Applications International Corporation (SAIC) as the systems integrator for the project.
Financial Scandals Lead to Cost Overruns
One of the leading technology application companies in the nation, SAIC was a natural choice to lead the effort. However, as early as 2005, suspicions arose about a kickback scheme siphoning money from the project.
The scheme, which included wire fraud and money laundering, caused the project budget to skyrocket. Eventually, the total estimated cost to taxpayers was close to $760 million.
In all, 11 people were indicted in the scandal, including top SAIC executives, as well as the city official overseeing the project.
In 2010, new City Controller John Liu began putting the steps in place to shut down the CityTime project. He gave SAIC until June of that year to ensure all 165,000 city workers originally targeted to use the system were actually using it.
However, the project officially finished in 2011 with only half of those workers using it.
How to Avoid Similar Mistakes in Your Organization
Without digging too deep into the criminal investigation, let’s take a look at some of the high-level issues that were at play in the CityTime ERP failure, and what your organization can learn from them.
1. Don’t Rush Your Implementation
One of the earliest and most enthusiastic champions of CityTime was Mark Page, the New York City Director of the Office of Management and Budget.
A lawyer, Page was frustrated with the idea that soon-to-retire employees were abusing the current, manual payroll system. He cited that unauthorized overtime use could increase pension payouts to city workers, costing the city far more than it planned. He wanted to curb such timekeeping abuses through payroll automation, hoping that the new system would save NYC tens of millions of dollars per year.
With the power to control agency budgets, Page persuaded commissioners to support the project. It wasn’t long until the project launched, even as questions were swirling about its implications.
Lesson Learned: Project planning is an important part of any ERP implementation, and it can’t be rushed, even when key stakeholders are eager to fix pain points as soon as possible.
2. Minimize Change Resistance
Another issue that led to the CityTime ERP failure? Not every city agency transitioned to the new system at the same time.
During the 10-year rollout, certain smaller agencies were ordered to quickly adopt the new timekeeping system. Meanwhile, other agencies were allowed to delay the switch. In most cases, these were larger and more powerful agencies, such as the NYC Police and Fire departments, as well as City Hall.
As you might imagine, this created a logistical nightmare. Likely, it also sowed seeds of resentment among those employees who had no choice but to embrace a shift that was still under development.
Lessons Learned: Each department should understand its role in the ERP project, and each should have an equal voice at every juncture. Developing a change management plan is the best way to prepare personalized messaging for every impacted department.
3. Outsource with Caution
While it can be helpful to bring in outside consultants to assist with a project, there should always be a level of internal control and oversight.
At the time of the CityTime failure, former NYC Deputy Mayor Stephen Goldsmith admitted that there were too many outside partners working on city contracts. He went on to explain that more work would be insourced to city workers in the future. Moreover, moving forward, city managers would more closely control any work to be outsourced.
Why is outsourcing so risky? With so many moving parts, it can be difficult to see even the most glaring signs of team member misconduct.
When three contractors from the project were sentenced for their crimes in 2014, the federal judge pointed to a lack of oversight in the city’s contracting procedures. This included insufficient background investigations, which led to contractors and subcontractors joining the team without a careful evaluation.
Lesson Learned: Any time there are subcontractors involved in an ERP implementation, it’s important to clearly delineate the terms of the agreement. There should also be internal leaders who maintain visibility into every project phase.
4. Prioritize Project Management
Even if the city had prevented the fraud situation, CityTime was poised to fail.
In a 2014 report, the NYC Department of Investigation (DOI), explained that the city did not properly supervise the project. Issues included inadequate executive oversight and a lack of expertise in managing large-scale technology initiatives.
The report also explained that the city didn’t assign someone to monitor integrity, which would have been necessary for a project that size. The role should have been assigned to an independent government agency, such as the DOI. The monitor should have performed regular audits of the time worked by consultants and analyzed when and if any new consultants should be added to the team.
Without such oversight, consultants had the freedom to overwork and overspend, having no accountability when deadlines were missed or when budgets were expanded.
Lesson Learned: Strong ERP project management can make or break an ERP software implementation. The roles your project manager will play will be unique to the nature of your organization and the nature of the project.
5. Beware of Scope Creep
The DOI explained that city leaders didn’t evaluate the ever-changing and always-expanding project scope.
Along the way, there were changes and contract amendments that increased the overall cost of the project. As a result, hundreds of new workers were added to the CityTime project, which caused the budget to significantly increase.
This is a phenomenon known as scope creep, and it’s all too common in ERP efforts. What begins as a conservative, well-planned effort can quickly spiral out of control if the right change controls aren’t established and followed.
Lesson Learned: Change control in project management is essential.
Avoid Scope Creep and Corruption
The CityTime ERP failure was a project marked by shameful scandal and astronomical costs.
While much of this corruption was the result of unscrupulous leadership, there were foundational issues that contributed, as well. Specifically, the project lacked effective leadership, proper planning, and internal controls.
Contact our ERP consultants below to learn how to apply these lessons learned to your impending IT project.
