Supply chain bollocks!

---

If you're working projects in the construction industry then you know what I'm talking about: supply chain constraints and missed or stretched schedules everywhere.

 

It may be time to dust off two ideas that are actually timeless:

1. "The theory of constraints"
2. "The Critical Chain"

Now as it happens, both of these ideas come from the same industrial theorist: Eliyahu Goldratt; and he wrote books -- well received and widely read -- about each one (*).

Theory of Constraints

Goldratt had two big ideas in his theory

1. There's no point piling up "inventory" ahead of a constraint, only to have that "inventory" languish and possibly expire before it's sell-by date.
   This means don't work feverishly in one part of the project, only to have another part of the project constrain the utility of that work.
   Resources will be unnecessarily committed to tasks that could be done at another time.
   It's better to put those resources to work -- perhaps even on another project -- where their outcomes can be readily used. Matrix management anyone?
   
   
2. If the constraint is really impacting outcomes in a material way to project objectives, then subordinate everything else to the task of mitigating the constraint.
   In a few words: don't accept the fact of the constraint; do something!

The Critical Chain

Most project managers have heard of this one. Even PMI talks about it. The ideas are these:

1. Figure out the chain of events and tasks that comprise the path to the most important project outcomes. Often, such is the 'critical path' as defined by PDM methods, but not always. Unfortunately, "critical" and "important" do not have a common definition. Let's focus on "important" as the critical chain , and leave "critical" to PDM.
   
   
2. Create 'buffers' -- or schedule slack -- between any activity that joins the important critical chain path. The buffer is there such that those less important activities do not impact the performance of the critical chain, even if they run over and thereby consume their buffers.
   
   
3. And, create a buffer at the end of the critical chain such that any variance along the way is absorbed by the buffer. In schedule speak this is known as "under promise and over perform"
   
   
4. Finally, and somewhat controversially in the age of Agile, centralize the oversight of the 'buffer budget' so that the budget is applied to the most important project objectives as determined by the high command in the project office.
   

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

(*) "The Goal" is the business novel that explains the theory of constraints

"Critical Chain" is also a business novel

---

Buy them at any online book retailer!

PMO in the construction domain

---

I don't write about construction projects all that often, but lately that's been my thing: construction... roofing, HVAC, electrical, even some plumbing and floors, etc

The PMO construction extension to the PMBOK is pretty much a non-starter in my opinion.

The place to start is the AIA -- aia.org -- the American Institute of Architects. And, it's not just for architects: general contractors, contract managers, and PM's all find really good stuff.

And,you don't have to be an AIA member to take advantage of a lot of the stuff, including sample contract documents, of which they have dozens, if not several dozens. However, be watchful of the copyright claims

Here's the thing. There are these important points to grasp:

1. There are generally four day-to-day players in construction: the architect (or engineer), general contractor, attorney, and owner (or buyer). Read any AIA contract template and you'll find "the architect shall...; the GC shall..., etc)
2. At a strategic level, you've got the regulators, construction code authorities, and the permitting authorities (And, the latter are often at the bottom of the political food chain involving public planning, zoning, waivers, etc)
3. Often, the owner and the general contractor (GC) both will have project managers, though sometimes the architect or the GC plays the role of PM for the owner. So, which one are you?

With four major players day-to-day, you'd think the communication channels would be about 15 (using the N-squared minus 1 rule, where N is the number of communicators). That's a lot of cross-talk.

But no! My observation and experience is that communications in a construction environment is not a mesh; the communications architecture is hub-and-spoke.

And, guess who is at the hub; guess who is the risk manager managing all the sequences and buffers among players? Right! You are, if you are the PMO for the owners (or possibly the GC if the owner is contracting "turn key" with the GC)

• It's almost childish the way the various independents and independent contractors insist on communicating through the hub. If a conference is needed, only the PM can call for it, it seems.
• And, since most of the construction industry multiplexes the white space among many jobs, to maintain any kind of project schedule requires constant attention to sequences of who works when
• And, did I mention the supply chain? Everyone seems to work "just in time", maintaining minimum inventory, and thereby pushing buffers and sequencing to the limit! 

