Univ. of Wisconsin's 30-Year-Old Payroll System Needs a $40 Million Fix

jaroslav writes "The University of Wisconsin is attempting to update a payroll system they have had in place since 1975, but spent $28.4 million in a 2004 attempt with no results, and now is experiencing new overruns in cost and time after 'not hav[ing] the full picture of how complex this project would be.' The current estimate of the redesign is $12 million and years of further work on top of the money already spent."

Comments

Re:What is so special about this university?

[emmons]

This is a statewide system that needs to be deployed on all 26 UW campuses, administration and UW-Extension (which has an office in each of Wisconsin's 72 counties). It handles all types of employees from student LTEs to professors to staff to administration, all of their benefits through the state retirement fund and the state employees healthcare plan (which itself is fairly complex). It has to deal with union and non-union employees and their different pay structures, special deals for certain faculty, etc. It's a complex system that is specific to the State of Wisconsin, so no, there is no off the shelf solution.

On top of all that, much of the cost is in deployment and training of all the people who have to use the thing.

The money goes quickly on these projects

[kbob88]

I've been involved in a few of these types of projects (unfortunately), and believe it or not, the money goes quickly. So does the time. It's not just coding -- that's actually a very small part of the money. It would take some time to burn through $40mm, but you'd be amazed how quickly these project eat up cash. I certainly was when I first got involved.

Here are some things to consider:

• They always consider the costs of the internal people's time on these projects, even if they're not dedicated to the project. So if you have a 4 hour requirements meeting with 6 business folks from Payroll, well, that gets figured into the overall budget at 4 * 6 * hourly loaded cost of employees, plus your time.
• Software and database licenses add up quickly for this type of project. You know they're not running on MySQL, right? It's probably Oracle all the way, and that's $$$. Some vendors charge by the seat -- how many users do you think a payroll system for 60,000 employees has? That's right, a lot. Plus hardware costs -- they're not running this on their old hardware.
• A project of this size probably has a project manager, several project administrators, an internal business lead, and an internal technical lead, at a minimum, running the show.
• How much do you think gathering requirements, mapping out existing processes, mapping requirements to functionality, developing specs to cover the gaps, creating the new processes,
  testing the new processes, and getting buy-in and approval on all that from all the stakeholders costs? You know there will always be 3 to 5 revision and feedback cycles for everything. That's an easy 6 to 18 months of work for a team of six to eight people probably.
• They're going to have run it in test mode for several pay periods, while the old system is still running, and check the results. That will result in duplicate work for all the people entering in the data.
• Converting the existing data costs money.
• Training costs for the users -- there are probably several hundred users, at different sites. (Plus there's always "Change Management" costs)

(Ugh, thank God I'm out of that ERP systems business these days!)

Yes, a fair amount of the money is probably wasted. But these projects do cost big bucks. This isn't hacking up a new blogging tool from open source toolkits. I'm not saying it's right, or well managed (it almost certainly isn't), but to say "dude, I could hack up a payroll system in a couple of months, pay me the money!" just shows that while you may know how to sling code, you don't have a clue about delivering solutions to business problems.

Here's the real story

[Anonymous Coward]

There's nothing wrong with the current payroll system other than it's old and runs on old hardware. The guys who wrote it 30+ years ago did a pretty good job.

The problem is, those guys are long retired, and some are dead. The ones who are still living have some hard feelings. They got treated like crap and were told to give up their jobs to youngsters whose sole knowledge of COBOL was a CS professor saying how awful it was. Consequently, there hasn't been much in the way of maintenance or knowledge transfer; the young'uns simply weren't interested.

They brought an old guy in to deal with Y2K issues. They agreed to pay him well, but then got chintzy when it turned out that there really wasn't much that he needed to do. They eventually did pay him, but kicked him to the curb again afterwards.

Since none of the young'uns understand the system, and the old guy refuses to deal with them any more, they have no choice but to replace it entirely. The problem is, nobody really knows what went into the system except for the old guy, who has the irritating habit of wanting to be paid to have his knowledge tapped.

COBOL is not that horrible, except in the minds of the ignorant. If you could do BASIC or FORTRAN, you could do COBOL. The bulk of a COBOL program isn't code at all, but instead is structure and format definitions ("data division"). Don't expect to have recursion or local variables (those are all new-fangled extensions) or object-oriented semantics. Be grateful that the original self-modifying feature of COBOL got removed. Then just break it down. Each procedure is labeled, and unless the programmer was an idiot the variable names have some relationship to what they mean.

The only real PITA for COBOL is learning all the reserved words (there's a few hundred of them) and their semantics. Other than that, it's just drudgery.