If the change happens at all. The IT department might say "we don't have the time to do that," or "other users depend on the app being like this so we can't change it to be like that," or even "why do you need that, your justification isn't good enough."
Excel is the non-programmer or non-admin equivalent of "I'll just bang that out in [php | python | perl | powershell]." We've all done it, we will all continue to do it, and yes it will look like an absolute mess...that probably winds up powering a Fortune 50 company.
I get that most of us live in a land of "Of course I have an IDE and compilers / REPL" at work.
You know what IDE and compiler IT can't take away? And the last option that's always available at any company?
Excel.
(For those cursed to work in Windows enterprise land, most of what is being talked about here is that Powershell is essentially .Net, e.g. '$DateTime = New-Object System.DateTime -ArgumentList 2015, 10, 10')
https://mcpmag.com/articles/2015/11/04/net-members-in-powers...
Many are spoiled by having their own devenv nowadays.
Ironically cloud computing is going back to those days, where the cloud IDE and shell only allows for IT validated tools.
As a service owner of some fairly significant technology services, every time one of my colleagues “fixes” some business problem with an enterprise IT system, it’s measurably worse than a well-defined excel driven process.
My favorite was when our travel and expense system moved to some Oracle monstrosity, and we literally hired full time staff to data enter expenses that were submitted on paper because field service folks were spending 5-10 hours a week on expense submission.
Another great example is when almost anything is “improved” by some sort of quick and dirty interim servicenow task.
But then IT of bigger companies treats Access as not a real DB and often disregards it with the same contempt as Excel.
My beef is that tech folk have a tendency to make themselves the customer, or maximize convenience to IT over whatever the actual problem is. Internally, the politics of the company tend to dictate this stuff. In the marketplace, software is usually much better!
Tech folks: That's a business use case
Business users: This is something I do 500x a day, this I do 10x a day, this I do once a month
PMs are supposed to be the ones to do this work, but they tend to be technically clueless and blinded by project timeline spreadsheets.
BAs usually don't take the time to actually ask the user "Why are you doing this?" and get all the nuances.
IT says no to or unnecessarily complicates acquiring a needed product? Fine. In Excel it goes.
It never matters how un-auditable the mess is. That never enters the calculus.
A week would be brilliant. Months or years is more realistic. And every change has to go through five levels of management and business analysts before it goes to some clueless people at an outsourcing company and costs insane money.
There is no other tool of which I am aware that enables the common person to sit down at a computer and make the computer do useful real world work work for them in a flexible way than Excel. I have used it for budgets, lists, form entry, and reports. In addition, it provides a very smooth on ramp into programming via the record macro button, which will write the VBA function that does what you are doing in the GUI. Most of my VBA functions started out as record macro, and then were edited to generalize. Truly an amazing piece of software.