Conclusion: the number one skill of a construction PMO is communication ... far and wide, and often!

• Tell them what you are going to tell them
• Tell them
• Tell them what you told them!

---

Buy them at any online book retailer!

If you can't draw it, ..... (can you build it?)

---

Many creative people will tell you that new ideas begin -- often spontaneously -- with a mind's sketch that they then render in some kind of media.

Fair enough -- no news there. We've talked about storyboards, etc before.

But then the heavy lifting begins. How to fill in the details? Where to start?

My advice: Draw it first.

If you can't draw it, you can't build it!

And so the question is begged: What's "it"

Three elements:

1. Narrative
2. Architecture
3. Network

And, one more for the PM:

• Methodology

Digression: My nephew reminds me that now we have 3-D printing as a prototype "drawing" tool. Indeed, that's his job: creating 3-D prototypes.

Narrative: (an example)
Bridge stanchion with strain sensor and sensor software

Architecture:
Let's start drawing: Actually, I like drawing with boxes. Here's my model, beginning with the ubiquitous black box (anyone can draw this!):

Black Box

Of course, at this point there is not much you can do with this 100% opaque object, though we could assign a function to it like, for example: bridge stanchion (hardware) or order entry shopping cart (software)

And so given a function, it needs an interface (blue); some way to address it's functionality and to enable its behavior in a larger system context:

Interface

And then we add content (white):

Content

Except, not so fast! We need 'room' for stuff to happen, for the content to have elasticity for the unforeseen. And, so we add a buffer (grey) around the content, but inside the interface, thus completing the model:

• Black: Boundary
• Blue: Interface or API
• Grey: Buffer
• White: functional content

You could call this an architecture-driven approach and you would not be wrong:

1. First, come the boxes:

• Define major functional "boxes"... what each box has to do, starting with the boundary (black): what's in/what's out. This step may take a lot of rearranging of things. Cards, notes, and other stories may be helpful in sorting the 'in' from the 'out'. If you've done affinity mapping, this boundary drill will be familiar.
• Our example: three boxes consisting of (1) bridge stanchion (2) strain sensor (3) sensor software

Then comes the interface:

• Then define the major way into and out of each box (interface, I/F, blue). If the interface is active, then: what does it do? and how do you get it to do it?

And then comes the "white box" detail:

• The buffer, grey, captures exceptions or allows for performance variations. In effect, the buffer gives the content, white, some elasticity on its bounds.
• And then there is the actual functional content, to include feature and performance.

Network

2. Second big step: networks of boxes

• Think of the boxes as nodes on a network
• Connect the 'black' boxes in a network. The connectors are the ways the boxes communicate with the system
•  Define network protocols for the connectors: how the interfaces actually communicate and pass data and control among themselves. This step may lead to refactoring some of the interface functionality previously defined.
• That gets you a high-level "network-of-boxes" . Note: Some would call the boxes "subsystems", and that's ok. The label doesn't change the architecture or the functionality.

3. Third big step: white box design.

Define all the other details for the 'white box' design. All the code, wiring, and nuts and bolts to build out the box.

• Expect to refactor the network as the white box detail emerges
• Expect to refactor the white box once development begins. See: agile methods

And, not last: Methodology:

The beauty of this model is that each box can have its own methodology, so long as interfaces (blue) and boundaries (black) are honored among all boxes. In other words, once the boundaries and interfaces are set, they are SET!

The methodology can then be chosen for the white box detail: perhaps Agile for the software and some form of traditional for the hardware. This heterogeneous methodology domain is workable so long as there is honor among methods:

Interfaces and boundaries are sacrosanct!

Now What?
Estimate the work (yes, estimate: you really can't start off spending other people's money without an estimate); segment and sequence the work; and then build it, deliver it, and you are DONE!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Design-build

---

If you're in the construction industry you probably know about and have experienced "design-build". Notice that there's a word missing after "design", to wit: competitive bidding.

Ooops, a typo? No, there is a body of knowledge around this that says that it's faster-cheaper for the same quality to go "design-build" than "design-competitve bid-build".

