UK govt signs IT contracts 'without understanding' the needs The UK government can be prone to signing contracts for major IT projects before it has a good understanding of the requirements, according to a National Audit Office (NAO) director. Speaking at a Whitehall event examining priorities for the Central Digital and Data Office, the Cabinet Office's central technology team formed a …
This has been evident for many years, at all levels of government - I witnessed one particularly egregrious f***-up in local government about 30 years ago. Wont listen or take advice from underlings that know what theyre about, try to insist that shit is pure gold, and then waltz off with a huge pay-off to mess up some other organisation.
You seem to be describing the Seagull Management System.
Fly in through the window, flap around and cause problems.
After a short while, head back through the window leaving a mess, sh1t and other problems behind you.
I am wondering if the events in Ukraine are Vlad the Invader seeking to leave such a legacy.
It matches many of my experiences in Defence, as well.
There are two points that I'd make: first of all that management consultants and IT/IS vendors cultivate the "non-digital leader" (hereinafter PHB) because it is to some extent there that the fulcrum of their marketing leverage rests. It's then hard for the PHB to listen to their own staff contradicting some of those smooth marketing messages, because (a) the contradictions aren't dressed up in marketing jargon, and (b) they don't come with lunch and a really nice Chablis.
Secondly, there is the fact that fuzzy requirements are somewhat to the contractors advantage. Post-contract changes are pretty lucrative, but the relationship of Profit to Requirement Definition is not linear. A few changes will yield some nice income, and a manageable time overrun. Get in on a contract where the customer can't tell A from the track of a duck, though, and then both parties are in the shit.
"If you don't have the skills to implement it, you probably don't have the skills to write the spec either"
I disagree, you can be skilled enough to understand the requirements and write the spec, without being skilled enough to implement it. You need however to be skilled enough then to engage with the specialists and refine that spec, understanding what's possible etc.
I had the misfortune to work with a software project that resulted from an SSADM study carried out on an existing system with a view to upgrading the hardware/software.
The SSADM specialists were not allowed, by the customer, to talk to the people actually using the existing system.
The tender for the new software generated from the study was let with no requirements review by anyone who knew how the tasks were actually carried out or what weird temporary fixes had been applied to the original system to make it work.
Needless to say the new software really wasn't fit for purpose - PHBs were wailing and gnashing their teeth, even though it was their policy that caused the issue in the first place.
It was sorted, eventually, at the cost of time (three years) and effeciency (many things that should have been done were delayed until the new software came on line).
"The UK government can be prone to signing contracts for major IT projects before it has a good understanding of the requirements, according to a National Audit Office (NAO) director."
Can't wait for the next article about water continuing to be wet, although I would argue that it's not just IT projects that get signed off without understanding what it's about. Literally every other aspect of government that requires a signature to unleash funds is done without understanding what is needed. It happens in Health (especially), Education etc.
But do you know what part of the whole system that gets signed off with 100% clarity, foresight and understanding? Aspects relating to wages, expenses, and how to get a peerage.
""We found in large scale programmes that, before things start for real, [there is] insufficient thinking, analysis, architecture and design. Often this is actually skipped over,"
But why expect governments to do IT differently to the way they do everything else?
It might be argued that when governments have to face unexpected events - pandemics, wars or the like they have to make decisions on the fly. But even in those cases the decisions would be easier and more effective if there had been some preparation made to deal with such events.
Many waterfall projects have succeeded; many agile projects have failed.
Oddly, it doesn't seem to be down to the methodology so much as the overall management. And if you don't know what your overall design and requirements are going to be (even if you don't have the fine detail), you are asking for trouble.
The problem is that if a proper set of requirements and specs, from concept through to support, are done then the estimated costs will be too high and the projects won't get started. I suspect that there are some bright people in the civil service whose main job is to get enough of the project started to make it self sustaining without breaking the current administration's 5-year budget.
I've managed a couple of MoD development projects. They had a full set of requirement specs, but at the preliminary design reviews it was apparent that that the MoD had left some areas of their requirements either undefined, vague or disguised. Their assumption was that once we were on the hook (fixed price) then their commercial people were better than our commercial people and they'd get the extra stuff for free and not have to ask for more money from the chancellor. It didn't work out well - for either of us.
I was just two days into an MOD contract and opened the "XXXXXX Specification Document". There were lots of pages marked "this page intentionally left blank" and paragraph sections with TBA in them.
It was reminiscent of the Blackadder scene where they are planning to go around the world. Melchett says: "“Blackadder, here’s a map of the known world (hands over blank parchment)… fill it in as you go along”"
On my project I was given a fairly complete section to code and told not to worry about the rest for now. At every point where an API call was required I made something up and updated the specification document. It was coding by the serendipity method.
“Blackadder, here’s a map of the known world (hands over blank parchment)… fill it in as you go along”
This extends all the way down to small software houses. Having just arrived in one I was given the job of looking after a system they'd put together for one client which they were now trying to sell to a few more. For two of the customers it was something new, for the third they'd been told it would drop in in place of what they already had. I already had problems such as trying to pick it apart and reassemble it in such a way that users in one part of the business didn't have access to every other users' part of the database. I quickly found out I had another: that it was in no way going to be a drop in replacement - the data model was too different.
So I asked management what the spec was for what I was to produce. I was told that whatever I produced would be the spec.
Fortunately, shortly after as I was leaving Embankment station I bumped into someone from my previous employer's customer and more or less offered a job there and then (the ensuing interview was one question "Are you still interested?").
"I suspect that there are some bright people in the civil service" Not so much - one thing the external contractors are good at is spotting people who know what they are talking about and lifting them out of the way one way or another. You'd be surprised the number of people who had a great salary for a couple of years before being in-outsourced.
@Headley_Grange
Quote 1: "...a good understanding of the requirements..."
Quote 2: "...the detail of requirements and complexity start to emerge over time as the programme gets underway..."
Once upon a time, a long time ago (in the 1980's), I worked for a big consulting firm. This firm REFUSED to bid for huge design-to-implementation projects.
The firm won a lot of work by suggesting that the work should be split into two contracts:
(1) A short (i.e. low cost) contract to do the analysis and write the requirements
(2) A second contract to do the design and implementation
In fact, this firm sometimes won contract #1, but even when they did win contract #1, they didn't always win contract #2.
......but at least there was an opportunity to ASSESS the quality of the requirements written at the end of #1!!!
This article seems to imply that thirtysome years later, an obvious lesson has not been learned!!
Why am I not surprised? Huge contracts, billions of pounds (sterling), no opportunity to change course (until 100s of millions have disappeared).....
.....and, of course, plenty of time for politicians and civil servants to retire.....to cushy directorships.....with consultancies!!!!!!!!
I have worked for a defence contractor that has also worked on several projects like this.
Step 1: Bid to prove the company is capable of requirements analysis for a given project title. Money given to perform requirements analysis and provide an initial overview of key concepts of the solution.
Step 2: Customer selects 'x' number of companies to perform analysis and manages questions. For example: if one of the bidders asks a question regarding the requirement analysis, the answer gets shared to all others performing the analysis (all done anonymously, so no-one knows who else is performing the analysis).
Step 3: Bid to prove your analysis and provide an initial overview of concepts. At this stage everyone now has a clearer view of the requirements, and the customer has not only an initial concept to review, but can also understand who understands the issues better, how quickly things move in the company and how everyone has worked to come up with a solution.
It takes more money and time upfront, but at least its more likely issues are ironed out early.
Splitting the requirements phase from the implementation phase is a good approach but the risk is that the client takes the requirements output from the first phase and treats it as a shopping list from which they pick stuff until they hit their budget limits. Unless the requirements phase was run on the basis of it being a shopping list then the client will probably get a half-arsed implementation that ends up costing at least as much as doing it "properly" would have done and whoever did the requirements will be blamed for all the problems.
Way, way back in time the then Inland Revenue delivered CESA, the last major IT project entirely designed, developed and delivered under Civil Service control. It was on time, under budget, and delivered every function point working at go-live. The IT function was then privatised and the issues described became very apparent. All the IT knowledge had been packed off to the private sector and the contracts under which projects were developed were specified such that the companies delivering could bleed the government dry.
Such serial incompetence in government though appears all to easily thought well worthy of a knighthood, with glaring evidence of such an abomination most recently demonstrated in the positing of Gavin Williamson for ...... well, now surely is surely rendered a thoroughly dubious honour.
I wonder if Gavin was threatening to walk and talk about all that he gleaned while in high Office. Spill the dope on shenanigans uncovered ..... "Give us a Knighthood or the dogs on Fleet Street get it!” .... etc etc.
Since Michael Keegan (Husband to Gillian MP and cabinet minister), who was Fujitsu CEO from 2015-2019, also know as the cover up years of the Horizon Post Office Scandal, and in 2018 a Non Executive Director for Centerprise International who based in Basingstoke (as Fujitsu are) who supply Fujitsu the computers they use on their Government projects, has joined the cabinet office (as he did in 2019) as 'Crown Representative.
His main role as Crown Representative is where he oversees the Government’s relationships with suppliers, basically helps award contracts to "industry partners".
Can you guess who has been winning a lot of Government projects since 2019? Despite Horizon being exposed as an awful piece of shite, spoiler, they get their computers from Centerprise International.
So just assume all these projects will go to them.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
