Broadscope vs Narrowscope and Outline Specs

[paulgerber]

I am looking at finally updating our office Master spec from MF95 to MF10 format (as well as some personal reasons that some of you are aware of, which I will not go into detail on in a public forum but am more than willing to discuss by e-mail). So I am looking for some input from my global spec writing brothers/sisters-in-arms.

One thing I have always struggled with is broadscope vs narrowscope approach to sections. Examples of this would include:

• project co-ordination, project meetings, project schedules, submittals requirements in Section 01300 Administrative Requirements (present office practice) vs mutliple sections (01 31 13, 01 31 19, 01 32 16, 01 33 00)
• 04200 Clay & Concrete Unit Masonry vs multiple sections (04 05 00, 04 21 00, 04 22 00, 04 27 00)

How do different offices/specifiers handle this?

Also, what is your approach to Outline specs? Do you use them all the time or occasionally? How broadscope or narrowscope do you make these? (ie 07 70 10 for Roof Specialties including sheet metal flashings, roofing accessories hatches/scuttles, skylights vs. separate sections for various components). This is of particular interest from my perspective for issuance to cost consultants and/or CM for cost estimates during DD phase, as opposed to changing the header information on the last “similar” project and issuing that to them.

Although I think some open discussion on this topic would be good for the group as a whole, it may be cumbersome for providing any detail. Therefore if anyone would be willing to share their Table of Contents from their office master and/or master outline specs I would greatly appreciate it. You can forward the Table of Contents to my be e-mail at paul.gerber@rogers.com with the assurance that it will be kept confidential.

Thanks in advance for any feedback or information you may be able to pass along.

Paul

[awhitacre]

Paul:
I think the answer to your questions are a big “it depends”. I alternate between broadscope and narrow scope sections depending on how complex the project is, how big the project is (which typically intersects with complexity but not always); whether the project is being bid or negotiated; the degree of understanding and trust we have with the contractor, and even how far away the project is located. (a project down the street will have a greater day to day presence by the office; a project two states away may have 2 times a month on-site person, so the documents have to carry more of the load.

And, in addition, on some projects, some portions of the work are very complicated and require narrowscope sections – I often divide up “casework” into three sections (plastic laminate casework; back of house casework; and super premium casework) because I know it will be fabricated and bid by very different subcontractors; I use a narrow scope section when I want particular attention to a portion of the work, coupled with particular contract requirements.

this is the “you can’t be taught” part of specifying because its more intuition and experience (ie, intuition) than any hard and fast rule.

as for "outline " specs, I seldom use the actual outline version because in most cases when I’m asked for a Schematic or early DD set, it will be used for pricing, and I simply need more information than the outline section provides. I typically use a short form section and then take some things out. When I’m doing this, I used exactly the same table of contents that I will use in the final project – I want visible transparency between subsequent sets of documents.

Keep in mind that I work on a range of projects from a new conference room (with furnishings) to multi-building laboratory campuses, (or in dollars: from 200K to 2 billion).

[robert_w_johnson]

I think broadscope/narrowscope choices relate mainly to your practice and ease of editing. If you routinely make major changes to some subjects in a mult-subject broadscope section, then you may want to break it up so that you can reduce your editing time by having multiple versions of a narowscope section that is often different. Another factor would be overall length - you are less likely to have people read sections that are excessively long - better to break them up. It is just an ease of reading decision - is particular detailed information easy to find or not.

I do a decent amount of outline specs, but certainly not on every project. I think it is better to keep them organized the same as the full spec - easier to keep my masters coordinated and easier to translate and progress with project specs.

[lynn_javoroski]

I agree completely with Anne and Robert regarding the scope of the sections. We do a fair amount of laboratory work and have very narrow specs for the various types of laboratory equipment - fumes hoods, for example.

As to outline specs, what we do is to start with a full spec, same one we will use for the final product, and hide Parts 1 and 3 (unless there are articles in either Part that would effect pricing, since that’s the usual use for an outline spec at a DD phase), leaving only Part 2 visible. We lose no time to re-writing specs that way and the Table of Contents stays the same.

[john_regener]

I echo Anne’s comment. IT DEPENDS.

Elsewhere on 4specs.com are some articles written by Herman Hoyer, PE, FCSI regarding “shortform” specifications. Herman is a strong advocate of “shortform” specifications yet he also criticizes the concept of “shortform” because ideally no specification has too little or too much information. One should neither under-specify or over-specify for the requirements of a particular project.

For office master (I prefer the term prototype) specifications, it is probably better to over-specify or specify for the situation requiring the greatest detail. Then, for projects with less intense requirements, edit the prototype by deleting requirements that are not essential.

This is the application of “broadscope” and “narrowscope” concepts within a specification Section.

As for the set of office prototype specifications, there would need to be both “broadscope” and “narrowscope” Sections. “Broadscope” Sections by their nature would have less detail than the “narrowscope” Sections.

Figuring out which “broadscope” and “narrowscope” prototypes to use, and editing the text itself in “broadscope” and “narrowscope” fashion, is part of the “art” of specification writing for specific projects.

[jpjordan]

There are so many factors to consider; scale and complexity of the project, type of owner (public or private), type of procurement (invited bid, public bid, CMAR, design-build, etc.), office policy and procedure. It is also important to understand whether the owner and the architect are familiar with the contractor (or the list of invited bidders).

I want as much as I can get in the specifications (as much as is reasonable) on public work that is open bid; and I hope that the people producing the Drawings are able to coordinate all of that.

On the other hand, for private work that is negotiated where the architect puts a relatively complete finish schedule on the drawings (exterior and interior), I have an outline spec format that is very skinny on Parts 1 and 3 for most stuff. I would suggest that if you have a complete color schedule on the Drawing (exterior and interior finishes), you don’t to say much more than “We want to approve colors with mockups” and “Apply in accordance with manufacturer’s instructions.”

I have found for my consulting practice, most of my clients (the architects) put a lot of stuff on the Drawings. I still go heavy on some sections (e.g., roofing and fenestration), but there are many sections that simply don’t need very much mor than an appropriate submittal article, the name of the product, and “Follow manufacturer’s instructions.” The projects are usually negotiated or invited bidders with known (and reputable) contractors so a “shortform” spec provides “just enough” coverage for the architect without producing a weighty specification that tends to have great impact when hurled across the room by an irate architect. A specification that is “just enough” neither over specifies nor under specifies; it is just enough.

I subscribe to MasterSpec (both full length and short form versions) and have developed my own master outline specification. I also have a “suite” of “office masters” for special prducts and systems. What I use and how I use it will entirely depend on the project context.

I have often observed that it is the jobsite superintendent who makes or breaks a job. If you have a good super, your CDs can be extremely flawed and he (usually a he) will see that it gets built the way the owner wants it. If you have a poor super, he (again, usually a he) will find a way to screw it up even with the highest quality CDs. It is the in between situations when a good set of CDs, one that is reasonably accurate, complete, and coordinated can bee an effective means of the construction phase yielding a positive outcome for everyone.

[jim_sliff]

To take Peter’s notes a step further, a good superintendent not only interprets CDs with an almost clairvoyant “vision” (and even the best CDs are flawed in some way - at least I have not yet discovered “perfection”, which is a goal rather than a “thing”.) but also 1) Knows what parts of particular CDs are (realistically) “guides” rather than absolutes, and 2) lacks a self-inflated ego and solicits/welcomes input from subs, manufacturers and other resources for help when he’s out of his league.