In effect, one team -- architect, general contractor, and owner rep -- carry the project all the way through.

Faster-cheaper
The "faster" thing is obvious: there's a missing step, so the cycle has an inherent time advantage. The "cheaper" thing is not so obvious. Why should it be cheaper? There's nothing built in to drive the cost.

Best Value
Maybe it's not cheaper (though the track record over years seems to say it's cheaper), but it should be a best value project. 

That's the segue to: How do you decide which team is the team you are going to go with?  Certainly not lowest-cost, because the cost is not known until the design is known. So you decide on the basis of "best value"

Ah yes! Recall what value is: the best combination of quality, feature, and function that fits a budget. (Did I mention I wrote the book? "Maximizing Project Value". See the cover below)

And so, best value must mean value optimized for one or more of the variables. Of course, your bias will be different from mine, so your optimization will be different from mine. Nonetheless, each opportunity does have a "best value"

And, best value could be "lowest cost, otherwise acceptable". But, often it's not. There are other considerations other than cost. (We'll leave corruption off the list)

Public sector
But, if you're in the public sector, where the public expects probity when expending funds, how do you explain "best value"? Can it even work in the public sector?

Answer: Yes, it works.  In the U.S., some 20 states have made it legal, even desired, to go design-build. So the arguments that convince are out there.

If you read through the Wikipedia article under the link above, you'll see a pretty good to-and-fro on the good, the bad, and the marginally acceptable about design-build. There's even a design-build handbook and of course a design-build society.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Construction PMO

---

I don't write about construction projects all that often, but lately that's been my thing: construction... roofing, HVAC, electrical, even some plumbing and floors, etc

The PMO construction extension to the PMBOK is pretty much a non-starter in my opinion.

The place to start is the AIA -- aia.org -- the American Institute of Architects. And, it's not just for architects: general contractors, contract managers, and PM's all find really good stuff.

And,you don't have to be an AIA member to take advantage of a lot of the stuff, including sample contract documents, of which they have dozens, if not several dozens. However, be watchful of the copyright claims

Here's the thing. There are these two important points to grasp:

1. There are generally four players in construction: the architect (or engineer), general contractor, attorney, and owner (or buyer). Read any AIA contract template and you'll find "the architect shall...; the GC shall..., etc)
2. Often, the owner and the general contractor (GC) both will have project managers, though sometimes the architect or the GC plays the role of PM for the owner. So, which one are you?

With four major players, you'd think the communication channels would be about 15 (using the N-squared minus 1 rule, where N is the number of communicators).

But no! My observation and experience is that communications in a construction environment is not a mesh; the communications architecture is hub-and-spoke.

And, guess who is at the hub; guess who is the risk manager managing all the sequences and buffers among players? Right! You are, if you are the PMO for the owners (or possibly the GC if the owner is contracting "turn key" with the GC)

• It's almost childish the way the various independents and independent contractors insist on communicating through the hub. If a conference is needed, only the PM can call for it, it seems.
• And, since most of the construction industry multiplexes the white space among many jobs, to maintain any kind of project schedule requires constant attention to sequences of who works when
• And, did I mention the supply chain? Everyone seems to work "just in time", maintaining minimum inventory, and thereby pushing buffers and sequencing to the limit! 

Conclusion: the number one skill of a construction PMO is communication ... far and wide, and often!

• Tell them what you are going to tell them
• Tell them
• Tell them what you told them!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Capital efficiency in large scale construction

---

Need a checklist of what to consider when evaluating capital requirements for a large scale construction project -- like say replacing the Golden Gate Bridge?

Bob Prieto has just the one for you, and only 21 pages!  Bob writes:

Large capital construction projects in both the industrial and infrastructure sectors are challenged today in three significant ways:
 1. Capital efficiency of the project – this considers both first costs as well as life
cycle costs
 2. Capital certainty – reflecting execution efficiency, predictability and effective risk transfer through appropriate contracting strategies
 3. Time to market – perhaps best thought of as schedule certainty but also accelerated delivery of projects, often an essential ingredient in capital efficiency

