Documenting the Building Design - Project Manual - Revisions

So, as we said, the process of writing a project manual starts early on in the project overall. So maybe during schematic design, we might start with an outline, and then design development, we're filling in information about the specific material choices that we have started to kind of hone in on. And by the time we get to the CD sets, the construction documents and contract document sets, we're filling in that information, and by the time we get towards the end of that, we're ready to go to bid, well, now we have to do a final edit, we're kind of going through that whole process, and we're getting every last little bit down.

So a lot of people will often just are wait, wait, wait, wait, wait, and then write the whole thing at the end, and that's always a problem, because it just takes so long to produce one of these things. But if you're sort of building it up through the process, well, then the information is likely to be fuller, and be more, sort of, thorough, and to have a sort of logical relationship between the drawing sets and the project manual, it's easier to tag information back and forth, if you've been building it along, it's a lot harder if you're just going to, at the last second, throw a bunch of tags onto the drawing sets and hope for the best.

But, obviously, in the same way that the drawings do, there's gonna be issues that are gonna change as it goes along. So, if it's in-house changes, if you've been moving through it in-house, you may wanna have your own system for how you keep track of those changes. Maybe some way that you're gonna be making sure that when we make a change over here, that we make a change in the project manual.

And that would be by keeping some sort of log system. So that would be the project manager, or the project architects, one of those players would be sort of keeping track of what the issues are, and then making sure it shows up in the drawings, and making sure that that new change shows up in the project manual. So that's during that whole sort of design process, as you're going along, you're trying to keep up between the two. And the only way you can really do that is by keeping a running log of what all the issues are that have come up over the time of that process.

But then we get to this certain point where the project manual becomes actually a legal document. Prior to the bid phase, the project manual's just a sort of useful tool that you're putting together, and it's sort of in-house. You're not really using it in any sort of legal construct before that point. But, when it becomes part of the bid package, it's now part of the legal sort of package of information about a project. So, as soon as you start making addenda, where there's a sort of conversation between the architects, and these potential bidders, and they're asking questions, and you're writing all those questions down, and coming up with answers, and altering the drawings, and responding to the information that's been requested, from these bidders, well, you have to make sure that you're also changing the project manual, as well.

Because typically both the drawings and the project manual would have to be altered in order to answer all of the questions that come up for an addenda.

And just like with a drawing set, if I have a drawing, and that sheet of, on the drawings, has one change on it, and you have a whole big plan, with all kinds of stuff going on on it, and there's lots of notes, and there's tags of information, and things are pointing in at different places, and the change is right there, it's really hard to see that. It's just lost in the information, this sheet is filled with dimensions and notes and lines and all kinds of stuff going on.

So, that idea of the bubble, the revision cloud bubble, that you go around, when I look at that sheet now, it's like, wow, that's clearly where the change is, I can see it immediately. Well, so on the project manual, you do the same thing. You actually can put a revision cloud around the area that's been changed. But it's not gonna work as well as it does with the drawing sets.

With a drawing set, I have this big drawing, I open it up, it has a lot of information on it, and the revision cloud sort of jumps forward. You can visually, sort of graphically see it very easily. But I have a project manual, it's an eight 1/2 x 11 book, it's probably pretty thick, it's hard to actually find those moments. You'd have to literally look at every single page in order to find that, which isn't such a terrible thing to do, even on a big, thick set of drawings, you know, maybe I have 100 pages, well, that's believable that you could kind of see those pretty easily.

But in a project manual, it would be very hard to track that down. Now, it's still useful to put something like a revision cloud, or an underline, or some other sort of tool, that sort of says, "something's happened here, "and this is now a different situation." And, often these days, if you're doing it in certain kinds of formats, there'll be ways that you can highlight, and ways that you can cross out and underline, that are sort of built into the programs that you're using, so that that is all sort of part of the process, and it's easy to see, but still, it would be hard to find in the project manual.

So, usually you have to find other ways to note where those changes are. So, one thing you might find is, when your produce an addenda, that you would note in the addenda where the change is, or what sheet number, or what section number that change was, you would tag the addenda to the change in the project manual. And then once they can flip to that page, there would be the spot where it's underlined, or the revision cloud, or whatever highlighted, or made bold, or whatever it is, it would then jump out on that sheet, or in that section, what areas had been altered.

So, it's a way to take the addenda, and use that as a tool for helping people find the information that's been altered. You might also tag it to what's been changed on the drawing sheets, you'd have the sheet numbers, the drawing numbers, that kind of thing listed on the addenda, if there was a change, and that would be a useful thing, it's just not as important as doing it in the project manual, 'cause, as I said, it's just so hard to find any change that happens in a project manual.

Another way that you'll often see this done is that project manuals, like drawing sets, are always dated. They must have a date on them in order for them to have any legal consequence. So when you do a bid set, it says, "bid set, October 10th," you know, whatever the year is, right.

You're gonna have that information right there on each of those drawings. And that way, when it goes into the bid set documents, the bid set documents will say, "this bid set is using this drawing set, "or this project manual." And the way that we describe that is by giving it the name of the project, with the date. And then the contract, when the bidder is chosen, the contract's gonna say, "alright, here's the project, "this is the project we're doing, "and we're using the drawings dated X," right? So everything has to be dated, and one of the ways that you can help people navigate through a project manual is to have a special date on the table of contents that says, "alterations," and then the date.

So it would be "revision one," "addenda one," or "change order two," or something like that. You would just literally just title it out and put a date, and then you would do the revision cloud on that section, so you would be clear that there's a date, that means something has changed, that section has been highlighted, and then you can go into the project manual, and find that specific piece of information, and then from there, again, it would be highlighted, or underlined, or whatever system you were using.

So, those are all ways of using the documents themselves, the addendas, the project manual, that you're actually altering them in such a way that people can find the changes, the revisions that have happened along the way. But, of course, you can also do other kinds of documents, just kind of separate memos, you can do bulletins, you can do, there's all sorts of other ways that you can highlight the idea that something has changed, and, again, you would then be giving the specific section number, and finding other ways to sort of get across how people could find that information.

So, typically, in that scenario, if I'm doing a memo on this topic, I would probably include, in the memo, what the change was, what it was before, and what it became, in the memo, and then I would include a link or a tag or some way to show people what section that was, so they could also see it in the context of the project manual.

And again, it's really important that these things are all dated, and that there's a log being kept of these kinds of changes, because the legal construct is really all about the dating. You can't really be talking about any of these different issues, a change that was made, or what the drawings look like, or how clear something is, it's all dependent on what drawing set, or what project manual somebody's looking at. So, what date it is, is hugely important.

What date the memo was is hugely important. So, you can kind of fit all of these things together. If you did have a memo that went in that was altering that project manual, it really should go in to the project manual, as well, so that would be something where, if you were flipping through, you would be able to see that information. So, you're looking for ways, not only to keep it up to date, so a system for keeping it up to date, keeping a log of changes, keeping a log of the sort of process as it goes along, but then, also, using the questions during addenda periods and bidding periods to sort of make sure that when you're updating the drawings, you're also updating the project manual.

So, you trying to keep it as up to date as possible, but you're also trying to make it possible for somebody to navigate through that system, and find those revisions.

Log in to access files