Is 57% waste real in delivery of projects in the Built Environment?

What is the highest portion of waste in construction projects?

It appears that rework tops the list. The data show that rework often has more than one cause. A recent CII study called "A Guide to Construction Rework Reduction" reveals that the biggest contributor to rework, at 25.4%, is scheduling, followed by issues related to materials and equipment (19%), design and engineering (14.6%) and instruction/monitoring (14.5%). Cutting costs too much can also drive rework. To save money, for example, some architects and engineers use old designs or templates for new projects, and those designs may have problems that were fixed on a previous job but remain in the original design and are passed along to a new one.

At the beginning of this year a conversation began between myself and collaboration principles of NoSilos.com. The reports from the Building SMART Alliance and the Construction Institute and others have been purporting A huge percentage of waste in our industry. While I cringe at the huge numbers, the reality is a lot of that number is infrastructure costs which are inflated due to the litigious nature of our business. Examples such as insurance, performance bonding and financing directly increase the cost due to the risky nature of the current methods we use to deliver Built Environment  projects. So eliminating these excessive costs will be difficult until lenders, insurers and risk assessment folks change their policies to favor less risky arrangements.

That said, the Cll study cited in the ENR article gives us a glimpse behind the numbers from yet another perspective. The study points out that rework, aka failure that manifests itself at the tail end of a project, is spawned by many different failure mechanisms. Bad schedules, materials, equipment, design, execution, supervision etc. etc. account for rework BUT most rework arises from more than one failure mechanism. Further, rework is merely the visible tip of the iceberg. The real failure points lie submerged and ignored.

If necessity is the mother of invention then crisis is the father of failure. And we see the father of failure sowing wild oats all over! And let us count the ways:

•  RFI's
• Energy
• Re-work
• Waste removal
• Poor site logistics
• Over priced construction materials
• Over priced construction equipment
• Poor delivery coordination
• and more, more, more.....

At NoSilos.com we have a metric we use called ROF or Return on Failure. Sort of like the Return on Investment metric known in the financial world, but in reverse. The value of failure compounded over time creates its own wave of increased cascade of failure. 

So how much can be reduced. Past experience shows a possible reduction on privately funded projects of at least 10% and more likely around 15% when we used a modestly integrated design and delivery process not even close to true IPD process. The key to these numbers was a combination of great communication, clear goals and some judicious use of technology to help make the process a bit easier. 

The bottom line, from our perspective, is that waste and inefficiency are known realities by key stakeholders in every sector of the economy regardless of their willingness to admit to the presence of the waste. We bring solutions to identify the differences between uncontrollable and controllable waste. What our clients do to reduce those costs is up to them. There is a vast opportunity for every company to reduce their ROF and increase their ROI to levels not seen before. 

Lean Startups and the Flow of Value-A lesson for the AECO Sector

Dave West recently wrote an article in ProjectsAtWork.com's June issue  that I immediately identified with. In fact he almost writes a parallel post to one of my original posts which is also one of the all-time favorite posts here on this blog. BIM & XPM-A Made Marriage.

Dave is currently the Chief Product Officer at Tasktop and one of the foremost industry experts on software development and deployment. He has helped advance many modern software development processes, including the Unified process and Agile methods. As such, he knows of what he talks and it is a strong validation of the work I discovered somewhat by accident and happy circumstances over ten years ago.
Please read Dave's article here

Dave's mention of the Lean Startup movement, that is going through companies right now lead him to some interesting conclusions. As a mentor at our local Gangplank chapter in Tucson and having been through several Lean Launchpad  Startup workshops, I can attest to the parallels which Dave highlights. For the real focus on the Lean Launchpad is creating value and validation of a new idea using the minimum of effort to seek the greatest return. In a Lean Launchpad we don't go into big elaborate tests, but use simple tests to determine if an idea has merit in the marketplace. For me that was natural. I have been doing that in design practice for quite a while. Tweaking the context was easy for me to see how focusing on creating the greatest value using the least expensive means possible gave way to determine where the maximum effort should be spent as an idea matured and became validated.