This paper focuses on achieving improved capital efficiency in large capital asset projects through the adoption of an expanded basis of design that considers all aspects of a capital asset’s life cycle

In this paper, Bob focuses on Capital Efficiency.

And he discusses the whole life cycle; he makes a distinction between development costs, post-project sustainability, and post-project O&M, though frankly the difference between these last two appear a bit fuzzy to me. Taken together, they represent the life cycle costs, unless you want to throw in salvage at the end. (Would we ever budget salvage end of life for the Golden Gate?)

Even if you're not in construction, this is a handy checklist for the large scale among us.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Lean in Orlando

---

Here in my hometown, they've discovered lean principles applied to construction:

The SkyHouse high-rise will top out in just a few weeks at 23 floors. If it stays on track, the building's 320 units will open ... only 13 months after the first dirt was shoveled aside. It takes that long just to build some custom homes.

The tower's builder, Batson-Cook Co., isn't pushing workers to rush; the job has gone quickly because of something called the "Lean" method, which is dedicated to ridding the construction process of waste, especially wasted time. Work schedules have been drawn so that nobody is left waiting on someone else

As the newspaper quote says, this project is going along in remarkably short time; and, the cost is reasonably under control.

And so what is the "lean method" applied to hi-rise construction? In this case the project manager adopted a unique schedule sequence for both task and resource.

The way we've always done it
The usual approach is to schedule each floor in a trade-craft driven sequence: first all the steel workers come in; then all the cement guys; followed by the plumbing and electrical, glass workers, and the like.

Another way to do it
In general, what they did was build each floor with parallel time boxes that align with different physical spaces, each time box/space centered on a particular trade. So, while the cement guys were working in one space on a floor in one time box, the electrical or plumbing guys were working on the same floor but in a different space in the same time box.

As one block was finished, the tradesmen (mostly men, but some ladies) rotated to the next block, and then up to the next floor. This makes for somewhat of a spiral planning method

The idea is that no trade is idled waiting for another. Each is fully engaged, so there's little loss to marching army expenses. The newspaper didn't say whether some Kanban system was incorporated for parts and supplies, but the supply chain had to be adjusted.... lot's of small lot deliveries. That may have driven the cost a bit, depending on how deals were struck.

Maybe Bent Flyvbjerg should come to town, take in the theme parks (no small feat of engineering, given the swamps they started with), and then see how downtown is done also

---

Bookmark this on Delicious

Check out these books in the library at Square Peg Consulting

More on robotics

---

TED has a feature of 8 videos on robotics, the first of which caught my eye because it's a flying utility robot that is highly agile and very small -- only a few inches in radius. (Agility and radius are inversely related exponentially, so radius (size) has a big effect on agility.. more on this later)

One by itself, or a fleet of them, might be quite helpful on any number of projects, especially construction, and especially construction in a high threat environment. One might think immediately of pipelines and buildings and bridges, but also buzzing about large antennas and denied areas like biohazard project facilities or demolition sites (after a disaster).

In this video, entitled "Robots that fly ... and cooperate", hosted by Vijay Kumar of the University of Pennsylvania, we learn a few things that seem like really unique ideas, and might even be useful in non-robotic humans in project situations:

For instance: implicit coordination; the ability to work in a team by the simply expedient of sensing co-located neighbors and sensing an object that the whole team is working on. These robots can do this; there's no explicit communication or leadership among them (self directed work and work flow)

To to accomplish such coordination, the robots operating system assumes:

• decentralized control
• local information only
• agnostic to neighbors
• adaptive on the fly

(I wonder if they took a page from the Agile Methods book?)

Since each robot is individually small so as to maximize agility, to do big tasks it necessary to scale up and work as a team. Now here's an interesting sets of physics: as you scale up (use robots in a cooperating team), the apparent or synthetic radius increases. (Not unlike a synthetic aperature used in radars and other optical devices.) However, agility goes down exponentially, in part because of increased inertia.

Does that sound like a real agile team of humans? Indeed, as you add team members, inertia increases and agility is inhibited. I don't think I want to go so far as to put mathematics to the human situation, but it sure predicts the robotic situation.

