Slashdot Mirror
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."
The University should just scrap the system and go with a commercial payroll vendor. Bigger organizations have done the same, and there's no shame in it.
That's exactly what they're doing. They are trying to switch to PeopleSoft.
As I understand it, they've totally scrapped the old system and are starting over from scratch using PeopleSoft - which they should have done from the beginning rather than trying to roll their own solution.
So yeah the title is misleading; it's a $12 million system. And that includes deployment across 24 campuses statewide, training costs, etc.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
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.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
Without really understanding the details of their payroll system and the task involved, I don't necessarily agree with your assessment. Most university IT groups don't have stellar project managers, which is the one thing that a project of this scale (and criticality) needs. Further, it's likely that nobody has have the expertise in either the outgoing payroll system or the one that's going to replace it (either in a shrinkwrap or roll-your-own configuration). I'm not sure whether or not hiring a high-paid, highly experienced and qualified project manager as an FTE is warranted. Further, what does an IT department do with a really good PM with tons of experience and a huge list of successful projects when this project ends in 18-24 months? The smart money is to eliminate the position, which is what a smart manager will see when they interview the university. Instead, they would likely work on a contract basis and (as you say) slice off 50% for themselves.
Rolling their own payroll system is also a possible disaster for them. It's very likely that they're having a hard time communicating requirements to professional payroll implementation/transition consultants who do this sort of thing all the time with a shrinkwrap ERP (like Oracle, SAP, etc). What makes you think that the university will be able to better communicate requirements to developers?
I guess that this is all armchair quarterbacking from both of us, since I have no idea of the circumstances beyond the details that the article provides (which are light, at best). It appears that this was mishandled on multiple levels though - likely both the fault of the university management and the consultants. Usually for projects to fail on this level, it has to go both ways - consultants mismanage a project, the university mismanages the consultants, and probably isn't able to clearly communicate requirements.
-Turkey
With agile methods and a multi-disciplinary team ("good coders" is an unfortunate catchall phrase I used to mean people who can gather requirements, write user stories, validate, iterate, manage a burndown list, etc.), five years would be absolutely more than enough time to do all of the steps you mention and more... like change management and getting iterations into stakeholder hands early... and on and on. I am neither a youngster nor naive about the software development life cycle (both waterfall which is what it sounds like you're used to, and agile).
Even with specs, the hard part of a payroll system is known all of the tax rules and regulations to start with, then toss in the byzantine local rules such as the pay grades and union seniority rules. Then when this is done, be prepared to change it again each year as the rules change.
Payroll systems tend to have a lot of people on staff maintaining them. Which is why a lot of corporations just outsource it all if they can.
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:
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.
(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.
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.
Stanford had a very expensive conversion to PeopleSoft a few years ago. Stanford had a huge collection of in-house systems from the 1970s and 1980s, running on either DEC PDP-10 machines or IBM mainframes. They've finally phased out all the PDP-10 based stuff at Stanford proper, although SLAC is still running some PDP-10 code.
The $12m is just for the planning. They originally though $8 million would be enough but it wasn't. The UW payroll system (really HR system) has to take care of around 60,00 employees at several campuses plus county extension branches. There are all sorts of job descriptions with different contracts, vacation, sick leave, seniority, retirement plans, insurance, etc. The previous failure was an embarassment and some reporter figured they could stir up some trouble by making a big deal out of this. It's better that they get all the processes sorted out before they start writing custom code.
A dyslexic man walks into a bra.
Actually the University of Wisconsin-Madison (the flagship UW school) gets so little money from the state these days that it is within their rights to rename the school if they wanted. If I recall correctly, UW-Madison gets 10% of their budget funded from the state.
First the UW adopted the PeopleSoft financials. This has been in place for awhile (my secretary uses it often). It was an adjustment but is going o.k.
Then it's decided to upgrade the HR system and some PHBs at UW-System decide on Lawson HR instead of going with PeopleSoft. Big integration problems (go figure), and iirc, even prior to the Lawson debacle the UW System CIO council came out against it, but the PHBs didn't listen. Project fails...UW takes lots of heat. Starts over now with PeopleSoft HR, finds out needs to do more planning to not repeat past failure. AP comes out with story about being late and over budget again.... when really they're trying not to f-it up again.
Not on that scale but still a hefty chunk of change nevertheless.
The cost and complexity of moving the entire payroll and finance system over to peoplesoft was so much that it lead to the resignation of the CFO of the university because he spent more without the authorization of the board - never mind that the board and the president pushed for this improvement knowing the budget will go over from $25 mil to $40 mil or so.
http://www.vermontnewsguy.com/tag/daniel-fogel/
Bottom line is that these type of projects are incredibly complex and no one really knows the long term costs when they get into it initially. But due diligence and oversight would be critical and helpful no doubt.
TimeTrex may be a good start... Its the only open source payroll and time management software that I've seen that is even remotely capable. Its extremely powerful and works great for organizations with many thousands of employees across multiple countries/states/unions.
Not only that but its currently used in some of the largest most well known Universities in the world.
Sorry to dis-aillusion you, but take a look at NU standard of living data - we actually have quite good health care up here. There is a lot of scare mongering about "long waigts", and in some of the bigger cities you might have to wait a few hours if you walk into emerg. without a critical condition. But I don't have to reach into my pocket to pay for a visit to a clinic or my physician. And when my mother had to spend a month in the hospital, we did not have to mortgage her house. And - best for last - if you come down with a serious illness up here, you won't ever get told "sorry, you you don't have insurance, go somewhere else to die." Last time i went to a hospital, I was treated within 2 hours - and it was a non-life threatening injury. seeing the guy wheeled in on a stretcher, covered in blood, it was no problem letting him go first (they call that "triage"). Get the facts.
Please don't dominate the rap, Jack, if you got nothin' new to say.
Unions? Most of the complexity comes from the legislature.
And why do so many Americans come to Canada and lie to get basic medical treatment?
.00001% of the population.
Here's the deal:
Most Canadians would rather not get stuck in some American hospital bankrupting themselves for survival. So most of us don't go to the US for care.
The thing about Waiting Lists is that because we have regular contact with our doctors (free contact) we can identify issues early on. It's called Preventative Medicine, rather than addressing problems after they happen, we identify them before they start. It sucks to wait 9 months for a knee replacement, but that knee problem was spotted potentially months earlier for a Canadian as opposed to an American who may have waited until they were forced to go to an expensive doctors visit because their knee doesn't work.
However there are some treatments that are more developed in the US, some of the *rare* cancer treatments. That's because there are 300million Americans, allowing for more specialization in health problems that affect a very small
And here's the kicker: Our Socialized medicine will pay for Canadians to go to the US for these treatments when they aren't offered here.
Some Canadians aren't going to the US for rare treatments though. There are also some who feel that good enough Health Care isn't fast enough. They spend their own dough in the US, saving my health system money and generally showing their stupidity.
And then there are the Boobs. I'm hard pressed to find anything comparable to the Beverly Hills Plastic Surgeon in Canada. Of course Socialized medicine shouldn't be buying Boobs as a general rule of thumb.
-------
What it really comes down to is LIFE EXPECTANCY
You can shout to me until your blue in the face that the United States has a superior Health Care system than Canada. It's certainly more expensive per capita, but 2 years after you're dead I'll still be here laughing.
The rock, the vulture, and the chain