The "Unwitting" Lean Thinker

If you're a Lean geek like me, you might have read All I Need to Know About Manufacturing I Learned in Joe's Garage. It's a fun little book about utilizing lean thinking in our everyday world.

The title of the book got me thinking about when I used to spend summers working as a roofer for my dad. After thinking about it for a while, I realized--all I need to know about Lean I learned working for my dad.

My dad is what I call an "unwitting" Lean thinker. I say this because he had never heard of Lean until a few years ago when I started learning about it, but he has for years operated his small roofing business in an extremely Lean fashion. Here are a couple of Lean traits that his business exhibits:

1. Just-In-Time (JIT) material supply...No warehouses, no inventory. Materials arrive within a half-hour of when the roofing begins. No exaggeration. This results in extremely low overhead and less conveyance and motion waste from material handling.
2. Close partnership with suppliers...Item #1 above would not be possible if it weren't for the fact that my dad has an extremely tight relationship with his materials supplier, Bradco. He's been with them for years, hasn't beat them up on prices, and enjoys the benefits of a cooperative arrangement (one of which is JIT delivery).
3. Employee loyalty...Construction trades are infamous for churning employees. A common practice for roofing contractors is to add on some "strong-backs" for a few weeks when business is good, pound out a lot of work quickly, and then lay-off half the crew when the backlog vanishes. My dad has taken a different approach. He keeps his crews together for years and years, rarely adding or losing any team members. His crew members can anticipate each other's moves, are best friends off the roof, and understand the performance level that is required to work for my dad. This is invaluable.
4. Workload balancing...One reason why my dad has been able to keep his crews together so long is because he balances the workload. By working steady like the tortoise instead of frantically like the hare, he is able to reduce the overburden (muri) on his people and avoid the senseless depletion of the work backlog that is caused by overproduction. Even in these desperate times for the construction industry in Florida where my dad works, he has been able to keep his crews working steady.
5. Focus on value...My dad doesn't try to be the low-cost provider, or try to reach customers via fancy marketing, or try to land huge contracts through political networking. He just focuses on minimizing waste by keeping things simple, maintaining the highest quality by having the best crews, and creating word-of-mouth advertising by being more focused on customer satisfaction than anybody else. That's value.

As a Lean advocate, I've drawn upon my experience with my dad countless times. People intuitively understand these concepts, regardless of the organization. I think if you could strip an organization down to a simple business like my dad's, you could get going on the Lean path a lot quicker.

All the complexity and distractions of a modern bureaucracy get in the way. That's why I think it's important that we Lean advocates get better at organizational design. We can begin by going back to basics, maybe by studying small businesses like my dad's.

Here's a photo of my dad...in full company uniform, but not exactly hard at work :)

What is a Lean Advocate?

Hey Lean Advocates, do you ever struggle with how to explain to people what you do for work? Some people have well-recognized professions: lawyers, engineers, nurses, and so on. Unfortunately, most people I meet have never heard of Lean. This can make it hard for us Lean Advocates to validate our experience and describe our skill-sets.

Maybe it's just me, but there just seems to be a lot of unresolved questions about being a Lean Advocate. Here are a couple that come to mind...

What is the job description?

It's not the same thing as a Lean expert, because I know I'm not that. It's more about being passionate about Lean than being an expert. It's somebody who wants to achieve excellence in everything they do, using the principles, thought processes, and tools that have collectively become known as 'Lean.'

The problem that I've personally encountered in my career is translating my role as a Lean Advocate into the common vernacular of the business world. Am I a management consultant? Sometimes I guess. Am I a process engineer? Sometimes, but not really. Am I a project manager? Yes, oftentimes. What about trainer/coach? Oh yes.

So, I guess Lean Advocates are consultants, engineers, project managers, trainers, and coaches. As unrealistic as that seems, it's actually true from what I've seen.

What industry though?

Lean Advocate is one of those roles that really is not associated with a single industry. Does that mean we can move around from industry to industry? For example, lots of Lean Advocates come from manufacturing. I worked for a construction company for seven years. Am I disqualified from working in manufacturing because of my construction background? What about being a Lean Advocate in the burgeoning Lean Healthcare sector? Do the skills translate?