Now here's something cool: using the Kinect sensor from the XBOX 360, a variant of the robot can do an empirical coordinate system -- no GPS required. (Who said empirical process control -- advocated in agile methods -- was impractical and only the defined process control paradigm known to all the Six Sigma crowd would work?)

The application is obvious: for denied areas, and especially for denied areas with physical unknowns, self mapping is possible from sensing the environment.

(When I was a field operative in the intelligence community many years ago, where was this thing?)

Vijay Kumar, U Pennsylvania.

---

Bookmark this on Delicious

Check out these books in the library at Square Peg Consulting

Tactics v Strategy

---

Retreat hell! We're just advancing in a different direction

Major General Oliver Smith, US Marines

Battle of the Chosin Reservoir,

November 1950

You're the PM. You've set a strategy.  Fair enough.
And now you're faced with a situation that seems to require tactics at variance to the strategy. What to do?


A metaphor (less daunting than that faced by General Smith) is the sailing maneuver called tacking. Take a look at the picture below.

The lay line is the strategic direction. But sometimes the wind doesn't cooperate (if the wind is directly opposing the direction of the layline, you have to sail away from the layline to pick up some wind energy that's off the line).

It's necessary to tack across the line going way off the strategic course with a tactic nevertheless intended to make progress, albeit minimal, toward the strategic objective.

The 'input elements' are what you do tactically to make progress; the output is progress in the strategic direction. There's a lot more input than there is output, so this is a losing game re efficiency, but it will get you there... slowly.

How does this work in the project world?

Consider this:

