From LetterToSoftwareDevelopers:

I am resigning because the customer for the project I am working on has absolutely no idea how a software development project should be managed.  This customer has done and continues to do the following:

	* Continually changes the requirements for the product.  Even worse, they do this with complete disregard to schedule and cost.
	* When the development staff rejects a new requirement due to the scope creep/significant cost/schedule hit involved, the customer rejects our explanation with the standard, "your software is not flexible enough".
	* Has no technical experience but has the audacity to suggest designs and implementations for the software.
	* Rejects any suggestions from the software development staff as to how to improve the product simply because they did not think of it first.  When they do accept one of our suggestions, they make it clear that the suggestion is not really what they want but it will do for now (i.e. "If we want your opinion, we will give it to you").
	* Despite the classic mistakes continually made by this customer (see RapidDevelopment by SteveMcConnell, ISBN: 1556159005), the customer insists it is doing absolutely nothing wrong and if the project fails, my company is the only one to blame.

Bottom line, this customer cannot be satisfied.  A former co-worker before  resigning often said that relationships with customers should be win-win for the customer and the company providing the products/services.  Clearly, this situation is win-lose, win for the customer, lose for us.  Despite all of the problems (and there are more in addition to the above list), my company is committed to finishing this.  I for one will not stick around.  Unfortunately, my departure will only make things worse for my soon-to-be former coworkers who must continue to work on this project.  For them, I have a great deal of sympathy.  Whatever pain the customer feels due to my departure is well-deserved.  For them, I have absolutely no sympathy.

--KeithWedinger

This sounds just like one of my present building projects. You should try being a real Architect! The tale of woe recited by Keith is in fact all too common an occurrence in real building projects. 

Sometimes, in fact, it's even worse in construction: some clients simply want a building with little or no idea of its function or purpose. 'Design' in this case can be a little like the problem of Nebuchadnezzar's Dream (cf Old Testament Book of Daniel ch 2) where the King asked for the interpretation without first telling the dream!

Another good scenario is where there are at least two client bodies for the same project with conflicting, unresolved requirements and expectations.

In these situations it can often be quite helpful that Architects do have agenda of their own (eg spatial/formal/iconographic/contextual ideas) which enable a framework for design to be established independent of the Client's brief & requirements. 

--MartinNoutch

There are some juicy parallels between what you say here and a number of situations I've come across with software projects Martin.  But I'd like to ask a question about your most provocative statement (to me) - in the last paragraph. How are the differences between the architect's agenda and the client's ambiguous or even self-contradictory requirements finally resolved? In the high court or before that?! 

--RichardDrake

''Hopefully not the High Court! No, resolution usually depends on HardWork requiring large amounts of additional time by the Architect (unpaid if the Client can swing it!). At the end of the day most architects are concerned to solve all problems in a design even when it means unreasonable efforts: it's part of being an ArtistByProxy.'' -- MN

----

See Also: JustAnArchitect, ArchitecturalModel, InvestigatingConcreteThings, SoftwareArchitect, ChiefArchitect