Discussion: View Thread

At the 2016 AEI Forum, speaker David Odeh suggested while the project being discussed was a successful IPD project, there may be projects that chosing IPD may not be appropriate. Perhaps, AEI members with experience in this area can share their thoughts.

------------------------------
Moses Ling P.E.
Associate Professor and Undergraduate Program Officer
Department of Architectural Engineering
Penn State University
University Park PA

------------------------------

Choosing an IPD approach is an appropriate solution when collaboration of players is needed to add efficiency to a system, otherwise this may disrupt an established balance within that system. This approach has to have a clear defined question to be answered, so that efforts may loose focus and discussions turns into endless brainstorming sessions. Players have to be able to work independently, and choosing collaboration has to focus on keeping this balance in which each part of the system can restore its independence.

------------------------------
Rodrigo A. M. Pissarra S.M., ASCE.
Sao Paolo, SP, Brazil.
rodrigo.pissarra@...

Original Message:
Sent: 08-27-2016 11:28
From: Moses Ling
Subject: IPD - Why not?

At the 2016 AEI Forum, speaker David Odeh suggested while the project being discussed was a successful IPD project, there may be projects that chosing IPD may not be appropriate. Perhaps, AEI members with experience in this area can share their thoughts.

------------------------------
Moses Ling P.E.
Associate Professor and Undergraduate Program Officer
Department of Architectural Engineering
Penn State University
University Park PA

------------------------------

We've been discussing IPD for years, but have yet to see it fully implemented in any sort of "standard" way as we have seen other delivery methods implemented in the industry. Instead, we often see "IPD-ish" projects that use some of the IPD concepts without being a true IPD project. The link to the presentation I believe was referenced in the original post on this thread is here: Using Integrative Project Delivery (IPD) for Design, Fabrication, and Construction

The 5 tenants of IPD shown in the video (@ 7:17) are:
1. Early Involvement of Participants
2. Joint Project Control and Decision Making
3. Shared Risk/Reward based on Project Outcomes
4. Jointly Developed Validated Targets/Goals
5. Reduced Liability

The areas I've seen that tend to fall short on "IPD-ish" projects are #2, #3, and #5. Many clients like the idea of joint decision making, but also want the final say when it comes to decisions, in addition to limiting their own liability. There are often sticking points on the legal side of the contracts.

The video makes the case that complex institutional projects are ideal for IPD (a hospital project is used as an example). Additionally, the excellent point is made that there are large clients (for example the government) that have a mindset valuing competition above all, including but not limited to the best outcomes for the project. The video closes by stating that increased collaboration is becoming more and more the expectation, which is my experience also.

Yet, it seems to me that in the current collaborative environment, we as engineering professional services providers are sometimes giving away extra services (because in order to be more collaborative, more meetings, web conferences, phone calls, and emails really are required) such that the owners and contractors are gaining the benefits of IPD without the risks. A collaborative environment can be great, but it can also produce a "death by consensus" approach where team members - particularly the more inexperienced ones -  believe they cannot make a decision without running it by the group.

The IPD or IPD-ish approach requires very strong project managers for all team members. Team members must be able to both collaborate and maintain appropriate boundaries/scopes of work, which generally will require a higher level of advocacy for your own technical area of expertise than many engineers have been traditionally comfortable with. You absolutely must be able to explain why you made a particular technical decision to the team in a way a non-technical person can understand. This is one of the reasons I believe IPD was been slow to gain traction. Many firms (and clients) simply don't have strong enough managers to profitably manage the process, and/or are unwilling to create the levels of trust and transparency necessary to be successful.

​​​​

------------------------------
Stephanie Slocum P.E.
Engineers Rising LLC
------------------------------

Original Message:
Sent: 08-27-2016 11:28
From: Moses Ling
Subject: IPD - Why not?

At the 2016 AEI Forum, speaker David Odeh suggested while the project being discussed was a successful IPD project, there may be projects that chosing IPD may not be appropriate. Perhaps, AEI members with experience in this area can share their thoughts.

------------------------------
Moses Ling P.E.
Associate Professor and Undergraduate Program Officer
Department of Architectural Engineering
Penn State University
University Park PA

------------------------------

IPD depends on trust.  Unfortunately "trust" is not high in the construction community (I include consultants in this group). How often have you a consultant say, "The only way you can ensure that a project will give you what you want is to let the contractor to make money" or a contractor say "Pay the consultant what he needs to produce good documents, it will save you money".  When the construction community has a more trusting environment, owners may be prepared to trust consultants and contractors, IPD will be more common.  It is a good delivery method.

------------------------------
David Thompson M.ASCE
KTA Structural Engineers Ltd.
Calgary AB
(403) 246-8827
------------------------------

Original Message:
Sent: 03-19-2019 17:02
From: Stephanie Slocum
Subject: IPD - Why not?

We've been discussing IPD for years, but have yet to see it fully implemented in any sort of "standard" way as we have seen other delivery methods implemented in the industry. Instead, we often see "IPD-ish" projects that use some of the IPD concepts without being a true IPD project. The link to the presentation I believe was referenced in the original post on this thread is here: Using Integrative Project Delivery (IPD) for Design, Fabrication, and Construction

The 5 tenants of IPD shown in the video (@ 7:17) are:
1. Early Involvement of Participants
2. Joint Project Control and Decision Making
3. Shared Risk/Reward based on Project Outcomes
4. Jointly Developed Validated Targets/Goals
5. Reduced Liability

The areas I've seen that tend to fall short on "IPD-ish" projects are #2, #3, and #5. Many clients like the idea of joint decision making, but also want the final say when it comes to decisions, in addition to limiting their own liability. There are often sticking points on the legal side of the contracts.

The video makes the case that complex institutional projects are ideal for IPD (a hospital project is used as an example). Additionally, the excellent point is made that there are large clients (for example the government) that have a mindset valuing competition above all, including but not limited to the best outcomes for the project. The video closes by stating that increased collaboration is becoming more and more the expectation, which is my experience also.

Yet, it seems to me that in the current collaborative environment, we as engineering professional services providers are sometimes giving away extra services (because in order to be more collaborative, more meetings, web conferences, phone calls, and emails really are required) such that the owners and contractors are gaining the benefits of IPD without the risks. A collaborative environment can be great, but it can also produce a "death by consensus" approach where team members - particularly the more inexperienced ones -  believe they cannot make a decision without running it by the group.

The IPD or IPD-ish approach requires very strong project managers for all team members. Team members must be able to both collaborate and maintain appropriate boundaries/scopes of work, which generally will require a higher level of advocacy for your own technical area of expertise than many engineers have been traditionally comfortable with. You absolutely must be able to explain why you made a particular technical decision to the team in a way a non-technical person can understand. This is one of the reasons I believe IPD was been slow to gain traction. Many firms (and clients) simply don't have strong enough managers to profitably manage the process, and/or are unwilling to create the levels of trust and transparency necessary to be successful.

​​​​

------------------------------
Stephanie Slocum P.E.
Engineers Rising LLC

Original Message:
Sent: 08-27-2016 11:28
From: Moses Ling
Subject: IPD - Why not?

At the 2016 AEI Forum, speaker David Odeh suggested while the project being discussed was a successful IPD project, there may be projects that chosing IPD may not be appropriate. Perhaps, AEI members with experience in this area can share their thoughts.

------------------------------
Moses Ling P.E.
Associate Professor and Undergraduate Program Officer
Department of Architectural Engineering
Penn State University
University Park PA

------------------------------