• Your strategy: you want to build an integrated system; you want it to interface to an existing system. (Maybe you're adding a room to your house)
• Your issue: Doing everthing at once and delivering 'big bang' may be too disruptive and too risky to the customer base. (Your spouse)
• Tactical response: You design and build "throw away" interfaces that allow a modular, temporary, build-out of capability.

Tactically, you're going way off the baseline, building stuff at extra cost, extra test and integration, extra training that you're only going to throw away and replace (later at some time) with a permanent interface that also has to be tested, integrated, and trained.

Is this an advance in a different direction? You betcha! In many situations, such a tactic -- at variance with the strategy -- is well worth it. Click here to see how it might be otherwise!

---

Bookmark this on Delicious

Innovative construction

Silly me. I actually didn't know that there is a whole industry around something called "accelerated construction" in transportation projects (roads and bridges). It seems like these program guys have come up with the ultimate schedule fast-track.

I stumbled on this reading about fast projects for bridge construction. It turns out, there's a lot of them. And the reason seems to be economics (no one has any money) driving fast (read: cost efficient) solutions, or perhaps solutions (read: new methods and technology) making it economical. I'll leave the chicken and egg argument for someone else.

Nevertheless, accelerated construction is a project phenomenon that is being moved along by these factors:

• A US federally funded Accelerating Construction Technology Transfer (ACTT) Program
• Pre-fabrication (nothing new, but part of the plan), and
• SPMTs (self-propelled modular transporters) which are multi-axle, computer-controlled platform vehicles that can move bridge systems weighing up to several thousand tons with precision to within a fraction of an inch. (Let's hear it for GPS!) The vehicles can move in any horizontal direction and also have vertical lift.

Now, down here on Florida's space coast, we know a thing or two about large scale transporters: after all, moving the space shuttle around was no small matter

But, in the bridge business, having the right transporter technology is perhaps the one project tool above all others that makes the rapid schedules workable.

From the US Federal Highway Administration website, we learn a few case studies:

• Sam White Bridge over I-15 in American Fork, Utah - In March 2011, the Utah DOT (UDOT) used two sets of SPMTs to lift the Sam White Bridge across eight freeway lanes of I-15. This was the longest two-span bridge ever moved by SPMTs in the Western Hemisphere and was UDOT's 23rd use of the technology.
• Massachusetts FAST 14 Project - The use of accelerated bridge construction, prefabricated bridge elements and the design-build project delivery method enabled the Massachusetts DOT to shrink a four-year bridge replacement project to just one summer. The $98 million project, dubbed "Fast 14," involved the rapid replacement of 14 deteriorated bridge superstructures along I-93

In a few words: bigger is usually better! Let's hear it for transporters.

Bookmark this on Delicious

Extreme prototyping

Talk about extreme prototyping! If you were trying to figure out earthquake threats on your next construction project, what would you do? Well, this one made the national news: a full scale building with a hospital theme, complete with a doctor's examination room on the top floor, was shaken on a big(!) shake table.

Talk about the Spiral method: I'm not sure this is what Barry Boehm had in mind! A 6.7 magnitude quake for 60 seconds, and no broken glass... Now, that's a test.

But Boehm had the right idea in mind: when it comes to feasibility risk, you've got to set the right direction early or else you'll be doing a lot of backtracking (if you're still around to do the backtracking). The greatest hazard is often not the risky outcomes, but it's making the wrong decision about how to proceed: left, right, or straight ahead.

And, in the construction industry itself, when you get it wrong, it's often right out there in the public space where someone is going to be embarassed big time. And, that's where the political trouble starts.This is Bent Flyvbjerg's favorite topic, as depicted in one of his articles, "Design by Deception: the politics of megaproject approval"

Bookmark this on Delicious

Reference Class Forecasting

Bent Flyvbjerg has a long track record getting at the root causes of cost and schedule estimating errors in large scale projects, particularly those in the construction and transportation domains. His work is both theoretical and pragmatic, reflecting his former position as professor of planning in the Department of Development and Planning at Aalborg University [Denmark] and his current position as Research Director and professor of major program management at Oxford University [UK]

One of his favorite targets is the Sydney Opera House, notoriously difficult to build, some 1400% over budget, but a priceless source of  civic pride; and considered by most to be an architectural masterpiece. [Business value vs project value?!]

I ran across some of Bent's papers in a search I was doing on estimating.  One, "Design by Deception"  is a litany of major failures with some insights to their problems, mostly cases of looking the other way and choosing to believe the unbelievable. It's definitely worth a scan.

However, my attention was drawn to a paper he wrote the the PMI Project Management Journal, somewhat strangely entitled "From Nobel Prize to Project Management: getting Risks Right"

In spite of the title, the theme of the article is a practice named "Reference Class Forecasting".  From one view, RCF is just cost history applied to parametric model-based estimating, a method that's been around forever.   However, Bent and his co-authors spin it a little differently.  Their idea is given in 4 steps:

Step 1: Form the 'reference class', a collection of similar-to projects for which there is both history and reasonable insight to the history so that adjustments for present time can be made.  [Bent never did say what the simliar-to projects might have been for the Opera House]

Step 2: Develop a true distribution of the reference class, and from that distribution calculate the cummulative probability.  [Actually, they may have done it the other way around, but the main point is to come up with the cummulative probability].  They call the probability curve, developed from reference class, "the outside view".

Step 3: Develop the "inside view".  The inside view is a traditional estimate by the project team.

Step 4:  Adjust the inside view based on the probability of historical outcome from the outside view.  That is, develop a forecast using the reference class probability confidence curve.  In effect, according to policy or doctrine, or other direction, pick a confidence limit, and then adjust the inside view to have a corresponding confidence.

Obviously, the objective of RCF is to improve the confidence in the final estimate.  Along the way there are a couple other objectives addressed.  One is to overcome "delusion" brought on by "optimism bias", a phenomenon studied by Tversky and Khaneman.  A general statement of such a bias is that indiviuals with optimistic outlooks tend to underestimate risks; the corollary holds: depressed individuals tend to overestimate risk effects.

The other is overcome--or least provide the ammunition,--"deception" brought on by political neccesity.  Of course, in the latter case, legitimate accuracy is not actually politicially convenient.  Many times, the better data is 'buried'.  Shocking!

The good news is that delusion and deception tend to be counter-acting.  When one is in accendance, the other tends to retreat.  Obviously, as an academic, Flyvbjerg has some appreciation of the politics of delusion, but he campaigns against it nevertheless.  On the other hand, delusion seems to be the easier target to shoot down.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.