Complex capital projects across all industries, from health care, oil, gas, mining, manufacturing and power generation all have at least one thing in common. According …
Yet Usually Ignores.
Project Managers for any type of project (construction, IT, new business service line, etc.) think they have control over many aspects of the project. Schedule, scope, budget, and plan all come to mind.
Where PMs don't actually have control, they seek to invent it through various tools such as meeting minutes and documentation, so they always have at their fingertips a "so and so told me on this date" which creates the illusion of control.
Usually what makes a good PM at first is a Type-A personality, one that seeks to check the box, document decisions, drive action, and deliver. When a project gets tough, this personality seeks more control by tightening their grip on the issues and people, often at the expense of the people involved in the project.
These mechanisms are reactions to the single aspect a PM truly can control - the expectations of behavior within the project team.
How people behave, interact, treat each other, engage, and work together when the PM is not around is the project culture – all set by behavior expectations.
Too often a project is created, the group is pulled together (not a team yet, just a group of people), and it's off to the races (hurry up! we have to do something tangible to show progress!). This results in an accidental project culture, where personalities of people and the groups they represent are the primary contributors to the accidental project culture.
This gambling can pay off on projects, and it also can destroy projects. If you have enough strong personalities that are seeking the right things, you may get lucky and have a good project culture.
If, and this is more likely, the drivers are purely statistics such as time and budget, strong personalities will allow excuses for bad behavior and poor treatment of people. Especially when the project team gets stressed the first time – then the “real” people show up, with all their learned behaviors of how to act, behave, and “solve the problem.”
Just look at any longer project – the project usually started off in a positive light, and many of the true undercurrents never saw the light of day. In fact, the team floated along in artificial harmony for many weeks or months or even years, never learning how to engage in real conflict, instead choosing to avoid it and instead behave like “professionals” and “respectfully challenge.” Then adversity hits and BAM – all those undercurrents, badly learned habits, and control take over. Many of us have been there – that moment when the project goes from fun to “the PM is just barking orders – I’m out.”
The question is - can you avoid gambling by focusing intentionally on the project team culture?
When a PM takes ownership of the culture he or she creates, amazing things will happen. Think about a PM who stands up and thoughtfully leads the project team through defining the project team behaviors. How will we treat each other? How will we measure ourselves and our culture? How will we develop an environment that allows us to call each other out when we are deviating from our desired relationships with each other?
When you take the time and devote effort to talking thru and collaboratively defining the culture the project team wants to embrace, you are setting the tone for the entire project.
You are putting people first, and the project second. When a PM puts the project over the team, the project will be delivered at the expense of the team. When a PM puts the team over the project, the project will benefit tenfold.
Control in project management is an illusion. Control over intentional project team culture - how a group of people interact, behave, and treat each other - is the only true control PMs have.
Kyle presented this content in a webinar on June 27th, 2018. A Recording of the webinar along with the slides is available here.
The most successful IPD teams can answer 3 questions:
- Why are we building?
- How are we building?
- What are we building?
Less successful teams eventually figure out what they are building and they may have spent some time determining how—but they never clearly understand why. After 10 years of structuring and watching IPD projects, we believe that “Why” is a critical first step and that IPD teams should work hard to understand the why and to communicate it continuously to all of the project participants.
By “Why” we mean the essential reason for undertaking a project. It is more than a program or a set of owner’s requirements. It is the problem or opportunity (or both) facing the project sponsor and reflects the value the project will bring and the values of the project team.
Understanding “why” is important to project success because:
- It aligns everyone to achieving the project goals;
- It establishes the criteria for decision making;
- It gives the participants purpose; and
- It provides standards for measuring project success (and sometimes compensation).
A good film is when everyone involved is making the same film. A bad film is when everyone has a slightly different film in their head.
Sir Alan Parker
One of the most dysfunctional aspects of traditional project delivery is misalignment and local optimization. Because participants are siloed and compensated based on individual outcome, there is little hope of routinely achieving outcomes that are optimized to the project. Even on IPD projects we often find that at project inception, team members may only generally understand the project’s principal goals. Getting everyone on the same page is one of the principal benefits of a values workshop.
Understanding the project values is a first step in taking ownership of the entire project. Unless an effort is made to understand and commit to the project values, solutions will tend to remain locked into individual specialties.
Alignment also allows the parties to work independently and concurrently. Even in a co-located project, many decisions will be made during independent work. But if the end goal is known to all, it is more likely that the individual decisions will be consistent with the overall plan and will harmonize with other decisions. This leads to better optimization and less re-work. If the parties don’t have this common understanding, they are forced to work sequentially to avoid rework. The time loss in sequential work—as well as the loss to creativity—then becomes a major source of project waste.
Participants committed to the same values will design and build the same project.
When your values are clear to you, making decisions becomes easier.
Roy E. Disney
In a traditional project, the builders execute what they are told to build. Success is achieved if they build it for less than the bid/planned cost, and thus make a profit. “Why” is irrelevant because they only need to achieve “What” which is given to them. Whether the project is a success is irrelevant from their perspective.
In IPD, however, “What” is not a given, but it is developed during the project. And because the builder is an active member of the decision making team s/he must have criteria for choosing among the many alternatives that are possible answers to “What.”
Consider the choice of a chiller under an IPD or a design bid build project. In both cases, there is some flexibility because the contractor is allowed, in most DBB projects, to provide a chiller that is “or equal” to the specified unit or that meets a specification. Final choices are not made until submittals have been made and approved. Whether DBB or IPD, decisions must be made—but the process and the role of “Why” is very different.
In the public project, the contractor contacts vendors and identifies units that meet or exceed the specification. The contractor then compares them, probably with regard to delivery time, ease of installation and most importantly cost. These criteria that relevant to the contractor’s personal profit. Note that how well the chiller performs (as long as it met the specification) has no value in this analysis nor will design options be considered that have fewer or no chillers.
In the IPD project, the alternative chillers would be evaluated based on whether they had differences relevant to the project ‘s values. For example, if life cycle cost was a key value, the contractor’s criteria would be considered, but they would be balanced against the life cycle cost of the alternatives. Durability, maintainability and energy usage would become important factors. If sustainability was a key value, the team, including the contractor, might not only consider chiller alternatives, they might consider different building orientations, insulation, lighting strategies, windows or other factors that might result in reducing or eliminating the need for the chillers—or some of them. In the IPD case, the project values directly relate to the decisions to be made.
Thus, to make decisions in IPD, you need to know your values.
A compelling team purpose is clear (which orients the team), it is challenging to achieve (which energizes the team), and it is consequential (which engages the full range of members’ talents).
Research on team motivation (and common sense) tells us that we like to feel that the work we do is valuable. Moreover, we are social animals that feel better when we identify with a group. Having a common purpose makes us members of the tribe and knowing that what we do is both useful and valuable gives us purpose. These factors lead to deeper engagement and more productive team members.
By defining and jointly agreeing on values we satisfy both purposes. By committing to the common goals, we identify with the group. We are all “insiders.” By having a positive purpose, such as building a school or hospital, we gain satisfaction by knowing our work is worthwhile. Even if the project is solely about creating a profit making venture, if we have an understanding of the full project, we have the satisfaction of whole and complete work.
Common values engage our hearts as well as our minds.
Standards for Success
What you measure is what you get. Period.
If what you measure is what you get, you best be very careful with what you measure. One of the reasons we get misalignment in traditional project delivery, is that our measurements—and our compensation systems—measure individual and not group outcome. The surprise is that we are surprised by the result.
If our values reflect what we really want to happen, shouldn’t we measure against our values? Even if we don’t directly tie the values to compensation (and that can be complex), if we track progress against values we will be much more likely to achieve them. Which takes us back to the beginning, because if we are going to measure against values, we really, really, need to know what they are.
When we run project or contract workshops we almost always include a segment on defining values. At a minimum, this is a several hour exercise that gets project participants working in small groups with other team members. We use the exercise as a learning moment for team dynamics and management, but the real purpose is to develop the project values. Interestingly, the workshop participants often remark that the value exercise was the most valuable (sorry about the pun) element of the workshop.
We have a methodology for running the workshop, which we believe works well, but the point is less how you define values than whether you do so. As long as you engage the right people in the process, avoid overpowering the quieter voices, and gain consensus on values, then you have made progress.
Once you have values, use them! Values can be used to develop specific goals. Specific goals can lead to developing tactics. And project management should regularly score the project against the goals. Do this and you will have a “star to steer your ship by.”
This post was originally published at hansonbridgett.com.
We are often asked whether negotiating an IPD agreement takes longer than negotiating a traditional agreement, such as a construction manager at risk contract. The answer is probably “yes”, although that answer is incomplete.
A better answer, would be that negotiating and crafting the IPD agreement is an important step that increases the likelihood that a project will be successful. Although we have long believed this, it was recently confirmed in a superb set of case studies published by the University of Minnesota. One of their “takeaways” was that “For the teams who were heavily invested in developing the contract, the contract discussions were structured to serve as training about IPD, and the teams believed that this contract-development process formed the foundation for trust, respect, and collaboration”.
We believe this alignment function supports the common understanding necessary for collaboration. In addition, during negotiation team members first learn and demonstrate how they will work together. For these reasons, contract negotiation is often the team’s first collaborative act.
Negotiation is the test drive
The quality and chemistry of the project team—including the owner—is critical to success. It is fairly easy to evaluate the experience and competence of team members—a good proposal and interview process should garner most of the needed information. But assessing the ephemeral qualities is more difficult. How well can the team work together? Can team members put project interests above their own? Are they transparent? Will they freely share information? Will they create the communicative environment necessary for innovation and creativity? What will the team members do when the going gets tough?
It is easy to be collaborative—or at least profess collaboration—during the interview process. The prospective team members aren’t faced with thorny problems with real consequences that can only be solved by putting the project ahead of their own interests. The rehearsed and polished presentations sparkle, but they are like a first date where everyone strives to make a good impression and carefully masks their less appealing qualities. But when you start to negotiate the contract, you get a glimpse of life after the honeymoon.
What you hope to see in IPD negotiation is a perceptive blend of personal and group interests. The basis for this IPD negotiation mindset was neatly modeled in the bar scene in the movie, A Beautiful Mind. Russell Crowe, playing Nobel Prize mathematician John Nash, had a breakthrough moment when he realized that he and his friends would have better dating success if they each did what is best for the group as well as best for themselves. The best outcome didn’t come from pure competition, (every man for himself) but from collaborative negotiation. In the same way, IPD negotiation is not selfless, but it does recognize that putting the project first while considering individual interests optimizes everyone’s outcome.
We often see negotiators that either understand this implicitly, or quickly have their own breakthrough moments. When faced with a negotiation problem, they try to understand the different viewpoints and interests and jointly develop a strategy that respects everyone’s legitimate interests. These firms will be good participants and partners throughout the project.
Less often, we see firms that can’t see beyond their own self-interest. These firms are happy to get new work but don’t really understand the IPD process. They can be mistrustful and view the negotiation process strictly from their own perspective. They can’t (or don’t care) to understand other’s legitimate concerns. When they realize that collaboration is contractual—that they will be bound to the project and to each other, they get nervous, defensive and then balk or try to skew the deal in their favor. And if this is how they act during the honeymoon, just think how they will act when the going gets hard.
Another problem exposed during negotiation is the power of the home office. We see this occurring when the local principals can’t make decisions because they must get approval from a senior decision maker who is distant from the project and is not committed to collaboration. In other instances, corporate policies (that might be irrelevant in an IPD project) can’t be modified. A corporate culture of home office control undermines the rapid and reliable decision making required by IPD.
We have had several instances where the negotiation process resulted in resetting the team. As doubts arose about the suitability of a team member, the team engaged in serious discussions to determine whether the non-collaborative participant really wanted to work on the IPD project. In some cases, this resulted in an “attitude correction” and in other cases, the firm left the IPD project and was replaced. Although these weren’t pleasant situations, it was far better to resolve them before the project was underway than it would have been if discovered later.
So, returning to the initial question. Does it take longer to negotiate an IPD agreement? Yes, because you are doing the real work of determining whether the team can work together. In our normal process, negotiation includes the team jointly assessing risk, opportunities, targets and distribution of responsibilities, i.e., figuring out how to work together. Contract negotiation is the test drive, where you get the opportunity to really see the team in action and to make changes before it is too late.
Negotiation Aligns the Team
We explained in Values First the importance of understanding why a project was being done and agreeing on the key values that will guide the project. Negotiation of an IPD contract, if properly done, addresses why the project is being undertaken, how it will be done, and what the team wants to accomplish. In short, it is a critical step in team alignment. In our workflow, the contract doesn’t lead this process, it follows and documents it.
The flowchart below lays out a generic approach from initiation to execution of an IPD agreement. Although it includes development of the IPD contract, it also has key workshops to develop the business and contract model, refine the model with the team, and jointly negotiate the final terms. In a 2-day contract workshop, easily one day is spent on training and alignment.
One observation from many contract workshops is that if the training/alignment is done thoroughly and well, the actual time spent negotiating the “legal” contract terms is greatly diminished. In one notable project, we held the project kickoff prior to the contract negotiation session because of scheduling difficulties. I withstood many frosty stares, when I announced to the lawyers who came ready to advocate for their client’s interest, (complete with binders bristling with tabs marking “major issues”) that we might get to contract language on the second day. But on the second day, after training and alignment, the lawyers told us that with this better understanding, they had very few comments to make. Had we started with contractual language, the legal side of the negotiation would not have gone so smoothly. Since that experience, we prefer to have training and alignment precede negotiating the IPD contract.
Negotiating the IPD agreement is hard, but valuable work. If done correctly, it starts teams on their collaborative journey and helps align them to the project goals. Moreover, it gives each participant the opportunity to learn who their potential partners are while the stakes are still low. If you could skip this by just signing a form contract with others that you had just met, would you really want to?
 It is incomplete because we often are negotiating with multiple key trades and consultants at one time, whereas in a traditional project these would likely be independent and sequential negotiations, that can take more effort. But as that isn’t the key point of this article, we will not worry about this detail.
 Cheng, R. et al, 2016. Motivation and Means: How and Why IPD and Lean Lead to Success. Place of Publication: University of Minnesota. <http://arch.design.umn.edu/directory/chengr/>
This post was originally published at hansonbridgett.com.
Tri-Party vs Multi-Party IPD contracts.
The tri –party agreement is certainly a step in the right direction by combining the 3 most influential parties in a building project, the Architect (A), CM/GC (C) and Owner. This can certainly help align the major stakeholder interests to one goal and dramatically reduce the finger-pointing of a traditional contract model. The multi-party agreement casts a wider net over the key trades and design partners as well. I have seen as many as 17 partners on one contract with the average being closer to 8. A key to making this determination is to understand what behavior a team wants from the trade partners (design and build).
Tri-Party Agreement – A contract where the owner, primary designer and primary builder execute a single contract for delivery of a project. Other partners for design and construction may be bound to the same terms as the primary signatories yet they do not sign the base agreement.
Multi-Party Agreement – A contract where the owner, primary designer, primary building and other key parties to design and construction execute a single contract for delivery of a project. Each member that is bound to the terms of the agreement is a primary signatory with at least 4 signatories and as many as the team chooses to include in the contract. (this is sometimes called a Poly-Party Agreement)
If your desire is to offer trade representation and a voice in: establishing and managing target cost, developing and managing risk and opportunity, procurement strategies, design packaging, operational efficiency management and contingency management, consider how this looks in each case.
IPD contracts contemplate consensus decision making to optimize the project for everyone involved. A tri-party agreement will typically have a 3 member management team and a multi-party will have as many as are signatory to the contract (8 on average). A tri party may seem to offer easier consensus, but often times the answer is not in the room and the principles must reach out to the extended partners anyway. The most affected parties should always be consulted.
The most important thing is to find a way to elicit input from trades in a meaningful way. If they are equal partners they are more likely to participate.
If your desire is to offer partners equal say in design, participate in the BIM, and to learn about and affect the work of others, the more equal partners the better.
A multi-party agreement breaks down traditional communication barriers. All parties are responsible to gain their own knowledge and information rather than funnel it through 1 party to many. Various subject matter experts can speak directly to their partners. Often this makes the A & C feel a loss of control, but the right parties with the most knowledge are making the decisions. Contracting directly with more than just the architect and the contractor helps empower the partners to speak more freely, improving communication.
Establishment and Management of Targets
If you want the trades to inform design, to meet a target cost, to confirm constructability coordination, to participate in schedule planning for the entire project, to shift scope beyond traditional boundaries, to improve outcomes, to strive for continuous improvement, to be responsible for complete implementation not just what is on the drawings, and to tie their outcome to that of the rest of the team regardless of individual outcome, bring them to the contract table.
Targets are established by the parties and memorialized at signing this multi-party contract. This brings bore visibility and ownership by trades over the target and adjustments thereto. The multi-party agreement breaks down the barrier of trade to engineer (specialty consultant), creates tension between design and cost in search of the best solution, and empowers trades to assert cost authority until consensus.
If you want the trades to: influence the sequence of work for the best project outcome sometimes at the cost of their own productivity, to accurately predict duration of tasks and comply, to negotiate task handoffs, to manage and optimize work flow amongst all participants, and to assume field leadership for all personnel not just their own staff, then offer them the authority to do these things.
Traditional Architect and Contractor roles can be shared, distributed, assigned to partners to allow distributed leadership. The GC doesn’t need to manage the Trade Partner but relies on it to behave equally.
The industry for many years has treated the trades and designer consultants as Subordinate to the prime and they have learned to behave that way. A tri-party is not going to change that relationship or behavior. If you want the trades to behave differently you must start by treating them differently. A great way to do that is empowering them with equal status to the others on the project.
One might think negotiating with 8 parties at one time is much more complicated than with 2, but my experience is quite the opposite. When you gather 8 firms around the same table it often helps drive a much fairer contract all around. With 8, it is really difficult for one party to try to gain advantage for themselves. In the tri-party, both the Architect and Constructor have to quickly turn around and contract with their “sub-contractors” but have far less latitude to address specific terms as they have already been established with the owner. This leaves the sub-tier with an almost take it or leave it approach.
There is a bit more “cat herding” required with more parties to a contract to ensure all comments and changes are considered and managed timely. There may also be some trepidation with sub-contract tiers and their understanding of their ability to influence a traditional customer while still carrying the risk of each other. This is a required education regardless of tri-party or multi-party agreements, so take it as an early challenge to gain the benefits and behaviors described above.
The trades and the sub consultants provide major portions of the project deliverables, why should they not be properly represented at the contract table? The outcomes far outweigh any education needed at the outset. Be prepared to challenge and change traditional relationships and build a new culture.
This post is the 2nd of a 3 part series looking at Integrated Project Delivery. The first post focuses on IPD agreements (contracts), this post focuses on IPD as a Lean Operating System, and the final post focuses on culture.
When a team is aligned financially, traditional operating systems are not efficient for strong team performance (note: the operating system development starts with the earliest negotiations of the contract.)
To maximize the value of the contract structure, teams require a new work philosophy focused on efficiency and reliability. A Lean Operating System delivers customer value, through streamlined processes practicing continuous improvement.
We will focus on lean processes and tools for each part of this definition first by looking at ways to define and document customer value, then at processes for efficient value creation and finally at feedback systems to allow for evaluation and systematic improvement of processes used by project teams.
To successfully deliver a project with minimal waste, the project team must clearly define the customer’s expectations.
IPD teams are included at the start of a project, often prior to finalization of the owner’s business case. Understanding why a project exists prior to developing conceptual designs, teams have freedom to explore diverse options to deliver value. The final business case, budget, schedule, and program are captured in a collaborative report called a Validation Study.
Set Based Design:
Traditionally, teams look to make decisions about options before detailing them. Set Based Design is a concept of advancing multiple designs in order to make the best decision based on additional information gained from further design development.
Instead of picking a structural system for a new building prior to detailing it, a team may advance three systems into the Design Development phase along with floor plans and shaft layout. By continuing to advance multiple sets, the team can make a better decision with significantly more information. This process also reduces or eliminates negative iterations that occurs when one of the options becomes unviable.
An A3 is a structured process of documenting a problem, options, proposed solution, and action plan on a single sheet of paper (A3 refers to a standard 11”x17” paper).
Developing an A3 is done collaboratively with all stakeholders. The process generates consensus around the proposed path forward by first gaining consensus around the problem statement. You can learn more about A3 here.
Choosing by Advantages:
Choosing by Advantages (CBA) is a systematic decision making process developed by Jim Suhr which focuses on advantages of options. While most systems focus on pros and cons, CBA removes cons by recognizing that a con can also be expressed as an advantage for one or more of the other options.
CBA works well to gain consensus with a large group of people with differing goals and values. The system also makes the decision-making process more transparent and more collaborative. With CBA, the advantages and the cost are shown separately so that the team can see the cost vs advantages trade-offs of their options. You can learn more about CBA here.
Traditional processes for communication and accountability contain inherent waste, leaving much room for improvement. Integrated teams are driven to work in a manner that levels workload and reduces waste.
Last Planner ® System:
IPD teams use the 5 connected conversations of the Last Planner ® System to manage activities from early feasibility studies through construction and commissioning. Projects are started with high level milestones, then phase pull plans are created as the work proceeds. Look ahead planning, weekly work planning, and learning (measured through PPC and variances) are implemented to manage the weekly work of the team.
To better align teams and remove barriers to collaboration, large IPD teams use a single office space, co-location space, for the owner, designers, and builders. There may be people from 5 to 15 or more companies all working together in this shared office environment.
Smaller projects will develop a way of working collaboratively in shorter sessions (ex: 1 day every two weeks) or through online tools. Designers and builders work directly with each other in an effort to break down traditional silos.
Building Information Modeling:
Many complex projects use Building Information Modeling or BIM during design and construction for coordination, prefabrication, scheduling, cost estimating, and facilities management. Smaller projects may not use the full capabilities of a multi-trade model, only designing the architecture in 3D.
Teams start with a discussion of what elements of BIM will be used on the project. This collaborative discussion between the owner, designers, and builders focuses first on desired outcomes (risk mitigation, prefabrication, operation efficiency, etc), then which elements and systems will be modeled (level of detail, etc).
With an integrated team, flow and control of information can still be wasteful. Teams implement a central point of storage for each type of project information, usually a cloud based documentation platform with a systematic naming structure.
Processes for using and sharing project information are developed by the team, documented and displayed for members to review.
High performing teams maintain a commitment to continuous improvement. Teams are self-aware of their processes and breakdowns, allowing them to reflect and improve.You can learn more about Continuous improvement here.
Teams create a feedback loop by implementing 4 steps in series: Plan, Do, Check, and Adjust. A process is implemented with an expected outcome. The actual outcomes are measured against the expected outcomes. A deep dive is done to discover the drivers of the measured variance and a countermeasure is integrated into the revised process. You can learn more about PDCA here.
To truly understand the root cause of a deviation from the expected outcome, teams implement a process called 5 Whys. This process involves asking Why 5 times, each time drilling down into why the previous activity occurred. The goal of this process is to arrive at the driver of an issue, to treat the cause and not just symptoms of a problem.
A specific way to drive positive change is to implement a plus/delta improvement cycle. A team takes 5 minutes or less to capture Plus / Deltas at the end of each meeting and event.
- Plus: Something that went well and should be repeated.
- Delta: Something that didn't go well and should be changed or altered next time.
Teams assign each delta to a specific individual with an action plan and commitment for completion. With a commitment to identifying and adjusting deltas, processes will improve over the life of a project or team and lead to outstanding results.
Aligning teams with a contract provides motivation to collaborate but does not guarantee it. A Lean Operating System is needed to remove traditional silos, speed up communication, and reduce rework.
While Lean processes are integral to successful projects, they don’t work without a collaborative culture, which is the topic of the next blog post.
James Pease will be presenting this content in a webinar on May 3rd. REGISTER HERE
This is Part 2 of a 3 Part Series on Integrated Project Delivery.
See part 1, The Contract
A recording of Part 1 is available here: View Part 1
This post was original published on the Lean Construction Blog.
How validation fixes the problem you didn’t know you had.
The construction industry hides a dirty secret. It hides this secret from the public, it hides this secret from the owner, and worst of all, it hides this secret from itself. It is a known and accepted fact that the majority of projects are delivered late, over budget, or both. So what is the secret? In the industry, even construction “successes” are usually failures!
In the construction industry we say that there are three primary measures of a capital project: schedule, scope, and budget. A recent survey of owners by Dodge Analytics found that over 70% of capital projects were late, over budget, or both, meaning that only 30% of projects are on time and on budget.
In a critical oversight, but sadly not a surprising one, the owners in the survey were not asked if they had received the original scope they requested. The unfortunate truth is that even when projects are on time and on schedule, the owner often does not receive the original project scope.
This is the dirty secret of construction. We don’t measure or report how effective we were in delivering the original scope of a project. While there is a natural process of refining scope while designing a project, that is a different exercise than having to modify or eliminate scope in later design phases for the project to meet the budget. Unfortunately, this can severely impact the way an owner operates a new facility, harming their ability to turn a profit and extending the time needed to repay the capital cost of the building.
You would never see a news clip that states “the hospital was delivered on time and on budget but a wing of beds was shelled because it was the only way to get back on budgetl.” That shell space would be portrayed and sold as “growth,” when in reality, the scope is simply kicked down the road to another capital project cycle.
Fortunately, there is a solution! Lean thinking tells us that we should never begin an activity that we cannot finish. This applies to capital projects in that a project team should never begin work until the program, schedule, and estimate are set.
Far too often the design process is used to define the project, an inherently speculative (read: wasteful) process, inevitably leading to value engineering (read: scope reduction) – the key ingredient for a scope failure. A number of owners with active capital facility programs use a process called validation to avoid these pitfalls.
Taken in the lean context, a validation exercise determines the scope of a project and establishes the conditions of satisfaction that govern how the team will deliver it. This is accomplished by assembling an integrated team of stakeholders who work collaboratively to refine the program, the base design as reflected in a working estimate, a project schedule, and a pro forma that describes the target business plan and schedule for capital facility ROI.
Functionally, the team proposes alternatives that are run through a validation cycle. The owner may ask for a surgery center with four operating rooms. The designers develop a functional program and test fits that are priced and scheduled by the builder. The owner plugs the schedule and cost data into the pro forma to test payback against the business plan. The team then undertakes alternatives to improve various aspects of the cycle. One fewer operating room would cost less to build but would extend the payback while an additional operating room would cost more to build but would increase operating capital.
After multiple, rapid cycles of validation, the team settles on a best value solution that the team can deliver on time and on schedule. Most importantly, the team will deliver a facility that the owner can afford and that meets their operational objectives. Full scope, delivered on time and on budget!
The sound lean thinking in this approach is reflected by the fact that project delivery becomes a task of execution rather than one of exploration. There is no question that the team will need to work hard to deliver scope, with myriad design decisions required to achieve the conditions of satisfaction. But seeking how best to deliver on design intent is a different kind of exercise than seeking to uncover the design intent.
As lean thinking permeates the construction industry, scope must become a stated measure of success. Right now, we need owners to demand that teams accept scope accountability. Scope failure must be seen as project failure and validation is the remedy!
An Australian Perspective on Integrated Project Delivery
In many parts of the World, contracting can seem like the modern-day equivalent of a Roman gladiatorial battle, where a single project cost blow-out can end a promising political career or bankrupt a once profitable company.
The Rules of the Game
The rules of the contest are set out in the construction contract and rival teams of lawyers seek to negotiate their side an early advantage in the battle to come through the introduction of carefully crafted indemnities, notification regimes, liability caps and risk transfer, with little or no consideration as to whether the party that ends up liable for a risk is best able to manage it. This process commonly results in a Zero-Sum game or a game where one only party can win at the expense of the other.
There are however growing signs of battle fatigue as contract directions and awards are increasingly fought in court, tying up resources on both sides and leaving even the winner with a large legal bill and potential reputational damage.
Owners seek better value from projects and Architecture, Engineering and Construction (AEC) companies desire greater certainty for their shareholders.
Step forward Integrated Project Delivery.
If implemented correctly, Integrated Project Delivery (IPD) contracts can deliver a project win for both the Owner and the AEC companies.
How is that possible?
Under an IPD model, value (from the Owner’s perspective) is carefully defined and the AEC team engaged early in a project’s development on a multi-party contract that incentivises delivery of the defined value. This contrasts with a traditional contracting model where each party contracts separately, either with the owner or main contractor and is purely focused on delivering value for themselves.
Under an IPD model, the AEC team are reimbursed their actual costs incurred on the project based upon agreed cost rates plus an agreed Fee for overhead and profit. This reimbursement model, coupled with a shared risk contingency pool provides a greater degree of certainty in respect of the AEC team’s financial return.
An Australian Perspective
On the face of things, the IPD contract model seems very similar to Alliance contracts that have been used in Australia for nearly 20 years. Both are multi party collaborative contracts that reimburse the participants based upon their agreed costs and incentivise them to achieve value for the owner. If IPD contracts are to be successful it is important to review the reasons why, in twenty years, Alliance contracts have not become more widely used in Australia and beyond.
With Alliances all participants agree to a ‘no blame’ culture and the contract specifically precludes any party seeking legal redress for any lack of performance by another. This can lead to a situation where it is not possible to adequately address a party’s poor performance and the performance of the Alliance as a whole suffers.
This is not an issue with IPD contract forms as they contain provisions that allow the parties to seek legal redress for a party’s poor performance which should provide a big enough threat to ensure performance without any need to follow through with action.
The Alliance delivery model has been a victim of its own success with early government funded projects coming in significantly under budget and the AEC team sharing the under run. The fact that the owner also shared in the under run was overlooked and there was a perception amongst the general public that budgets had been set too high.
Recently, there have been attempts to address this issue through the introduction of mandatory independent third-party reviews of budgets and ‘competitive alliances’ where two teams work independently to develop an initial design and budget with a winner chosen (based upon overall value) to move forward to the construction stage.
There has also been a lot of work done to refine the incentivisation model to allow for any share of saving payment to be modified by the team’s performance against other non-cost key result areas in terms of value to the owner- something that IPD contracts to date have not allowed for.
On the flip side, under traditional Alliance forms, the maximum downside for the AEC team if the project budget is exceeded is the loss of their Fee, Reimbursement of all agreed costs incurred is guaranteed which can again seem like the AEC team does not have much skin in the game.
This issue is addressed in some forms of IPD by the introduction of a Guaranteed Maximum Price which places a limit on the amount of agreed costs payable to the AEC team.
Whilst some Alliance forms include provision for sub-alliances, the Alliance team rarely comprises more than the main consultants, designer, owner and main contractor. Any further required trade contractors or speciality consultants are engaged using traditional forms of contract. This limits the
extent of possible collaboration and therefore benefits that can be obtained.
IPD forms of contract allow for greater engagement with the wider supply chain on a collaborative basis.
Alliance contracts do not generally mandate any elements of Lean Construction such as Building Information Modelling (BIM) or Pull Planning thus missing an opportunity to improve overall value to the Owner.
IPD contracts, provide an opportunity in Australia to address the issues with the Alliance form (perceived or otherwise) and reinvigorate collaborative contracting as a delivery model which in turn can provide a foundation for the adoption of lean construction principles and processes.
Elsewhere, Australia’s experience with Alliance contracts can be used to further refine and improve the IPD model in order to allay any concerns with its use and to accelerate take up.
A win- win in the move towards win – win project outcomes!
Zul- Is soft cost for IPD much higher than design-bid-build? Does the savings in rework or hard cost able to pay off the added soft cost?
James– There is not a black and white answer to this question. The biggest difference I think is that you are spending more of your soft cost upfront. When you are hiring the contractor early, you are investing in your RFI process during design instead of doing it later. So, you are spending more money upfront, from a cash flow point of view and you are also making a lot of detailed decisions much earlier than you typically would. One thing that we have learned that CA cost is not dropping off though, we are still paying for CA and in many cases for more CA because it benefits the construction to have more people on staff to answer questions really quickly. We are co-locating our CA staff, we are having them on site with dedicated chunks of time throughout the week to answer questions. In design-bid-build you try not to pay as much for CA and having them stay in their offices to answer RFI’s through emails.
Does the cost pay off? My belief is that it does.
On our big projects what we had seen is before going with IPD, anything over a $100m we delivered significantly over budget and significantly late. Since adopting IPD we have delivered $1.9B projects collectively 3% under budget. One of the projects went over but the whole program was under. We currently have $2.9B projects that are 75% through construction right now and tracking at 4% under. So what we are finding now is that if we give our board a number, we can actually make it happen. Then it’s up to the board to decide whether they want to fund that project or not. The problem before was that we would take something to the board and they would say yes we want to do that and then halfway through we would say you know what we can’t actually do it for that much and it’s gonna be late and you can’t stop at that point- you’re stuck. In IPD a lot of times we find out early that its going cost a lot more than what we thought it would and the board would say we are not going to fund that project if it costs that much- in a way that is an acceptable outcome.
In order to maintain affordable care for our patients yet grow access, we need to maximize the quality and quantity of facilities that we can build within the capital that we have available for investment.
Zul- Do you see less RFIs in IPD?
James– Yes, we have streamlined RFI processes by letting the team discuss a solution first then document it rather than shooting RFIs as soon as the issue is raised for every little thing.
Zul- What are the specific challenges for the owner, designer and contractor in IPD compared to design-bid-build?
James– For the Owner- a lot of our users, our doctors, nurses, executives are pushed to make decisions much earlier because we want to design every little drawer before we submit for permit as everyone wants certainty on cost. But they are used to waiting, saying I don’t want to make that decision until right before I move in. We’re asking them 3 or 4 years ahead of time to make decisions. That is a challenge for us and we’re figuring out how to work through that.
There are also challenges like benchmarking cost because you are not bidding the project. We get questioned a lot about how do you know that is the right number- it seems too expensive! So we’re working on better benchmarking and better conceptual estimating so we can know roughly how much the project should cost. That way we can be more comfortable with our team setting the target value- we’ll say this is what it should cost and we’ll make it work for less than that.
For the designer- I think the big piece for them is they are not accustomed to having good trade input upfront, so they are not totally sure how to use it yet. I find they still end up drawing things that eventually get redrawn and we’re constantly reminding them just call the trades and ask them for the real info.
I also see that a lot of architects who have been around in hard bid environments try to control quality of work by putting in a lot of stuff on the drawings. We are telling them you don’t need to draw that stuff, we already got the people on board, just tell them what your expectations are so that they can draw and price it appropriately. We’re telling the engineers don’t draw the framing details, just ask the framer and give him your design criteria and he’ll draw it for you.
Its changing the way the designers work with the contractors and I find they still very much want to say “give us three months we’ll go away and we’ll figure it out and then come back and show you.” We say- no you need to be more iterative and open book.
On the contractor side- one big thing that we need is conceptual estimating. We are bringing people in early and we’re saying things like “how much should this hospital cost?” And they are say okay, “give us the drawings and we’ll price it.” But we don’t have any drawings yet. We just want to know how much should it cost? There are a lot more of rules of thumbs like cost per sqft vs linear ft, this kind of skin system vs that kind, because we are using cost as a part of our design criteria. So before you draw anything, tell us what we can afford to buy. That’s challenging for the contractor.
Zul- To what extent do the designers need to use BIM?
James– They don’t have to use BIM. If it is a smaller project- it may not make sense to use BIM. If it larger than 20,000 sq ft ground up building then it works.
BIM is used as a natural risk mitigation tool. The team may say our profit is at risk, we’re going to need to model the thing so we can make sure that it would all fit. We ask the team to develop a BIM plan at the beginning of the project. This way they don’t say you haven’t told us that we had to model that project. We say, we are not going to tell you what to model, you look at what your risks are and come up with a way to mitigate that risk and if BIM is a way for mitigation then we’re willing to pay for it.
Zul- How do you see leadership fit into IPD?
James– leadership is hugely important. This model is not about telling people what to do, it’s about figuring things out as a team. It does take people stepping up and proposing solutions and then taking actions. A lot of people think that IPD is a way for the owner to do less work and transferring a lot of risk to the contractor and the designer. Our finding is it is actually more work for the owner. Owners needs to roll up their sleeves and be more involved. I think where people in IPD get into trouble is when they tell the team to collaborate and they don’t show up. Then the project fails and then they say- IPD doesn’t work!
That’s what I’m going to discuss in my upcoming webinar on Feb 8, 2018.
Again, for the owner- if you are going to go with this model then you need to be not only a leader like you need to know how to lead the team, but you also need to do your equal part. Show the team that you are also vulnerable and transparent. If you want them to be transparent, you need to show them your budget, you need to show what your constraints are, explain why sometime you may not have an answer. A leader doing that- that’s a good tone for the rest of the team. It is about both recognizing top down leadership and encouraging bottom up leadership.
When you see someone stepping up, say loudly- that was awesome, do it again!
We continually allow people with junior titles to take ownership of things. And then you are amazed, because they get really good results! For me that part is really rewarding when you see people on your team promoted within their own company through the project team advocating for them.
The first IPD project I did was 9 years ago after a lot of lump sum work. When I finished, I thought “that was awesome! I want to do that again!!” I’m still friends with people I worked with on that job!!!
Zul- Would you like to add anything?
James– It all sounds too good to be true. I want to make sure that people understand that it is hard work and it takes a long time. We find building a big collaborative team, like if you are building a hospital, it takes between 12 to 18 months to get the culture to a really collaborative point.
The other thing that is really hard for contractors, owners and architects is to say no I can’t do that. There is a tendency in the industry to say yes to everything even if you know you can’t do it. We would much rather people say they can’t do that or you can do that but there are all these constraints that you need to be aware of. Then you can make realistic decisions.
It’s hard, not easy- but if you are willing to do the work then you get pretty awesome outcomes!
That’s where we ended the interview by thanking James Pease. Read Part 1.
This post is edited for clarity and vetted by James Pease. He can be reached at firstname.lastname@example.org
This post was originally posted at Leadership for Quality.