No matter how agile your development practices are, and no matter how skilled your team is, you can still generate a failure.

There are some sure signs you are headed for a failure that you can watch for. One of the most obvious and common is when deadlines are set without regard to input from the development staff.

Artificial "drop dead" dates are always a sure sign of trouble to come. It is especially worrisome because it is so prevalent. I have participated in a number of projects where the milestones, phase durations etc, are set in stone before all of the analysis is even complete.

A common scenario, particularly in "internal" non commercial projects is that the business unit identifies a desired set of functionality and delivers the desire in the form of a loosely defined set of requirements, accompanied by a delivery date that is usually wildly optimistic.

I actually worked for a company where the development manager was fond of saying: "The customer will settle for 80% of the desired functionality."

This is far more common than anyone would like to believe. And the particular company I am speaking of is still developing internal projects with the same mentality 10 years later. (I am no longer there, but people I know still are.)

The result of this "settle for" mentality is that there is a loss of confidence in the development group by the customer, and a sense of hopelessness in the developers that becomes pervasive. Most developers leave, a core group will stay until they burn out, but by and large these teams are marred by high turnover rates, low morale and frequent re-organizations.

Do you work for a settle for group? Any idea on how to combat this from within? Please share your thoughts!

Cheers,

Robert Porter