How did all this resonate with me? I started using a variation of XPM and Agile back about 10 years ago in the design profession of architecture. The close parallels of SW development and working in the built environment design are quite scary. For that reason, and that it focuses on the value stream of information, the above rationale delivers very good results.

On my early journeys in this endeavor to find a better way to practice design I looked for ideas which would bring the design process together more efficiently. Since I'm not a purist on either the lean or agile side I just looked for what worked well and could be repeated over and over with consistent results. Creating a flow of information which delivered the value needed for timely decisions became our mantra. It reduced rework, it focused on the issue(s) at hand and set all others aside and above all was guided by the principle of keeping the end goal in mind.

Often, the project's end goal was modified along the way due to inconsistencies in assigning value in the beginning. But that is to be expected, since not all the value is known before a project starts. Discovering that new areas of value harvesting made more sense than staying with original ideas we were able to keep the project expectations in line and the Owner happy. More times than not, the final results were better than anyone would have imagined going into the project.

Who was responsible for delivery, everyone. If someone working on the project did not see it was their project to deliver value, they often were removed or isolated out to minimize their damage to the rest of the producing team.

As you can see, adaptability, collaboration, transparency, autonomy and focus on value were key components in our success.

Always remember "Collaboration is the Glue of Success"

NoSilos.com
Collaborative Construction Blog

This article is a continuation of conversations about how delivery of professional services in the Built Environment can change the way business is done. This article focuses on the change in focus from functional activity to delivery of value in every action and the need for all participants to own their part of the project delivery. It is a continuing String of thought with connections to project management, project delivery methods, change management and the continuing evolution of business delivery in our marketplace. 

Chaos & Change - Part 5 -HR. Part of the problem...

I admit it. I have a permanent negative bias for HR departments. They should be part of the solution, but they aren't. They are controlling where they need to be open. They are obstructionists where they should be enabling. They are restrictive where they should be expansive.

This post is one of a continuing series on the factors I see contributing to the debilitating chaos and waste in our working lives, no matter if in the private, public or non-profit worlds. Waste is a terrible thing to endure. If our organizations are to be effective in the 21st century, pervasive change needs to occur. For the start of the series see "Part 1-Chaos and Failure are Brothers" and continue through the series. I think you will find something which hits home for you and your organization. At that point it is up to you to start affecting the change needed in your world-take responsibility, move ahead.

In a recent blog post by Mike Cook entitled, "Is SHRM Fiddling While HR Goes Down in Flames?" he asks some really good questions about the current mindset of HR departments.

"In the course of my work I have many occasions to address local gatherings of HR professionals and am confounded by the lack of urgency I see towards the development of what seems to me the number one issue facing organizations, significantly improved capabilities in the acquisition, development and retention of the necessary talent for the business they are a part of."

I agree wholeheartedly with Mike. What is going on with HR in general? Have they been asleep in their little cocoons for the last 5 years? Have they even seen the transformations taking place in their companies which reward exploration, innovation and multidisciplinary involvement? Apparently not. While their house is burning, they continue to fiddle the tunes of the 1990's and have seemingly missed the 21st century transformations since 2006.

The chaos they contribute to an organization adds to the "Stupid Index" (my interpretation) of their companies they are supposed to be serving. Instead of contributing, they are distracting and compartmentalizing the efforts of their constituents they are called to serve. If I sound like I'm on a ran, I guess I am. I loathe the continued waste on the scale HR groups usually contribute to a company, when they could be a strategic contributor, rather than a tactical obstacle. Apparently those who know this subject much better than I and have recently reported their findings which supports the real life experiences I've had with HR groups. Both the Boston Consulting group and McKinsey are respected companies who measure their findings and support their positions with hard research.

When they find little or no change in HR departments over the past five years in meeting the changing market conditions of the organizations they supposedly serve, it supports the continuing mountain of evidence building that today's organizations are in dire need to shed old and ineffective action and thinking and replace it with more agile and responsive organizations. Permanent Change Management is needed, now.

