People frequently ask me for advice on adopting a lean approach on their projects. I write them, either by email or in Yahoo! discussion groups. Instead, I've decided to offer my advice in this weblog. Each Wednesday I will post a Project e-Tip of the Week. Subscribers of Reforming Project Management will get the weekly Project e-Tip in their Bloglet email each Thursday morning. If you haven't yet subscribed, then just add your email address in the subscription box to the left. That way you won't miss any of the e-Tips.

I have created an e-Tip Archive (look for the link in the navigation bar above and at the bottom of each e-Tip) and Adobe PDF versions of each Project e-Tip to make it convenient to share these with your team mates. I am looking for a javascript function so readers can email a Project e-Tip to a friend. Can anyone help me with that?

I encourage readers to submit their proposals for Project e-Tips. If I publish your submission, then I will give you a one-year subscription to Business Book Summaries or at your choice a copy of one of my favorite books. Of course I am the sole decision-maker regarding publishing submissions!

Here's my first Project e-Tip

The Project Reformer's e-Tip of the Week

001: Chart the Reliability of Task Completions

How often have we heard, "You get what you measure." Well, the ultimate measure of performance of your planning system is how often you and your team are completing what you set out to do. In Last Planner™ terms we call that PPC - percent of plan complete. It is measured as promised tasks completed divided by promised tasks. Post a chart on the wall in a place where your team meets. Every day (or at least once a week) record the percent of tasks completed as promised. In addition to the percent note the ratio, for instance 7/10. Conduct daily coordination meetings in front of the chart. In no time work coordinators/team leaders/last planners will learn how to promise reliably. Last Planner is a trademark of The Center for Innovation in Project and Production Management www.leanconstuction.org

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

I'm somewhat hesitant to write about this. This morning I received an email newsletter that included advice on How to give negative feedback properly. I can't say that John Reh's ten recommendations are either good or bad advice. Take a look…decide for yourself.

Let's look more closely at what is meant by "negative feedback". When we say "I have negative feedback" what does that mean? It might mean "I don't like you and I'm gonna tell you why." It could mean "I have seen negative consequences and I attribute them to your actions." This might be getting closer. At the heart of it negative feedback is about failing to meet a standard of performance. That standard could be stated or only implied. When we announce we have negative feedback we create a break in the conversation and the relationship. It's an unusual or extraordinary event.

