Archive for the 'Language Action Perspective' Category

Air Products Uses Lean Construction for Planned Outages, Paul Wood

Friday, September 23rd, 2005

[Notes from LCI's 7th Annual Lean Construction Congress]

Air Products operates plants that make The goal is to reduce the outage duration to the shortest time possible then hit that duration…no kidding! The plant straddles a rail link. The outage was planned to do control system modification. They were also adding automation throughout the process.

They planned a staged migration. They started with "outages of opportunities" to do as much work ahead of time as they could. They did the outage in 3 weeks rather than the usual 3 months.

Done meant done!

They designed the project using Last Planner techniques:

  • People responsible for the work did the plan
  • Gave their attention to handoffs rather than process
  • Work was organized into packets with clear description of completion
  • Sequenced the work using a pull process

They operated to a set of principles:

  • Teams were autonomous. They worked to an irreversible level of completion. Done meant done!
  • Daily workplans, one/phase/day
  • Planning process
  • Used a decoupling approach that aided in the debugging of the installation.
  • Couldn't wait 'til the end of the process to do inspection. They could afford to build good work onto bad. They planned for immediate inspection when workers announced they were done.
  • Punchlists are to be avoided. Inspectors are to communicate the standards for performance to the installation workers so they can pass inspections.

85% PPC (for Air Products) would have been a failure.

They regularly reviewed their workplans in a workshop format to coordinate among the crews. Each contractor had a daily workplan. They held shift-to-shift hand-off meetings with the last planners. The conversation focussed on what needed attention to stay on schedule. They achieved a 98.8% PPC. They refused to allow people to work ahead to avoid getting the work out of sequence. Planning for the 14 day outage took 3 months totaling about 500 hours.

The Air Products outage approach conforms to the language-action perspective.

What Did You Hear?

  • Shooting for predictability rather than productivity
  • Don't tap the keg before checking that the toilets flush
  • Impressed with how quickly you got the last planners engaged
  • Early on key people were brought in to make accurate promises kept in reasonable times
  • They did everything possible in downtime to avoid the p
  • People responsible for the work did the planning
  • Don't work ahead or outside of the plan
  • Struck by the level of detail…seemed more like a choreographed dance than a plan
  • Team leader dedicated to each of the phases
  • Inspectors encouraged to help the contractors succeed rather than catching them fail
  • Classic example of the value of planning
  • The notion of the irreversible level of completion
  • Concentrating and discussing the handoffs causes planning to breakout
  • Working on unapproved work is unsafe

Audience Questions

  • Was it difficult to get the last planners involved early on?
  • How did cost play into this?
  • How did you establish the initial 21 day goal?
  • Did you have a list of workable backlog?
  • How many total man hours were involved?
  • Was the effort to plan this way driven by the company?
  • How is
  • Look at extreme circumstances to predict the future. How did actual unit rates compare to your plan?
  • What was the opportunity cost of doing the planning vs shutting down the plant?
  • How many total activities did you manage?
  • Could the inspection teams been replaced by self inspection?
  • How did you provision the site?

Closing Comments

Steven Convey says, "Trust has two hats: the first is competence, the second is character." It's a helluva time in the middle of an outage to find out you have a snake in the grass. By working on the plan way ahead of time I got a feel for the guys I could count on.

It wasn't difficult getting last planners involved. We used the same individuals during the outage as we used for ongoing maintenace and operations.

We set the 21 day goal by looking at the pace of a long phase. We managed 800 activities taking about 7100 hours. Cost planning was done on a fixed unit price basis. The subs made more money than they expected and they went home early! They identified workable backlog prior to the outage, but didn't have one during the outage.

The project was done on the basis of "Let's see if we can do it?"

Greg Howell: Air Products has about $75 million of projects underway using LPS. They recently conducted a pull planning session prior to asking for the bids. In this case the company that knows the most won the bid.

| Convert this post to a PDF document.

Related Posts

PMI-OC in Action

Sunday, August 14th, 2005

My hat's off to an amazing group of organizers and volunteers of the Orange County PMI Chapter. Saturday's PMI in Action event brought out about 150 people on a sunny day. The agenda was packed. The speakers did a great job from Mark Mullaly's keynote "What Makes a Great Project Manager" to David Anderson's back-to-back sessions on Agile, Deming, and the the use of cumulative flow diagrams (CFD) for managing project work. (More on CFD in another post.)

I did my two presentations on Let's Play Catch! and Why Do Projects on a Lean Basis? They were well-received. I've uploaded them for you.

| Convert this post to a PDF document.

Related Posts

Invite Performers to Decline

Monday, July 4th, 2005

In the last week saying "No" on your projects is getting attention. Thanks to Frank Patrick for pointing us to postings from Jeffrey Phillips, Getting to No, and Ester Derby No Is in the Air. I couldn't help but add my two cents Be Responsible, Say "No". Long time readers know this as one of my soap boxes. In November 2002, I was writing about uncertainty Reduce Uncertainty by Promising Reliably.

Promising is in our control. We can say "yes" or "no". (I know some people think they must say "yes" to keep their job.) When we say "yes" but we mean "no" we add uncertainty to the project. When we say "yes" but fail to allocate sufficient capacity to the task (blocking time in our calendar) we add uncertainty. When we say "yes" but don’t understand what will satisfy our customer we add uncertainty. Do I need to go on?

A few years earlier (1994) Greg Howell and Glenn Ballard, both of the Lean Construction Institute, wrote the paper, Lean Construction Theory: Moving Beyond 'Can-Do'. They claim that we can't improve our project performance without people saying "No".

(C)urrent management approaches are built on and entice dishonesty. We cannot improve performance unless new thinking exposes the contradictions and weaknesses in our underlying mental models and injects certainty and honesty into the management of projects. It is simple in concept and not hard in execution once we take the challenge of no longer accepting "Can Do" when "Won’t Do" is appropriate. Only then will we have the consistent feedback needed for rapid learning.

The idea of saying "No" as being responsible has been around for quite some time. While "simple in concept and not hard in execution", we still get far too many yeses when no is more appropriate. It may be simplistic to suggest fear is in the way of saying no.

Here's one action you can take to get the no you need to get. Make it your routine to invite people to say "No". Only then will Can-Do mean anything. That's right, by inviting people to decline requests you and others make you are creating the situation for honest conversations among your team. It's in that setting of honesty that we can be most successful.

| Convert this post to a PDF document.

Related Posts

Hope Is Not a Project Strategy, The Project Reformer’s e-Tip

Tuesday, April 5th, 2005

There are warning signs that commitments might be missed. Learn to focus your listening on a speaker's doubt.


The Project Reformer's e-Tip of the Week
040:Hope Is Not a Project Strategy

I've been having some fun lately attending clients' project meetings. It's great seeing project teams plan collaboratively and make commitments to accomplish work. But, I'm worried. I don't recall attending a meeting where someone hasn't said, "I hope to get this done by…" and then the meeting just moves along to the next item. I'll repeat here what I say every time I hear "I hope…"

Hope is not a project strategy.

When we say, "I hope…" we are announcing some doubt we have about what we are setting out to do. Don't just continue in the conversation. Explore the doubt. What is it that is beyond our control? What are we missing to carry out our promise? Who are we depending on for wherewithal? Answering these questions (and others) can shift mere hope towards confidence — one way or the other — of fulfilling our promise.

Replace the positive attitude of hope with positive actions for results. Our team is expecting nothing less from us.

This e-Tip was inspired by a participant comment at a workshop and the book Hope Is Not a Strategy: The Six Keys to Winning the Complex Sale, by Rick Page. href="http://www.complexsale.com/HopeIsNotAStrategyreview.pdf">Read the 10-page book summary.
The Project Leaders' Studio™


©2005 Hal Macomber | RPM | e-Tip Archive | PDFs | Submit Tip

I have four more e-Tips in queue. How about some suggestions from readers?

| Convert this post to a PDF document.

Related Posts

Tyranny of Managing as Decision-Making

Tuesday, November 16th, 2004

What is management? We train some of our managers in business school. They study marketing, accounting, finance, statistics, operations, policy, organizational behavior, economics, and decision-making. Recently, students also have courses in ethics, leadership, and entrepreneurism. Dig into the syllabus and you'll find an emphasis on making good choices. That's right, to manage is understood to mean be the decision maker. What a burden.

It's time we gave up the notion that the head of the organization can control the body.

I'm not saying our future managers needn't study the above subjects. Those subjects introduce the wanna-be manager to the everyday conversation of managing. However, I am saying that managing as decision-making as a way of understanding the primary role of a manager is obsolete.

The managing as decision-making paradigm is left over from the time when we thought the head is smarter than the body. The one person on top tells the rest what to do. The brain controls the rest of the organism. Armies, the Roman Catholic Church, and governments worldwide have been based on that view. We now understand organisms don't work this way. It's time we gave up the notion that the head of the organization can control the extensive body of autonomous thinking and caring human beings.

There's no reason to accept a portfolio of projects where a few succeed while the others miss important objectives.

So what is it that managers do in this alternative view of an organization? They cultivate conditions or circumstances for performance. Managers care for the promises to the customers, the network of commitments for delivering on those promises, and the well-being or futures of the people they manage. Giving one more importance over the other won't succeed in the long-run.

Greg Howell, Lauri Koskela, John Draper, and I authored a paper which we presented at IGLC-12, in Denmark, titled Leadership and Project Management: Time for a Change from Fayol to Flores. In that paper we contrast the prevailing style of project management with a style we see emerging. We don't think you need to settle for lackluster project performance. There's no reason to accept a portfolio of projects where a few succeed while the others miss important objectives. I could say that we need to make numerous changes to the way we do projects, but I won't. We need to make one significant change. Give up the tyranny of being a manager who has to make the right decisions. Instead, create planning conversations in your organization and on your teams that continue to unfold with the changing futures. The success of your projects depends on it. Even more, so does your sanity!

| Convert this post to a PDF document.

Related Posts

Update to Securing Reliable Promises on Projects

Monday, August 30th, 2004

Securing Reliable Promises on Projects
Back in July 2001 I wrote this paper on promising that I later made available through this weblog. The paper is one of the most-accessed files on the site. Based on some recent inquiries I've updated it.

When I wrote the paper I was attending to a missing skill I observed on project teams implementing the Last Planner System®. People on the jobsite didn't have the habit or the skill of making commitments. I wrote the paper to aid the project manager and the superintendent to get promises where they are needed. Later, I developed a clearer interpretation of planning and control on projects: planning is conversation that both prepares performers for action while dealing with uncertainties and activates the network of commitment. With this interpretation securing reliable promises is more important.

Take another look at the paper. Make copies. Share with your team. And, here's access to Securing Reliable Promises on One Page. Hang it where everyone will see.

| Convert this post to a PDF document.

Related Posts

Two Great Wastes™

Sunday, August 15th, 2004

The Taiichi Ohno 7 wastes of production are a simple and elegant way to focus improvement actions in production process settings. The 7 wastes are taught to teams who use them as a way to observe, assess, and improve process to provide more value. The 7-item taxonomy has been so successful that it is one of the first aspects of lean thinking that is adopted.

Is the taxonomy complete? Many people think not. People have been tinkering with the taxonomy starting with the book Lean Thinking, by Jim Womack and Dan Jones, who proposed the eighth waste to be providing something that the customer doesn't value. Others followed suit making 7 other proposals that I could find. Read the rest of this entry ¶

| Convert this post to a PDF document.

Related Posts

Project e-Tip 031: Make the Next Performer in Line Your Customer

Wednesday, August 4th, 2004

Project tasks are usually dependent on prerequisite tasks. Variability in the performance of the prerequisites can have significant impact on the downstream activity. Getting done when you say you will is one key. But that's not even half of the issue. We need to complete work to the conditions needed by the following performers. This week's Project e-Tip has a proposal for this. It comes from a reader in Canada.


The Project Reformer's e-Tip of the Week
031: Have the Next Person in Line Say when Something is Finished…"Done-Done"

We have all seen those instances where someone reports that a deliverable is finished but the people who need that deliverable disagree that the plan reports progress that has not been made. A common example is when programming is supposed to produce error-handling instructions to computer operations for the code that they deliver. A useful discipline is to not be able to report complete unless the receiver accepts the deliverable as complete. This encourages project performers to communicate and make clear what their requirements and capabilities are earlier in the project. Through time it improves planning and estimating by making the concept of internal acceptance a requirement.

We've heard people use the expression done-done. The first "done" is the statement the performer makes when completing the task. "I'm done." The second "done" is what the next person in line says. "Looks done to me." Don't settle for anything less.

This e-Tip was suggested by David Waller, Work-Words, Ontario, Canada. David runs a project management coaching and business communications consulting company, 905-468-8484.
The Project Leaders' Studio™


©2004 Hal Macomber | weblog.halmacomber.com | e-Tip Archive | PDF | Submit Tip

Share this e-Tip with your project team. And then ask them what advice they have for others. David Waller is receiving the book The Blind Men and the Elephant, Mastering Project Work, by David Schmaltz as a reward for publishing his proposal. There are more prizes where that came from! Get one for yourself.

| Convert this post to a PDF document.

Related Posts

Evolution of Lean Projects

Monday, August 2nd, 2004

As I approach the 2nd anniversary (on Aug 26th) of writing Reforming Project Management I reflect back on the various topics I've covered in these pages. When I started writing I considered using a name for this weblog that included the word "lean". I had a hunch that it would be limiting…that the reform of project management would necessarily consider other elements, theory bases, and interests. Since I continue to write about lean project delivery I thought I'd give some attention to lean, the roots in the Toyota Production System (TPS), and the influence on projects.

The Last Planner System (one aspect of lean project delivery) places the emphasis on the collaborative planning (coherence of commitment-making and fulfilling) of project teams.

Robert Hall, editor of Target, the magazine of the Association for Manufacturing Excellence (AME), wrote about lean and TPS in the 3rd issue of 2004 'Lean' and the Toyota Production System. Hall distinguishes lean from TPS in the programmatic application of techniques and approaches from the Toyota practice of infusing the DNA of TPS at the worker level establishing habits of problem-solving and continuous improvement.

Early adaptations of the TPS and lean to the construction project environment came on the heels of an emphasis on productivity improvement. The Last Planner System of Production Control™ developed with the intent to improve the quality of worker assignments. A big breakthrough came upon the reading of The Goal, by Eli Goldratt. The LPS founders came to understand that production throughput depended on dealing squarely with dependence and variation. The LPS began to be viewed as a reliability planning system rather than a production optimization approach. A few years later the work of Fernando Flores brought attention to the opportunity the LPS offers for attending to the conversations on projects. Planning was newly understood as conversations for action.

My view of projects has evolved in these two years of writing. I now see projects as single-purpose endeavors undertaken by temporary organizations (teams) performed as an evolving network of commitment. The central issue to the performance of project teams is the conversational nature of coordinating action one with the other.

Toyota places their emphasis on the problem-solving skills and practices of teams. The Last Planner System (one aspect of lean project delivery) places the emphasis on the collaborative planning (coherence of commitment-making and fulfilling) of project teams. Does kanban matter to Toyota? Of course, as does, single-minute changeover, visibility management, etc. Likewise, phase scheduling, look-ahead plans, first-run studies, etc. are important to lean project delivery. But what distinguishes both Toyota's approach and lean projects is the emphasis on accessing the knowledge, talents, and judgement of those performing the work.

| Convert this post to a PDF document.

Related Posts

Five Keys for Coordinating Action on Projects

Wednesday, July 7th, 2004


We can all succeed at our projects. The secret is staying nimble to the ever-changing project circumstances and the interests of project participants. The key skill is coordinating action.


The Project Reformer's e-Tip of the Week
029: Coordinate Action for Project Success

Last week I wrote about Measure Plan Reliability as a first and necessary step for improving project performance. People regularly ask me, "Why do projects go bad?" and "What should we be on the watch for?" While project team members are quick to speak about the outside influences that derail their projects, my experience is teams are mostly responsible for the plight of their projects. In other words, the factors for succeeding and failing are within your control. The main issue is coordinating action.

I view a project as a network of commitments. One person makes a promise for completing a task that others depend on for starting their work, and so on, and so on, and… Many project teams never articulate and activate the network of commitment. Instead, they try to manage and take direction by a schedule. This is a recipe for failure. The future is uncertain. No schedule can possibly anticipate what the team members will be doing with each other or in their lives. Consequently, planning must continue on a weekly and even daily basis if the team is to stay on track.

Top 5 Ways to Elminate Miscoordination Variances

  1. Get reliable promises.
    Listen critically for the presence of all elements of reliability.
  2. Anticipate possible breakdowns.
    Prepare actions for circumvention.
  3. Stay engaged with the performers.
    Show interest in others' success and provide help.
  4. Pay particular attention to those actions that make work ready.
    Minor interruptions can result in major task variances.
  5. Acknowledge performers for their success and their efforts.
    Timely appreciation makes the difference.

By honing your project team's skill at coordinating action they will be able to adust and stay on the desired overall project plan.

Next up: Securing reliable promises.

Based on lesson 23 of The First 30 Days on the Last Planner System™


©2004 Hal Macomber | weblog.halmacomber.com | e-Tip Archive | PDF | Submit Tip

Any takers for a Free Prize Inside? I've got a cereal box with your name on it if I publish your Project e-Tip!

| Convert this post to a PDF document.

Related Posts

Projects Are Networks of Commitment

Wednesday, May 26th, 2004

This is the fourth in a series of project e-Tips on the five big ideas reshaping project delivery. As you read this ask yourself, what action can I take today? Leave a comment with your answer.


The Project Reformer's e-Tip of the Week
027: Projects Are Single-Purpose Networks of Commitment

A project is is a single-purpose network of commitment performed by a temporary social system. Unlike recurring business processes, the network of commitment on a project emerges rather than is designed and refined as performers have experience in the network. Performers in a project get one shot through the network. To complicate this project performers come together as strangers. They often lack experience with each others' reliability to perform within the network. Without the experience with each other, project performers will hold out on making their best commitments.

Your role as project leader is to activate the network of commitment on your project. Here are four actions you can take:

  • Set an example of making offers (promises) that take care of the concerns and needs of project performers. People will follow your example.
  • Encourage project performers to make offers and promises that they can reliably deliver. Help them as needed to improve on reliability.
  • Be a good customer for the promises made on your project by offering your help to performers and announcing your anticipation of completion.
  • Be quick to show your appreciation for the completion of promises including being notified at completion rather than at the next project team meeting.

These actions begin to bring project performers together as team members who are taking care of each other while they take care of the project. Doing this publicly provides the basis for people to develop trust in each others' competentce and reliability to perform. And it is just the beginning. Your role as project leader requires continued attention on the functioning of the network of commitment.

The Project Leaders' Studio™


©2004 Hal Macomber | weblog.halmacomber.com | e-Tip Archive | PDF | Submit Tip

I hope you are enjoying this series on five big ideas reshaping project delivery. Only one more to go before I get back to publishing your project e-Tips. And when I do I'll be sending a cereal box as a thank you!

| Convert this post to a PDF document.

Related Posts

Projects Are People-Centered

Sunday, November 16th, 2003

Continuing in the series of postings on variation as an enabler let's explore more of what I mean by "projects are people-centered."

Why do I keep making this point? Because our language in business is so often that of the machine. In the last ten years the computer metaphor has gained ground. Those metaphors hide the nature of what happens on projects. Work doesn't flow like material flows in factories. People don't access their memory bank like computers. That people are not machines nor computers hardly needs saying, but how can we speak of our projects with a vocabulary that brings forth the nature of the project?

Let's start by looking at what constitutes human-ness. I've written about both the social and biological aspects of being human in many postings. Let's fill out five elements for starters:

  • Capacity for language
    This goes beyond our ability to communicate. Dogs and dolphins can do that. Language gives us the power of naming or distinguishing one thing from another often in nuanced ways. Language is what allows us to coordinate action which is central to all projects. Written language provides a basis for sharing with people who are not present at some moment of action or experience.
  • Historical
    Humans have a past, present, future. Not only do we have memories of the past and dreams of the future, but we call on our past in the stories we tell for shaping our futures. This sharing of pasts and futures provides a rich context for what we do in the present.
  • Moods
    The accepted word in use is emotions or more familiarly, feelings. I am using the word mood to make a richer distinction. People in a present situation have an emotional condition that is triggered by some event or action. That triggering usually has to do with some personal experience in the past or one as told to us. That emotional experience is projected into the future shaping what is then possible for us and others.
  • Biological
    Of course we are biological. Have you considered that learning is biological…that it happens not just in the brain, but throughout our system? How about considering that goal-setting and innovation are also biological in nature?
  • Social
    Humans not only act with others, but we do some of our best work, play, learning, and creating with others.

I'll explore these five attributes one-by-one in the coming week, or so. I suggest you start looking at how human-ness creates opportunities and challenges on your projects. Please share what you notice as comments to these postings.

| Convert this post to a PDF document.

Related Posts

  • Business PLUS Design
  • Design for design sake? Not according to BW Best Product Designs of 2005 nor bplusd. Jess McMullin writes, "Value-c...
     
  • Unsettled About Variation
  • My exploration of variation started with a chapter title The Corrupting Influence of Variability in Factory Physics (2nd...
     
  • Build Trust on Your Team
  • I've been travelling extensively for the last week. Somehow, client work took a priority over blogging. (Imagine that!...
     
  • Language Action Perspective
  • Fernando Flores made the language action perspective popular in his books Understanding Computers and Cognition, Disclos...
     

No Commitment, No Breakdown, No Problem!

Tuesday, November 4th, 2003

Let's start with my definition of a breakdown:

An interruption while in the midst of fulfilling ones commitment jeopardizing the completion of the commitment.

In the previous five postings I described three actions for preparing for breakdowns:

  1. Make commitments at the last responsible moment by engaging in recurrent conversations exploring, "Is it time to act?"
  2. Make our commitments with confidence that we have what we need to fulfill the promise.
  3. Distribute accountability for the outcome of the project by
    • Expand the group of people who can assess and declare breakdowns.
    • Empower those people to take compensating action.

Those are the summary points. Here's my summary commentary:

The failure to take our own promising seriously is the principal source of breakdowns and therefore project delays, dissatisfactions, and budget busts.

Breakdowns are inevitable…in life. We've seen that as humans we must make commitments to just get through the day's events. We tell our children we'll meet them at the soccer field. We tell our spouse we'll deposit a check. We tell our mechanic we'll drop the car off before 5:00 PM. We promise throughout our day accumulating like charges on our credit card. At some moment we must make good on each commitment. Others are depending on us to do so.

Projects are exactly the same. We are continuously making and re-making or re-negotiating our commitments to complete some aspect of the project by a given time. We do this so others on the project can plan and perform their work. When anyone of us on a project fails to manage the commitments we make, or worse, when we fail to make commitments, then we bring about the situation for one breakdown after another. The failure to take our own promising seriously is the principal source of breakdowns and therefore project delays, dissatisfactions, and budget busts.

Designing our projects to be tolerant to breakdowns is simple. Deciding to take that action is another matter all together. I've laid out the steps. Now step up and make it happen.

| Convert this post to a PDF document.

Related Posts

Back to Designing Breakdown-Tolerant Project Environments

Monday, November 3rd, 2003

I last wrote about Designing Breakdown-Tolerant Project Environments in a four-part series: [1] [2] [3] [4]. It's not complete — my thinking that is!

I keep thinking about uncertainty and variation. One of my clients says we are preoccupied with making our futures certain. Wondering, I think we just don't have enough trust in the strength of our relatedness. The more related we are, the greater chance we have of a future that is perfect. Yes, I know this is philosophical. So am I. However, I see this like luck. There is no luck. There is only preparation meeting opportunity. (Anyone know where that came from?) The best preparation we can make is in getting connected with others. By doing so, they will take care of us as we take care of them.

So…I have more to write, particularly a summary of what I started. That'll have to wait 'til tomorrow!

| Convert this post to a PDF document.

Related Posts

Designing the Project Environment for Resilience to Remaining Breakdowns

Tuesday, September 23rd, 2003

Life happens. It just does. If we wake up in the morning we are bound to be surprised at some moment during the day. I bought a Jeep Wrangler to share with my about-to-be 17 year-old son. The vehicle had 71,200 miles on it when I purchased it. I was naturally concerned about the condition of a Jeep with that many miles. So I asked many questions of the salesman. Each answer was intended to reassure me. I asked, "When I