There are a few types of challenges I’ve seen, Organizational and Technical - I’ve divided them into two main categories, with a lot of sub-categories.
Organizational
People are just used to doing things a certain way and they resist changes, even if they are for the better
You might not have all the right people, you could be short-staffed, or the product the customer is asking for might be too demanding for your current team, maybe the features are too complex or the scale of the project is too big to handle, for the number of people you have available.
Budget - the project may be too ambitious for the amount of funds allocated to it, so the decision-makers decide to make sacrifices, like not having developers do unit tests, not focusing on a scalable architecture, reducing the time reserved for testing to a minimum, etc.
Technical
The team is good with one technology stack, and maybe the customer is asking for a different one they’re not as comfortable with
The client is asking, let’s say for performance testing, but you don’t have anyone available who’s done that - in that situation, maybe check if anyone is eager to learn about it, provide them with the support they need, and try to convice the client to accept the risk.
There is too much technical debt, and the team believes it’s too late to make improvements successfully.
In short if you want to make change, you need to be able to answer whats in it for me? questions from lots of people. Otherwise you won’t get buy in, no matter how good / correct the change is.