Many HR/recruiting folks might disagree, but I think Lean Advocate skills absolutely translate. Being able to communicate with people, facilitate collaboration, identify waste, increase customer value, scientifically solve problems, help relieve overburdening of employees, help create alignment throughout the organization, and foster a culture of continuous learning and improvement...where do these skills NOT translate?

How do we prove our value?

How do we avoid being considered non-essential? How do we show that we add value? I think we sometimes do a poor job of defining our value to our organizations. The most successful Lean Advocates I've known are not the smartest or most passionate ones, but the ones who connect improvement activities to business results. I believe this is sometimes referred to as...Show Me the Money!

Anybody interested in Lean Advocacy as a career choice will need to get really good at showing the money. If we can't consistently prove the value of Lean, we'll always be susceptible to cost-cutting. Lean Advocates are too talented and too passionate to be considered expendable.

Just as safety advocates proved that good safety saves money, quality advocates proved that quality is free, and sustainability advocates are currently demonstrating that being green makes business sense, us Lean Advocates must make the business case to the decision-makers...over and over again.

So, what is a Lean Advocate?

Everybody has their own definition, but I think the job description needs to be something like: "A person who harnesses and promotes Lean as a means to better tangible business results in pursuit of excellence." Is that too far off the mark?

Learning & Teaching with the Dallas Chapter of PMI

Message for my Project Management friends--start going to the PMI Dallas Chapter events!

I went to my first monthly meeting last night, and was impressed by how much value it delivered. And I'm not even talking about the high-quality dinner buffet. What I am talking about is the quality of the people that attended. I met consultants, educators, recruiters, fellow project managers, Dallas-based corporate leaders, and more. A great mix of professionals.

Specifically, I had the pleasure of meeting two impressive people that I'm tremendously excited to collaborate with in the near future: Colleen Drabek and Beth Burnside. They are involved with the Dallas chapter's Education Committee, which develops educational programs, such as PMP Exam reviews and practical training on specific aspects of project management. The committee also networks with local universities, colleges, and other types of schools through the Student Outreach sub-committee.

As a lover of learning and teaching, I can't wait to get involved with this committee. Colleen and Beth's enthusiasm for their work only bolsters my enthusiasm to volunteer.

If education is not your thing, project managers, then opportunities exist with several other committees. The point is, us folks living in Dallas-Ft. Worth are fortunate to have such an active PMI chapter, and we should take advantage of it. I know I will.

Great Expectations for Lean Construction in DFW

Today, I was fortunate enough to attend a kick-off meeting for the new Dallas-Ft. Worth chapter of the Lean Construction Institute. The meeting, which was hosted by Texo and facilitated by Cynthia Tsao from LCI headquarters, was an excellent opportunity for us participants to brainstorm and identify priorities for the chapter moving forward. I was truly impressed with the brainpower, experience, and boldness in the room today. I was equally impressed with the quality of ideas and priorities that were identified during our meeting.

For me, three items stood out as the most critical items to focus on, at least during the first year or so of the chapter's existence. In no particular order:

1. Developing internal knowledge and competency of Lean Construction principles. This process can be initiated through education and training, although true learning ultimately comes from doing. LCI and its friends have the ability to provide this, and the construction folks in DFW want and need it. Developing that common vocabulary, understanding the thought process behind Lean, and getting some hands-on practice with everyday Lean tools are all valuable objectives for the DFW Chapter.
2. Engaging all construction-industry stakeholders. The expectation is that the architects, engineers, and construction folks will probably join in on the fun, but that's not enough. The customers of the A-E-C industry (building owners, building operators, developers, etc.) must also be engaged. So much of lean construction depends on the level of commitment and cooperation of our customers because of the way construction contracts are typically structured. Without the support of our customers, establishing a better approach to construction will be so much more difficult. One way to begin gaining support for lean construction is by demonstrating how it actually reduces risk for the customer (more on this in a future blog post).
3. Creating the buzz. Dallas-Ft. Worth is such a great capital of business for the U.S. and the world. So many talented people, so many successful companies, so many industries, and so much pride! The DFW Chapter of LCI needs to take advantage of this by creating a buzz about lean construction. This will have to happen on many fronts, one of which should be through online social media. With plenty of talented people willing to contribute value-added content, and a wide range of platforms for delivering this content to the people that value it, there's no reason why we can't build a tribe of people who are passionate about lean construction in DFW. Once we have a tribe of passionate people spreading the word about lean construction, we have a chance at really opening it up to the mainstream construction industry.