My thanks to Mike for writing such a revealing and on point post. Hopefully, some CEOs and HR directors will awaken to the burning timbers around them, get the fire out and rebuild a new house which is really a responsive representative of their constituent stakeholders.

This is a continuing series of articles as a Connection about Chaos and Change Management in the workplace. Other ideas here include Lean, Agile and Management 2.0 management theory as applied to complex or wicked problems. 

Chaos and Misdirection - Part 4 - A Classic Case of Missed Opprotunities

This is the forth part in a continuing series about missed business opportunities inside businesses which create points of failure and loss of value. In this article I highlight a trend inside companies where one part of the company should be engaged and responsible with a key component of the company's success and for any number of reasons they aren't. Use the links here to read parts one, two and three.

Chris Murphy, Editor for InformationWeek magazine has a recent blog post entitled, "Will CMOs Outspend CIOs?" For those of you not in the know, CMO is Chief Marketing Officer. Just another alphabet soup entry in the seemingly never-ending stream. The important take away from Chris' article is that Information Technology has largely taken to a bunker mentality and has stopped being the R&D arm needed for strategic decisions in a flexible corporate organization. Here is a classic case of created silos of operation hindering real growth and innovation in any organization. Here's what I think is the crucial take-away of Chris' article.

Chaos and Change - Part 3 - Lean, Agile and Mgt2.0 Can Succeed

This is the third article in a series about Chaos and Change. How they change our working worlds and how we can gain come control of the chaos. The previous installment was titled Chaos and Change are Brothers - Part 2  I suggest you might want to go back and catch it as well. 

The following is a reply I posted on Fierce Healthcare's discussion area. The site is one challenging healthcare folks to stay up with the latest developments in their fields. I came across Susan D, Hall's post in a LinkedIn Group and thought it interesting. While all of you know I'm a big supporter of better management and highly collaborative frameworks for companies, I thought it appropriate to clear the air about change initiatives and their chances to survive and make have some permanent change as a result. The following is my comment on Susan's blog post you can read here entitled, Lean leadership in healthcare: What does it take? Of course my comment there is posted here, but please read Susan's work as well.

Your Brains Work Best When They Can Turn from Failure to Success

Susan,
As an evangelist for better business principles which are more lean, more agile and responsive both internally and externally, I applaud your efforts in healthcare. Unfortunately, the cards are stacked against you. J, Kotter in 1995, Turner and Crawford, 1988 and Prosci, 2005 all indicate that only 30% (at best) of projects introducing change in organizations have reported any real measurable change. If you look at the flip side, that's 70% failure. Now I'm

7+ Reasons PM's Don't Improve Efficiency or Productivity

Many of you know I subscribe to the art of stealing and transforming ideas to get new results or perspectives around difficult problems. It's just an axiom of our world, 'nothing is new under the sun.' Did you know they had vending machines in Pompeii? Amazing!

In a recent article on Projects@Work there was an article closely titled to this entry, but it related to CEO's. It was written by Mike Beard who is a pro at Project Management. Mike was writing about the folks in the C-Suite, but let's take a minute and step back to take a closer look at the everyday activities of project leaders and managers. I would contend that Mike's seven reasons falls squarely on the shoulders of just about every person who managed a project or held some kind of management responsibility. At sometime all of us have been party to one or more of these seven reasons. It's not an indictment, it's just the way we are as humans. It is also not an excuse for the behavior to continue. I would hope all of us are working to become better practitioners in our chosen fields and have some ability to look at ourselves candidly to measure how well we perform and act. So let's look at Mikes' Seven Reasons quickly and see how we measure up. Oh and I've added a bonus reason at the end for you.

1. We have met the enemy and he is us: (my paraphrase). Yup, I'm my own worst

BIM and XPM: A Made Marriage - Part 4

So far in the previous parts One, Two and Three of this series I've introduced you to an alternative work management method using eXtreme Project Management theory (XPM). XPM is a variant of the Agile light-weight management movement. The roots of this management theory caught hold in the software world and has moved into other business domains. If you want to change your management to fit more closely with collaborative efforts and use BIM in your practice, then you need to give XPM a very close look. It has a lot of advantages to offer and gives a lot more control to the people actually doing the

