The intersection of domain expertise, contracting/procurement creativity, and technical evaluation is the tough part to wrangle. Getting to the point where development can start is 95% of the battle in my experience.
Not to trivialize the actual development portion of the project, but most missteps happen early, dooming projects before anyone sits down to code.
"Because we don't have the expertise to do software development."
The comments in this thread, which I fully agree with by the way, just cement my belief that if government wants to deliver high-quality IT projects they need to start developing the expertise to do it in-house.
I've also been a consultant cog in a mega-corp and run my own small consulting business, so I've seen it from both sides.
Tech folks underestimate non tech challenges (basically anything outside of their domain), and clients don't actually know what they want. It's an age old problem in lots of industries.
“We need a new system, but it has to function exactly like the old one.”
Including any bugs and craziness.
Perhaps worst of all, when failure has no true cost, avoiding failure matters far less. The CDC won't go broke because they blew through $44 Mil. Most every other organisation would. That's one of the challenges of government, the lack of creative destruction.
They should be diligent in what capabilities they choose to support. And ruthless in continually developing and pivoting these capabilities.
This is true of any large organization or enterprise that operates in a software enabled domain, so yes, most industries. The idea that software development is too difficult and should only be contracted out to fleety consultants is one that needs to be properly put to rest.
And to be clear, I'm not saying that consultants have no place. But for the type of technology and delivery as required by the project in the OP - there's no excuse.
Camunda is not as well known in North America, it will be interesting to see what emerges in the digital transformation/rpa space.
If the hardest / longest part of any project requires domain knowledge and personal relationships, then why are you outsourcing that part?
I don't care if it's not a core competency / something you can do. Make it one.
A high-quality consulting partner works to build the relationships and internal lines of communication that are necessary for the client organization to do more of the work — maybe all of it! — in the future. A cash-grab consultancy will just make themselves the organization's "glue" and bill until the money runs dry.
I think that's the reason you tend to see these unhealthy dynamics in extremely conservative, quasi-monopoly industries (government, financial, healthcare), where there's no real question of if they'll be a going concern. And no real rewards / attempts to outperform at the cost of increased risk.
Only an outsider can safely talk to everyone. They aren't a threat because they aren't part of the company and therefore can't take over.
Also, the end result and the path to get there isn't clear for FTEs – let's say they did the functional domain requirement gathering work – then who will implement it – they will have to contract out the development work – they may not be empowered to think and see through to the end goal fully.
On the other hand, for the top management folks – it is easier to temporarily empower the external consultants and terminate the engagement with them at any time – but they cannot do the same with FTEs due to employment laws etc.
Except I usually just stared at bad movies in hotel rooms to decompress after dealing with clients, rather than blow and strippers. Sue me, I'm boring.
After 8 hours in a windowless conference room with a parade of stakeholders, making RACI matrices on a stained whiteboard and scarfing down cafeteria sandwiches during "bio-break," I want to _talk to my wife on the phone then stare blankly at the ceiling_, not go out for a night on the town.
... did get really good at reading between the lines of Yelp / maps reviews. (Objectively, friends have since commented on it)
Upvote just for this line of poetry. Mondo 2000, haven’t heard that name in decades.
I am definitely biased by my past experiences with tech consultants. I’m trying to sort out if it’s a service provider issue or if it’s a customer side issue.
From my limited perspective, it seems management consultants are focused on 80/20 solution approaches. While it seems technical consultants are focused on delivering MVPs that don’t seem to map well to the business space.
I have no idea if that's the way larger firms do it (would expect not).
Consequently, profit = contract price - consultant hours. Every bad happened from minimizing the latter.
Even if you do straight up billable hours with the client, your time was typically scheduled 1-2 projects in advance. This lead to being prematurely (in terms of things being "done") rolled off a project, onto a new one, and finishing / supporting the first from your hotel after-hours.
This was in a pretty cowboy area. I imagine different parts of technical consulting behave differently.
But yes, MVP quality code seems to be a constant. I saw that delivered from a top-tier technical consulting firm (ML solution) to a T100 customer.
Nearly every time all the knowledge and skills necessary are hidden and fragmented inside our client's org. With our access through all the management layers and silos we could work to fullfil the contract and also enable change within the client organisation and culture.
But why kill the golden goose? Our higher people' bonuses depend on us being the glue as someone else wrote in another comment. And a lot of my colleagues actually on the client's really do a great job in opening lines of communication. They work their a*es of to help the client.
Sadly helping isn't a monetary long term strategy for upper levels.
In the end
And once a year as the government decides its budget you get to chew your nails as you wait to see if the money is in the next budget.
To what extent is this due to neo-liberal "small government" policies, where from the highest political levels - through lobbying - it is decided that outsourcing is a win-win that leads to financial savings and budgets that are cut, and later on cut some more, etcetera?
I've witnessed the crazy dance of enterprise consultants in large corporations (not government) and it is astounding how much money is wasted in inefficiency.
I was in a small tech shop and we had just won an RFP at a big corporation, with a very practical solution and for a limited domain. Our down-to-earth approach led to so much enthusiasm with corporate employees, that they sent all their consultants to us to investigate interfaces to ever more back-end systems. Scope ballooned, and we - being a small party - were dictated to support all this stuff. It was utter madness to such extend that we decided to more-or-less graciously wringle out of the contract. Just-in-time before we were committed to a monstrous project that was 100% certain to fail. And that was not the only time we experienced this phenomenon in big corp.
It's better to have an in-house dev department in these cases even in the complexity side, if you realize that complexity in the contractor side is just as bad as complexity in the basic org.
I notice that they spend oddly large amounts of money on anything for which we know what the cost roughly should be -- e.g. CDC web sites -- and don't seem to do so very quickly or very well. Should we assume that they're a lot more competent at things we know less about?
Unless an organization recognizes the core importance of software and carves out a specialisation stream and C level ownership of it, they rarely achieve more than brief or isolated competence.
This is the reason why SV is so appealing -- nowhere else do SWEs hold sway over entire companies and industries.
Govt can do excellent software if it becomes a priority, they could pay competitive wages (there are special pay scales for doctors and lawyers), but they choose not to because of risk aversion from politicians, who mistakenly believe they can outsource the risk.
For something like this, paying Eventbrite to do it wouldn't have been a bad place to start. But the fat cat consulting firms never have domain expertise beyond getting Govt contracts.
In my experience, a lot of the time it's not so much that the contractor is trying to make money by prolonging the problem. It's that the customer doesn't know how to be a competent product owner that prioritizes and scopes things properly.
Then, frequently the software being designed ends up replicating broken/inefficient business processes, so it ends up being difficult to make cleans and efficient software. This becomes worse when there's legacy software in the mix where the customer wants the contractor to port over all of the clunky functionality of the old app. Which of course isn't documented in the first place, so you've got to perform software archaeology to figure out what it did.
Some other show stoppers I've seen are when key stakeholders act as gatekeepers and prevent developers from talking to SMEs directly, so you have to build your requirements based on what the person with the 10,000 foot view knows. So of course you get incomplete and sometimes completely wrong requirements. And you might not find out how wrong they are until after you've spent a lot of time building things
Just those dynamics alone can add an enormous amount of cost or outright doom a project. I could probably fill a blog with all of the dysfunctional stuff I've seen in federal IT, but suffice it to say that these factors can easily balloon costs and timelines to a comical degree. This $44 million failure is actually small compared to some other government IT failures like the billion dollar Air Force accounting system.
This always comes down to piss-poor and craven senior management decisions.
This is basically true for any organisation.
There are a few issues with authentication, but there is support. Everything that's related to dealing with the UK government btw is all in ONE website, where everything is explained to you in Plain English - gov.uk
Coming from a country where this doesn't exist, I was blown away by every interaction I've had with the system. It's simply amazing.
Their UX documents and implementation are for my money some of the finest in the industry.
I've actually looked into getting a job there even though I'm from a start-up background
One of them is high-tech DYI solution, the other one is super simple yet not used at all by any other govt service I've interacted with.
This is the single most important and insightful sentence that a lot of HN-ers are going to read today, and they don't even know it.
The contract was given to a team used to do intranet websites in classical JEE format and the letting them lose in such a project, designing as they knew.
No, of course not. But it's undeniable that these threads on HN (and other engineering-dominated forums) always include a healthy dollop of "I'd have done that better, because I'm a good software engineer" disdain. It's often paired with ignorance of how large-scale enterprise and government contracts and procurement work, what roles are necessary for large-scale projects with a significant discovery component, and what the planning process looks like when a team can't afford to launch-and-get-feedback or fail-fast-and-learn their way to a full specification.
I mean, this Deloitte project and the rollout are clearly a shitshow on a million levels. They got a no-bid contract for an eye-popping sum, then more than doubled it before the building even started! But the approaches boldly prescribed in most of the comments here wouldn't have produced a working system at the scale needed, either — only a cheaper broken one. A cheaper failure is still a failure.
This one is more insightful (in the big non-tech enterprise / government spaces). Because the takeaway for most HN developers who flip between projects should be: (1) learn how to recognize one of these projects & (2) stay away / find a new job when you do.
You'll save years of your work.
which works very well if the developers and the customer really know what they want when the project starts.
- is the scope well defined?
- do I understand the value add and agree with it?
- do I feel as if all stakeholders are aligned and adequately involved?
- do I think the team can pull it off ?
- do I think the mood and style fits myself?
- do I think the timelines and budgets are realisitc?
- do I agree with the level of transparency from management?
Etc etc
Ask yourself these questions - and more - and you will discover the answer for yourself.
In the end listen to your guts.
One important nuance: A project can be a major fail overal but a big success for you. Big check, new knowledge, rich connections...
- Does the customer have an IT org capable of fulfilling basic tasks you won't be authorized to do (app / db access, AD / rights modification, firewall adjustment, AV adjustment) in a timely manner?
- Can the customer provision necessary machines in a timely manner? If using VMs, is the virtualization team competent with their chosen platform?
- Does this project directly threaten the job of anyone whose blessing / help is required to successfully deliver the project?
- Is your leadership / your customer champion intelligent and willing enough to say "No" to scope creep when the customer gets excited?
- Do the PMs attached to the project have a basic understanding of how software is built and the systems involved?
- Does their management understand the actual processes being interacted with? (Major red flag! If their management / leaders say things in meetings that demonstrate a basic lack of understanding in what their own people do, run)
At the city of antwerp we flipped over in 2015 from a typical assortment of poorly integrated consultant-built monoliths to a microservices api-first approach. It became a hard requirement that all functionality provided by new systems had to be offered by a documented api, and most of the newly built systems dogfood their own api’s from the ui. In 5 years this caused a fundamental shift, where it gave us the ability to set up a covid contact tracing app for schools in weeks, because it was mostly the piecing together of well documented and battle tested api’s.
The business team schedules an hour meeting with the project manager once a week for two years to figure out the requirements.
I spend a sprint implementing the backend in parallel with a frontend person. We spend another sprint testing and fixing bugs.
Then the project sits in UAT for 6 months while the business suggests contradictory things.
Finally the project is shelved indefinitely due to budget issues.
Edit: fixed typo
I have worked in tiny very early stage startups and old dinosaur companies. What comes across loud and clear is that early stage companies could use a bit more organization and dinosaurs could cut huge portions of what they “do” and then both would be in a similar situation to get things done reasonably well.
The bulk of the waste is an attempt to get people who don’t know what they’re doing into a position of getting things done. Sometimes it works.
On one hand, you limit (beneficial) mutation.
On the other hand, you limit (harmful) mutation.
An organization usually doesn't scale past a certain size without stabilizing its ability to copy itself. For better and worse.
also it is good that corps and governments try to innovate and spend money on it.
Can it be more efficient?
Always(!)
Can it be more focused?
Sure.
But a big innovation takes a lot of factors to be well balanced and that alone is often not guaranteed nor possible given the circumstances. You just might not find the kind of devs it really needs (and not even knowing about it). So you hire the best thats available but it won't work...
Bad luck. At least you tried.
I see it that way. Whether vcs pump millions into 100 startups so that one succeeds or corps pump millions into 100 projects... Who cares? The money is not burned. It hopefully ends in my pocket
People spending their lives pushing a boulder up a hill.
People paying taxes to pay for people pushing boulders up hills.
The problem is wasting human life on wildly inefficient endeavors.
because that's what you will get!
If money is left over, apply to the next available item via (logic).
Unless money is sent twice, for two separate sub-items on the same item, in which case if the first amount is insufficient to cover the entirety of the first sub-item, the excess (if any) from the second amount, after being applied to the second sub-item, must be applied to the remainder of the first sub-item.
There are legal ramifications of doing the first way, without the second. And only the actual in-the-trenches people were able to tell us about the second.
Using outsourced process documentation is @&$&ing useless.
In reality, there's one edge case where things needs to be applied in a different, distinct, and very specific order, otherwise (legal consequences).
That said, if I get requirements like that I always have a strong feeling the case can be generalized. Laws generally aren’t as specific as that.
This is a booking management system for appointments, the initial problem statement is trivial, the difficulties lie in interfacing with other systems, simplifying UI, getting data in and out, providing some customisation but not too much, etc. These are all things you don't know how to do till you start using it.
The process you describe of getting 'domain experts' in a room to decide on a spec without contact with the real users then throwing it over the wall to build is fundamentally broken. You won't get to even 50% done without real users - that's the problem, and it sounds like that's what happened here.
You simply can't build a system like this without frequent contact with real users (old people booking appointments, volunteers entering data in a hurry, pharmacies who need to add extra info for patients), experts on the other hand will often add negative value unless they are trying to use it.
If there was a will within the org commissioning the work to appoint one project lead and then get out of the way apart from demanding weekly builds from week 1 onward this would be tractable. Collect feedback from real users and deliver every week. This is not rocket science and a small team could and should do it if allowed the space to do so.
Sure all the requirement gathering and other costlier project parts can doom the success of the project because you built the wrong thing.
Here however the tech debt and bugs is why the project is abandoned
One of my previous employers had a very good software and it sold such software to various other companies around the world. Such software was highly complex and really the top money could buy in the field. A yearly seat for a single user could cost up to around 5-7 k$.
Yet for years the company made most of its money from "installation projects" and "professional services", that is working with the client to understand its needs and implement customisation to the software to make it work well in the customer environment.
Wash, rinse repeat and it won't take long for things to run very nicely.
Bonus, code can be published, standards made, all that and bot rented by the year.
The high bill rate is for your pain and suffering from having to deal with them.
Granted, that was a pathologically bad customer, but it happens.
The ironic thing is the question you usually get from them is "Do you have access yet?"
It's your system and your company! How do you not know the answer to that question?!
This has not been my experience, which is really to say that the world is big enough that you can find any combination of blame imaginable somewhere. Once you have misaligned incentives no part of the dynamic can be relied on not to cause problems.
This is true, too often, in poorly run and ineffective consulting firms who optimize best practices to mean what is best for them.
It's because they have to shoehorn their solution into a morass of garbage software, that this turned into such a complex task.
The real answer is to dump ALL these huge contractors, and their 'solutions', and make something new and better, with proper engineers directing the process.
Imagine if Deloitte had been contracted to 'invent' the Internet...
This is usually not the solution. You have to understand the requirements/know your actual users. Engineers don’t necessarily do this well. They build with the latest tech but as you see in this example, the primary users are older people who can’t use latest tech
As far as I’ve seen there’s people that build first, and ask questions later, and the reverse. Only the latter are engineers.