
This year, Tocci sent out an e-card. I meant to post it, but then I forgot. Oops. Better late than never... In any case, we've had a lot of feedback, including Mark Sawyer's thoughts on it, which we truly appreciate.

One of the features of “full” IPD contracts is that project participants (who are involved in the IPD team) bill “at cost”. For us, this includes architecture, design MEP, CM, MEP/FP subcontractors and drywall. This creates an interesting dynamic on site – where the most appropriate and cost efficient participant performs work that may not traditionally be considered in their scope. This forces all to focus on optimizing the whole. This includes tasks from layout to using lifts/equipment to cleaning up on site.
Traditionally, we require our subcontractors to clean up on site. However, in this case, we didn’t want a trained specialty contractor spending time cleaning up on site when we could have a Tocci laborer do the same work at a reduced hourly rate. So, we “bought back” that typical scope component and are adding to the project savings for everyone by spending less.

Something that people tend to discuss is the need for an audit trail in model authoring tools to facilitate IPD. But I believe it was Wayne Muir (from SCI) countered that point during the Software Vendor panel discussion. He made the case that only lawyers want and benefit from an audit trail. We all need to understand what has changed in the model, but have no need for who did what. These tools enable collaboration; we don’t need to add features that send us back to the traditional litigious process.
On the Autodesk Waltham project, we don’t have any audit trail. We don’t need one (also we couldn't have one even if we wanted one). Because there is trust between all the team members. KlingStubbins trusts that we won’t modify anything without discussion it with them, and we trust that they will notify us of changes they are making, so we can implement them.
I agree with Wayne – it is not about the technology; it’s about the process. Although, as someone else brought up, is that just giving the vendors an excuse not to resolve dysfunction? (Actually, probably not – I don’t believe that vendors want to create less than functional tools that prevent companies from purchasing them.)
Mark McDonald, from NBBJ, gave an interesting presentation on Tools for Effective IPD. One of the most interesting points to me was his insistence that the entire team read the contract. This is something we are preparing our team for; although, there is some resistance to reading 70+ pages of “lawyer speak” (as one of our modelers says) for each project. We are having the team read all the available IPD and BIM Addendum-like contracts, and then scheduling discussions in order to ready them to read project-specific contacts. Hopefully some exposure to “lawyer speak” will make it easier to read project-specific contracts.
Mark gave several reasons for why the entire team should read the contract, but the most important is that it: defines what it is expected of the team. I agree with this wholeheartedly.
He also said not to worry about company manuals because the contract is the guide; the team should align the tools to the contract. Although I agree that the team’s tools and processes should be aligned to the contract, but I don’t think that company-specific protocols and manuals should be thrown to the wind.
In a more traditional project, company-specific protocols will most likely govern the interaction and process on the project, because the contract probably won’t. And on IPD projects, the team needs to be prepared to hit the ground running, and experience and company standards will facilitate the integration with other project partners. On of the things that both Sarah & I say about working together is that it was easier to develop standards and work together because of our experience with Revit and company standards. We knew that the other had a lot experience and could be trusted.
Obviously company standards do need to be modified to meet contract requirements (or vice versa), but it is critical to have a base standard.


Another interesting use of the model for the Solaris project (presented at the BIMForum by SCI and Weitz) was during the building permit review process. After discussions with the team, the town of
This use of the model is impressive; there is significant value in speeding up the permit review process by supplying information that is easier to understand and more consistent.
Of course, as towns move in this direction, this may require all of to model to standards specific to permit review. At the very least, we may have to model additional components for the process. I guess we all need to practice with Solibri (which I have been doing for the past few weeks – more on that later).
The theme of the January BIMForum meeting at La Quinta was the Path to IPD; although, when the theme was first selected, it was referred to as “BIM-Enabled IPD”. Why the change? As the conference chair, David Morris (EMCOR) explained in the keynote: the 6 people planning the conference has 8 different opinions. Some people defined IPD strictly as a contractual form, much like the AIA295 (the Project LLC contract) and Consensus Docs’ 300. Others saw IPD as integrating design with construction in any fashion (i.e. design assist).
It seems like the fate of IPD is similar to that of BIM: it will mean something different to everyone.
For what it’s worth, I define IPD as a specific tri-party form of agreement/contract that sets up a framework for people to work together more effectively.