<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Use of the Imperative Mood in Architectural Specifications</title>
	<atom:link href="http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/</link>
	<description></description>
	<lastBuildDate>Tue, 31 Jan 2012 01:23:03 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=abc</generator>
	<item>
		<title>By: James</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-93502</link>
		<dc:creator>James</dc:creator>
		<pubDate>Thu, 12 Nov 2009 13:54:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-93502</guid>
		<description>A specification is not a contract- It is an Instrument of Service, just like a drawing.  Because it uses words that look like a contract does not inherently make it so.  Why is it not a contract? Because it does not contain all of the elements of a contract- parties, obligations, money, and time as a cohesive whole. 
The function of the Contract is to define responsibilities, schedule and cost.  If you follow Maureen&#039;s observation then we would add schedule clauses into each sentence?  In fact, we already do that but in separate locations- the Contract provides schedule i.e. complete the Work by July 15 2009, while the Project Manual (note that I did not say specification) provides the action i.e. Paint the wall white.
As the Instrument of Service, the Project Manual has a specific purpose-to provide instruction/direction to the Contractor.  It includes drawings which show what goes where, and specifications which state what and how.  Both are inherently, though not absolutely, imperative.
Examine the other part of the Project Manual - drawings.  Are drawings indicative or imperative- they are imperative.  Consider a dimension of 12 feet long wall- should the dimension be written as 12&#039;-0&quot;, arguably imperative, or should it be written indicative &quot;The Contractor shall build this wall to be twelve feet long&quot;?  If you argue specifications are Contracts then you must accept that Drawings are as well and by extension of the argument posited in this commentary then the drawing s should be developed in an indicative voice.
In specifications as there are many thousands of discrete simple actions that are required to be performed by a single entity, the Contractor, not the relative few of a contract that has complex actions to be performed by both parties.
Brevity has value- more words do not change the simple action.
I recommend the Construction Specifications Institute Construction Document Technologist coursework as a means to understand the full relationship of all components of a project and the relationship of the Contract to the Project Manual.
Keep the contract language where it belongs- in the Contract.</description>
		<content:encoded><![CDATA[<p>A specification is not a contract- It is an Instrument of Service, just like a drawing.  Because it uses words that look like a contract does not inherently make it so.  Why is it not a contract? Because it does not contain all of the elements of a contract- parties, obligations, money, and time as a cohesive whole.<br />
The function of the Contract is to define responsibilities, schedule and cost.  If you follow Maureen&#8217;s observation then we would add schedule clauses into each sentence?  In fact, we already do that but in separate locations- the Contract provides schedule i.e. complete the Work by July 15 2009, while the Project Manual (note that I did not say specification) provides the action i.e. Paint the wall white.<br />
As the Instrument of Service, the Project Manual has a specific purpose-to provide instruction/direction to the Contractor.  It includes drawings which show what goes where, and specifications which state what and how.  Both are inherently, though not absolutely, imperative.<br />
Examine the other part of the Project Manual &#8211; drawings.  Are drawings indicative or imperative- they are imperative.  Consider a dimension of 12 feet long wall- should the dimension be written as 12&#8242;-0&#8243;, arguably imperative, or should it be written indicative &#8220;The Contractor shall build this wall to be twelve feet long&#8221;?  If you argue specifications are Contracts then you must accept that Drawings are as well and by extension of the argument posited in this commentary then the drawing s should be developed in an indicative voice.<br />
In specifications as there are many thousands of discrete simple actions that are required to be performed by a single entity, the Contractor, not the relative few of a contract that has complex actions to be performed by both parties.<br />
Brevity has value- more words do not change the simple action.<br />
I recommend the Construction Specifications Institute Construction Document Technologist coursework as a means to understand the full relationship of all components of a project and the relationship of the Contract to the Project Manual.<br />
Keep the contract language where it belongs- in the Contract.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Adams</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-92559</link>
		<dc:creator>Ken Adams</dc:creator>
		<pubDate>Fri, 19 Jun 2009 00:16:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-92559</guid>
		<description>Bob: I don&#039;t have a background in specifications, but I&#039;ve spent quite a few years immersed in language that seeks to regulate conduct. A broader perspective can be useful.

I did read the CSI Project Manual sections you point to. They&#039;re necessarily simplistic, as they cover in a few pages what I cover at much greater length in my book.

I understand your concerns about making specifications comprehensible for people who aren&#039;t used to legal language. There&#039;s a whole industry geared to such writing, for example for purposes of insurance policies and credit-card documentation. It would be interesting to see whether they make use of the imperative mood. On the other hand, such documents tend to use the second person, which makes an indicative-imperative mix more feasible.

Ultimately, the clearest way to examine this issue would be to present an analysis of some actual specifications language. I may do that at some point.

Ken</description>
		<content:encoded><![CDATA[<p>Bob: I don&#8217;t have a background in specifications, but I&#8217;ve spent quite a few years immersed in language that seeks to regulate conduct. A broader perspective can be useful.</p>
<p>I did read the CSI Project Manual sections you point to. They&#8217;re necessarily simplistic, as they cover in a few pages what I cover at much greater length in my book.</p>
<p>I understand your concerns about making specifications comprehensible for people who aren&#8217;t used to legal language. There&#8217;s a whole industry geared to such writing, for example for purposes of insurance policies and credit-card documentation. It would be interesting to see whether they make use of the imperative mood. On the other hand, such documents tend to use the second person, which makes an indicative-imperative mix more feasible.</p>
<p>Ultimately, the clearest way to examine this issue would be to present an analysis of some actual specifications language. I may do that at some point.</p>
<p>Ken</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: mike</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-91866</link>
		<dc:creator>mike</dc:creator>
		<pubDate>Wed, 10 Jun 2009 21:59:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-91866</guid>
		<description>I&#039;ll be the first to admit I had never heard of the &quot;indicative mood,&quot; but really it seems to me that Sheldon&#039;s point is simply: indicative mood is not as useful in a specification because the obligations are really only the contractor&#039;s.

But assuming this is even true, it would be a quirk of the setting in architectural contracts. Because the moment the specification applies more than one person (e.g., to delineate responsibility between more than one contractor), then it falls flat.  As we computer scientists like to say: it doesn&#039;t scale.

But really, as pointed out by Maureen though, a well-written imperative mood clause does not change overall wordiness or level of ambiguity:

[Subject] shall [verb] ... 

I think the CSI argument is actually less persuasive if, as Ken points out, the examples weren&#039;t written in the passive voice, which increases the overall awkwardness.

As to Sheldon&#039;s final point, regarding use of fewer words, the fact that something has more or fewer words does not really change the amount of misunderstanding.

The type and amount of information you need in a specification is more a function of the specificity needed.  And the length of most legal contracts has more to do with figuring out all the things that can happen and resolving them now rather than later.  Nothing is worse than a client coming to me with a one page contract with nothing but the business terms and stating, &quot;I can&#039;t get them to do this, now what?</description>
		<content:encoded><![CDATA[<p>I&#8217;ll be the first to admit I had never heard of the &#8220;indicative mood,&#8221; but really it seems to me that Sheldon&#8217;s point is simply: indicative mood is not as useful in a specification because the obligations are really only the contractor&#8217;s.</p>
<p>But assuming this is even true, it would be a quirk of the setting in architectural contracts. Because the moment the specification applies more than one person (e.g., to delineate responsibility between more than one contractor), then it falls flat.  As we computer scientists like to say: it doesn&#8217;t scale.</p>
<p>But really, as pointed out by Maureen though, a well-written imperative mood clause does not change overall wordiness or level of ambiguity:</p>
<p>[Subject] shall [verb] &#8230; </p>
<p>I think the CSI argument is actually less persuasive if, as Ken points out, the examples weren&#8217;t written in the passive voice, which increases the overall awkwardness.</p>
<p>As to Sheldon&#8217;s final point, regarding use of fewer words, the fact that something has more or fewer words does not really change the amount of misunderstanding.</p>
<p>The type and amount of information you need in a specification is more a function of the specificity needed.  And the length of most legal contracts has more to do with figuring out all the things that can happen and resolving them now rather than later.  Nothing is worse than a client coming to me with a one page contract with nothing but the business terms and stating, &#8220;I can&#8217;t get them to do this, now what?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Adams</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-91820</link>
		<dc:creator>Ken Adams</dc:creator>
		<pubDate>Wed, 10 Jun 2009 11:14:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-91820</guid>
		<description>Sheldon: In everyday English, the imperative is used sparingly—&lt;em&gt;Do the dishes!&lt;/em&gt;. Specifications do seem to contain less variety than actual contracts, but those few that I&#039;ve looked at nevertheless consist of more than a simple list of A&#039;s instructions to B. The result is that anything that isn&#039;t a simple instruction has to be twisted to fit in an imperative world.

Regarding the comments by your attorney friend, comprehension isn&#039;t, unfortunately, entirely a function of how few words you use.

As for Maureen&#039;s suggestion, you&#039;re throwing the baby out with the bathwater. The approach Maureen suggested is also applied to good effect in contracts.

(By the way, readers, Sheldon is a specifier who was previously institute director and president of the North Central region  of the Construction Specifications Institute.)

Ken</description>
		<content:encoded><![CDATA[<p>Sheldon: In everyday English, the imperative is used sparingly—<em>Do the dishes!</em>. Specifications do seem to contain less variety than actual contracts, but those few that I&#8217;ve looked at nevertheless consist of more than a simple list of A&#8217;s instructions to B. The result is that anything that isn&#8217;t a simple instruction has to be twisted to fit in an imperative world.</p>
<p>Regarding the comments by your attorney friend, comprehension isn&#8217;t, unfortunately, entirely a function of how few words you use.</p>
<p>As for Maureen&#8217;s suggestion, you&#8217;re throwing the baby out with the bathwater. The approach Maureen suggested is also applied to good effect in contracts.</p>
<p>(By the way, readers, Sheldon is a specifier who was previously institute director and president of the North Central region  of the Construction Specifications Institute.)</p>
<p>Ken</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sheldon Wolfe</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-91806</link>
		<dc:creator>Sheldon Wolfe</dc:creator>
		<pubDate>Wed, 10 Jun 2009 06:48:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-91806</guid>
		<description>In the context of the traditional owner-contractor agreement, there are two parties - the owner, whose documents describe what is to be built, and the contractor, who is solely responsible for constructing the building. The design professional (architect or engineer), who designed the building, acts sometimes as an agent of the owner and sometimes as supposedly independent interpreter of the construction documents. 

The general conditions of the contract describe the relationships between the owner, contractor, and design professional, and their responsibilities to each other. Because they are written from the perspective of an outside observer, they are in the indicative mood. 

In contrast, the specifications are directions to the contractor. As such, there is no need to use the indicative mood. Imagine a conversation between the owner and the contractor. Would the owner say, “The contractor shall paint the fence”? No. The owner would say, “Paint the fence.”

Because there is only one party, the contractor, who is responsible for construction, the specifications can and should be written as directions to the contractor. It doesn&#039;t matter if the contractor&#039;s own people or subcontractors do the work, all of them, as employees of the contractor, are responsible to the contractor, and the contractor is responsible for what they do. One party to the contract, the owner, is telling the other party, the contractor, what to do. In general, the owner does not care who does what or how it gets done; that is the contractor’s responsibility.

There is good logic to support this approach. Not only does the owner have no direct relationship with a subcontractor or other employee of the contractor, but trade agreements and contractor-subcontractor relationships are beyond the knowledge of the owner or design professional, while the contractor works with them daily. 

The argument that you can’t specify obligations of persons other than the contractor is specious; it is because there are only two parties to the contract that you cannot specify obligations of those who are not parties. In terms of the contract, it doesn’t matter who paints the fence, as the contractor is the party responsible for doing it. Looking in the other direction, the contract does not specify where the owner’s money comes from, only that the owner must pay the contractor.

In those cases where the contractor has discretion, there is no conflict in allowing options. The perception that it “would read very oddly” is hardly a convincing argument. Is it so difficult to understand “Paint the fence, using one of the following materials”? The average contract written in legalese reads much more oddly.

Yes, the specifications do constitute contract language, but, properly written, they are refreshing in the lack of ambiguity and complexity that seems to be required of documents written by attorneys. Writing in “abbreviated form”, i.e., short, concise imperative statements, is less likely to be misunderstood, and less susceptible to creative interpretation. 

The Project Resource Manual, which incorporates CSI’s old Manual of Practice, is not “inventive”, rather, it goes back to basic rules of writing, as espoused in Strunk &amp; White’s “Elements of Style” for nearly a century, and, perhaps more importantly, the “keep it simple, stupid” principle. The MOP has been around for decades; it is curious that “[t]his is the first time” the author has encountered the recommendation to use imperative, rather than indicative mood. Why we accept - and expect - &quot;legal&quot; documents to be written in the most complex way possible is a mystery. 

Comments from an attorney I know shed some light on this subject. In essence, he said the more words you use, the greater the opportunity he has to interpret them in favor of his client. An architect I know said the same thing in a different way. He said that if he specifies simply that a coating be “waterproof” there is no room for misunderstanding or interpretation. The more he adds to make it “easier to understand” the weaker the specification becomes. For example, if he specifies that the membrane must prevent passage of a certain amount of water at a certain pressure over a certain period of time, he has a weaker specification. (I know, there is no such thing as waterproof, just as there is no such thing as bulletproof; it’s only an illustration to make the point.)

And for goodness sake, Maureen, please don’t use what the legislature does as an example! If anything, our legislators and attorneys should be required to understand and use “Elements of Style” in their work.</description>
		<content:encoded><![CDATA[<p>In the context of the traditional owner-contractor agreement, there are two parties &#8211; the owner, whose documents describe what is to be built, and the contractor, who is solely responsible for constructing the building. The design professional (architect or engineer), who designed the building, acts sometimes as an agent of the owner and sometimes as supposedly independent interpreter of the construction documents. </p>
<p>The general conditions of the contract describe the relationships between the owner, contractor, and design professional, and their responsibilities to each other. Because they are written from the perspective of an outside observer, they are in the indicative mood. </p>
<p>In contrast, the specifications are directions to the contractor. As such, there is no need to use the indicative mood. Imagine a conversation between the owner and the contractor. Would the owner say, “The contractor shall paint the fence”? No. The owner would say, “Paint the fence.”</p>
<p>Because there is only one party, the contractor, who is responsible for construction, the specifications can and should be written as directions to the contractor. It doesn&#8217;t matter if the contractor&#8217;s own people or subcontractors do the work, all of them, as employees of the contractor, are responsible to the contractor, and the contractor is responsible for what they do. One party to the contract, the owner, is telling the other party, the contractor, what to do. In general, the owner does not care who does what or how it gets done; that is the contractor’s responsibility.</p>
<p>There is good logic to support this approach. Not only does the owner have no direct relationship with a subcontractor or other employee of the contractor, but trade agreements and contractor-subcontractor relationships are beyond the knowledge of the owner or design professional, while the contractor works with them daily. </p>
<p>The argument that you can’t specify obligations of persons other than the contractor is specious; it is because there are only two parties to the contract that you cannot specify obligations of those who are not parties. In terms of the contract, it doesn’t matter who paints the fence, as the contractor is the party responsible for doing it. Looking in the other direction, the contract does not specify where the owner’s money comes from, only that the owner must pay the contractor.</p>
<p>In those cases where the contractor has discretion, there is no conflict in allowing options. The perception that it “would read very oddly” is hardly a convincing argument. Is it so difficult to understand “Paint the fence, using one of the following materials”? The average contract written in legalese reads much more oddly.</p>
<p>Yes, the specifications do constitute contract language, but, properly written, they are refreshing in the lack of ambiguity and complexity that seems to be required of documents written by attorneys. Writing in “abbreviated form”, i.e., short, concise imperative statements, is less likely to be misunderstood, and less susceptible to creative interpretation. </p>
<p>The Project Resource Manual, which incorporates CSI’s old Manual of Practice, is not “inventive”, rather, it goes back to basic rules of writing, as espoused in Strunk &amp; White’s “Elements of Style” for nearly a century, and, perhaps more importantly, the “keep it simple, stupid” principle. The MOP has been around for decades; it is curious that “[t]his is the first time” the author has encountered the recommendation to use imperative, rather than indicative mood. Why we accept &#8211; and expect &#8211; &#8220;legal&#8221; documents to be written in the most complex way possible is a mystery. </p>
<p>Comments from an attorney I know shed some light on this subject. In essence, he said the more words you use, the greater the opportunity he has to interpret them in favor of his client. An architect I know said the same thing in a different way. He said that if he specifies simply that a coating be “waterproof” there is no room for misunderstanding or interpretation. The more he adds to make it “easier to understand” the weaker the specification becomes. For example, if he specifies that the membrane must prevent passage of a certain amount of water at a certain pressure over a certain period of time, he has a weaker specification. (I know, there is no such thing as waterproof, just as there is no such thing as bulletproof; it’s only an illustration to make the point.)</p>
<p>And for goodness sake, Maureen, please don’t use what the legislature does as an example! If anything, our legislators and attorneys should be required to understand and use “Elements of Style” in their work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ken Adams</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-91779</link>
		<dc:creator>Ken Adams</dc:creator>
		<pubDate>Tue, 09 Jun 2009 21:39:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-91779</guid>
		<description>Maureen: That&#039;s exactly what I had in mind. Ken</description>
		<content:encoded><![CDATA[<p>Maureen: That&#8217;s exactly what I had in mind. Ken</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maureen Kane</title>
		<link>http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/comment-page-1/#comment-91775</link>
		<dc:creator>Maureen Kane</dc:creator>
		<pubDate>Tue, 09 Jun 2009 21:14:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.adamsdrafting.com/2009/06/09/imperative-mood-in-specifications/#comment-91775</guid>
		<description>Why not do what the legislature does and use imperative for the opener and make a bulleted list, as in the following:

The contractor shall perform the following jobs by July 15, 2009:
- Spread adhesive with notched trowel
- Paint all exposed surfaces</description>
		<content:encoded><![CDATA[<p>Why not do what the legislature does and use imperative for the opener and make a bulleted list, as in the following:</p>
<p>The contractor shall perform the following jobs by July 15, 2009:<br />
- Spread adhesive with notched trowel<br />
- Paint all exposed surfaces</p>
]]></content:encoded>
	</item>
</channel>
</rss>

