When To Say NO To A Project

During my Agile talk at RailsConf 2008 I was asked if we turn down jobs. My answer was yes. Some clients can work within a scrum process, others cannot, and yet others you just want to stay away from. A follow-up question to that was how I know if we should turn down a project, what are the indicators that someone might be a bad fit for scrum or the company. My responses included:

The person has not invested any time up front to create any documentation listing what they want their site to do.
The person is asking for an estimate on a laundry list of features that they cannot explain the goals of (i.e they heard the stuff is cool and want a site to do all of it).
They are trying to rush into a project without much forethought (similar to #1 but with added urgency and increased danger of failure).
The client is non-technical and attempting to dictate application architecture.
No budget. While a budget isn’t always a necessity, it usually means that the person on the other end is fishing and doesn’t have funds yet available. This is more of a warning sign than a “turn down this project” sign since people sometimes go for funding once they know how much their project will cost.

Note that I said “might” before, as some of the above can be handled through education. Chris pointed out a list of Software’s Classic Mistakes, some of which apply to turning down projects as well. The main ones that jump out at me are: