Unleashing the Power of "Prediction" in Strategic Planning

Top Blog of 2013: Reprint

Let's say 10 people are invited to propose how they would execute taking a trip from New York to LA. The goal is to leave NY and be in LA in 7 days (to deliver a letter for some kooky eccentric who makes-up odd challenges). Each competitor would propose details of their planned trip and would sign a contract to deliver the letter.

What would influence the path and pace of their individual routes? Let's say each person had only $1,000 to spend toward the trip. Does the mode of transportation change? Let's say each must visit at least one National Park along the way (more than one park visited earns a 'tip'). Do the routes change? Let's say that each had to spend at least one day photographing a "national landmark" along the way (more than one photographed earns another 'tip'). Does the 'itinerary' change?

Of course each 'proposal' would likely be different, there is a thousands ways to get from NY to LA and dozens of National Parks and landmarks along the way...any way. So how would the 'eccentric' and 'tripper' form a contract for said service? What would be the contract basis? Would it include maps with highlighted routes, circles and arrows indicating parks and landmarks, timetables down to the minute for breaks and sleeping arrangements, taxi schedules at airports or automobile refueling locations? (sounds like plans & specs to me)

Or would the contract simply restate the expected outcome detailed above (the "problem statement")...7 days, be in LA, deliver letter, submit proof of parks/landmarks...ready, set, GO.

If we apply this concept of "expected outcome" to a building or infrastructure project, we have established that "satisfying" the "problem statement" can be the basis of the contract. In other words, solving the owner's "Problem Statement" replaces the designer/builder's "Proposed Solution" as the contract's scope-of-work.  The designer's and builder's detailed "solution" to the problem statement is important, but does not change the ultimate goal of satisfying (i.e. resolving) the owner's stated "Problem".

Since the "final solution" provided by the designer/builder (through the execution of the contract) must satisfy the owner's "problem statement"...maybe we don't need to actually know the "solution" before we award a contact and move the schedule along. Maybe we can "qualify" the designer/builder based on skill, knowledge, understanding, experience, or better yet, based on unique risk elements of the project at hand. Imagine the time and resources saved by such an acquisition process...a contract that lets the design/builder "figure it out" as we all go along. This would really reduce the "proposal cost" and "stipend" discussions."Prediction

Sound spooky?...bet your "traditional drawings & 16 division specifications" it does. Why is it spooky...CONTROL. Specifically the owner's traditional "outcome control" has been violated. To date most (and I mean most) owners cannot conceive of a reliable acquisition process that allows them to "control" the "project outcome" in any other way than via plans & specs, and "their decisions" made relative to said plans & specs.

So it's MY problem?

If you are a "project owner", ask yourself how many times have you been up to your elbows in "design & construction decision making", working side-by-side with your designer, sweating out the answers to endless questions, recording them in volumes of 'contract documents', making them the basis of the contract, intended to 'clearly' guide the builder, only to be disappointed when halfway through construction things change and you become the "hinge pin" to moving the project forward (usually accompanied by a Change-Order, or 2, or 3...). How on earth does the path to "their solution" become "your problem"? To borrow from Steinbeck: "The best laid plans of mice and men often go astray".

The trick for the owner is simple: create a contract in which measurable results define the scope and define success...pay only for results i.e. success...and allow (no wait...empower) the designer/builder to do what ever they want to achieve the contracted "results".

I don't mean to suggest by saying "their solution" and "your problem" that collaboration is not essential to a project's successful outcome. But I do suggest that "decision-making by committee" is a wasteful and unreliable process. Ultimately every contract must "obligate" a result. And I am not suggesting that the owner is not intimately involved in assisting the designer/builder in satisfying the problem statement of a contract. But "deciding" the elements and details of the "solution" is not the responsibility of the owner...the architect is not a draftsman for the owner's ideas, nor is the builder the owner's labor force for its execution. Mr & Ms Owner...get out of their way, they're "big boys and girls"...besides your "problem" is likely not that difficult for them to solve...we're not curing cancer here.

Problem-Based Contracting

A "Problem-Based" contract within a methodic acquisition process is the answer. This is the ultimate evolution of Perfromance-Based Design-Build. PBC does something so simple, most do not believe it can work. The contract basis replaces plans & specs with problem satisfaction. What are the fundamentals of a "Problem-Based" contract and acquisition process?

1. Define the "Problem" to be "Solved" in terms of "outcome" (not based on a set of predetermined "inputs" i.e. "the design")

