Here’s a quick quiz…
Imagine you’re seated at a table and in front of you are:
5 red Skittles
4 green Skittles
2 yellow Skittles
A snap pea
A green M&M
2 yellow M&M’s
4 red M&M’s
Across the table from you are seated a child, a nutritionist and a designer.
Now, if asked create 3 groups from your items for the child, what would they be? Skittles, M&M’s and “healthy food”? Might you organize them differently for the nutritionist? (Fruits, vegetable, candy?) For the designer, would you group things by color?
Grouping submittal items into packages presents a very similar problem.
The best organizing principle is, we believe, whatever will be most understandable for the recipient, and what seems most appropriate and helpful. (For example – and much to the nutritionist’s dismay – the child may prefer only two groups: stuff I want to eat, and stuff I have to eat. More to the point, candy, and then everything else.)
A few weeks ago, we spoke with an architect who described a 168-page submittal package she received from a sub. It contained product data and supporting information about doors, about windows, and about bicycle racks, all in one giant pdf. In other words, apples, oranges, horses, and trees. The submittal, to say the least, was not easy to review. And, as the architect pointed out, “if you reject one item, you have to reject the whole package.” This doesn’t work for anyone: sub, GC, or designer.
There are better ways to go.
A submittal package is best defined as a set of items, ideally from a single spec section, along with the documents that support them. The items themselves come from the requirements in the specs: schedules, meeting minutes, safety plans, product data, shop drawings, test data, mix designs, samples etc. The supporting documents can be product datasheets, shop drawings, design data, warranties, maintenance data, safety plans, schedules – whatever you need to show you’re going to do what the specs call for.
Here are five suggestions to make your submittal packages easy to put together and, importantly, easy for your GC and design team to review.
- Be specification specific. Do separate submittal packages in each specification section. This approach corresponds with industry best practices and, often, the submittal requirements set out in the Submittal Procedures section (01 33 00) of most Project Manuals. For sure, don’t mix Wood Doors (08 14 00) with Bicycle Racks (12 93 13).
- Make it bite-size, effort-wise. Organize complex, design intensive items into a separate package. These items will require more focus by the design team. There’s less risk of holding up a job when you present these items separately from the more routine ones. The same approach holds true for items with long lead times.
- Keep your act together. Place “Action Submittals” in their own packages. These require review and feedback by the design team. Shop drawings, product data, and samples are almost always Action Submittals.
- FYI, by-the-by. Put “Informational Submittals” in one or more separate packages. Qualification data, test reports, field quality control reports and meeting minutes are often informational submittals – they are part of the project but do not require review by the design team. They tend to be less critical than Action Submittals.
- Get a start on the end. Tag or otherwise separate close out items into separate packages as you work through the project so they can be easily pulled up at the end of the job. This will save you effort later on when your attention is more likely to be required by your next project.
Lastly, think about sending your submittals for review on web pages. The individual line items for each submittal make it easy for your GC’s project engineer to compare them with the submittal log. Ultimately, it will make it easier for the design team to review them. Submittal.com will be glad to help you with this.
That’s it! Got questions about Submittal Packages? Call us at 888.717.8665. We’ll be delighted to talk with you.