How much does a university payroll system cost? $30 million, apparently. | Hacker News Reader

How much does a university payroll system cost? $30 million, apparently.

chicagotribune.com

14 pointsyummyfajitas31 comments

"He also said the subcontractor, Accenture, was playing a limited role and was well-qualified for the work."

And I'm well-qualified for doing brain surgery.

Like most enterprise debacles, this is NOT a technology problem. It's a management problem. Or lack thereof.

(Honestly fellow hackers, is there anything easier than payroll? That's what we used to give the new guys.)

You think payroll is a large enterprise is easy? Not a chance. They are dealing with multiple union contracts, salaried employees with various scales and benefits, students, etc. The legacy application is probably full of undocumented special cases that are necessary to get correct results, and have to be tediously reverse engineered.

For another example, see the (in)famous C3 project. http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensa...

That said, I'm sure you're correct that there was some serious management failures on this project.

The legacy application is probably full of undocumented special cases that are necessary to get correct results, and have to be tediously reverse engineered.

I think you hit the nail on the head right there. There is always some oddball case where workers X and Y get paid double time when there is a full moon on the third Tuesday of March in a leap year.

"There is always some oddball case where workers X and Y get paid double time when there is a full moon on the third Tuesday of March in a leap year."

And that's a tough case to program?

I've worked in the field of enterprise software; unfortunately, programming can be the least of your tasks. It is not a programming issue. A project manager has a lot of constituents (university employees) to satisfy. Lots of fiefdoms. It's more like a Zoo Keeper - an enterprise especially one like a university can be a complex ecoystem with its own predators - you can be in all-day meetings, dealing with the virtual ecosystem of vested interests, departments, groups who all want a say in how the software works. Pissing off someone inadvertently could cripple your project.

As anyone who has tried to get the registrar to do X in Y time and has been referred to Z to get P's signature and so on, universities can operate on their time schedules and march to the beat of their own drummer.

And, remember, a fair number of employees at a university who have been working there for 15 years and are used to doing things their old way might be passive-aggressive or hostile to the idea of something making a process more efficient.

"You think payroll is a large enterprise is easy?"

Compared to any other enterprise app, absolutely! The easiest, by far.

"They are dealing with multiple union contracts, salaried employees with various scales and benefits, students, etc"

Oh, you mean you have to do math? It's not like they're launching a rocket. Oh wait, that doesn't cost $30M either. Sorry.

"...have to be tediously reverse engineered..."

Or "tediously" analyzed and defined. Either way, it's what we do. Digital blocking and tackling. Relatively easy; that is, unless you don't know what you're doing and got the gig because your senior partner threatened the trustees by withholding audit approval.

We hackers don't profess to be experts at accounting. Why do accountants insist on being experts at building software?

To be fair, Accenture don't profess to be experts at accounting either: they're generalist consultants.

Interestingly, Accenture (then Anderson, DeLany & Co.) apparently built the first computerized payroll system in the US, back in 1953:

http://en.wikipedia.org/wiki/Accenture#History

"...apparently built the first computerized payroll system in the US, back in 1953..."

...and it will be ready next Tuesday.

Actually, they do profess to be experts at building accounting systems. Accenture was spun out of an accounting firm and as you mention they've been building accounting systems since 1953. Building payroll and other accounting systems is one of the main things they do.

So if they're doing it for 56 years then why don't they already have a modular offering where they can just mix & match the modules as required, akin to SAP?

I know the answer(s) ofcourse, but couldn't resist asking...

Compared to any other enterprise app, absolutely! The easiest, by far.

I don't know if I'd go that far, but of the 30 or so subsystems we sell our customers, I'd put it in the easiest 5 or so.

Here are some factors that make it easy:

1) The underlying domain model is well understood and has been for decades. Employee works for you. You pay them wages and benefits, set aside taxes, and mark that you did so. Periodically you export your records to show people. Changes in the overall procedure practically never happen. Changes at the data level happen all the freaking time but, hey, computers tolerate data changing pretty well.

2) The users of the system are all experts. They should be, using the payroll system is their job. They have a high tolerance for complicated workflows and will never push a button just to see what it does.

3) Performance demands on a payroll system would be rounding error on any other system in the enterprise. Even with 60k employees you have, hmm, a few dozen payroll clerks, if that? Changes take weeks to propagate anyhow, so if a report isn't quite up-to-the-nanosecond you don't have to sweat it.

4) I am not speaking about my employers or my employers' customers: many enterprises do not want fantastic payroll systems. If it has a little black magic involved and some sharp edges, that suits the payroll clerks perfectly fine. After all, that means there will always need to be payroll clerks who know about those little usage niggles.

As soon as I hear the words "software" and "Accenture" alarm bells start going off in my head.

