Business trying to make technical decisions

Question

We've often run across scenarios where the business will promise a client a new feature. The business will promise that the feature be implemented in a specific way. These technical details promised by the business are usually poor. Unfortunately, client is now set and want this feature to be implemented in the way described by the business.

In the end, the business just wants this feature to be completed without regard to quality and maintainability. Is there a good way to push back? How can we explain to the business that providing technical details before the requirements have been gathered is a bad idea?

Answer 1

That's an organizational issue. If the higher-ups don't understand this, there's not much you can do. Try to explain the issue to your non-technical bosses, but don't be surprised when you get nowhere.

It's is a common problem for developers working in non-development companies that, for whatever reason, sell software.

It's not a pleasant tactic, but you can just bludgeon them with evidence. At the start of a project, write down exactly why it's going to fail (because technical details were poor) and email it to relevant people. Keep emailing them throughout, and when the project eventually ends up a disaster with pissed off customers, cite those emails you sent at every opportunity. It may generate some ill will, but there's really no good way to try to fix a systemic issue like that.

Answer 2

From the developer's perspective, this is one of two flavors of fail, when it comes to spec-writing. The other thing that can happen is when sales makes big promises, and then turns to IT to specify the project and deliver a write-up that can be turned into a quote.

Problem is, often that's the bulk of the work. Quite likely the actual code is just implementing the details of the approach laid out in a well-designed spec.

At the same time, sales finds it difficult to bill for preliminaries like specs development. We're not quite in bed yet with the client, and it's weird to hit them up for money to figure out how much money to hit them up for.

This is why most "first time" projects with new clients end up being loss leaders. If you're LUCKY, you use that first project to train the client on how to be a client, and you can start earning your butt back on the second project, or the maintenance agreement on the first one.