My favorite management author is Ken Blanchard author of The One Minute Manager and dozens of other books. (Anyone who has a best-selling book — over 10 million copies — for over 21 years has to know something about what he's talking.) Blanchard implores people to focus on positive feedback. In his book Whale Done! he goes into how trainers never use negative feedback when working with dangerous animals. If killer whales can be trained to do the spectacular things that they do with only positive feedback, then why would we want to use negative feedback with the even more dangerous human beings? [smirk] Another way of saying that is be unconditionally constructive in all our conversations. Blanchard recognizes that sometimes we are not satisfied with a particular behavior or performance. In those cases he instructs us to redirect the action.

So let's put this in the context of the project setting. Projects are one-of-a-kind endeavors always involving people. The project setting by definition entails novelty. Projects often end "before we know it." For many participants that newness and speed calls on them to learn so that they can perform. Learning fast, making mistakes, discovering what works or doesn't work, are part of the usualness of projects. Of course individuals will at some moment fall short of standards. That is what it means to be a learner.

So what are we to do in projects? Am I saying there are no situations for giving negative feedback? Maybe. The most important step to take is to create a space and practices on the project for the free expression of opinion (assessments). Everyone who signs on for (owns) the mission of the project cares about how well we are doing collectively. Are we on track, or not? Are we learning what we need to learn, or not? Are there unexplored opportunities and risks? Each question is answered with assessments, both positive and negative. Some people will tell you to grant permission for speaking our assessments. NO! Granting permission doesn't go nearly far enough. We must create a responsibility for speaking our opinions…in a timely manner…in helpful ways…positive…with openness to modify the assessment based on what others say.

Timely (in the moment) assessments are the mechanisms for adjustment keeping individuals and teams moving in concert with each other in fulfillment of the project mission. New and revised actions follow assessments. The wonderful aspect about this is with everyone on the project making and sharing assessments we create a guidance system that goes orders of magnitude beyond what anyone in a project controls role could accomplish.

Making assessments — powerful assessments — is one of two foundational skills for functioning in the project setting. The other skill is making and securing reliable promises. Negative feedback is old school. Continuous practices of assessment is the future of project control.

Donna Fitzgerald writes a regular column for Builder.com, The Nimble Project Manager.
She has been writing a series about Peter Senge's book The Fifth Discipline. Her series is very good. Two of the articles are about mental models: How to understand the bias of mental models and Understanding your mental models can help sharpen PM skills. She explains what Senge means by mental models, describes the significance for managing projects, and goes on to introduce techniques and actions.

Fitzgerald contends that the nimble project manager is one who operates with the view that projects are complex adaptive systems. Another way of saying the same thing is project ends and means emerge from the unique interactions of the team members with each other as they respond to an unfolding future. Fitzgerald doesn't refer to projects as linguistic by nature. However, her description of a mental model for project management applies to the linguistic action perspective.

The Mental Model of Nimble Project Management

• It's appropriate to invest the time up front to understand the goal of the project without needing to plan every step along the way.
• Nothing makes up for, or replaces, good people — staffing is everything.
• It's imperative to create a project structure that facilitates good communication — opportunities need to be communicated as well as risks.
• Nimbleness requires knowing when a situation needs to be controlled and when it needs time to evolve.
• All projects are unique in some way. Investing the time up front to understand the uniqueness helps establish the initial area of order.

Compare Fitzgerald's proposed model with Flores' seven claims listed in yesterday's posting Linguistic Action Perspective of Projects.

Fitzgerald proposes two approaches for dealing with the bias of our mental models:

1. Nimbleness requires considering the impossible, the improbable, and the unlikely as a matter of course.
2. (C)reate a culture of creativity on our projects.

She goes on to recommend four specific actions. They fall short. The two above approaches are manifested in conversations. Recurrence is critical. A project manager can design agendas and protocols that explicitly consider the impossible, the improbable, etc. When the team is put in the practice the behavior will follow.

One of the best sections in her article is on Chris Argyris' approach for investigating the seemingly intractable personal conflicts. Argyris calls this left-hand column exercise. Do check it out. It works. I have used the exercise for over ten years.

Warning: these articles will take some time and attention to appreciate what Fitzgerald is saying. I predict it will be worth it.

Before I get too far into these postings on the Linguistic Action Perspective, I think I should speak about my prejudice…

Dr. Flores taught me project management. Not for the first time. No. I learned to manage projects at Digital Equipment Corp. Dr. Flores re-taught me project management. To give you an idea of what it was like, imagine you are a golfer, or tennis player, or skier. You perform well, so well that others strive to beat you. Now you decide to start again as a beginner. Really! Imagine the breakdowns that would create. Now, exaggerate that. That was what it was like relearning project management.

I was already good at creating work breakdown structures. I could teach the critical path method. I did six major projects in a row on time and 'close' to the budget. (I was over as often as I was under.) Thirteen years ago, Flores turned it up-side down for me. How? By shifting attention from the mechanisms of project management to the conversations of project management.

Projects succeed (or fail) not by how well we manage the critical path, but by how well we care for the critical conversations.

Dr. Flores made these claims: (Some of these are from my recollection. Apologies for any misrepresentation.)

1. Projects are always about human beings acting in cooperation with each other.
2. People have moods which influence the direction and outcome of projects.
3. The project is a promise to a customer.
4. Team members individually and collectively own the promise of the project.
5. Team members make promises to the project manager and to each other in fulfillment of the promise to the customer.
6. Assessments of project progress allow for (re)direction of team member actions.
7. Planning is the conversation that continues to unfold the project.

So, now you know my prejudice. I go into new project situations with my eyes on the linguistic aspects. Sure the sequence of work is important…really important, as is the constraint for the project. I've learned that even more important are the practices and systems for coordinating action along with the care given to the varying concerns of the project participants. Projects succeed (or fail) not by how well we manage the critical path, but by how well we care for the critical conversations.

Management by Blog? Some see it coming, but it's not here yet. writes
Jimmy Guterman in this week's Business 2.0 Barely Managing column.

Blogs are popular. This business blogging thing is like a solution looking for a problem. So where might the problem lie? How about the ongoing articulation and activation of the network of commitment? Guterman offered these observations:

The internal weblogs I've seen work are those that track an idea's progress from offhand notion to fully matured proposal. I have seen three such blogs, always-on virtual whiteboards that have sped development and kept the status of projects clearer than they'd been before.

Weblogs can fill a gap in the systems and practices of coordinating action by providing a tool for the team. Some think management's job is to control what is happening on our projects. Let's leave that job to an informed team with appropriate tools.

I've written in this weblog about the linguistic action perspective as it applies to projects. Greg Howell and I have authored a paper to be presented at the International Group for Lean Construction in July 2003 at Virginia Tech. The paper is titled Foundations of Lean Construction: Linguistic Action. I can't publish the paper here ahead of time, but I've decided to explore some of the key points. I'll start by sharing an altogether different view of management.

Fernando Flores, often referred to as a practical philosopher, offered the following definition of management in his doctoral dissertation titled Management and Communication in the Office of the Future, 1982, University of California Berkeley.

Management is that process of openness, listening, and eliciting commitments, which includes concern for the articulation and activation of the network of commitments, primarily produced through promises and requests, allowing for the autonomy of the productive unit.

At the time he was speaking about the work in the offices of business. However, he could have been writing about projects.

Flores is saying that work is accomplished by eliciting commitments with one another. Management's task is to see to the effective workings of the systems and practices employed for making and delivering on those commitments. We can think of projects as temporary business endeavors. There is no time for the processes and systems to mature as they would in the usual business setting. Projects complete too quickly for that. The temporariness of projects calls for more attention, not less, at the outset of a project on the design of the systems and practices that together manifest the "articulation and activation of the network of commitment."

Examples of coordination systems and practices include forums for planning, agendas for detailing tasks and assignments, protocols for capturing commitments among participants, open-item lists for working off unresolved questions, routines for coordination meetings like the daily Scrum. Too often project teams default to what the leader did on the last project or whatever is called for in the company policy. This robs the project of an approach that fits the circumstances and complexities of the situation.

Final remarks on the series on Theory of Constraints

Frank, Joe, and I had fun blogging collaboratively on the Theory of Constraints this week. We hope you enjoyed it too. I want to underscore one point Frank made yesterday.

(M)y role in this series is to remind you that the reason we're doing the day-to-day work lies at the end of a string of days — at the end of probably more than one chain of tasks — and that while dealing with the current and immediate constraints, how we do so must take into consideration their import and impact on the larger constraints of the project as a whole.

We do projects to make good on a promise to a customer. The big promise at the end of it all. This is easy to see when a customer contracts for a new building. The customer is obvious, so are the conditions of satisfaction. But what about internal projects?

None of our advice on TOC matters when we act without a promise to a customer.

So often on internal projects someone has a good idea. S/he assembles a team. And they go to work. This doesn't mean it's a project. If you don't have a customer acting as the customer, then you don't have a promise, nor do you have a project. If you don't have explicit conditions of satisfaction for fulfilling the promise, then you don't have a promise, nor do you have a project.

We make all kinds of mischief (waste) in companies when we don't take care to be explicit about the customer and the conditions of satisfaction. So, as we leave the subject of the Theory of Constraints remember that none of what we discussed this week matters when we act without a promise to a customer.

Stop by and see what Frank Patrick and Joe Ely are up to.

Previous in series

Projects are always constrained. Accept it. Now what? (Day 5 in the TOC series.)

We've discussed three types of constraints, the focusing process for managing constraints, and the perils of multi-tasking in a world that work is not ready. Now what? Let's consider some practices we can employ on a day-to-day basis to operate successfully in the uncertain world of projects.

Manage the project in a way that keeps the constraints busy performing what should, can, and will be done.

• Planning is a practice that runs throughout the life of the project.
  Constraints will change. As the project unfolds plans can change to take advantage of what new is learned.
• Have an everyday focus on doing what you said you would do.
  Being reliable is the first step for improving project performance. It is also the step that allows you to anticipate demands on constrained resources. Reliability keeps the project flowing from one task to the next.
• Shield the constrained resources from variations in the release of work to them.
  The last thing you want to have is a constrained resource standing around. Have a queue of ready work (workable backlog) that the constrained resource can work down if a feeding activity fails to perform.
• Conduct the project anticipating you and the team will learn.
  The work breakdown structure used to plan a project to six levels of detail before the project has begun is not the way the project will be conducted. Keep re-planning. Do it with the people who are closest to the tasks. Adjust your plan considering the emerging talents and competencies of your team.
• Measure your planning reliability.
  How often are people able to finish what they said they would finish? When there is a failure understand why. Not to blame, but to identify the underlying source(s) of the failure. Take action to remove the underlying causes.

Particularly on large or remote projects you can't watch everything all the time. Status reports are rear-view mirrors. By keeping your eye on the constrained resources you will have your hands on the leverage point for your project. Manage the project in a way that keeps the constraints busy performing what should, can, and will be done.

Let's see what Frank and Joe have to say.

Previous in series Next in series

Multi-tasking can be eliminated (Ok, maybe significantly reduced). Day 4 in the TOC series.

We've been discussing constraints, resources in contention, and multi-tasking. Frank's posting yesterday showing the red, green, and blue tasks shows clearly that multi-tasking delays completion of some activities with no advantage to others. How could it be reasonable to follow a rule that resources in contention can only work on one thing at a time? Particularly in the world of projects where we often don't know what is needed from that resource 'til the last minute?

By queuing up ready work for people (resources) they can start work that will be finished.

The trick (technique) is to always have the work for a constrained resource in a condition to be started and finished PRIOR to the resource starting. Have you ever watched a person climb a ladder only to have to come down again to get materials or tools? Have you ever been asked to do something for someone and the person wasn't able to tell you what it meant when done is done? Joe offered this example yesterday:

The key? Making work ready for Loren to work on it. We have instituted standards for him to work on a request. No specs for the loading of a roof?? No truss analysis. Wow. That's a shock to the system of those who were used to calling and letting Loren work on unclear requests. But it is vital. If we have a true constraint then there must be a queue of ready work in front of him.

By queuing up ready work for people (resources) they can start work that will be finished. Finishing work on projects usually means work is released for others on the project. Further, when work is in a condition to be started and finished, the work gets finished reliably.

But how do you do that? How do you know ALL of what needs to be done? You as a project manager alone don't know. You plan with a team of people who are responsible for assigning work on your project. You do this every week looking out a month or so. In these conversations you will discover what resource will be constrained and what is yet to be addressed for making the work ready. These are the conversations to assign responsibility for addressing each of the issues that keeps the future work from happening as intended.

You know the routine — time to visit Frank and Joe.

Previous in series Next in series

Day Three of the Series on TOC in the Project Setting with Frank and Joe

Multi-tasking resources in contention is a principle source of throwing a project out of sequence.

The lift story was an example of a temporal constraint. We call these resources in contention (RIC). There could be plenty of overall capacity for performing over the life of the project, but at any given moment two or more actions must be taken by the same resource. Engineers find themselves in this dilemma. An engineer may be asked to get 2 (or more) tasks done for the same or different projects in the same time window. Trying to please both parties by getting a little done on each everyday, the engineer fails to get either done on time. On the surface this only looks like a physical constraint. But is it? There may be a 'policy' to always please the customer. That policy gets interpreted as not saying "No" to a request. Further, engineering organizations are often run to maximize the amount of time spent on engineering. To do that, they build up work queues for each engineer. This necessitates a practice of starting and stopping and then restarting. Does it sound like waste? It is.

Multi-tasking resources in contention is a principle source of throwing a project out of sequence. Projects that get out of sequence get delayed. So what can we do? Know who (or what) are the resources in contention on your project. Apply the five focusing steps to them. And, do not let team members start one task before they finish the task they are working on. Sound crazy? We'll deal with that tomorrow.

In the meantime check out these two TOC resources: CIRAS and TOC Dictionary. Then go see Frank's Focussed Performance Business Weblog and Joe's Learning About Lean.

Previous in series Next in series

Exploring the Theory of Constraints in the Project Setting (second in the series) with Frank Patrick and Joe Ely.

Physical constraints are not the only limiting effects on projects. Eli Goldratt identifies two other types: policy constraints and paradigm constraints. Let's work through an example.

On a multi-story building job site there will be an exterior man-lift for carrying workers and material up and down the building. Large jobs might have more than one lift. We can begin to understand the lift as a constraint considering it only holds 8 people. If there are 80 people to travel on the lift it will take at least 10 trips to get them to their place of work. It will take more trips when the lift is not full. On the surface this looks like a simple physical constraint. But is it?

On most job sites the policy is for workers to start at the same time. While some people will come early to avoid the rush, which will only succeed if one of those people is the lift operator, what inevitably happens is a queue builds every morning, at lunch, and again at the end of the shift. What if the policy was changed? Perhaps the iron workers would come in first, followed by the plumbers five minutes later, followed the electricians, etc.? The end of their workdays would also be staggered. While there could be a bunching up due to variation in the arrivals of the individual trades, you wouldn't have less lost time waiting for the lift. Still, iron workers, plumbers, and electricians will likely be scattered across a number of floors. Bunching by trade will result is losses in travel as folks are dropped off on different floors.

So what about paradigm? We live in a world that thinks whoever is in line first gets to go first. Further, if the lift is there, then one can ride it. Are these stated explicitly? No. But we do operate that way. What if we change the rules for riding the lift? Let's say it is reasonable for people to walk up one flight of stairs and walk down two flights of stairs. On what floors would the lift need to stop in a ten-story building?

[think]
.
.
[think]

In the usual case of first-come, first-served, a mixed group of people get on. Each time the lift stops some people get out, while others must wait to ride to their floor. That waiting time takes away from operating time. Adopting the proposed policy changes that. The lift only makes

- the fifth floor and the ninth floor. A policy could be added to have people arrive for travel to the fifth floor at one time and the ninth floor sometime later. That would reduce the waiting time for the lift and the waiting time on the lift.

In this example we turned a physical constraint first into a policy constraint, then into a paradigm constraint. Make your constraints disappear in the same manner. And, remember to check-in on Frank and Joe.

Previous in series Next in series

The first in a five-part series on applying the Theory of Constraints in the project setting.

Projects of all types get bogged down. Something happens - unexpected - that puts the team members into a react mode. From there it is all downhill. While many people will offer good advice (they've got no skin in the game) few can offer a perspective that can keep a project on track. Enter the Theory of Constraints.

In the simplest terms think of a constraint as a restriction to flow. A bottleneck restricts the flow of liquid. Widen the neck and the bottle is emptied faster. Cranes are an obvious possible constraint on construction projects. Anything that must be lifted has to be carried by the crane. On any given day there may not be enough crane time to move all the material desired. Therefore the crane restricts the amount of work that can be performed in the day.

These are the physical constraints:

• People - not enough engineers for the work needed in a given time
• Space (access) - often there isn't room for two people to be working in the same location
• Equipment - availability of any one tool can limit progress on a given day

Think of physical constraints as anything that carries a load — people, tools, equipment, space (access), and talents (special competence). Projects are often long enough that we often have time to address physical constraints.

We manage our physical constraints through a five-step process of focusing.

1. Identify the constraint - look for places that work bunches up
2. Exploit it - get everything you can from it.
3. Subordinate all other actions to it - don't use the constraining resource if you can use another resource…even if it looks less efficient to do so
4. Elevate it - find ways to increase the capacity
5. Repeat the cycle - usually another pass through will improve the situation

Of course, this can be done prospectively. Look forward on your project. Ask, "What could keep us from proceeding at the intended pace?" Use the five focusing actions to stay out of trouble.

Now visit Frank Patrick and Joe Ely for their concurrent postings on TOC for projects.

Previous in series Next in series

Who is Claude Emond? Among other things he's made the most comments to Reforming Project Management. I just had to talk with him. I did and this is what I learned.

Claude is a mechanical chemical engineer, PMP®, active member of the Montreal PMI Chapter, and longtime project manager and consultant.

A few years back Claude started speaking of this time we're in as The Project Age. Companies' competitiveness will be determined by their responsiveness, innovativeness, and their ability to make adjustments to their practices. Claude says,

Companies will change and evolve thru projects. It's the management framework of the modern company.

Read more of his views in The Project Age Value Model.

Claude went on to caution us on the value of Project Management Offices (PMOs). Companies in all industries are setting up PMOs with an intent to bring some order to the projects they pursue. Unfortunately, PMOs have become hierarchical, centralized, and political. Claude commented,

PMOs are a fad responding to a collection of project failures. PMOs don't work for the same reason organizations don't work. Companies centralize when they don't trust. (It's time) to stop telling people what to do and start listening.

Alternatively, Claude encourages people to set-up a project support office. Provide tools, methodologies, and training at the pull of people on your projects. Help when asked to help. Impose nothing.

I asked Claude what he sees working in on projects and in companies today. Here's his list of eight best practices he observes:

1. Participate planning (with team members)
2. Planning that involves the final customer
3. Planning that clarifies what is to be done
4. Permission for project participants to say, "No."
5. Creating collective responsibility for the promises of the project.
6. Only make promises for tasks that can be met
7. Face-to-face frequent project team meetings
8. Free circulation of project information

Claude summarizes the practices this way, "You can't build anything top-down. Build collective accountability for projects and you can succeed."

I hope you enjoyed meeting Claude. Here are three of his recent comments: [1 Project Portfolio Management], [2 Lean Projects], [3 Listening]. Enjoy!

Blogging, Blogging and Blogging on Theory of Constraints

I am embarking on a series of postings next week on the Theory of Constraints created by Dr. Eliyahu Goldratt. I've made minor postings before. This series will be geared for people who find themselves making choices on projects. I am aiming for something practical, concise, and in a form you will want to share with others.

I've decided not to do this alone. I started this weblog with the intention for me to learn about project management and how to speak about project management. In that spirit I will write each day to continue my learning. While I've been a proponent and student of the TOC for many years there are others who can speak more authoritatively about the subject than I. I've invited Frank Patrick to post along side of me, but to do so in his own weblog Frank Patrick's Focused Performance Business Blog. Frank is an expert on conducting projects on a TOC basis. He maintains a good website with a special section on projects. I am sharing the postings with him ahead of time so he can post at the same time I do. We will link to each other to make it easy on readers.

To make this a even more interesting, my friend Joe Ely, who writes the weblog Learning About Lean, will be joining in by posting alongside us on his weblog. His postings are often based on real experience pursuing a lean approach in a project-based fabrication setting. Joe has been using the TOC to provide focus to improving activities at his firm.

If you aren't subscribing to my weblog via Bloglet, then now's the time to do so. (See the subscription box in the left column.) This way you won't miss a posting. You will receive an email each day with the previous day's posting. For all of you who are subscribing, Frank's and Joe's weblog postings are available the same way. If you subscribe to their weblogs you'll get all postings in the same email message. All three postings neatly grouped together. (You can always unsubscribe at the end.)

We plan on having some fun with this. I hope you enjoy it.

Next in series

There's a new archive that has an alphabetic listing of some of the more popular postings based on the reader responses.

I apologize to all the Bloglet subscribers. There's been a problem with the service. Postings during the last week have not been delivered. The folks at Bloglet are working on it. Stop by the weblog to see what you've missed.

Some of you might have noticed a delay opening the weblog. This is caused by the heavy load on the commenting system during this time of war. If you don't see the "comments" link at the end of any posting, then refresh your browser. If it still doesn't show, then the service is temporarily down. I've tweaked the code so it should be faster.

Ready for a little entertainment today? I'll try to be unconditionally constructive. Please forgive me if I fail to pull it off. Let's look at the white paper Refining the Project Planning Process by Bernard Ertl.

This "white paper" was delivered via an email newsletter. Even I'm awake enough to recognize a wolf in sheep's clothing. The white paper is just a marketing piece for eTaskMaker™. Maybe even a well-written marketing piece.

I've identified by inference these suppositions in the paper and "supporting quotes" (You might want to read the paper to draw your own inferences.):

• Planning is a distinct and separate phase from execution.
  "…project planning enables project managers to derive useful information for making decisions."
• Concerns for efficiency have us assign specialist roles of "planners" rather than use those people who are responsible for performing the work.
  "Given sufficient time, experienced personnel can produce the highest quality plans with the manual planning process."
• Planning is an analytical p