Accenture's model for software development is to get first-year consultants who've had 6 weeks' worth of online training in Java to "architect" the system, then send the implementation to big, cheap teams of pretty talented coders in India. Unfortunately, no matter how talented the coder, building to a specification put together by somebody who doesn't know what they're doing always results in terrible, broken systems.

Having worked at companies where they've implemented systems, and seen first-hand the minimal levels of real IT experience they require from the consultants they get to architect software, any mention of Accenture and IT makes me run screaming away.

Don't forget their business model. Pay the first year consultants $50K but bill them out at $125 per hour.

If it is that easy, why don't you and others just create an open source project for this matter and submit the result to university. I am sure they will glad to have it for free.

I'll do it for $29m.

I think you're missing the point a little.

To give you an idea of the scope of the problem, another school dealing with the same legacy issues:

"The inadequacy of these systems is resulting in operational inefficiencies that impact people at every level of this institution. It is difficult for faculty and staff to perform even the most basic functions, such as hiring, purchasing, tracking and managing multiple budgets, and making accurate budget projections.

The systems lack basic tools and functionality to help staff do their work, such as controls to prevent over-spending, visibility into pending financial transactions, or ability to do financial reporting at the unit or department level. The systems do not collect the level and detail of data required to meet the UW’s growing information needs.

As a result, staff must engage in “daily heroics” just to keep business operations running and get the information they need to do their jobs. They must make extraordinary efforts to perform basic job duties, employing numerous manual workarounds and engaging in other cumbersome and time-consuming processes that take away from higher-level work.

To compensate for missing functionality, departments and units across the University have created hundreds of shadow systems at considerable cost and effort. These shadow systems represent a significant security risk to the University, and maintaining them is costly and inefficient."

http://www.washington.edu/provost/oim/roadmap/report/replace...

There's no justifying the cost for this project. However, UW has 27 institutions and a central office that this software is supposed to cover. Dealing with all of the campuses is an astonishingly difficult task. University systems in general are not simple hierarchical structures, and state university systems even less so. The challenges of working within that kind of environment are very different than the challenges of dealing with most businesses. Not that $12 million for planning is justified (especially not after a failed $28 million project), but this project isn't quite as cut-and-dry as you might expect.

Interesting, they note that the university has 60,000 employees. I'll leave the jaw dropping math to you.

Why make people do math? It's $500 per employee assuming the $30m figure in the headline (which doesn't actually appear in the article). They spent $28m on another system they never used, and are about to spend $12m on the second attempt, making it $40m in total, or $666 per employee.

Either way, holy cow.

I know of a Smalltalk system reputed to have similar capabilities, developed by a Chicago area community college for only $4 million. (I've heard that both systems go beyond just payroll, and are like complete ERP systems for college/university organizations, and can keep track of payments due to them from the government based on resource utilization, which is also integrated with registrar functions.)

This is what the big consulting houses do. They convince the board that it's rocket science, but that they're just the very smart, credible, impressive looking people to do it for you. But they are motivated to inflate the price.

And the $12m is just for the initial planning stage, no actual implementation, so the final cost will be much higher. But you get to amortize it over ~35 years.

Or if your accountants are clever enough, amortize it over 200.

Let's call it $70 per year per employee, since we're going to amortize it a bit.

That is, what, a tenth of a percent of the fully-loaded cost of the cheapest FTE they have? It is wasteful, but it is wasteful in a way that is rounding error next to the cost it will be compared to.

At first I thought it was an outrageous cost for a payroll system, but according to the article, the UW system has 60,000 employees over 27 campuses. For those 60k employees, getting paid is a VERY IMPORTANT deal... there can't be any mistakes in this scale. (A single tiny mistake will propegate it self 60000 times and that won't be fun to fix).

Plus their last system lasted ~35 years (since 1975), so I am guessing their planning a equally long lasting system.

That seems a really charitable guess, given the levels of incompetence that seem to surround every other aspect of this project.

I'm curious where the OP got the $30 million from, it sounds like it's a lot more than that unless some of these numbers overlap (it's tough to tell).

A first attempt to replace it with Lawson Software was scrapped in 2006 after years of work and a cost of $28.4 million.

The system's top budget official, Tom Anderes, told the Board of Regents this month that planning for the project alone is now expected to cost $12 million.

An I.T. solution for this shouldn't cost more than it would for human beings to walk around with a checkbook and a pencil.

So basically 400k of this is actually consumed by employees at the university working on the project (if that), while the other 11.6 million is for paying off good friends of the board that just so happen to have roles in the consulting companies that provide services.

I can't help but think there's a big market for new, low-cost, web-based software in old, boring markets that are ignored, like accounting, payroll and CRM.

I'm not saying payroll is easy, but the guys who are building payroll systems aren't facing a lot of competition, because the field is so dull.

Those systems already exist.

The problem is the people in charge of acquiring the system go with someone like Accenture because it is low risk for them, and people associate spending more money with a better product.

Reply on news.ycombinator.com