A while ago my husband and I were hosting a couple’s baby shower at our house.  We were going to have about 30 – 40 people over on a Saturday.  Scott had Friday off and I had two big deadlines at work so he was in charge of cleaning to house.  I was very appreciative because I needed to get the food together that evening.  He spent hours cleaning and when I got home we had the cleanest garage in the neighborhood.  Now I know the garage is part of the house, and the beer (apparently a must have for men attending a baby shower) would be in the garage, but honestly I could care less if people left our house thinking we had the dirtiest garage around.  On the other hand, I would care if guests saw a filthy bathroom and kitchen.  Needless to say, I was very annoyed and spent the evening cleaning while Scott admired his beautiful garage.

In hindsight, I realize we were both at fault.   I did not clearly define what I expected when I asked him to clean the house.  I was vague as to what I wanted and assumed we were on the same page.  In Scott’s case, he did not ask questions so that he fully understood what I was expecting.  He did not clarify what his scope of work was and made assumptions (why he would assume I wanted a clean garage over a clean bathroom I will never know).

Insurance companies and seminars are always preaching “define your scope” at the beginning of every project for a reason.  So many problems that occur during a project stem from misunderstood expectations.  The project is going great until the client expects you to do something and it clearly is not in your scope of work and you have to ask for additional fees.  The client is annoyed because they feel that it was obviously something they needed you to do, and now your great relationship has soured.  Whose fault is it?  The architect’s for not asking the right questions?  The client’s for not communicating exactly what they wanted?  I would say both.  The architect as the design professional is the leader.  Whether they are working with an inexperienced owner or a seasoned developer, they need to be sure that the client is clearly informed as to what services they will be receiving, and what they will end up with at the end of the contract.  The client needs to clearly lay out what their expectations are and not make assumptions.  They need to be sure they have read and understand the contract.   I don’t believe there is a full proof method to avoid miscommunications, but a good start would be to sit down before the project starts and review the contract and verify everyone is on the same page.  Discuss the scope and ask questions.   This one step seems to be glossed over because everyone is in a rush to start the project, but think of all the misunderstandings it could prevent.