In July 2014 I wrote about the University of California's project to update its payroll & HR systems to Peoplesoft systems and how the project had ballooned out of scope. The goal of the $156 million project was to save a reported $100 million per year eventually and to replace a 30-year-old Payroll Personnel System (PPS) that runs separately for each of the 11 UC locations with Oracle’s PeopleSoft payroll and HR systems. All systems were planned to be live by the end of 2014.
At the time, I quoted Christopher Newfield at Remaking the University with this summary:
The project timeline has grown from 48 to 72 months, and its costs are said to be $220 million (it had spent $131 million by May 2014) . Worse, the repayment schedule has mushroomed from seven to twenty years.
Well, those were the good old days it appears. The project has now grown to more than half a billion dollars (estimates) according to the Sacramento Bee. The project is now four years behind schedule.
From today's update from the Sacramento Bee:
But deadline after deadline has come and gone as UC struggled to integrate the business processes of its 10 campuses, five medical centers and central administration. Though 1,800 employees in the Office of the President have been receiving paychecks through the system since January 2016, UCPath has yet to go live at any of the other sites.
With the latest revision to its schedule, Vazquez said, the project is estimated to cost $504 million, including a $26 million contingency “to accommodate any unexpected large expenses in the final year of the project budget” that may not be used. The university has spent $327 million so far.
The University of California is not the first and will not be the last enterprise to have its ERP scope explode. What is more concerning is the tendency to double down or triple down without (re)questioning the original assumptions to make sure they make the best decisions today. As we can see (read the blog post), UC made major financing decisions based on the $220 million estimate and two years delay. But that estimate proved inaccurate. Would they have done the same if they thought the total was $504 million and four years delay?
I have not had time to research the latest board presentations, but I'll include this concern I added in the 2014 post:
- What about the current estimate of benefits – is it $30 million per year as Chris described or closer to $100 million per year? One big concern I have is that the information on project benefits was not updated, presented to the regents, or asked by the regents. While I question the $25 million financing and $30 million benefits numbers, I think Chris got it exactly right by noting how UC administration is failing to ask hard questions:
Moving forward, I’m afraid that officials are going to have to get much better at admitting mistakes like UCPath, and then actually undoing them. I couldn’t listen to the recording of the UCPath conversation, but Cloudminder made it sound like a lot of restrained finger-pointing with no solution in sight. Did anyone say, “well, this seemed like a good idea at the time, but it’s not. Let’s just cancel it, figure out where we went wrong, and come up with something better”?
It is possible that continuing with the rebooted project is the right answer, but UC is not even asking the question. Failing to ask whether 15-20 year financing of a new ERP makes sense seems like a major oversight. Won’t this lock UC into an Oracle system that is already antiquated for another two decades or more?
It may be that this project is finally coming to completion (the article claims they are in testing and data migration now), and the project may pay off in a decade or more. But there is still room for concern on this project and the impact it will have on UC finances, especially at a time when cost of education and student debt are becoming more important. Think of the educational areas that will lose funding to cover for this major increase in administrative spending. I wish them the best - they need to get this project under control.