There are numerous other focus areas that are all important. These are just the ones that really stood out to me after listening to the discussions and presentations at the meeting today.

I'm just thrilled to be involved at such an early stage of the DFW Chapter. I see limitless potential in this group, and have no doubt that we will improve the construction industry in North Texas. This will not happen over night, but in true Lean fashion, it will happen through continuous improvement over time. Today's meeting was a great first step.

Seven Years of Lessons Learned at PHH

Last week was my last week at Palm Harbor Homes, Inc.. I spent seven wonderful years with this company (the only place I've worked since graduating college in 2003). Before I turn my sights towards the future and my next great company (TBD), I think it's appropriate to reflect back on the time I spent at my first great company. In the Lean world, they might call this hansei; while in the Project Management world, they might call this "Lessons Learned." Either way, the idea is the same--learn from the past. Here are some of the things I've learned from my time at PHH...

Lesson Learned: Get your hands dirty, often.

When I was first hired as a Manager-in-Training in 2003, I thought I was going to be sitting at a desk, firing off e-mails, and filling out TPS reports. That's not what happened...not by a long shot! On my first day, I was sent out to the shopfloor to start welding steel I-beams together. Within about six months, I had worked hands-on in every department in our homebuilding factory. Blood, sweat, tears, and all. After that, I spent another six months supervising our crews and doing quality control inspections. Not exactly what I expected coming out of college.

But let me tell you, that was the most important year of my life. That was the year I first learned the importance of going to the place where the real work is being done, and seeing for myself how things are functioning. In the Lean world, they call this genchi genbutsu. At Palm Harbor, we just call it getting your hands dirty. Whatever you call it, just recognize that without it, you're limited in how deeply you can really understand the problems faced by your people everyday. This is no doubt one of the best lessons I ever learned at PHH.

Lesson Learned: Communicate, communicate, communicate.

After that year out on the shopfloor, I got promoted to our on-site construction division as a Personal Construction Manager. At first, I spent all my time putting together detailed construction schedules, examining blueprints, and analyzing cost estimates. Then, in no time at all, I began receiving all sorts of complaints from my customers, sub-contractors, employees, and just about everybody else. While I was paying so much attention to the technical aspects of my job, I had failed to pay attention to the communication needs of my project stakeholders.

The lesson I learned is that stakeholder communication is absolutely critical to project success. You can bring in a project on-time, on-budget, within scope, and with great quality; but if you fail to address the communication needs of your stakeholders, you can have a completely failed project on your hands. I learned that lesson the hard way, on more than one occasion.

Lesson Learned: It's the money, stupid.

For a couple years, I was one of PHH's most staunch supporters of the Lean Manufacturing methodology. For a while there, during my stint as the company's Corporate Lean Manager, I was responsible for spreading the Lean gospel to all our manufacturing divisions, and I did so with the fervor of a zealot. People started calling me Mr. Lean, and I felt good about that moniker. What I should have felt was the need to be a little more business savvy.

By that, I mean that I should have been doing a better job of framing Lean as an approach to achieving our business objectives. I was such a believer in Lean that I never felt the need to translate the benefits of Lean into dollars and cents. Unfortunately, many business managers only speak the language of accounting. I should have recognized that fact and adjusted my approach accordingly. That was an extremely hard lesson to swallow.

Lesson Learned: It's hard to fit a square peg in a round hole.

Following my time as Mr. Lean at PHH, I got deeply involved with the company's large-scale military construction projects. These projects were completely different from any work we had ever done before at PHH. Not only was the complexity of the buildings much greater than our normal product, but we also had a much larger scope of work being performed on-site (as opposed to in our controlled homebuilding factories). To top it all off, we had the pleasure of complying with the labyrinth of federal and military regulations pertaining to these types of projects. This was definitely not our bread & butter work.

But, it wasn't the complexity, or the huge scope of work, or the mother lode of bureaucratic red tape that caused us the most problems. It was actually our organizational structure that hurt us the most. Without going into great detail, PHH has always been organized around ongoing manufacturing operations, as opposed to temporary construction projects. As expected, PHH is quite experienced and competent at managing operations, but much less so at managing projects. Making the transition from our traditional type of work to large-scale construction projects was a huge challenge for us.

Fortunately, PHH has a great organizational culture to help mitigate the shortcomings of its organizational structure. The culture essentially smooths out the square peg so that it fits nicely into the round hole, albeit with a good deal more effort and stress involved. But that's Palm Harbor Homes in a nutshell--not a perfect company, but a company with a team full of people willing to do whatever it takes to get the job done. This wonderful organizational culture really sets PHH apart from other companies I've dealt with in my career.

Final Thoughts (Jerry Springer style)

I learned a lot in my seven years at Palm Harbor. The four lessons learned mentioned above are just the ones that stick out to me at this transitional moment. They are the ones that have resonated the most with me, and that will help me the most in my career, but there are literally hundreds of other important lessons that I've learned over my seven years with PHH. My entire time with the company was one giant learning opportunity.

I suffered through many mistakes, and enjoyed many successes. The company allowed me to try a wide range of jobs, and gave me serious management responsibilities early and often. This is a great business best practice that I wish every company utilized. I just can't see how I could have had a better environment in which to mature professionally.

On top of it all, I made friends for life while at PHH. Some of the people I worked with are just incredible. I could not have asked for a better place to begin my career. While I'm anxious and excited about the future, I'm appreciative and respectful of the past seven years. Thank you to the entire Palm Harbor family.

My Scrum Infatuation

I'm infatuated with Scrum. I had heard the term before, but never really knew what it meant. This past week, I was lucky enough to attend a lecture on the subject by Dr. Tom Sheives with the University of Texas at Dallas' Project Management program. Keeping in mind that this four-hour lecture/discussion was pretty much my first and only exposure to Scrum, I gotta say I like the concept a lot.

The Scrum Process in a Nutshell

I won't go into the history of Scrum, or how it fits into the Agile Project Management methodology, but you can read all about it here on Wikipedia. I'd rather just focus on one of the visuals that Dr. Sheives used in his presentation (courtesy of Mountain Goat Software):

This gorgeous graphic explains at a high level how Scrum works. Going from left to right on the graphic, here is the Scrum process:

1. Product Backlog is established by a Product Owner
2. Blocks of the Product Backlog are moved into the Sprint Backlog and decomposed into smaller chunks of work
3. The project team processes the smaller chunks of work in 2-4 week intervals called "sprints"
4. There are also 24-hour feedback loops during the 2-4 week sprints that include Daily Scrum Meetings
5. The Scrum process yields an output called a "Potentially Shippable Product Increment"

Interestingly, on projects utilizing Scrum, there is no project manager per se. There is the previously mentioned Product Owner, who decides on the features of the product and prioritizes the Product Backlog. There is also a ScrumMaster, who supports the project team during the sprints and conducts the Daily Scrum Meetings.

The project team is somewhat self-managing, as the team members decide for themselves how to break down the work in the Sprint Backlog and how to execute the work during the sprints. This approach to project management is quite different than the standard approach as defined by PMI's Project Management Body of Knowledge (PMBOK). Not everybody likes this departure from the standard.

Scrum & Lean

To traditional project managers, the Scrum approach seems risky and laissez-faire, but not to us Lean advocates. We understand the power of Scrum because it adheres to many principles of Lean:

• Pull...the project team pulls work from the Sprint Backlog, which is pulled from the Product Backlog
• One-Piece Flow...work is processed in small, rapid intervals with frequent course corrections along the way
• Daily Accountability...during the Daily Scrum Meeting, commitments are made, progress is verified, and problems are communicated
• Customer Value...the Voice of the Customer is provided by the Product Owner
• Servant Leadership...the ScrumMaster supports the project team, Gemba Kaizen-style
• Self-Adaptive Teams...the constant change inherent in a Scrum environment tends to yield flexible team members capable of adapting to the needs of the project
• PDCA...the Daily Scrum Meeting and the 2-4 week Sprints allow for frequent PDCA cycles, as do Sprint Reviews and Sprint Retrospectives, which are pretty much self-explanatory

Anybody who has studied Lean can see elements of lean thinking embedded within the Scrum methodology. For me, one of the best ways to tell if something is "lean" or not is to see how traditional managers react to it. While the audience at Dr. Sheives presentation seemed to be curious about Scrum, I definitely sensed some apprehension about using it in the real world. I've seen this same reaction dozens of times in regards to Lean, so I have a good feeling that Scrum is a lean approach to executing project work. This is obviously a silly way to judge the merit of a management system, but it has been surprisingly accurate in the past.

Scrum & Construction

During Dr. Sheives' presentation, one of the first things I thought of was the Last Planner System, which is an approach to construction management developed by the good folks at the Lean Construction Institute. Similar to Scrum, the LPS focuses on short time increments, rapid feedback, frequent course corrections, and continuous planning.

Whereas Scrum was developed in response to the constantly changing product requirements of the software industry, LPS was developed in response to the overwhelming complexity and lack of control in the construction industry. Scrum and LPS are just two variations of the same concept--lean project management.

Scrum has proven to be a highly effective approach in the software business, just as LPS has in the construction business. However, Scrum seems to be more utilized in software than LPS in construction, which probably points to the cultural and organizational barriers we face in construction. Figuring out how to remove these barriers is key. If we can do this, we can increase the adoption of lean methods in construction and start seeing the same great results that the software folks using Scrum often see.

Work-Arounds in Haiti

A good friend of mine, Mike Wnek (pictured above), was down in Haiti shortly after the devastating earthquake hit there on January 12, 2010. His story was well-documented in the news (click here, here, and here), as he and his contingent were one of the first groups to deliver desperately needed food and water to the ravaged city of Port-Au-Prince.

While tons and tons of supplies and resources were being bogged down at the airport in Port-Au-Prince or being re-routed to neighboring nations, Mr. Wnek was riding shotgun on a rented truck as his group made their way from the Dominican Republic to the Haitian capital with a truckload of survival supplies. Only their courage and resourcefulness made it possible for them to successfully complete their voyages across Hispaniola. Their actions were truly remarkable.

Once I had time to reflect on what my friend and his group had done, I began to assess their actions in an objective way (this is easier said than done when people are performing heroic deeds to save lives). Once I had assessed their actions from a business perspective, I realized that they had made great use of one of the all-time most frequently used tactics--the work-around.

Work-Arounds

Pretty much anybody who has ever worked in an organization has had to resort to work-arounds to get things done. Work-arounds are informal, alternate methods for completing work that frequently arise in response to ineffective formal work processes. Basically, whenever doing work the normal way is just not practical, we resort to the path of least resistance.

Folks in the the Lean world understand this concept all too well, as the presence of work-arounds is one of the best indicators of poor process flow. Sometimes a process is unreliable, thus requiring an expert to babysit the work. Sometimes there is too much buffer between processes, thus requiring an expediter to push the work to the front of the line. There is no limit to how many work-arounds we might find in a workplace.

Work-Arounds on Projects

On projects, every bit of the work might be completed through work-arounds. This is quite common in organizations that are not organized for project work. These types of organizations typically feature a traditional vertical hierarchy, and are usually geared for only ongoing operations, not temporary projects.

The unfortunate soul who is assigned to lead a project in this type of organization usually has to navigate a byzantine web of work-arounds cutting across several vertical silos to get anything accomplished. This sounds a lot like what my friend, Mike Wnek, had to do in Haiti.

Quick Fix in Haiti

When it became apparent that the most obvious needs of the earthquake survivors, food and water, were not being met by the official agencies in charge of the relief effort, Mr. Wnek and his group immediately constructed a makeshift work-around to get aid flowing. They went to small grocery shops in the Dominican Republic and bought their entire stocks of food and water, and then proceeded overland to deliver the goods.

Forget the airport. Forget the air drops. Forget bureaucracy. Forget red-tape. Just get food and water to the survivors! This was a classic example of the use of work-arounds, albeit in a highly remarkable context.

Learning from Haiti

Why did my friend and his group have to resort to these desperate work-arounds? Why didn't the aid start flowing into Port-Au-Prince sooner from big relief agencies? Why did the focus early on seem to be on riot control instead of the delivery of survival resources? Why were evacuation efforts diverted? Why was the airport bogged down? Lots of questions.

If we can say that disaster relief efforts are a form of project, then we can probably deduce that many of the same factors that we see on everyday projects are in play on relief efforts as well. Maybe we have vertical silos that aren't communicating with each other. Maybe decision-making is not being made by the people who understand the situation on the ground. Maybe not enough contingency planning had been performed (there is no time to plan a relief effort after the fact). Many factors could have contributed to the delays in Haiti, but there's no way to completely understand the situation from afar. Maybe an expert in large-scale project management will someday publish a case study on the response to the Haitian catastrophe.

Moving Forward

Understanding the lessons learned from Haiti is critical. Without it, we are doomed to repeat the failures of Haiti, Katrina, and elsewhere. But we can not blame individuals! The people working on disaster response projects deserve our respect and appreciation. Just as on everyday projects, the system is usually the culprit, not the individuals. We need to have better project delivery systems in place to support the efforts of individuals.

If we don't improve our systems, we better pray that we never find ourselves in the middle of a natural disaster. After all, there are only so many people like Mike Wnek who have the ingenuity and courage to establish a lifesaving work-around supply chain in a disaster zone. Do you want to rely on heroics?

3 Lean Tools for Improving Construction Reliability

The Opportunity

“Let me get this straight, you think we should reduce our inventory of cabinets? That’s our safety buffer! What are we supposed to do when the hot glue machine breaks down again and we can’t build cabinets, huh? We gotta have a buffer.”

That was the reaction I got from a construction manager upon hearing my suggestion that he winnow down his inventory of finished cabinets (this was on a construction project where the cabinets were being prefabricated nearby). His response was valid, but so was my suggestion.

From my perspective, I saw several problems with the excess inventory—problems that are usually associated with this form of waste: finished cabinets were getting damaged as they sat around, they were often in the way of installers working in the building, and they were even creating a trip hazard for any passersby. It was not pretty.

From the perspective of the construction manager, he saw any reduction in cabinet inventory as a risk to the project schedule. His point was that if he eliminated his safety buffer, the unreliability of the cabinet-building process could cause cabinet production to halt, and potentially cause construction delays. Not only did the cabinet shop folks have problems with the hot glue machine, but they were also dealing with a whole host of other issues that created variation in process results: untrained cabinet builders, a messy workshop, conflicting production schedules, etc. Again, it was not pretty.

The Lean Approach

So, what to do? What would you, as a lean thinker, do to create more reliability in the cabinet-building process? I’m certainly not an expert in the lean methodology, but I have seen some practical lean tools applied to construction processes that have yielded improved levels of process stability. Here are 3 of my favorite such tools:

1. Tool # 1—5S Visual Workplace

We all know about 5S by now, I’m sure (check out JC’s excellent blog post). It’s a fantastic tool that can really help us create visual control of the workplace, so that we can spot abnormalities quickly. This would help reduce variation in the cabinet shop by reducing time wasted looking for tools and materials, as well as by eliminating the chance for a lost-time work accident by removing safety hazards from the workspace. This would no doubt help improve the stability of any construction process.

Construction Industry Particulars...

However, applying 5S to a construction site is a bit different than in a traditional workplace. The main difference is that construction projects are temporary in nature, while ongoing operations tend to be a little more permanent (although a wise strategy would be to design the workplace to be flexible enough to change with the times). This means that a 5S process designed for construction sites would need to be able to be implemented during a short ramp-up period, flexible enough to accommodate multiple stages of construction, and exceptionally easy to understand for those random people that tend to visit construction sites (inspectors, salespeople, etc.).

What other barriers exist to using 5S in construction?

2. Tool #2—Preventive Maintenance

Just like factory workers depend on conveyor belts, press machines, and welding robots, construction workers depend on their ladders, generators, and hand-tools. Unlike lean factory workers, most construction workers do not perform much preventive maintenance for their equipment. Often, equipment is just loaded up at the end of a long work day and tossed in the work truck. Worse yet, construction equipment is often exposed to Mother Nature in ways that most industrial equipment is not. This leads to a ton of equipment failures that slow down our construction processes, much like the hot glue machine did for our cabinet shop. A great approach for mitigating this source of variation is to implement basic Preventive Maintenance (PM) procedures.

Construction Industry Particulars...

PM is not a difficult concept to explain, but a frustratingly difficult tool to implement in the construction industry. This probably has more to do with bad habits than anything, so the big challenge is creating a work culture than encourages good habits. Instead of making it a habit to knock off work at the last second before the sun sets (which leaves little time for Preventive Maintenance), we should build-in time to inspect and repair our equipment. Instead of making it a habit to drag equipment on the ground, we should make sure that our people have better ways of transporting heavy items. Bad habits are hard to break, but the benefits of having reliable equipment far outweigh the costs of making a cultural change.

Do you think it would be too hard to get buy-in for PM based on your experience?

3. Tool #3—Job Instruction

Job Instruction (JI) is another great tool for improving process reliability. With construction processes, a lot of variation comes in the form of different techniques being used by different installers. Often, you can observe two installers building cabinets in four different ways. This is not good for consistency.

JI helps mitigate this source of variation by providing us with an effective approach to teaching standardized processes. Once we have established a set of best practices for cabinet building, we can incorporate them into a job sequence that can be taught using the Job Instruction method. This is a great tool for training new installers and cross-training veteran installers. By properly training our people, we can reduce variation between installers and greatly reduce the chance of human-related errors occurring.

Construction Industry Particulars...

The difficulty of implementing JI in the construction industry is that quite often the work is being done by sub-contractors who are not always amenable to being trained. Their business relies on having a reputation for knowing how to do good work, so nobody wants to submit to training, as that is an indication that they are still learning how to do good work. This is a huge cultural, systemic issue in the construction industry.

One way to overcome this barrier is to take the Toyota Way approach of investing in long-term suppliers. Choose sub-contractors who are open to long-term learning and partnership. Provide them with training on how to perform JI, and let them become their own trainers. Work together to develop the standard job sequences that are being taught. Include JI as part of the statement of work for the contract. Think long-term.

Do you foresee construction managers allocating time for JI?

Reflection

The three tools listed above are just a few of the many available in a lean construction manager’s toolbox. What other tools might you recommend for our cabinet shop? Do you think the tools I listed are appropriate given the situation I’ve described in the cabinet shop?

Of course, the particular tool chosen is not what’s important; it’s the thought process that counts. The thought process should be to look for barriers to creating better process reliability, and then pick the right tool to address those barriers.

Eventually, as we stabilize individual processes, we can begin to reduce our buffers and improve the flow between processes. This leads to problems being surfaced more easily, and to waste being systematically eliminated from our processes.

In the case of the cabinet-building process, if we were to implement 5S, Preventive Maintenance, Job Instruction, and other appropriate tools, we should see an improvement in process reliability. This would allow us to lower our inventory of finished cabinets at the job site, which would in turn eliminate the wastes associated with excessive inventory. This would lead to what we all lean thinkers want—better results.

Do you agree with my hypothesis? Do you have an alternative approach?

Technology is Cool, Collaboration is Better

When it comes to utilizing technology in the construction business, I'm a little ambivalent. On the one hand, I consider myself an early adopter of technology (for a construction guy anyways) who can't have enough Google apps and online social networking tools. On the other hand, I'm a firm believer in the Toyota Way principle of "Use only reliable, thoroughly tested technology that serves your people and processes." I'll often get all excited about some new project management software, only to be reminded that many of my project stakeholders don't have work computers or aren't too proficient at using even basic software. It's a major barrier that we must overcome in the construction industry, because there are some technology tools that could serve our people and processes well.

While this technology barrier won't be eliminated in the short-term, I still plan on utilizing technology tools whenever and wherever I can on my projects. For example, one tool in the pipeline that I'm really excited about is Google Wave. If you haven't heard anything about it yet, you can check out this long demo video here or a good assessment from a construction industry perspective here.

I really think that Wave can be a powerful means of developing project knowledge and building consensus among the project stakeholders. While I love the technology, it's the focus on collaboration that really appeals to me, not the tool itself. Even if I can never convince any project stakeholders to get on-board with Wave or other tech tools, the focus on collaboration can still be a constant part of the projects I manage.

By that, I specifically mean that I can treat project planning as a collaborative activity. If you think about it, building a project plan is nothing more than building a common base of knowledge and agreement that all project stakeholders can refer to throughout the project. The project plan is the standard by which the project will be managed, and as with any standard, the people involved with the work must lead its development. This is why Google Wave has the potential to be a powerful collaboration tool; it efficiently allows anybody we designate to contribute to the knowledge base and have a say in the project planning process, real-time and with rich multimedia communication. It's an awesome tool!

That being said, Wave is by no means the only collaboration tactic available to us. If we have folks with limited tech skills, as we often do in the construction industry, we can always fall back on more low-tech solutions. A face-to-face meeting, properly facilitated, is still an excellent approach. Regardless, the format is not what's most important; it's the end result that matters.

So, while I'm all for the construction industry shedding its Luddite past, and even though I'm tremendously excited about Google Wave, I think it's much more important for us to first start seeing collaborative project planning as a "must-have," not a "nice-to-have" element of construction management. While some folks, like proponents of the Last Planner system, have been actively promoting collaborative construction management methods for years now, a huge majority of builders still defer to the old-school "boss man" archetype. This has to change. No amount of technology will be enough if we fail to make this philosophical leap to collaborative planning.

Eliminating Tunnel Vision

One of the most overused sayings is "Don't miss the forest for the trees." While it may be an annoying cliche at this point, we in the construction industry would do well to remember it as we manage our projects. I say this because I've found that construction project managers, including myself, often get so caught up in the technical construction requirements that we miss the overall conditions that must be met before we can call our project a success. In other words, we focus too much on assembling buildings and not enough on managing projects.

Typical construction industry approach...

When you put a bunch of veteran construction managers and superintendents in a room to discuss an upcoming project, the focus of the conversation is almost always on the specifics of the construction work. Rarely is the focus on the project management activities that must occur in order to bring the project in on-time, under-budget, within scope, and with good quality. Construction folks are typically really good at envisioning the construction deliverables that are required to assemble a building; however, they're usually not so good at envisioning the administrative deliverables that are required to successfully complete a project. Why is this?

Well, many construction project managers have solid backgrounds in construction (as installers, superintendents, engineers, etc.), but oftentimes have much less knowledge of standard project management best practices, such as Scope Management. For this reason, a lot of administrative-type deliverables are unaccounted for on construction projects. This is a huge risk!

Failure to deliver on any project requirement can cause huge problems. For example, if we fail to plan for team-building activities, our project group will probably have difficulties becoming a high-functioning project team. If we fail to plan for stakeholder communication, we can have all sorts of misunderstandings and overreactions. If we fail to plan for collaborative scheduling sessions, we can have wildly inaccurate schedule updates. None of these activities are directly related to assembling a building, but are just as critical to the overall success of a project as pouring a level foundation, framing a square wall, or setting sturdy trusses.

So, how do we go about doing a better job of meeting all project deliverables?

The Lean approach...

First, we need to get good at hearing the Voice of the Customer (VOC). The VOC is a central element of Lean thinking, and hearing it is a talent than all Lean thinkers must acquire. One of the best commonsense strategies for hearing the VOC is to get out of the office and go talk to your project stakeholders. We shouldn't try to predict our stakeholders' needs; we should just ask them! We shouldn't try to be the know-it-all construction manager; we should be the facilitator for communication. We don't have all the answers, but we can get them easily by just listening to our stakeholders.

Second, we need to get good at performing Scope Management planning. This is a standard part of the Project Management Body of Knowledge (PMBOK), so it's nothing new to professional project managers; but, it may be somewhat foreign to traditional construction project managers. The good news is that Scope Management planning is not all that complicated. The PMBOK guides will take you through the details, but it boils down to defining the project scope, breaking it down into manageable pieces, and having a gameplan for adjusting the project scope as necessary throughout the course of a project. By going through these steps, we develop a Project Baseline that we can use to ensure that we're delivering on our stakeholder requirements.

So, hearing the VOC is the social skill that we must learn, while performing Scope Management planning is the technical skill we must learn in order to eliminate tunnel vision. By eliminating tunnel vision, we are no longer blind to all the project deliverables that we might otherwise ignore. Ignoring stakeholder requirements is a big reason why the construction industry is infamous for being unreliable and disagreeable to work with, and is a construction management practice that must end. If we as construction project managers can learn to hear our stakeholders and properly plan for managing the project scope, we can fulfill all the project deliverables, not just those related to slapping a building together.