It's not about in-scope/out-scope

The software project is behind schedule. The deadline is looming and everything finally acknowledges -- too late -- that we have to start making concessions.

So there are two choices, right? Release later, or reduce scope by throwing out features.

Not so fast.

"Remove from Scope" is not the answer
Too often we developers are stuck on this "remove it from scope" mantra. Yes, completely throwing out features is a way to get to the release date, but this isn't necessarily the best thing for the product or the customers.

Ultimately our job as engineers and not just worker-bees is to make trade-offs. Not just in design or algorithms, but in the end user use-case and, yes, even to support marketing and sales with their promises and messages.

Not cutting, but changing
Five years ago I was on a project with an impossible deadline. We had to get a complete custom reporting system integrated into a project for their v3.0 release, and for uninteresting reasons we had just four months to do it. There was a spec that couldn't possibly be completed in time, but the deadline was firm because a customer contract was in place.

The project ended up a complete success. The system was demonstrated to the customer on time and was accepted. It was so popular, it became the "big finale" for product demos.

The reason it was a success is because we never posed the question: "What parts of the spec do you want to throw out?" Instead we would ask: "How can we allow the user to accomplish what the original spec wanted him to accomplish, but in a different, simpler way?"

Sure that means less "stuff" -- fewer absolute number of features and fewer choices. But it doesn't mean tossing items J-M -- it means reevaluating the entire spec from the point of view of the use-cases and marketing requirements.

Happy days
There's another benefit to this approach.

We're all used to the tension between development and sales. Sales wants more, faster. Requirements pushed from the outside are ambiguous, and when you deliver it's never the right thing.

The normal reaction from development is: "You're changing the rules, therefore we simply refuse to give in. Either stop changing the spec or change the deadline. It's a zero-sum game, and we won't be responsible if you make the sum larger."

But that's not helping sales OR the hapless customer. (Customers don't have hap, apparently.)

What helps is arriving at a better solution. The project drivers will be more willing to negotiate if you're going to meet them halfway. They know they've added to your schedule. If you show the genuine desire to get their root problems solved, they'll be more willing to bend on exactly how you're going to solve their problems.

Besides, we can all agree that "Customer Success" is the ultimate goal, and clearly negotiating for their success is better than cutting them off.