Industry watch – Collaborative Delivery – How Contract Templates For Collaborative Agreements Are Structured and Why You Might Choose Not To Use Them

In late January of this year, I attended and spoke at the ProcureCon Facilities Conference.  You can read my review of the conference here.

The subject I addressed during my talk was Collaborative Delivery.

For several years the industry has been abuzz about Collaborative Delivery models.  I have yet to encounter an Owner who showed interest in collaborative delivery, but the interest from the industry was so strong, that I was curious to learn more.  When the opportunity to speak at ProcureCon came, I felt it would be a great topic for that audience.

I’ve written about these models before, but felt I need to dive deeper.  To deepen my understanding of the topic; I soaked up all of the content available on the American Institute of Architect’s website, read commercially available sample contracts, reviewed case studies, read articles on the subject, and spoke with colleagues that have worked under the model.

The most helpful piece of information I found is a document called the AIA Integrated Project Delivery Guide.  I also took the added step of reviewing the standard terms in the contract templates offered by AIA.

I was surprised to find that under the heading of collaborative delivery the AIA includes a contract template for Integrated Project Delivery (IPD) contracts and also for Single Purpose Entity (SPE) contracts.

In this article, I will document the basics of both models.  I will follow this article with a deeper dive on the terms that form these agreements.

When to use Collaborative Agreements

Before I get into the differences between IPD and SPE, we should specify why one would use one of these agreements over traditional contracts.

The AIA and other industry groups, recommend Collaborative Agreements because they create shared objectives between the Owners, the Architect, and the Contractor.  These agreements are also designed to stimulate collaboration between the parties by initiating the engagement earlier than traditional contracting methods.

The AIA recommends using collaborative agreements on large projects (defined as complex projects with a duration of a year or more).

In general, I would say that the industry likes these agreements because above all else, they promote collaboration.  Traditional contracts tend to create adversarial relationships between the Architect and the Contractor.  Whereas these agreements remove the terms that create tension between the parties and unify the interests of the team.

For Owner’s, this form of engagement has some very positive potential benefits, but as we will see later on, some of the terms that make up these agreements may make them difficult for Owner’s to accept.

That said there is more than one way to achieve the benefits of Collaborative Delivery and we will explore a method that uses traditional contracts in a future article.

Integrated Project Delivery (IPD)

An IPD agreement is a multi-party agreements which is executed by the Owner, the Architect, and the Contractor.  I should note that in my exploration of this topic, I have found variations on this where major sub-contractors are also parties to the agreement, but this is a deviation from the way the standard AIA agreement is written.

The agreement establishes certain time and cost objectives that all of the parties agree to.  These are called the target costs and target schedule.  Any changes to either schedule or cost must be agreed to by all parties.

The parties all agree to work at cost until the project is completed.  Profits and savings are calculated at the end of the project from the target costs and are then distributed among the parties at the end of the project.

Single Purpose Entity (SPE)

I first heard of the concept of a Single Purpose Entity 2 years ago when I reviewed the 2018 objectives of the Specialties Engineering Contractors (SEC) Group in the UK.

In response to the fall of Carillion, the SEC began lobbying the government of the UK for greater adoption of a delivery model they referred to as Alliance Agreements.

Single Purpose Entities and Alliance Agreements are essentially the same thing.

Under this contracting model the owner, the Architect, and the Contractor agree to form a new legal entity who’s sole purpose is to build the building.

The SPE agreement establishes a common schedule and a common budget for the parties. This is very similar to the way schedule and cost work in an IPD contract.  SPE’s also initiates early engagement between the parties and distributes profits at the end of the project.

The distinction between the IPD and SPE is that under SPE, the parties actually form a separate company.  The members of the Company then share in the Company’s risk and the Company’s rewards.

Employees from the Owner’s Company, the Contractor’s Company, and the Architects Company are then seconded to the new SPE under a staff augmentation model to support the Project.

I have been told by colleagues who actually worked under this model, that the tendency for the staff is to forget they actually worked for another company and assimilate to the SPE as if it were your employer.  This creates a sense of unity and the staff work collaboratively towards their common goals.

Closing

It would seem that the structure of these contracting models could have very desirable effects, but there are contractual compromises that you will need to accept in order to implement this model.

In my next article, I will share some of those compromises and share findings from several real-world case studies of collaborative delivery.

What about you?  Have you worked with these contracting models?  Did you have a good experience?  Tell me your stories.

Thanks for reading.  If you enjoyed this content, please feel free to browse my previous articles and please like, share, comment, and subscribe.  This helps promote my content and is greatly appreciated.

Advertisements

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.