Some orgs just don't have the in-house capability to do this, so they seek a consulting firm... oh wait.
Edit:
I guess the strategy is to hire technical staff, keep them around a few years until you can be sure they can deliver on projects and understand your existing systems and processes, and then embark on the larger project to transform those systems and processes.
Alternatively, shop around to find a consulting firm that is motivated to have good long-term outcomes. Probably a smaller operation, that has good word-of-mouth reputation, but doesn't have an established brand to fall back on.
I’m not describing how the world should work, just how it does when outsourcing IT to consultancies (which can work anywhere from successfully to very unsuccessfully)
A good strategy is to hire a team, get a few consultants who have literally built the same system down the road, and use that blended team until 2.X release.
That way you a team that has made a thing already (and often consultants are just as passionate about their work too!) ready to build a better 2.0, plus you keep responsibility and control.
Some orgs may not know how to hire. I think here, competent (and well connected) consultants can help, and maybe source from their own networks, but we're back to the dilemma of which consultants to trust. And let's not speak of recruitment agencies :)
Hint: the rivalry will make it also expensive (extra meetings, defensive bullshit). But you will end up with what you wanted, at a price.
That is oh so very Deloitte...look if we took $100M from you and you didn’t get what you wanted, that’s Clearly not our fault, YOU shouldn’t have been handling that type of budget in the first place. After all there are people like us out there that will hornswoggle you, luckily you can retain us Again to deliver the original contract and you should consider a separate retainer so we can protect you from people like us in the future.
Id love to see a single instance where Deloitte admitted to fault and footed the bill for a $100M contract, care to link proof for such a claim?
Why would they admit fault? The entire point is to take the hit and preserve reputation - you being able to find a link would defeat the entire point.
> Why would they admit fault?
That’s just it they never would.
But reading your comment:
> If the system didn’t work as agreed in the statement of work and that was clear, Deloitte would be footing the bill.
You certainly make it sound Deloitte is a fair company that would admit when a system doesn’t work as agreed and then foot the bill, but that’s not the case.
Whether they admit fault For delivering a failed system or not, do you have an actual example where Deloitte was magnanimous and returned $100M to a client after delivering a system?
I am not the OP, but working for an agency shop (way way smaller than Deloitte) I know we footed some bills. But we don't publicly talk about that. wouldn't be good for business.
it's a double edged sword. I know of projects that were sub par. I have seen systems build by others (Deloitte included) that were nothing but a shit show. and I have seen systems from the same brands that were doing way more than originally expected.
sometimes it is the client, sometimes it is the project management sometimes it is the consultants. and sometimes it is the circumstances. I wouldn't expect a system designed for normal load to hold in times of covid-19 and work flawlessly. some examples like the call center being overwhelmed is to be expected when designed for normal loads.
I strongly believe, that there are real faulty systems to be found. and that for some of these the contractor is to be blamed. but without knowing the specifics I wouldn't feel qualified to judge from the sidelines.
disclaimer: I work for an agency that got bought by a Deloitte competitor some years back. all opinions are my own.
Help me out with that.
I’m really just asking for some support of the original statement that Deloitte will foot a $100M bill for a client when they fail to deliver a working system.
I mean Deloitte isn’t singled out in the article, the article really goes after IBM also. That said I wouldn’t even say the article has an aggressive tone, but it speaks for itself. Deloitte has delivered systems that don’t work on multiple government contracts, all of which have run significantly over budget, and Deloitte has requested new contracts to fix the systems (Instead if footing the bill) and when sued for breach of contract by the states Deloitte has engaged in protracted litigation rather than “footing the bill”. I think it’s fair, not aggressive to ask for some validation of Deloitte footing bills where their systems failed in light of Deloitte's practices detailed in the article.
The article is all about state unemployment systems, I mean really they aren’t complex and they either work or don’t. Even Deloitte‘s argument amounts to be well if the $xxM unemployment system Doesn’t work it’s because the state requested a non functioning system, of course it’s all backed by Deloitte Representative quotes denying the systems don’t work and championing how great the systems they delivered are, and otherwise blaming the client if these great systems failed.
I didn’t say that, they would foot the bill for the changes required to make it work as expected in the contract. It’s unlikely you would deliver 0 value with 100m, so it would be a fraction.
This would lower the overall margin on the project, be considered business development or some other activity. There’s also discounting future work as a lever to resolve it.
They aren’t stupid, biting the government hand that feeds them isn’t a good way to keep winning new work.
Have you read the article? The article details multiple failures to deliver on government contracts nearing $100M. The article details a practice of refusing to amicably resolve matters in good faith, instead Deloitte prefers protracted litigation, which when involving government is just additional costs to the tax payers above and beyond the initial costs tax payers footed for the original contract to Deloitte resulting in a non working system.
There are a few read between the lines also, Deloitte knows their litigation budget is significantly larger than the state governments and they know their attorneys can overwhelm the states ability to litigating just through costs alone. The other point about biting the hand that feeds them...sure if you were small time and failed to deliver and forced the states to litigate a breach of contract case, you may be cutting your nose off despite your face. But entities like Deloitte can do this, and they will continue to get new government contracts while the prior contracts are still being litigated. You got your Deloitte’s, McKenzie’s, Goldman Sach’s, haliburton’s, Boeing’s, etc...they could set the world on fire and then lobby and get the contracts to put out the fires they started. Those firms are the reason for the term “revolving door politics.”
Unemployment systems really aren’t that complex in the grand scheme of things. The problem domain is well defined — the program is almost identical to what it was 50 years ago (or more).
When you look at the examples cited, failure is not exactly a surprise. Florida isn’t exactly a poster child for competent governance.
https://www.smh.com.au/technology/worst-failure-of-public-ad...
I believe Canada had a similar project fail in the same way - probably even the same software.
Yep I agree with you totally.
This is the money quote.
Big 4 companies (Deloitte, PwC, EY, KPMG) are historically accounting auditing companies. And their culture is heavily skewed towards billing their employees to clients per hour/day, or per unit of service, as auditors and lawyers have been doing for more than a century. It is not in their DNA to "create products" but to "render services"; that is, to sell employees availability. Boundaries and scope of those traditional services are typically clearer than building a new unknown program from scratch.
If you are hiring these firms for exploration of how do you work, how you should work, and a complete functioning system that sustains a big number of new processes that are not yet defined, you are in for a big bill; you better be sure that you have put on the time to think about what you are buying in written form. When you see big failed projects like those the problem lies in that no one stopped to research the complexity of the ask before entering into a contract.
Even then, these consultancies normally are very flexible when a contract is actively harming the client, and the client wishes to change it / stop it (it would not be good for the business to do otherwise, because you want to see more after this contract is finished). When these costs go out of control is because internal politics in the client impede the rational decisions of killing projects, changing command, etc., and the sponsor keeps feeding money into the project to save their ass.
Source: worked in big 4 for years.
> “ "Deloitte also faced blowback in 2013 for an unemployment benefits system it built in Massachusetts. There, the benefits system arrived in 2013, two years late and $6 million over budget—only to be filled with glitches that erroneously cut workers’ benefits, according to the Boston Globe."
Deloitte delivered a major project way behind schedule, over budget and full of defects.
If you provide a vague spec or don’t have good governance of a more dynamic/agile project, the consultants aren’t the root cause of failure.
The folks in these companies are masters at separating customers from money, for sure. But, these guys aren’t ripping off clueless dentists either. The typical F100 customer isn’t a babe in the woods. When the parties are Accenture vs. Exxon or IBM vs. the IRS, who is the good guy? :)
And that’s where they get ya!
They’ll win a lowest bid contract for the exact word for word spec.
But then will bill wayyyy more for any change request. Which will be numerous obviously.
That’s how actual project costs get inflated.
Want your oil changing? 100$ no worries - oh you didn't realise you also needed new tyres and we only found out when looking at them? That's extra.
I know people working with big consultancy companies and the recurring thing they complain about is a difference of opinion between client and provider about what exactly the terms of signed agreements mean.
You know, the process that's been shown again and again to be pretty useless in delivering a working software product?
Great way to highlight how incompetent you all are! Honestly can't tell if you're trolling or being serious.
A good agile process will not have an ironclad upfront definition of what is to be delivered in a large project. A process with that may not be waterfall, but it's definitely non-Agile Big Upfront Design.
OTOH, Agile is largely about managing risk and incrementally delivering value without overcommitting forward, so the contracting process with Agile should reflect that and shouldn't commit to a giant project in a lump contract.
"what is to be delivered" does not have to be a rigid definition of "5,000 lines of code program with features 1, 2, and 3". A good agile contract will allow the possibility for changing project requirements but also still define how those changing requirements affect expectations and responsibilities of the consulting company.
The agile process itself can actually be a deliverable that you define in a contract, and it should spell out, for example, how new requirements are prioritized and the criteria you use for determining if it's something that the consulting company is responsible for. In my experience if you can't write out your agile requirements in a contract, then you don't have a good enough internal understanding of your own agile processes and should probably work on that, too.
Far too many people use "we're Agile" as an excuse for "we don't plan or document anything" and extend that to contracts, but that's absolutely not what good Agile actually is.
Design documents also need iteration, because there's always something that was overlook, something that just escaped common sense, and so on.
In other words: Code can have bugs. Design documents also can have bugs, and the latter are almost never fixed.
Why is that? Because fixing a design document involves negotiations and changing budgets.
Accountability only works with fixed price IMO
Fixed price deliverables are usually more expensive due to bidders pricing risk. Or you see big delays due to PCR requirements. Or the project owner don’t have the political power to not accept a deliverable and tell the vendor to go pound it.
Correct, that’s the only way the vendor takes on the risk really. That was my point.
> Or the project owner don’t have the political power to not accept a deliverable and tell the vendor to go pound it.
Yeah I agree... but if you have 100m to hand out and the in org politics where you can’t tell a vendor to go pound it, there are real structural issues in your co preventing you delivering systems.
In several years I never once saw the firm not deliver what they agreed to in writing.
There’s one way to deal with a consulting firm: a rock solid statement of work and people on the client side to verify you got exactly what you paid for.
If the system didn’t work as agreed in the statement of work and that was clear, Deloitte would be footing the bill.
If you gave out a time and materials contract without clear acceptance criteria, testing requirements, and verification / support / warranty detailed, you probably shouldn’t be handling 100 million dollar budgets.