In my experience shortform Specs work best for simple construction with negotiated contracts (and where the GC has good relationships with quality subs, who in turn have the same types of relationships with quality manufacturers). In these cases the construction team is best assembled during design, although it’s not essential.

OTOH I’ve seen shortform disasters when the superintendent thinks he knows more than the subs, manufacturers, or (this is usually more subversive) the design team.

Document-wise I don’t find it practical to use one “office master” Specification and chop it down to create a shortform version. They’re different animals; I find short form specs are better when developed early and with input from a negotiated team of participants. They “guide” a qualified team rather than dictate to an assemblage of ow bidders.

IMO they make lousy bid documents because of the “disconnects” and possibility of multiple interpretation by bidders - actually their subs. We sometimes forget that the “bidders” don’t do all the construction - it’s primarily performed by subs, and for a bidder to submit a qualified bid his subs have to be able to “see” the desired results. Shortform Specs that leave things open to interpretion can be a trainwreck - 10 “bidders” basing their proposals on information/prices gathered from 10 (sometimes different..and sometimes multiple) subs and/or suppliers in each trade, each with a “my way is best” attitude.

I don’t use them unless I know the players.

[bunzick]

In deciding upon broadscope vs. narrowscope, one needs to take into account the effort to maintain one’s office masters. If you subscribe to a library such as MasterSpec, as my prior firm did, I found it much easier to maintain our office masters if they paralleled what MasterSpec did. Having to merge or split sections is a fair amount of work. Even just a straight-forward compare only works if the two sections are pretty similar. You would not be able to easily compare the content of two MasterSpec sections to a combined office master except by carefully poring over printouts. As MasterSpec moved towards more narrowscope sections, we followed along. I think, in the end, I find it easier to manage, write and assemble project manuals with narrower-scope sections.