BIM and XPM: A Made Marriage - Part 3

Part 1 and Part 2 of this series introduced you to a new light-weight management method based on Agile and XPM planning methods. In Parts 1 & 2 I told you I would tell you how we used this theory so in this installment I'll make good on the promise.

We started out trying a piece of web-based tracking software which is open source. We abandoned it for a couple of reasons, the biggest reasons being a serious bug in the software and a lot of terminology specific to software development. As a second attempt we backed off and started over with a stack of 3 x 5 cards to represent the elements of the plan from Releases right through to the Tasks / Tests. Later on the team wanted to use an online solution and we agreed on a simple online forum as a platform. It meant a little more manual work than the previous online software, but we found it worked just as well and was simple to use and it didn't have all that foreign lingo of software development. We were free to make up our own language. I'll also say at this point we also tried spread sheets as an alternate to the web forum, but that was just too unwieldy and didn't have good multiuser support. Spreadsheets really are built for single authors. We did find the spreadsheet was OK as an alternative to the 3x5 cards for planning.

We created several different structures in our forums but the following became our standard of practice.

A list of categories called Active Projects, Completed Projects, General Discussions, and Food for Thought. We used General Discussions for topics that weren't germane to the production of any single job, but something someone wanted to pass along as a supporting thought or reference for the general practice. Food for Thought was used only for discussions that directly related to the management practices and how they might be improved or extended.

Next under each forum category we had the projects themselves. Under these we had children forums for Planned Work, Current Work and Completed Work That looked something like this.

So you can see a very simple mechanism implemented in a simple to use software tool like a forum, gave us the majority of the functionality needed to organize our work. It was easy to move the elements of the discussions as well as the discussions around as their information matured.

It only took us a very short amount of time to teach anyone in the office how to set up and maintain this organization method so we used the junior team members to do this task. That way they got used to the tool and how it was used every day.

The Language of the Forum
Next we had to create a lexicon and grammar to organize the information at each level. We tried a lot of different solutions with varying results. We finally gave each project team some latitude on their choices due to the preferences of team leadership and the complexity of the project. We had a range of organization that had little if any sorting string thought to some that could organize the views by selecting string or substring values along with numbering schemes that produced views with only a very selective result. For instance some teams chose to use a title string that looked like the following organization
[completion] | release | Iteration | story | task | [Responsible] | title and looked like....

[y/n]2.3.15.100[] Model interior sound partitions

If someone only wanted to see incomplete release 2 tasks they would look for a string like "[n]2.*". Or all the incomplete story 15 tasks with "[n]*15.*" If someone wanted to see all the work they had taken charge of they could look for "*[aa]" if their initials were "aa". So you can see there is a lot of flexibility in an open string and search tool to quickly create searches to display results. Our forum also had a listing view to show all the past activity as new or changed information in the forum, which made it easy to watch the work being completed without having to do a lot of searching.

We also included information in the body of the task / test entry like when it was due as a calendar date [11/15/11] and any reference documents back to the Project Notebook or other web resources before the task description. Work completed was created as a reply to the forum entry and signed / dated along with the hours used to complete the task and test. Both the Task and Test portions had to be completed before the work was marked completed. 

The wiki project notebook
The companion to our forums was a wiki organization which we implemented using Mediawiki. The wiki held both the higher order project information like clients, contacts, project budget and schedule information as well as specific information regarding selections for materials, assemblies and all the other design requirements information. In addition we used template pages that organized much of this higher level information so all a manager or other assigned team member had to do was select one of the template documents, duplicate it in their project and then fill in the blanks as needed. This normalized both the information and the organization pattern for this kind of information and gave each element a url page location which could be used in the forum to point back to when needed. So the wiki became the project notebook and it was uniformly accessible by anyone at anytime from anywhere they could get a web connection.

