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.)
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.
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.
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.
And that's a tough case to program?
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.
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?
Interestingly, Accenture (then Anderson, DeLany & Co.) apparently built the first computerized payroll system in the US, back in 1953:
...and it will be ready next Tuesday.
I know the answer(s) ofcourse, but couldn't resist asking...
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.