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 …

[Headley_Grange]

Scope Creep

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.

[Peter 26]

Re: Scope Creep

This was my view reading this. New client requirements is a legitimate reason to delay and increase costs. Why on earth would you suggest you could do it all within the same timeline and cost?

[neilo]

Re: Scope Creep

My thoughts exactly. If there are new requirements, you add the time for those requirements onto the project timeline. Any extra time in the project timeline is there for existing functional testing issues to be reported and resolved.

[Anonymous Coward]

Creepy Scope

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.

[Anonymous Coward]

Re: Creepy Scope

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.

[hoola]

Re: Scope Creep

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.

[Aristotles slow and dimwitted horse]

I do have sympathy...

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.

[Gordon 10]

Re: I do have sympathy...

Not sure I do. First rule of (honest) program management is go yellow early on the presumption it will be red next week/month.

Mind you sounds like the initial problem was poor buy-in/ownership from HR given the change requests.

[Anonymous Coward]

Re: I do have sympathy...

> 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.

[Anonymous Coward]

Re: I do have sympathy...

"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.

[Neil Barnes]

Cheop's Law

On time, on spec, on budget. Pick any two...

[Doctor Syntax]

Re: Cheop's Law

This is something those who consider themselves Masters of the Universe can never grok.

[lglethal]

Re: Cheop's Law

I've always preferred the longer version:

We operate on the three Values Principle - Good, Fast, Cheap.

Choose Any Two.

If it's Good and Fast, it wont be Cheap.

If it's Good and Cheap, it wont be Fast.

If it's Cheap and Fast, it wont be Good.

[katrinab]

Re: Cheop's Law

If it is a government IT project, it won't be any of those...

[GruntyMcPugh]

Re: Cheop's Law

If it's a UK, govt sponsored IT project, it'll be delayed by several years, never achieve it's spec, go massivley over budget, and then be swept under the carpet, until a new govt mkes the same promises, and same mistakes, and repeats the whole cycle again.

[Anonymous Coward]

Sounds to me like the board is making excuses and pretending they didn't know anything so they can throw IT under the bus to save their own jobs...

[Anonymous Coward]

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...................... $$$]

[ShadowSystems]

Just a question...

Has an ERP implimentation ever gone right the first time, been delivered on time, & on budget?

[Dave314159ggggdffsdds]

Re: Just a question...

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.

[Potemkine!]

Taking requirements from the customer is probably the hardest part of the project, even if it's the most important. It requires a lot of skills, not only technical ones, and people able to do this are the most valuable in the project team.

[hoola]

And sadly the most difficult to find and employ......

Then when you do find one, they are usually at odds with the view from high up in the food chain because they understand what the customer actually wants.

[Ian Johnston]

In April and June last year, new requirements from the HR department continued to arrive after the main software build was complete.

It would be HR. Is there anything which HR departments can't screw up?

[GruntyMcPugh]

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?

[arthoss]

moving from SAP to a second rate company?

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.

[Amused Bystander]

What does HR do?

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.