🎓 Continuous Delivery Fundamentals: FREE COURSE - Introducing the concepts, explaining the benefits and key practices, and suggesting first steps to start with Continuous Delivery. STUDY FOR FREE NOW ➡ courses.cd.training/courses/cd-fundamentals
Let's name names - the lead contractor for the failed FireControl project was Siemens. Why governments continually use large, faceless conglomerates for these contracts is baffling. You'd have thought that they'd have learned from the £10 billion failed NPfIT project and the catastrophic Fujitsu Horizon project, but they make the same mistakes again and again. The alternative would be to assemble small teams of elite developers to drive a highly focused, user-centric adaptive process. But this is never done.
Procurement. There are rules about Procurement that are designed to prevent fraudulently awarded contracts. Only very large providers can access the Procurement process. As there's no genuine market, there's no accountability for failure.
@@mrpocock I suspect you're right - but there must be ways around this. For example, the Department could do the work in-house, contracting their own direct staff. With Horizon, we now know that Fujitsu only employed a couple of competent developers. Then there were around half a dozen very average developers, and half a dozen who were outright inept. There were no proper coding standards, code reviews, documentation or systematic testing. Whistle-blowers were ignored or intimidated. They covered up the shambles, to the point that they perjured themselves in court and sent innocent people to prison. There simply has to be a better way - after so many failures, more of the same isn't a sane option.
@@tullochgorum6323 The horizon situation is horrific, at every level. I am increasingly of the opinion that there should be a proper framework for financial and legal liability so that this kind of situation results in bankruptcies and jail terms. Too often, it seems like subcontracting through multiple layers circumvents liability.
Brit project manager here. Disclaimer: I've never worked in a Continuous Delivery style, but I have managed to get Agile teams to succeed (more or less 🙂). I think the root of the problem is that the sponsors of a project want (above everything) a known cost and timescale for the project. The reality is that, for anything of non-trivial scale, that isn't realistic, certainly at the start. Software development is about exploring problems and trying (and testing) solutions, and Management don't want to hear about that.
@@tullochgorum6323 100% this. UK government procurements have to assign contracts to companies on a relevant "framework". Due to opaque reasons - ahem - only large faceless incompetant consultancies are on the "framework". I've just seen a £5M contract with one of the Big 4 go into the circular file - their expertise was in financial audit, not software development. The quality of their delivery was horrifying. But they were the best option of 5 similar large consultancies on the "framework".
Let me guess: a long list of requirements, no interest in an MVP product until everything is ready, once it works it doesn’t do what it was intended or it’s worse than using a spreadsheet so users don’t want to adapt.
a MVP project often requires to be much more complete in government , public it systems. So the MVP thinking is very hard to adapt. You can torture the concept a bit to make it so. A workable enduring prototypes approach would probably match better. And the complexity is more outside the systems and software development.
The usual reason that projects are big and bloated from the start is that they attempt to replace a core monolith or consolidate numerous running systems, where side-by-side operations with the new system aren‘t possible. With unfathomable complexity, this tends to necessitate traditional project planning approaches. The sign that it‘s all doomed to failure from the start is that the first release involves a big bang switchover of all systems and business processes. Even banks try this from time to time and the outcome is the same, though less visible to the public.
When I worked on government projects, we needed information from several different departments and they were not allowed to share the data with the other departments. Thus, after three years of development, the business analysts still gathered new requirements. I have no idea how the company bid on this government contract when the requirements were never known.
Seems you team lacked the expertise to work on public projects, because there are huge demands for protecting citizens rights, adhering to laws etc. And it is possible to gather information that is enough to go ahead. Probably what you needed was a very large faked data set and a complete closed of system for development and testing and occasional involvement of the systems. You need to test on the legacy or existing systems. And consider the cross cut of many other data systems. In these projects the difficulty on the systems developments is huge, but the company consideration of data safety, protection and laws and rights and protocols are much more involved. These are steps that can be skipped sometimes by many private companies, sometimes it's fine sometimes it's done even though it's not fine. The issue is knowledge and awareness. You need much more multi skilled teams. What i saw as an issue , is that at the BIDDING process level and maybe that's what you talking about, you need more access or more information?
It’s common practice to just ask what the budget is and spread that out over the government planned delivery timeframe. That way the contractor has set the expectation that it will all be spent. They put up a waterfall style process (with more in-vogue) names but it’s essential that requirements gathering will be an upfront thing and any/all late findings will require change requests (i.e. the client will need to pay more). That’s how you can endlessly go back to step 1 and never actually build any working software. For government, it can be excruciating to collect requirements as you’re being asked to replace a conglomerate of dozens of systems and no-one will sign off on the processes (that might make them accountable)
@Satook they have literally specific persons to sign of on that and a chain of command. If anything i seen in government, that is one of the things that are very well functioning. At least in good government. The lack of accountability i do see comes from the attempt on implementing private business ideas like LEAN and lack of resources. Another thing is that people often assume lack of accountability because they unconciously interpret, the multilayered acceptance chain where no one person can give complete sign off. As lack of accountability. Bit that is completely wrong. That is actually security and safety measures . But you have to account for the time to let it go through the chains. A public or government with entity has much much higher obligations to have that in place and almost never fail. Here we actual have an issue with smaller entities like small town or county offices as they often lack resources. If people or an org has obligations they need resources and backup resources to ensure that.
Mis-aligned incentives. If I could complete a 5 year $100M contact in 2 years and $50M, I now have made $50M less revenue than expected and my staff no longer has 3 years of work. In theory you could turn that success and reputation into more contracts, but imagine a large corporation having that kind of long term vision. Additionally, all the people who pulled it off would be split up and assigned to various other projects, likely with the expectation that they will "fix" them without any of the support and/or conditions to enable that. - A Cynical Government Contractor
Also the intended "customers", most of which of gov't employers, do not have skin in the game to see this project succeed. Helping these enviously well paid contractors do their thing is only adding to their work burden. And do the contractors actually listen, or are they incentivized to hit some arbitrary milestone, if they can do so by dropping the feedback on the floor to close work tickets more quickly? Furthermore, when a very capable software company steps into a private company, they can sometimes get acceptance of changes in to streamline the process and thus change the requirements. Government institutions cannot so easily do so. Who owns the requirements is often a mix of laws and regulations, some local and some not.
@@kaostheory1050 Fully agree. Mis-aligned incentives all around. Companies. Contractors. Taxpayers. Stakeholders. Consultants. Managers. Lawyers. All through these projects are people whose incentives range from absurdly high levels of risk aversion to conflicts of interest, empire building and outright graft.
Failure of big private company projects is somewhere north of 50%. We do not really know how much higher because private companies are not in the habit of proclaiming how much shareholder money they threw down the drain. They will declare victory even if only 10-20% of intended functionality is put into production, and the scapegoat encouraged to leave for another employer.
About a decade ago I worked for a big UK government software project as a contractor. The project was ostensibly being developed using a novel AGILE approach which was practically unheard of within the civil service at the time. In reality it was still a waterfall hell with detailed design plans being plotted on A0 papers all around the office, layers upon layers of non-technical management, pieces of specific work scheduled for several months to come, and a plethora of non-technical analysts, with any new terminology being redefined and overloaded to mean the basically same as status quo (as in Larman's second law of organisational behaviour). Everything you have said in the video is true. However, you omitted (or grossly underestimated) how incredibly clueless the senior public sector officials are when it comes to software, and I am NOT saying this lightly. Even in this supposedly most modern government project I worked on; the approach to software development process, comprehension of technical matters, and familiarity with common practices was abysmally low and decades behind the industry. Needless to say; the consultancies, contracting companies, and the engineers these officials hired were also visibly poor to a large extent. The programme management attempted to solve it with a crazy high turnover rate, with new people appearing and disappearing all around the office every week. One other factor worth mentioning is the requirements for different levels of security clearances in government projects. These significantly limit the candidate pool who are both able to meet the eligibility criteria and willing to have their personal lives, histories and finances snooped in detail by the government agencies.
If you don't fully understand a problem you will never get the proper outcome. Government doesn't know what it wants (other than to create headlines) and the supposed beneficiary is never asked what they need. Having managers who are technically incompetent (but who can talk the talk to those above them who are only interested in the bottom line and avoiding responsibility) doesn't help. Having 10 "engineers" who don't know what they are doing instead of having two that do. What could possibly go wrong.
you are exactly correct, for a Government body, its not the amount of money that is throw into a project that defines how successful the officer(s) is, but instead, measured by the value of the project it gives to the public and at lowest prices possible.
One of the biggest issues my organisation (the one I worked for) faced when putting together a large-scale Government solution was the constant stream of changes passed to the developers by the Government department. In a number of cases the change requested should have triggered a substantial re-write of a large chunks of code, but in order to meet deadlines was usually handled by creating a small module to handle the change, with all the associated problems of hooking it in to the core code.
There was job offer for a senior dev working a government contract here (in the UK), going around twitter as a meme. £50k a year, around covid money supply when 100k dev jobs were _everywhere._ Between the lack of competitive wage and excess of headache it must be hard to put together a high quality team with enough experience to push through the bs. Maybe if a little less of the money was misappropriated and went to paying wages rather than bonuses and bureaucracy.
"You can follow the process perfectly but still deliver nothing of value". Unfortunately many business stakeholders don't know what it is that engineers do... And so attempt to proxy it with process, then it's ITs fault when it inevitably fails. But it was just a broken process.
in larger orgs, I've also found it common to use IT projects as proxy battlegrounds for existing political fights. I did find it disturbing that the main capability for NHS CIOs is to navigate the politics, rather than understand anything to do with IT change/delivery/operations
I worked for a big government contractor delivering a crucial security sensitive service to the public of my country. Nominally we were trying to go from scrum to dev-ops but de facto we released at most 3 times a year with one project running two years until release. Testing was manual and slow, deployment went through a separate group using ancient technology and a lot of phonecalls. Communication between teams was often absent, management was distrusted, you name it. In my view one of the bigger underlying problems was the distrust and lack of communication between us, the customer and the end users (a separate entity from the end users, I weep). Our people tried to deliver as little work for money as possible and they tried every trick to get us to deliver stuff that was never discussed. There was consistent contract negotiations and no customer collaboration to speak of. This slowed everything down to a crawl.
A friend worked on a large energy government project as a contractor. He was told to slow down to keep his job going longer. Senior management commissioned large pieces of report writing and document generation to keep the billable hours flowing. Heaps of ceremony and tangential work. Project delivered but way too much wasted effort. Government got a working project and was happy. So much better than this one.
@rosshoyt2030 on the electricity distribution side. So fuel type agnostic. Being in Australia there was no nuclear. That's a dirty word over here at the moment.
There is a great book called _Lean From The Trenches_ by Henrik Kniberg about a successful government IT project in Sweden that created a new computer system for the police. They used Kanban and XP techniques to continuously improve their software and involved users from the beginning. The team was 60 people. Perhaps you might like to interview Henrik about it?
Yes, you are spot on. I was the lead in a series of government desktop automation projects from late '81 through '89. The first of ultimately four was a demo that was used to secure funding for the second. Just two of us were assigned to these projects- we were both mainframe Cobol developers that were a bit bored. We were ignored by management, a huge plus. We attended zero meetings, prepared nary a status report. The first project started by assembling a SWTPC multitasking microcomputer kit, installing the OS and learning Basic. Really. These first two projects had insanely short deliveries, four months each, so all we could do was build prototype after prototype for our wonderful SME until we ran out of time. It turns out this was a really good approach. We were given management and additional staff to "help" that required detailed specifications and too many meetings for projects 3 and 4. We were given 3 months to deliver the 4th- developers are always late so why be reasonable? We delivered it 18 painful months later.
I've seen successful government projects where: - There is a strong team of core technologists within the department, doing assurance and technical governance - A specialist supplier is brought in under a body shopping arrangement to do the software, under the direction of the internal team
When I just read the thumbnail I thought "Because they don't understand why Agile works, right?" I was amazed how your explanation basically boils down to this. But your case study is about the year 2004 (I think that was the year the project started?) - have government IT projects in UK changed in this respect since then?
Government IT projects "always" fail, as high as they often do because it is often high stakes projects, breaking news grounds both across the IT sphere but also the social sphere. Has safety and security implications, and citizens rights issues. And many more things. And then they have transparency that makes it a white box experience compared to companies. Today we have a new challenge as many places it is outsourced to private companies, including companies with lack of resources to take on that, lack of experience and lack of understanding and willingness to understand. When we compare inside projects with outsourced projects we get a real baseline and can see that often private sourced systems developments "fails" even harder. A huge example is hospital software. Where the usability and time wasting is a really bad problem.
I built a system for government once, and 2 years in they sent me home because I was too competent. No, that is not hyperbole, they literally told me I was too competent. The system was delivered on time and with high quality. Can't make the employees look bad like that when you're there as a HPC, apparently.
The private sector / public sector divide is not so clear, as most public sector software projects are outsourced to private companies. I would say the difference is more about how the developers are getting paid. If your model for getting paid, is that you are creating a product that will provide you a profit, you will make that product as good as possible. If your getting paid a fixed fee for meeting some criteria, you are going to optamise for criteria, which are probably poorly thought out. Also you can wash your hands of the project once the fee is paid.
A big one is probably government IT projects are one of the last places you can get paid for designing many of the products that are now being sold commercially.
The reward structure around these projects is what dooms them from the start. Starting with politicians who are rewarded for looking decisive and strong by kicking off mammoth projects, weak and ineffective by taking a smaller, incremental approach. As long as politicians are rewarded for looking busy these problems will persist, and some software contractors will continue to make billions in profits for not doing anything useful.
Cost Plus contracts are a huge part of the problem. The increasing lack of internal expertise means that contracts are too often managed by other contractors. I got paid back in the day to deliver 60 minutes every hour. There was a penalty, not a reward for being efficient. Small, firm fixed price contracts.
To get the budget for a project, the scope has to be 'fixed'. Otherwise how can senior managers approve the spend? On trust? Second, a contract needs to be written to ensure the supplier keeps aligned and to have payment milestones. Those two things will never go away. In private sector they are 'majority' of projects. In government, its all. @CD, the summary at the end is utopia. And you know the root meaning of that
I had the luck to work on a successful project. But the government organizations are heavy on process. And the project could have been realized cheaper and cheaper on maintenance (a lot of license fees for software you dont use to its fullest extent, like buying a f1 car for driving in a city). If you make a tender the company that wins that tender doesnt really have an incentive to do ci/cd and tdd. It could lose a future tender and thus help its' future rivals... Often when you have a contractor the organisation and the contractor have duplicate project structures to manage the project from each side... Then you have the contractual side of the relationship which makes things harder... The feedback loops are bad as well. You can never know if what you do helps users and the organization makes it hard to have direct feedback...
Ah yes, and then fight against "Why start small? We _know_ what we want!" A lack of honest understanding of the problem domain well, is as much an issue as not understanding how IT transforms that domain. Now I'm not sure how it goes in the UK, but here in the Netherlands we have the "Make it so" syndrome; Government decides to build a system (or just decides something without realizing that it requires a new or changed system), and the next day will continue with a new decision as if the previous one is already done. The result is an ongoing stream of changes, without the fundamental understanding of that stream's existence. So everyone keeps being surprised nothing ever finishes.
On number 3 "Department's management and oversight of the project was weak" has a more charitable view than shoving status reports to ever wider set of senior stakeholders - though there may be some of that as well. This 'failure' may point to potential re-direction that empowered individuals could have offerred, had they known the direction/state of the project. Sometimes these are the obfuscations inherent in large software consultancies that report only to their favourite sponsor.
I love your channel and most of the things it talks about, but I really wish you had a slightly better mic as you always sound a little bit muffled, which makes it harder to listen to in the background. I genuinely think you could increase the number of viewers you get with better audio
Contracts shouldn't be this large and long, the contract model and length matters, the people who create the RFPs and requirements are usually people who have never actually built software
Answer this: How can you NOT do Waterfall when Compliance is so important in places like Government! In Government (and others), we require more compliance! Therefore, Waterfall! You can't have compliance checkpoints if you don't plan the whole thing carefully, and if you're just constantly delivering. COMPLIANCE!!! This is what I hear when I discuss the benefits of Continuous Delivery / Deployment. I have answers, I wonder what yours is.
Short summary: Governments can't do software. Longer one, governments internal incentives are fundamentally incompatible with what it actually takes to do software. And probably incompatible with many other things as well.
Having been in the military for one contract, then later employed by startups and mid-sized businesses as a software dev, I think the underlying issue is that governments aren't businesses. They always have an incoming stream of revenue (taxes). Everything a government does, does not have the same incentives as businesseses. Everything is really inefficient and many (most?) times it's by design.
Dave what a very interesting business model you proposed! Take 1/2 the estimated value of the project and go on Holiday... the end result is the same and you've saved the taxpayers money. Brilliant! The company's name will be Swindle Software, that way we can't be sued for false advertising. LOL what a world we live in! Waterfall... Really!?!? Anyway... Cheers!
It is hard to imagine a more stupid or more dangerous way of making decisions than by putting those decisions in the hands of people who pay no price for being wrong.
What are you talking about. The government workers o met has always had high standards and rigid rules for how to act. So it's kind of the opposite in public contracts, including the transparency that is required. The public sector workers are not politicians or any thing. This sounds more like a hyper libertarian view point where most public sector workers are branded as bad and having "wrong " incentives. In my experience that's opposite of reality. Or you meant something else?
Government jobs are kind of funny. The money they pay goes back into the economy, in one way or another. So, that means the taxes to pay for those employees is seen in the goods and services in the areas where these employees work.
All this is too high level or wishy washy. ALL project failures happen because there is not cohesion. Once you get more than on person working on a problem, if you do not have cooperation the effectiveness and efficiency plummet. WHY there is no cohesion is different in different projects. I can almost guarantee most of the time (in govt) it is due to lack of experience at critical positions or at with the team OR because typically people in govt positions are not invested in the outcomes because nobody ever can be fired.
Oh come on, we know exactly what happened with that UK project: the building landlords made bank. Jobs for the boys! (Doesn't detract from what you said; I think that lots of govt. projects are overseen (at a political level) by people who actually care about value, leaving the public servants in limbo).
In Czech republic, the government gave on the order of 20 million dollars to make an online highway permit system. They locked down the public offering to offer it to one company, they said it was for security concerns, as the database of vehicles was supposed to contain identification of vehicles of secret services(unsolvable problem, apparently). This is probably worth about 200K a year or something. For us, this is a lot of money, considering that for me this is a weekend project.
Actually, the answer is far simpler than most of the answers here: you have to answer to Congress for every cent spent, usually with stacks of paperwork, endless bureaucracy, and oversight by non-technical people, using a top-down organizational structure with virtually zero faith in modern solution methodologies, or when they do, they only embrace those elements that really don't work properly. XP doesn't work without Agile, but there is absolutely zero use of actual Agile processes, and XP is overblown to begin with.
if you make everything require a high security clearance, they blocked out a bunch of homosexuals and occasional pot smokers. and in return, you get a rotating cast of people whose primary reason for being there is not about great software. everything that is not mandatory is optional. you get people who are more worried about appearance than function. it's just part of the culture.
Recently finished a government project, on schedule. It was quite easy to implement, with good architecture principles, but not TDD. TDD wouldn't have made sense for a REACT Quiz web game.
Thanks for the analysis! I have a quick question: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
Agile is at least partly to blame for large project failures. Systems today are bigger and more complex than they have ever been, yet companies insist on pairing them with a very lightweight methodology.
You mean Corporate Agile I assume? Most, especially large, companies don't do agile, they do many small micro managed waterfalls where agile technical practices are shunned and thay label is "Agile Scrum" but it's neither Agile nor Scrum.
🎓 Continuous Delivery Fundamentals: FREE COURSE - Introducing the concepts, explaining the benefits and key practices, and suggesting first steps to start with Continuous Delivery. STUDY FOR FREE NOW ➡ courses.cd.training/courses/cd-fundamentals
Let's name names - the lead contractor for the failed FireControl project was Siemens. Why governments continually use large, faceless conglomerates for these contracts is baffling. You'd have thought that they'd have learned from the £10 billion failed NPfIT project and the catastrophic Fujitsu Horizon project, but they make the same mistakes again and again. The alternative would be to assemble small teams of elite developers to drive a highly focused, user-centric adaptive process. But this is never done.
Procurement. There are rules about Procurement that are designed to prevent fraudulently awarded contracts. Only very large providers can access the Procurement process. As there's no genuine market, there's no accountability for failure.
@@mrpocock I suspect you're right - but there must be ways around this. For example, the Department could do the work in-house, contracting their own direct staff.
With Horizon, we now know that Fujitsu only employed a couple of competent developers. Then there were around half a dozen very average developers, and half a dozen who were outright inept. There were no proper coding standards, code reviews, documentation or systematic testing. Whistle-blowers were ignored or intimidated. They covered up the shambles, to the point that they perjured themselves in court and sent innocent people to prison.
There simply has to be a better way - after so many failures, more of the same isn't a sane option.
@@tullochgorum6323 The horizon situation is horrific, at every level. I am increasingly of the opinion that there should be a proper framework for financial and legal liability so that this kind of situation results in bankruptcies and jail terms. Too often, it seems like subcontracting through multiple layers circumvents liability.
Brit project manager here. Disclaimer: I've never worked in a Continuous Delivery style, but I have managed to get Agile teams to succeed (more or less 🙂). I think the root of the problem is that the sponsors of a project want (above everything) a known cost and timescale for the project. The reality is that, for anything of non-trivial scale, that isn't realistic, certainly at the start. Software development is about exploring problems and trying (and testing) solutions, and Management don't want to hear about that.
@@tullochgorum6323 100% this. UK government procurements have to assign contracts to companies on a relevant "framework". Due to opaque reasons - ahem - only large faceless incompetant consultancies are on the "framework". I've just seen a £5M contract with one of the Big 4 go into the circular file - their expertise was in financial audit, not software development. The quality of their delivery was horrifying. But they were the best option of 5 similar large consultancies on the "framework".
Let me guess: a long list of requirements, no interest in an MVP product until everything is ready, once it works it doesn’t do what it was intended or it’s worse than using a spreadsheet so users don’t want to adapt.
a MVP project often requires to be much more complete in government , public it systems.
So the MVP thinking is very hard to adapt.
You can torture the concept a bit to make it so.
A workable enduring prototypes approach would probably match better.
And the complexity is more outside the systems and software development.
The usual reason that projects are big and bloated from the start is that they attempt to replace a core monolith or consolidate numerous running systems, where side-by-side operations with the new system aren‘t possible. With unfathomable complexity, this tends to necessitate traditional project planning approaches. The sign that it‘s all doomed to failure from the start is that the first release involves a big bang switchover of all systems and business processes. Even banks try this from time to time and the outcome is the same, though less visible to the public.
The consequence of this are long-drawn out meetings and crunch times for employees.
When I worked on government projects, we needed information from several different departments and they were not allowed to share the data with the other departments. Thus, after three years of development, the business analysts still gathered new requirements. I have no idea how the company bid on this government contract when the requirements were never known.
Seems you team lacked the expertise to work on public projects, because there are huge demands for protecting citizens rights, adhering to laws etc.
And it is possible to gather information that is enough to go ahead.
Probably what you needed was a very large faked data set and a complete closed of system for development and testing and occasional involvement of the systems.
You need to test on the legacy or existing systems.
And consider the cross cut of many other data systems.
In these projects the difficulty on the systems developments is huge, but the company consideration of data safety, protection and laws and rights and protocols are much more involved.
These are steps that can be skipped sometimes by many private companies, sometimes it's fine sometimes it's done even though it's not fine.
The issue is knowledge and awareness.
You need much more multi skilled teams.
What i saw as an issue , is that at the BIDDING process level and maybe that's what you talking about, you need more access or more information?
It’s common practice to just ask what the budget is and spread that out over the government planned delivery timeframe. That way the contractor has set the expectation that it will all be spent.
They put up a waterfall style process (with more in-vogue) names but it’s essential that requirements gathering will be an upfront thing and any/all late findings will require change requests (i.e. the client will need to pay more). That’s how you can endlessly go back to step 1 and never actually build any working software.
For government, it can be excruciating to collect requirements as you’re being asked to replace a conglomerate of dozens of systems and no-one will sign off on the processes (that might make them accountable)
@Satook they have literally specific persons to sign of on that and a chain of command.
If anything i seen in government, that is one of the things that are very well functioning.
At least in good government.
The lack of accountability i do see comes from the attempt on implementing private business ideas like LEAN and lack of resources.
Another thing is that people often assume lack of accountability because they unconciously interpret, the multilayered acceptance chain where no one person can give complete sign off. As lack of accountability.
Bit that is completely wrong.
That is actually security and safety measures .
But you have to account for the time to let it go through the chains.
A public or government with entity has much much higher obligations to have that in place and almost never fail.
Here we actual have an issue with smaller entities like small town or county offices as they often lack resources.
If people or an org has obligations they need resources and backup resources to ensure that.
Mis-aligned incentives. If I could complete a 5 year $100M contact in 2 years and $50M, I now have made $50M less revenue than expected and my staff no longer has 3 years of work. In theory you could turn that success and reputation into more contracts, but imagine a large corporation having that kind of long term vision. Additionally, all the people who pulled it off would be split up and assigned to various other projects, likely with the expectation that they will "fix" them without any of the support and/or conditions to enable that.
- A Cynical Government Contractor
Also the intended "customers", most of which of gov't employers, do not have skin in the game to see this project succeed. Helping these enviously well paid contractors do their thing is only adding to their work burden. And do the contractors actually listen, or are they incentivized to hit some arbitrary milestone, if they can do so by dropping the feedback on the floor to close work tickets more quickly?
Furthermore, when a very capable software company steps into a private company, they can sometimes get acceptance of changes in to streamline the process and thus change the requirements. Government institutions cannot so easily do so. Who owns the requirements is often a mix of laws and regulations, some local and some not.
@@kaostheory1050 Fully agree. Mis-aligned incentives all around.
Companies. Contractors. Taxpayers. Stakeholders. Consultants. Managers. Lawyers. All through these projects are people whose incentives range from absurdly high levels of risk aversion to conflicts of interest, empire building and outright graft.
Many of these things happen in private companies as well.
Failure of big private company projects is somewhere north of 50%. We do not really know how much higher because private companies are not in the habit of proclaiming how much shareholder money they threw down the drain. They will declare victory even if only 10-20% of intended functionality is put into production, and the scapegoat encouraged to leave for another employer.
About a decade ago I worked for a big UK government software project as a contractor. The project was ostensibly being developed using a novel AGILE approach which was practically unheard of within the civil service at the time. In reality it was still a waterfall hell with detailed design plans being plotted on A0 papers all around the office, layers upon layers of non-technical management, pieces of specific work scheduled for several months to come, and a plethora of non-technical analysts, with any new terminology being redefined and overloaded to mean the basically same as status quo (as in Larman's second law of organisational behaviour).
Everything you have said in the video is true. However, you omitted (or grossly underestimated) how incredibly clueless the senior public sector officials are when it comes to software, and I am NOT saying this lightly. Even in this supposedly most modern government project I worked on; the approach to software development process, comprehension of technical matters, and familiarity with common practices was abysmally low and decades behind the industry. Needless to say; the consultancies, contracting companies, and the engineers these officials hired were also visibly poor to a large extent. The programme management attempted to solve it with a crazy high turnover rate, with new people appearing and disappearing all around the office every week.
One other factor worth mentioning is the requirements for different levels of security clearances in government projects. These significantly limit the candidate pool who are both able to meet the eligibility criteria and willing to have their personal lives, histories and finances snooped in detail by the government agencies.
If you don't fully understand a problem you will never get the proper outcome. Government doesn't know what it wants (other than to create headlines) and the supposed beneficiary is never asked what they need.
Having managers who are technically incompetent (but who can talk the talk to those above them who are only interested in the bottom line and avoiding responsibility) doesn't help.
Having 10 "engineers" who don't know what they are doing instead of having two that do.
What could possibly go wrong.
Don't forget the tory party handing out contracts to their mates knowing full well they couldn't be delivered
you are exactly correct, for a Government body, its not the amount of money that is throw into a project that defines how successful the officer(s) is, but instead, measured by the value of the project it gives to the public and at lowest prices possible.
why dont they find someone who wants to code rather than someone who wants to be corrupt, because the first thing they mention is the budget...
One of the biggest issues my organisation (the one I worked for) faced when putting together a large-scale Government solution was the constant stream of changes passed to the developers by the Government department. In a number of cases the change requested should have triggered a substantial re-write of a large chunks of code, but in order to meet deadlines was usually handled by creating a small module to handle the change, with all the associated problems of hooking it in to the core code.
There was job offer for a senior dev working a government contract here (in the UK), going around twitter as a meme. £50k a year, around covid money supply when 100k dev jobs were _everywhere._
Between the lack of competitive wage and excess of headache it must be hard to put together a high quality team with enough experience to push through the bs.
Maybe if a little less of the money was misappropriated and went to paying wages rather than bonuses and bureaucracy.
"You can follow the process perfectly but still deliver nothing of value". Unfortunately many business stakeholders don't know what it is that engineers do... And so attempt to proxy it with process, then it's ITs fault when it inevitably fails. But it was just a broken process.
in larger orgs, I've also found it common to use IT projects as proxy battlegrounds for existing political fights. I did find it disturbing that the main capability for NHS CIOs is to navigate the politics, rather than understand anything to do with IT change/delivery/operations
I worked for a big government contractor delivering a crucial security sensitive service to the public of my country. Nominally we were trying to go from scrum to dev-ops but de facto we released at most 3 times a year with one project running two years until release. Testing was manual and slow, deployment went through a separate group using ancient technology and a lot of phonecalls. Communication between teams was often absent, management was distrusted, you name it. In my view one of the bigger underlying problems was the distrust and lack of communication between us, the customer and the end users (a separate entity from the end users, I weep). Our people tried to deliver as little work for money as possible and they tried every trick to get us to deliver stuff that was never discussed. There was consistent contract negotiations and no customer collaboration to speak of. This slowed everything down to a crawl.
A friend worked on a large energy government project as a contractor. He was told to slow down to keep his job going longer. Senior management commissioned large pieces of report writing and document generation to keep the billable hours flowing. Heaps of ceremony and tangential work. Project delivered but way too much wasted effort. Government got a working project and was happy. So much better than this one.
What type of energy, May I ask? Renewable, Nuclear or Fossil?
@rosshoyt2030 on the electricity distribution side. So fuel type agnostic. Being in Australia there was no nuclear. That's a dirty word over here at the moment.
Everything makes sense when you understand that states were created following the Stationary Bandit Theory
There is a great book called _Lean From The Trenches_ by Henrik Kniberg about a successful government IT project in Sweden that created a new computer system for the police. They used Kanban and XP techniques to continuously improve their software and involved users from the beginning. The team was 60 people. Perhaps you might like to interview Henrik about it?
Yes, you are spot on. I was the lead in a series of government desktop automation projects from late '81 through '89. The first of ultimately four was a demo that was used to secure funding for the second. Just two of us were assigned to these projects- we were both mainframe Cobol developers that were a bit bored. We were ignored by management, a huge plus. We attended zero meetings, prepared nary a status report. The first project started by assembling a SWTPC multitasking microcomputer kit, installing the OS and learning Basic. Really. These first two projects had insanely short deliveries, four months each, so all we could do was build prototype after prototype for our wonderful SME until we ran out of time. It turns out this was a really good approach. We were given management and additional staff to "help" that required detailed specifications and too many meetings for projects 3 and 4. We were given 3 months to deliver the 4th- developers are always late so why be reasonable? We delivered it 18 painful months later.
I've seen successful government projects where:
- There is a strong team of core technologists within the department, doing assurance and technical governance
- A specialist supplier is brought in under a body shopping arrangement to do the software, under the direction of the internal team
When I just read the thumbnail I thought "Because they don't understand why Agile works, right?" I was amazed how your explanation basically boils down to this. But your case study is about the year 2004 (I think that was the year the project started?) - have government IT projects in UK changed in this respect since then?
Government IT projects "always" fail, as high as they often do because it is often high stakes projects, breaking news grounds both across the IT sphere but also the social sphere.
Has safety and security implications, and citizens rights issues.
And many more things.
And then they have transparency that makes it a white box experience compared to companies.
Today we have a new challenge as many places it is outsourced to private companies, including companies with lack of resources to take on that, lack of experience and lack of understanding and willingness to understand.
When we compare inside projects with outsourced projects we get a real baseline and can see that often private sourced systems developments "fails" even harder.
A huge example is hospital software.
Where the usability and time wasting is a really bad problem.
I built a system for government once, and 2 years in they sent me home because I was too competent. No, that is not hyperbole, they literally told me I was too competent. The system was delivered on time and with high quality. Can't make the employees look bad like that when you're there as a HPC, apparently.
The private sector / public sector divide is not so clear, as most public sector software projects are outsourced to private companies. I would say the difference is more about how the developers are getting paid. If your model for getting paid, is that you are creating a product that will provide you a profit, you will make that product as good as possible. If your getting paid a fixed fee for meeting some criteria, you are going to optamise for criteria, which are probably poorly thought out. Also you can wash your hands of the project once the fee is paid.
A big one is probably government IT projects are one of the last places you can get paid for designing many of the products that are now being sold commercially.
?
The reward structure around these projects is what dooms them from the start. Starting with politicians who are rewarded for looking decisive and strong by kicking off mammoth projects, weak and ineffective by taking a smaller, incremental approach.
As long as politicians are rewarded for looking busy these problems will persist, and some software contractors will continue to make billions in profits for not doing anything useful.
Cost Plus contracts are a huge part of the problem. The increasing lack of internal expertise means that contracts are too often managed by other contractors.
I got paid back in the day to deliver 60 minutes every hour. There was a penalty, not a reward for being efficient.
Small, firm fixed price contracts.
To get the budget for a project, the scope has to be 'fixed'. Otherwise how can senior managers approve the spend? On trust?
Second, a contract needs to be written to ensure the supplier keeps aligned and to have payment milestones.
Those two things will never go away. In private sector they are 'majority' of projects. In government, its all.
@CD, the summary at the end is utopia. And you know the root meaning of that
I had the luck to work on a successful project. But the government organizations are heavy on process. And the project could have been realized cheaper and cheaper on maintenance (a lot of license fees for software you dont use to its fullest extent, like buying a f1 car for driving in a city). If you make a tender the company that wins that tender doesnt really have an incentive to do ci/cd and tdd. It could lose a future tender and thus help its' future rivals... Often when you have a contractor the organisation and the contractor have duplicate project structures to manage the project from each side... Then you have the contractual side of the relationship which makes things harder... The feedback loops are bad as well. You can never know if what you do helps users and the organization makes it hard to have direct feedback...
We had a assigned super user an expert.
So that is just bad setup that is non specific to it being government approach.
Ah yes, and then fight against "Why start small? We _know_ what we want!" A lack of honest understanding of the problem domain well, is as much an issue as not understanding how IT transforms that domain. Now I'm not sure how it goes in the UK, but here in the Netherlands we have the "Make it so" syndrome; Government decides to build a system (or just decides something without realizing that it requires a new or changed system), and the next day will continue with a new decision as if the previous one is already done. The result is an ongoing stream of changes, without the fundamental understanding of that stream's existence. So everyone keeps being surprised nothing ever finishes.
On number 3 "Department's management and oversight of the project was weak" has a more charitable view than shoving status reports to ever wider set of senior stakeholders - though there may be some of that as well.
This 'failure' may point to potential re-direction that empowered individuals could have offerred, had they known the direction/state of the project. Sometimes these are the obfuscations inherent in large software consultancies that report only to their favourite sponsor.
0:33 read fhe project over completely, and ask any questions before starting.
Should there be a government IT/Software agency that creates software for all government needs?
@@BAmalakas Sounds like GDS. They have a reduced scope in recent years and never could do more than set standards. Useful though they were.
I love your channel and most of the things it talks about, but I really wish you had a slightly better mic as you always sound a little bit muffled, which makes it harder to listen to in the background. I genuinely think you could increase the number of viewers you get with better audio
The problem is not enough Agile Coaches.
Contracts shouldn't be this large and long, the contract model and length matters, the people who create the RFPs and requirements are usually people who have never actually built software
Because the managers were largely ignorant of software development, making them especially attractive targets for grifters.
Answer this: How can you NOT do Waterfall when Compliance is so important in places like Government! In Government (and others), we require more compliance! Therefore, Waterfall! You can't have compliance checkpoints if you don't plan the whole thing carefully, and if you're just constantly delivering. COMPLIANCE!!! This is what I hear when I discuss the benefits of Continuous Delivery / Deployment. I have answers, I wonder what yours is.
I would love to get a government sponsored project, but it's hard to take, so this is the reason of the failure.
State projects are given through relations
I haven't finished the video yet but my money is on the root cause being not delivering continuously
Why is there a sector in which government projects don't overwhelmingly fail?
What sector do you mean??
Star Citizen? No wait! Wrong channel 😁
I don't understand what the software was supposed to do. Does any one know?
Short summary: Governments can't do software.
Longer one, governments internal incentives are fundamentally incompatible with what it actually takes to do software. And probably incompatible with many other things as well.
It's funny how management resist to learn. It's all there, for centuries.
It comes down to the culture is government in general and penny-wise pound-foolish management as a result of that.
Having been in the military for one contract, then later employed by startups and mid-sized businesses as a software dev, I think the underlying issue is that governments aren't businesses. They always have an incoming stream of revenue (taxes). Everything a government does, does not have the same incentives as businesseses. Everything is really inefficient and many (most?) times it's by design.
Dave what a very interesting business model you proposed! Take 1/2 the estimated value of the project and go on Holiday... the end result is the same and you've saved the taxpayers money. Brilliant! The company's name will be Swindle Software, that way we can't be sued for false advertising. LOL what a world we live in! Waterfall... Really!?!? Anyway... Cheers!
It is hard to imagine a more stupid or more dangerous way of making decisions than by putting those decisions in the hands of people who pay no price for being wrong.
Exactly.
What are you talking about.
The government workers o met has always had high standards and rigid rules for how to act.
So it's kind of the opposite in public contracts, including the transparency that is required.
The public sector workers are not politicians or any thing.
This sounds more like a hyper libertarian view point where most public sector workers are branded as bad and having "wrong " incentives.
In my experience that's opposite of reality.
Or you meant something else?
Government jobs are kind of funny. The money they pay goes back into the economy, in one way or another. So, that means the taxes to pay for those employees is seen in the goods and services in the areas where these employees work.
All this is too high level or wishy washy. ALL project failures happen because there is not cohesion. Once you get more than on person working on a problem, if you do not have cooperation the effectiveness and efficiency plummet. WHY there is no cohesion is different in different projects. I can almost guarantee most of the time (in govt) it is due to lack of experience at critical positions or at with the team OR because typically people in govt positions are not invested in the outcomes because nobody ever can be fired.
Oh come on, we know exactly what happened with that UK project: the building landlords made bank. Jobs for the boys! (Doesn't detract from what you said; I think that lots of govt. projects are overseen (at a political level) by people who actually care about value, leaving the public servants in limbo).
In Czech republic, the government gave on the order of 20 million dollars to make an online highway permit system. They locked down the public offering to offer it to one company, they said it was for security concerns, as the database of vehicles was supposed to contain identification of vehicles of secret services(unsolvable problem, apparently). This is probably worth about 200K a year or something. For us, this is a lot of money, considering that for me this is a weekend project.
Acting like most private software isn't dogshit.
@@plaidchuck he literally said that it isn’t limited to government projects
Private companies have to deliver value or go bankrupt though. Government projects have truck loads of money thrown at them.
Governments ... not just in their software projects ... but overall .... are the very embodiment of the Waterfall process ...
In Poland gov mobile apps are successful.
Actually, the answer is far simpler than most of the answers here: you have to answer to Congress for every cent spent, usually with stacks of paperwork, endless bureaucracy, and oversight by non-technical people, using a top-down organizational structure with virtually zero faith in modern solution methodologies, or when they do, they only embrace those elements that really don't work properly. XP doesn't work without Agile, but there is absolutely zero use of actual Agile processes, and XP is overblown to begin with.
👏👏👏
if you make everything require a high security clearance, they blocked out a bunch of homosexuals and occasional pot smokers. and in return, you get a rotating cast of people whose primary reason for being there is not about great software. everything that is not mandatory is optional. you get people who are more worried about appearance than function. it's just part of the culture.
If you'd like to discuss government IT related issues further then feel free to contact me. I'm a former CTO for the republic of Estonia.
This is how modern day money laundering is done.
Recently finished a government project, on schedule. It was quite easy to implement, with good architecture principles, but not TDD. TDD wouldn't have made sense for a REACT Quiz web game.
Thanks for the analysis! I have a quick question: My OKX wallet holds some USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
Let me guess - they didnt use CoNtInUoUs DeVeLoPmEnT.
Systemantics revisited 😂
Agile is at least partly to blame for large project failures. Systems today are bigger and more complex than they have ever been, yet companies insist on pairing them with a very lightweight methodology.
You mean Corporate Agile I assume? Most, especially large, companies don't do agile, they do many small micro managed waterfalls where agile technical practices are shunned and thay label is "Agile Scrum" but it's neither Agile nor Scrum.
@@Timelog88 But they do standups! And sprints! *And* retros!