We also had sections in the wiki to assist project work planning teams to easily create stories, and task collections by creating lists of common stories and tasks / test combinations. They could cut / paste the needed information out to make it easier to create the forum entries. 

So there you have the core of our tracking and documentation methods. Nothing fancy, but it works and it is free. There is enough flexibility in the methods to accommodate a lot of differing need so if you need a simple implementation, pare off what you don't need and use the rest. If you have more people and work to manage, you can step up the organizational framework to meet your needs.

Advantages
This level of project documentation made it easy to add new members to the team. They only needed to read the information necessary around the work they were assigned to. If they needed some background on how the model was organized the BIM Execution plan gave them that info housed in the wiki and referred to in the tasks / tests they would work on. Instead of having to brief someone for 20 minutes or more, it took about 5 minutes for a new person to join in and get productive, and that was without a senior team member giving them a briefing. Yes this did take some time, but it kept people focused on their work. Work that was needed was completed in timely manner. Work that was not needed yet didn't get worked on. And tracking the completion of work or where there were issues were easily identified and solved quickly by the team or an outside source when needed. After setting the expectations and training this system was very effective in keeping our projects on track and eliminating waste.

I hope this helps you understand how we organized our work. In Part 4 I'll share the measurement indicators we used to track progress. Until then remember "Collaboration is the glue of success."

Now on to Part 4, the last one

 

This article continues a String of Connections between practice management, BIM and Agile management practices. 

BIM and XPM: A Made Marriage - Part 2

Recap
In Part 1 I introduced the concept of using Agile management techniques in a BIM-centric design / construction practice. After looking at the article I found I made a lot of assumptions and you know what that usually means. I have to apologize for the assumption you would know about Agile, or XPM and how those light-weight management tools would or could work in a design-centric work environment. So to make up for my oversight I thought a quick primer on what the basic parts of an Agile / XPM environment looks like, as we implemented it. One caveat here, if you are familiar with these

BIM and XPM: A Made Marriage - Part 1

Prelude...
Since writing this article back in April, It is ranked #2 for the number of all-time hits on this blog. I'd like to encourage you to read all four parts. The hook is I reveal how all this works in the later parts. These lightweight management theories will radically transform your business and professional practice. If you want to see more $$ at the end of the year and create a better working environment, then I strongly advise reading all of the series. aa June '12
 
Introduction
BIM and XPM were made for each other. BIM authoring tools of just about all forms are characterized by elements or families which have some kind of data construct attached to the graphic elements. The graphic elements can be driven by parametric data or not. Not surprisingly, the elements are organized in large categories which roughly approximate the organization of the construction material sets needed to erect a building such as foundations, floors, walls, ceilings, furniture, casework, equipment and the like. Views are organized in a way that traditional document sets have been assembled for decades such as plans, elevations, sections and tabular schedules. Since the model is 3d there is also a new view for 3d perspectives, isometrics and other similar views. A very modular and structured way of thinking.

Most importantly from a work management point of view all these elements and views are very atomic and largely independent of each other. They can be created with or without any data or graphic content in them, or at the very least only the barest of information or graphics as place holders waiting for more specific information. The other important

Complex Problems and Light-weight Project Management

I'm currently working on a new project which aims to reexamine one of the key components of our economy and how it might be modified to reduce waste, risk and in the process increase productivity and profit. As you might surmise, it is connected to the built environment.

I was reviewing some thoughts and notes with one of the team members last evening and the topic of  light-weight project management tools came up. If you aren't familiar with the term you probably have heard about Agile and Lean methods. They are the two leading PM methods classified as light-weight methods. Each has their own areas of application, one does not substitute for the other and there are dialects within each of these major classes. On the Agile side are two major dialects called Scrum and eXtreme Project Management (XPM). Scrum being the oldest and eXtreme being younger and having Doug DeCarlo as it's creator and proponent. Scrum came out of a skunkworks kind of environment and is almost totally focused on software development where Mr. DeCarlo's methods are used largely in the software world there is a growing interest and adoption of his simpler more transferable concepts in other domains.