Team behind delayed ERP project was aware of problems but didn't inform Surrey County Council for months Problems with Surrey County Council's £30m projects to replace an ageing SAP R/3 system with a Unit4 SaaS application were known in June, but not discussed with key council committees until after September. In April and June last year, new requirements from the HR department continued to arrive after the main software build …
I've worked with organizations that don't understand requirements management. The best way I found to deal with it was to agree a change management process with the client PM. The flowchart for the process includes boxes for "Supplier estimates cost and schedule changes" and "Client issues contract amendment for cost and schedule changes". It's can be quite entertaining when this is briefed to the client team.
I've worked on both sides, as a contractor and as a (US) government PM.
Scope just creeps people out. Clients want software that can do everything and contractors say that their software can do anything. Requirement lists (and explanations) are difficult for the client PM to pull out of the client users (pulling teeth would be much easier for the client PM, and more satisfying, especially if anesthetic can be dispensed with). On the contractor side, admitting that something can't be done never seems to be an option.
Once the project is underway, creep begins - always, and in all cases, and on both sides. It starts with clarifications. The worst are the implicit requirements that nobody wrote down and the ambiguous requirements that the two sides interpreted differently. E.G. "We said we wanted a date. The software has a YYMMDD date and you never said you needed YYYYMMDD."
Then you get legitimate and illegitimate change requests. The worst being when a user talks directly to a contractor and both "forget" to tell their respective PMs. Some legitimate requests can be put in the fabled Phase 2, but others have to be acted upon in the initial release (e.g. the law changed).
And we still haven't gotten to testing.
And so it goes. Generally downhill.
Someone disagree with some of the points here.
Getting a list of requirements out of the client should not be hard, it all comes down to the person asking for the requirements.
As a contractor myself, if I get a particularly weak set of requirements, I will identify the team for whom I'm supposed to be building out a solution for and I will go to them, I will speak to them.
They are the ones that will be using the system, not their PM, not their bean counters etc etc.
In the initial meetings, if there is nobody present that is actively using the system that they're asking me to upgrade, design...whatever...I will see red flags and GTFO. Because that is a project that is about to have a low budget and a long running time coupled with a probably civil lawsuit at the end of it. Fuck that.
If you have access to the staff and you can keep proof of the project managers incompetence in your back pocket, it might be worth the risk, but otherwise...leave it. Don't even quote for it.
There is also a very high possibility that this is IT/Manglement driven with this result that what IT believes the users want is what goes into the brief.
IT including IT project managers are utterly useless at actually finding out what the end user (or as the a know as "the customer") need to do.
This is repeated with monotonous regularity because the people who are the problem never believe that they are the root cause.
Everything is the fault of the users.
I do have some sympathy for the Programme manager. But then again, Change and Exception management are processes that should always be thoroughly understood and agreed from the lowest level PMs up to the leader of the Programme board on both client and supplier level.
It's almost inevitable that requirement and feature changes will come in, and it is almost a certainty that a "big-bang" go-live will not provide 100% coverage in terms of the entire business requirement, first time, within the originally planned timeline. So whilst I have no idea of what that baseline scope at the project outset was, a normal approach would be to have a "Release 1 " go-live candidate feature set, and then a "Release 2" candidate set that adds these changes in a controlled and planned manner. But then again, that comes with its own unique set of problems, and also adds time, cost and complexity.
If this host of changes required were for functionality that would not allow the HR business team to function at a core level - it does beg the question as to how and why they were missed from the original business requirements and process mapping sessions, who reviewed them, and who signed them off.
> Not sure I do. First rule of (honest) program management is go yellow early on the presumption it will be red next week/month.
And there's no suggestion that this didn't happen. I quote from the article:
> Richards said it was reported to the project board that there was a build risk on HR,
That the project board didn't report on to councillors is a different issue and not one that Richards is responsible for.
"It's almost inevitable that requirement and feature changes will come in, and it is almost a certainty that a "big-bang" go-live will not provide 100% coverage in terms of the entire business requirement"
No shit. Requirements tend to change if an unexpected issue arises. For example you discover that the new platform won't handle a super dumb 1,000 character titles that the old system does (because someone 10 years ago was hired to extend the existing platform in some way but everyone had forgotten).
There are some things that you just can't know in advance and will probably never know until you start working.
Also, a 100% big bang go live is always a bad idea, you run the new system in tandem with the old system for a short period of time with reduced functionality to ensure everything is fly tested by the users.
If you switch off the old stuff entirely and "Leroy Jenkins" the new setup, you're asking for a world of pain.
Waterfall. [Plan.....................................................................] [Dev/Deploy...]
Promise of Agile [Sprint, sprint] [Done]
Actual Agile [Fiddle, faff, sprint, fiddle, faff............... <1 week out from delivery, UAT test>] [things we didn't plan for, as we didnt ask the right people, no structure, well its "agile" guv] [Delay...................... $$$]
Yes, usually. These stories are about the truly terrible clients who no-one can complete a project for.
When people think certain contractors are just there to pick up the cash that's going while the project falls apart, they're not wrong - but those exist because the clients ensure failure, so the only thing to do (if you're not going to run a mile) is to make sure you get paid along the way.
We had a perfectly functional HR system at my place. OK, it was a bit 'Web 1.0', and wasn't single sign on, but it worked. It was replaced by a new HR system, which sucked. We fell out with the supplier, and I understand there was some litigation. We then panic bought yet another HR system, which also sucks,
Now, I'm no HR expert, but do HR requirements change so often, to make coding an HR system so difficult?
I'm going to get a lot of flak for this, but checking unit4's website, it looks like it's a bakery's cloud ERP suite. Why on Earth would you move from (technically beautiful) SAP r/3 to this? Only to go around a lack of qualified workforce, I can imagine, although you'll pay through your nose longterm on a cloud solution.
So anyone can answer why? I'm curious, because I do SAP HR since 20 years and so far (Workday, Peoplesoft) I wasn't convinced by the competition.
I worked for an outfit (now defunct / absorbed / assimilated) where we all had a Peoplesoft login. We could book holiday requests, it would send an email to the manager for approval etc etc.
......
Me: "How many days holiday do I have left?"
Boss: "Oh we each keep an excel spreadsheet / Word doc / notepad file"
And, obviously, there was no connection to any project planning software.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
