One of the major tasks on my plate is communicating with the client. One thing I find particularly difficult is dealing with deadlines because they are mandated by the client and I'm frequently not consulted.
If you are supposed to be responsible for communicating with the client, why are you not consulted on scheduling (and budgeting) so you can communicate this information between the people responsible for them within your organization and their counterparts at the client's side? I think that fixing this issue will be a huge benefit to you, your team, and your project.
The client comes up with a feature they want to add, Feature X. Feature X would look good in the next week's app release that is about 6 business days away. At this point, the feature request needs to go through approval and there are frequently other dependencies that need to be deal with. Eventually, N days later, the feature request trickles down to my team. Even if the original dead line (that was set by a non-developer manager) was achievable it no longer is.
This system for scheduling seems odd, to say the least.
In my experiences, the client signs on for a particular release. They might submit a list of features and changes they want and when they want them, and then negotiate with the team building the software. Or they might give a prioritized list of features to the development team, and the development team provides estimates as to when they can ship various sets of features. There are other variants, as well.
But one thing I've never seen allowed is a customer being able to change the release so late in the game, especially not a week away from a release. That doesn't seem right to put the designers, developers, and testers under that kind of pressure. If you are doing iterative development, if it's a high priority feature, just be sure to add it to the form of backlog and take it as soon as you can. If it's not a high priority feature, they definitely don't need it during this release and can wait until the next.
I would recommend setting some ground rules that accommodate your design, development, testing, and delivery teams as well as your customer as to feature freezes, code freezes, and deliveries. Put these in writing, get commitment from everyone, and stick to it. If you budge once, you'll be expected to bend more, and you'll lose control of the process.
Unfortunately, there's not much I can do because I'm not in a position of power here.
You might not be, alone. But it sounds like your designers and/or developers and/or testers are under a lot of pressure to meet schedules. You should have a sit down with your superiors as a team and explain the situation. First, get your organization to commit to improvement in the process, then work with the client to get their buy-in into how things are going to work.
This feels a lot like I am making excuses though.
When you start to make excuses, it might be time to have a Difficult Conversation or a Crucial Conversation. I would recommend one of those two books. Reading them has helped improve my communication skills, especially when you need to face a difficult situation where tensions are high on all sides.
To address some of the other answers.
Sadly, power is mostly taken by yourself rather than granted to you by others.
I don't know where Andrea is going with this. Yes, you need to fix the information flow. But you need to work with the PMs and client to ensure that everyone knows what was (I'm assuming, anyway) agreed upon at the start of the project. If the arrangement, for any reason, isn't working out, revisit it and redistribute work and roles to people better suited to them.
You don't take power or fight power, but you work with it, trying to tame it and make it work for everyone.
The problem is - customer mostly know business value for the feature, but don't realize its complexity. Just discuss and clarify. Always.
This quote from loki2302 is pretty much spot on. One of your jobs as a software engineer is to make sure that the right people know things like how difficult a task it, how long it's going to take, and what kinds of options and risks exist in doing something. As the lead communicator for your team, conveying this information from your organization to your customer is, in theory, your job.