2. Establish a clear, objective and specific "metric" for each "outcome" you desire (price, schedule, collaboration, program, performance, etc.)

3. Prioritize your expected "outcomes", giving emphasis to "mission critical" objectives

4. Evaluate & Select the designer/builder based on reliable "risk attribute mitigators" unique to your project (not boiler-plate criteria)

5. Establish the designer/builder's "authority & accountability" for the "decision-making" that ultimately provides the "solution"

6. Pay for "performance of outcome", i.e "satisfying the problem" (not work, not activity, not labor, not drawings, not problem solving, not commissioning, not flow diagrams, not schedules, not site supervision, or any other element the designer/builder deems essential to their satisfying your "problem")

Can this be done?...Has this been done?...you bet your "major-award plaques on the wall" its been done. Where?... here's a Case Study

Holding the Option: For Facilities

In the world of finance, investors are always hunting for ways to grow their wealth without taking on excessive risk. An effective approach is the use of options. Holding an option can unlock new opportunities for building investor wealth.

Similarly, In the world of construction project delivery owners are always hunting for ways to improve their project's quality without taking on excessive risk. Here too, holding the option can unlock new opportunities for project success.

In a prior post (Possibilities vs. Price: The Flip) we discussed how "The Flip" from competing price to competing outcome presents the owner an opportunity to compare various outcomes, i.e. options. In a performance-based delivery approach, the competing design-builders present their option aimed at solving the the owner's problem (defined in the RFP). As there a 3 competing design-builders, all working the problem that best delivers the 'solution', the owner is presented options to solve the problem (at a fixed price) and not merely a chase to the lowest price.

Most importantly, the owner is presented such options in the language of design: that is to say, the owner can consider how their unique problem will be solved by having it discussed and presented via alternative designs. It is an opportunity to measure approach and innovation in the context of what the owner values as detailed in their problem statement, i.e. their Request for Proposal (RFP). Done correctly, this procurement process (fixed price-variable scope) allows a deeper dive into the problem for which the owner seeks a solution within the constraints of resources such as price and schedule.

This "flip" tactic, along with others provide a more antifragile approach to project acquisition. At the heart of this antifragile approach is the 3PQ Acquisition Management System. 3PQ is designed to be antifragile with specific attributes for project definition, collaboration, price control, and quality of outcome.

Possibilities vs. Price: The Flip

When it comes to the typical building project's life, a need is first recognized, quickly followed by possibilities. Sometimes a little before. It is in our nature to dream. Somewhere between the need and the possibilities a budget is set, most likely the primary constraint to possibilities.

Or, maybe the primary constraint are the dreamers. More specifically, the "dreamer manager". The one that establishes the acquisition strategy.

In the construction domain, the "standard" acquisition strategy is to receive bids based on a set of plans & specs. The logic being: since the constructed results are all the same regardless of contractor, one should choose based on lowest (responsible) price. Based on this logic, the "standard" strategy risks price (budget satisfaction) to the solution (plans & specs). The plans & specs drive the price in the real marketplace. While the solution, one of many alternatives, may satisfy the functional needs of the owner, budget satisfaction is sacrificed. And since predicting markets are tricky at best and impossible at worst, the standard acquisition strategy is fragile and likely to fail budget satisfaction. And its important to note, the point of receiving bids is only the first attack on budget satisfaction: change-orders seem to always follow.

Now reverse the axiom of price and solution: to risk solution to price. When price (instead of solution) is fixed and the solution is bid from a menu of wants and needs (rather than dollars), then budget satisfaction becomes antifragile as the menu contains required elements that are well within budget, along with desired and if-possible elements in rank order. Budget satisfaction is antifragile because price is fixed to the menu, and the chosen menu items are expressed in offered solutions.. While the offers vary, the all meet the "required" scope. This concept is expressed in the diagram below.

• In design-bid-build (left), the owner decides a fixed solution subjected to offers for price from the marketplace: a fixed scope / variable price strategy

• In design-build (right), the owner decides a fixed price subjected to offers for solutions from the marketplace: a fixed price / variable scope strategy

With a fixed price / variable scope acquisition strategy, the project's scope (the menu of wants and needs) is satisfied by competing solutions. The details for how the menu (re: Preferred Price Priority Queue - 3PQ) will be discussed in a future post. As a case study, this is the strategy used on the designbuildoa.com/RSF project.