On Monday I'll be grid blogging on the subject of the "brand". Grid blogging is an experiment in tapping the knowledge across the web. Bloggers will post on the same subject on the same day. We'll also link to each other. And we'll offer a means for finding the postings via search engines. Just search on "[grid::brand]". Include the square brackets in your search. You might not find much early in the day. It might take a while for search engines to index new postings. I'll be posting here and at www.coachblog.com.

Late last week I received two autographed copies of David J Anderson's book, Agile Management for Software Engineering. (I actually received three copies. One was personalized. Thank you David.) I'll be offering these as premiums for publishing your Project e-Tip proposals. I haven't commented on David's book for quite some time. Don't be thrown off by the title. He could have titled it Agile Management for Knowledge Work and it would have been as good a fit. Anyone doing engineering, architecture, or design of any type will enjoy the book. We will be interviewing David in our Project Leadership teleconference series in the spring.

I updated the articles page of this weblog. (Click on the link in the horizontal navigation above, or click Hal's Articles.) The page now includes my latest article for the Zweig Letter, Project Management: Claptrap or Messy Work. There's been numerous new definitions of project management in the last year or so. I find it to be just more of the same. So, not being one to hold my views to myself, I offered up a 20 year-old perspective along with a set of 6 issues that continue to challenge PMs and a set of 5 actions to set the stage for messy work. Hope you enjoy. Please leave me your comments.

Continue to watch these pages for the announcement of the teleconference series with authors. I will be posting to give my email (Bloglet) subscribers a first chance at signing up. This first conference will hold just 100 callers. So sign-up for email delivery today to get your early announcement. Look in the left-hand column. And then tell your friends! We will be offering a sign-up page for each of the featured authors. Just to whet you appetite, we've got the godfather of the lean movement scheduled for March. Should be fantastic!

John R. Brandt writes the column Brandt On Leadership for Industry Week. His latest article Come On, Get Happy, is another gem. Brandt says,

It never ceases to amaze how completely the managers and employees of
unhappy companies — whether actively failing or merely mired in
mediocrity — can convince themselves that their troubles are unique.

Invariably, I'm told that their predicament is due to: difficult market
conditions beyond their control; wholesale customer defections based on
currency fluctuations or unfair trade; a particularly toxic or
strangled culture that prevents change.

Please.

Brandt claims all unhappy companies look alike sharing five fingerprints:

1. A belief that employees are dangerous and lazy.
2. A conviction that customers cannot be trusted.
3. A focus on policies, not principles.
4. An obsession with today, not tomorrow.
5. Leadership in all the wrong places.

Brandt does a good job elaborating on each of the five fingerprints. Take a look. While you're there, see if you recognize any of those fingerprints for your company or project.

Johanna Rothman and I mostly agree. Sunday, she posted a clarification More on Faster Cheaper Projects to her early posting Creating Faster Cheaper Projects. I started a little disagreement with my posting here in Reforming Project Management.

Here was the problem: Johanna was writing about the project portfolio environment while I was commenting on the single project environment. Here's how Johanna framed the situation in her clarification:

Let's assume the organization does not sufficiently differentiate between project priorities, i.e. not performing real project portfolio management. People are assigned to the next project as they come off previous projects… Since each project requires more people than anticipated, each project starts late, with too few people. Soon, all of the projects are starved for people, and all of them require more people and more time for fewer deliverables.

The longer a project is starved for people, the longer (and more expensive) it is for the project to be successful. The more unnecessary people added to the project too early, the longer and more expensive the project is.

Johanna stands by her recommendation to staff early. I agree. Assign early to get the project in shape for when the staff becomes available. My experience in the AEC industry and with DoD projects leads me to conclude that staffing a project late is a key source of project failure in the project portfolio environment. The corollary also holds: when extra people are assigned to projects that aren't ready for them you'll have more problems on other projects.

It's great what a nudge and a little clarification will do!

Thought I'd offer this as a follow-up to yesterday's Gray Matters posting. Bob Rosner writes the weekly column Working Wounded for the WSJ Career Journal. His writing is helpful and concise. In just a few minutes each week you'll get just the dose of management help you need.

In his 11/13 column How Savvy Managers Produce Solid Results Bob shares his strategy for getting big results:

You can usually accomplish more with subtle nudges than you can with heavy hammers.

Bob offers five questions for assessing your ability to produce solid results. (See the article for more details.)

• Can you play dumb?
• Can you model the behavior you would like to see?
• Can you use storytelling and metaphors?
• Can you use humor?
• Do you know your own personal competitive advantage?

So it's not a grand revelation. Read Working Wounded for the next few weeks. Then tell me that you want to stop. I bet you won't! And if you want a bigger dose of Rosner, et al, then get yourself a copy of Gray Matters.

Before I get back to the variation as an enabler topic, I want to tell you about a book I just finished. Fast Company has a new book club. Each month they offer readers the opportunity to vote for their favorite one of five books. The first reader selection announced in the December issue is Gray Matters, by Bob Rosner, Allan Halcrow, and John Lavin. This is a business book pretending to be a comic book.

The reviews at Fast Company and Amazon are universally positive.

When I saw the Fast Company selection I got myself a copy. It took just a few hours to read it cover-to-cover. I was somewhat skeptical of the comic book format for the first three chapters, but before I knew it I had read almost 200 pages. Each chapter has three sections. It starts with a casual presentation of theory. From there it moves into the story of Gray Blanderson, product designer at Global Gadget, taking on the challenge of saving the small appliance division told through a continuing comic strip. The third section is a reflection and commentary on what works and why.

The authors are quite well-known writing for the Wall Street Journal and as best-selling authors. Rosner's Working Wounded column at the WSJ is not to be missed. Their business insight shows through in the no fluff presentation of everyday business issues. In chapter 22 they tackle the spirit of innovation. Using the example of adopting a just-in-time approach in manufacturing they illustrate the issues of a continuous improvement strategy.

The reviews at Fast Company and Amazon are universally positive. This one sums up the enthusiasm readers have for the book:

Not your typical business read. It's changing my life.

While I wouldn't go that far, I do recommend the book. Here are 46 more reasons to get Gray Matters. At the end of all 23 chapters the authors recommend their favorite books on the topic of the chapter.

So, are you wondering what is a JELLO® Attack? Barbie's Brainy Glossary defines it as

A soft response to a crisis (such as having a meeting or forming a task force) that conveys the appearance of taking action without really accomplishing much.

No JELLO Attack here. Enjoy!

Johanna Rothman offered this advice yesterday, in her weblog Managing Product Development.

"If you really want to perform projects faster and/or cheaper, start them earlier."

Her proposal includes running with a smaller team.

Can't say I agree. Having worked in both software development and the AEC industry, I can see the point of having a smaller team. Fewer conversation lines does reduce the chance of miscoordination and therefore breakdowns. As Johanna points out, there's also likely to be less multi-tasking, and more organizational flexibility from this approach. On the other hand, as the team size decreases the opportunities for innovation and learning will decrease along with the decrease in total skills available. There are three other issues that Johanna is missing.

1. The accumulated investment of working longer on a project will raise the total costs. If you examine the extremes of 1 month with 10 people and and ten months with 1 person you'll see the issue. (For the sake of the example assume the work can be done as described and other variables stay the same.) In the first case I pay ten people for one month and I get my project done and start earning a return on the investment. Total invested: 10 person-months salary. In the second case I make my first investment in one month's work 10 months before I can reap a benefit. The following month I make another investment needing to wait 9 months before a return, etc. Total invested: 55 person-months.
2. The longer the project takes the more likely you will need to deal with changing client and market requirements. In other words long projects have more changes and more cost.
3. Client need and capacity availability. If you are at all market focused, then you need to respond to what is asked of you. You must also deal with the facticity that people are already busy fulfilling promises made on other projects.

Here's my operating principle:

Promise the end conditions at the first responsible moment and then commit to all the intermediate actions and start at the last responsible moment.

Example: The client wants something in 5 months. You don't have the people ready for 1 month. There's 10 person months of work to do.

The way I would do this project acting as the project manager is to delay the start even further to get the project in a condition where once people start their tasks they can work on them 'til they are finished. So, delay the start by another month, put 4 people on it working for 2 1/2 months, and deliver 2 weeks early. The invested time is kept low and there's time at the end for something unforeseen. Everyone wins!

We're on a roll. Readers are responsible for the last four e-Tips. This one comes by way of France. Laurent Bossavit is a project guy and he's a book guy. He maintains the site Bookshelved Wiki, a community of people who write about and comment on books. It's very cool. Have a visit.

The Project Reformer's e-Tip of the Week

019: Creating the Environment for 'Jumping In'

Some projects just can't succeed if project performers must always be asked to engage. Fast projects, innovation projects, and physically dispersed projects all cry out for 'jumping in.' How do you get more initiative and engagement? First, ask for it. But it is rarely enough. Set an early example of taking initiative. People may hold back 'til they've seen others in their group take part. Maybe this is an introvert thing, maybe not. But there's nothing like pointing to an example for calling for more engagement. Make a game of it. Share the rules (or guidelines) for play. Be clear how people win. Win? Sure. State clearly how 'jumping in' forwards the purpose of the project. If people see that, then they are more likely to take their first step. After a first step, there's bound to be a second. This Project e-Tip is courtesy of reader Laurent Bossavit. He left a comment to my lament "I was expecting more people to jump in." Laurent maintains Bookshelved Wiki.

©2003 Hal Macomber | RPM | e-Tip Archive | PDF | Submit Tip

So the challenge is on. Let's keep the e-Tips coming in from readers. I can send a book anywhere. This week I sent Laurent my last autographed copy of The Blind Men and the Elephant. Who's up next?

There's a book or two (or three) on this topic. I'll make a few points. Perhaps you can add to them with your comments.

     n.b. Remember the context of this posting is doing projects.

We take our capacity for speaking for granted. We can't remember a time when we couldn't speak. It's just what we do. But communicating with language is not straight forward. We think the meaning of our speaking is clear, only to discover the listener understood something different than we meant. Humberto Maturana claims denotative meaning (precise definitions) in speaking is not possible; there is only connotation (inference, nuance). He's saying that each of us gives meaning to what we hear based on the distinctions we can make, our preoccupations (concerns) at the time, and the relationship we have with the speaker. In other words, in spite of the care we give to saying what we mean, people will listen what they listen.

One of the tragedies of projects is when someone sees that action is required but they fail to speak about it. Sure, sometimes we see people complaining to a friend or coworker. But they don't speak up to a person who's in a position to act. We can speculate why this is the case. Frankly, it's not useful. Just knowing that people don't speak up is enough to begin changing the behavior of people with the authority to act.

Another tragedy of the project setting is when people don't listen. Not just the bosses. Finish the sentence, "How many times have I told you ..?" We've all said that. Breakdowns are inevitable when their are patterns of not listening. Further, not listening leads to not speaking. "Hey, I'm justified in keeping my mouth shut. They don't listen to me anyway."

The work of projects is coordinated through conversations. It's not about process. It's not about schedules. Work is certainly not coordinated through controls. It's all about conversations, particularly requests and promises. Yet people don't see the coordinating aspects of commitment conversations. Instead, they see writing code, hanging doors, designing product, and doing one report after the other. It fits that people don't get highly competent at something they don't see.

To recap,

• People listen what they listen, not necessarily what was intended.
• People don't speak when they have something to say.
• People don't listen to what others are saying.
• People don't speak or listen for commitments.

Disaster? You bet! But it is also the good news for project managers/leaders. We can anticipate that we'll encounter one or all four conditions throughout our projects. I bet you will find examples today!

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.

Previous in series

Being Saturday, I thought I'd offer something different. As regular readers of weblogs know bloggers link to other bloggers. It makes the experience of reading a blog so interesting. When I visit a blog I do so wondering "where will I go today?" Blogs like mine have a topical focus. You can read all sorts of things about project management, but you won't be reading about Brittany. (It is possible to escape the pop culture.) Most links on my pages will take you to other useful perspectives having some relationship (in my mind, anyway) to the topic of reforming PM. The linking of all these postings through time presents an evolving consciousness and body of knowledge.

Hold onto your chairs. You are about to witness an explosion in both the connectedness and production or presentation of knowledge. How? Through grid blogging. Instead of a few of us blogging on the same topics from one week to the next, Ashley Benigno has proposed that a whole bunch of us blog on a single topic for a day. That first topic is the "brand".

While we don't know what to expect or how many people will get involved, there are some models for this behavior. On these pages and in their respective weblogs, Frank, Joe, and I blogged on the Theory of Constraints for a week in Down 'n Dirty with the Theory of Constraints. Like this proposed effort we knew a week or so in advance what we would do. We also shared our postings with each other before we posted so we would do a good job introducing the topic. Not only did the three of us learn, but we had very high readership for the week and shortly thereafter. Something similar happens each year on World AIDS Day where bloggers post their thoughts. See www.linkandthink.org.

I am so excited about this. While the topic of the "brand" is interesting to me, what I'm more interested in is the possibility of extending what we know and can do by being focused like this. It should be great for those writing as well as those just reading.

Mark your calendar: Grid Blogging the "Brand" on December 1, 2003. I'll be joining in. How about you?

This posting came from Clarke Ching, Scotland, writing in the TOC Experts Yahoo! Group on November 10. Clarke is a regular reader of this blog and the contributor of Project e-Tip 009: Eliminate Multi-Tasking to Speed Project Completion. Clarke is a smart guy who writes well. He graciously allowed me to reprint his posting. Thanks Clarke.

[Look for my comments throughout the text.]

A reader asked the group how Scrum compares with Critical Chain Project Management (CCPM). Here's Clarke's reply.

Scrum is one of several Agile/Lean Software Development techniques. The opposite of Scrum/Agile/Lean is the waterfall development lifecycle where analysis, design, development, system testing, and user acceptance testing are done in sequential phases. Scrum/Agile/Lean works in short iterations - between 1 and 12 weeks each.

The core conflict for software development projects (and most others I imagine) looks like this.

[This is a fine example of Goldratt's Evaporating Cloud]

    D - Allow change throughout project
  B - Build functionality required by customer
A - Have a successful software project
  C - Deliver on time and to budget
    D'- Agree scope up-front and don't allow change throughout project

Or this see this graphic provided by Clarke.

[Read the above chart this way: I want (A) a successful software project. To be successful I need (B) to build the functionality required by my customer. And I need (C) to deliver on time and on budget. For me to build the functionality required by my customer I need (D) to allow for change throughout the project. However, for me to deliver on time and budget I need (D') to agree to the scope up-front and not allow changes throughout the project. (D) and (D') are in conflict and cannot coexist.]

In a traditional/waterfall environment "change control" is the mechanism used to do both D and D' poorly.

The agile approaches attack three assumptions:

Assumption CE1

We can prevent change if we spend enough time to ensure we get everything agreed and signed off up front. Agile/lean says that CE1 is just plain wrong (in all but the simplest environments). Therefore, E doesn't even give you C. Even if we get the requirements right up front, they will change, so if we don't change them as we go then while C (finish on time and budget) is satisfied, we won't satisfy B (customer gets what they need) so that A (the project) isn't successful.

Assumption CE2

It is many times more expensive (i.e. Boehm's cost of change curve) to change the further we get into the project. Agile/lean says that CE2 is wrong too. For instance XP (eXtreme Programming), a cousin of Scrum, suggests that the cost of change curve quickly becomes flat when using test-driven development and refactoring in a iterative/incremental approach.

Assumption CE3

The project only delivers value when it is finished. Agile/Lean says that you don't have to deliver everything at once to get value. Instead you can get value quite quickly by delivering small high-priority increments of the product. At the very least you gain value by discovering what's not working much, earlier.

[Clarke examines three cause and effect assumptions behind the evaporating cloud as it was described. He sets out to invalidate each one.]

The key points of Scrum are:

A product owner manages a product backlog.

This is a list of high-level requirements/features - e.g. user can register, user can login, user can add items to a shopping cart, user can search for books, etc - that has been prioritized by the product owner. It will also include "technical things" - e.g. install server, upgrade source management system - added to it if requested by the developers and agreed by the owner.

Every 30 days a new "sprint" starts.

Each sprint is a 30-day iteration where the development team picks a set of features from the product backlog that they estimate they can "deliver" within the next 30 calendar days. They then work on that sprint for the next 30 days.
During this time no changes can be made to the sprint unless suggested by the developers.

"Delivered" means that the feature could potentially, although not necessarily, be shipped or implemented.

It's fully coded and tested, the help is prepared, it's not going to break when the users get hold of it.

Each scrum team is self-managing with guidance from the "Scrum master".

Initially the team will struggle with self-management but, apparently, they learn quickly. Each day a 15 minute meeting is held where each person answers 3 questions - what did I do yesterday?, what will I do today? And what obstacles are holding me up? It is the Scrum master's job to clear the obstacles.

The theory behind scrum says that complex processes, such as software development, change too much and are too difficult to manage.

They need to be managed empirically, with constant inspection and adaptation.

[Those of you who use the Last Planner System™ will recognize similarities with Scrum. The backlog of tasks grows, as does a weekly work plan, as the project goes along. Project performers take tasks from the backlog making promises to complete them. The Scrum approach is done or not done. No credit for effort. And very much like lean, people understand their projects as complex and evolving.]

How does Scrum differ from Critical chain?

• CC aims to get the project finished as quickly and reliably as possible. Scrum aims to get working functionality delivered as quickly as possible.
• CC buffers with time. Scrum buffers with functionality.
• CC says "Don't put the safety in the task; put it in the project". Scrum says "Don't try and figure it all out up front because you can't. Things will change too much as you go. Instead, build working software quickly, inspect and adapt".

Despite these differences I believe that CC and Scrum are not only complimentary but synergy should be gained by using both together. That said, I don�t know of anyone doing this. Scrum is mostly used in IT along with changed engineering practices, but it has been used in non-IT projects.

[Good concise comparison.]

Write Clarke at clarke@chingz.com.

Project management could use more qualified gurus, if for no other reason but to solidify PM ideas and theories.

That was the opening line of Bob Weinstein's latest Gantthead article, A Guru's Approach to Project Management. Let's here it for Bob Weinstein and Gantthead. Woohoo! Weinstein is a regular columnist for Gantthead as well as an author of a dozen books. This article is a gem. Print or save a copy.

Weinstein interviewed two people he designates as gurus. Dave Schrader is the director of strategy and marketing at Teradata. Bob Sutton is the author of the well-known book Weird Ideas that Work. He calls them both "the real deal." So what does he mean by guru?

Gurus are justifiably praised for their unconventional view of the world. They have the unique capacity of taking theory and applying it, a skill possessed by a select few.

Here's a short summary of the two gurus' take on project management. Read the article for the rest.

Dave Schrader's seven guidelines for good project management

1. Perform quarterly reviews.
2. Control projects with a management triangle. The three parts of the triangle are features, time, and resources.
3. Customer-based staging of delivery is essential.
4. The bigger the project, the bigger the risk.
5. Highly motivated teams drive projects.
6. Provide constant feedback.
7. Celebrate!

Bob Sutton: The Process Paradox, Too little or too much process is dysfunctional.

Start out pretending there is a process, yet avoid falling into the trap of thinking that's all there is. Myopic thinking leads to failure. Don't let the process become an end in itself or a formula. Think of it as an initial roadmap that will have to be changed as problems surface. The people who are really good accept this fact of life. They understand project management is never as linear as it seems.

Wish I had said it. Gantthead is becoming a powerful voice independent of the PM professional forums. They take a practical view of the world while still being provocative. This article is just one of many examples of what Gantthead has to offer anyone managing projects.

I am really embarrassed. Over a year ago I added the Atomz search tool to my weblog and website. I've tried it a couple of times and was disappointed I couldn't find what I had written. Today I decided to dig in. I found I was not including my own weblog in the target for the searches. Aargh!

I apologize to all of you using the search tool. Just one more example of there's too much to know. Try it. You'll find the search tool in the left-hand column part way down the page and on the archives page.

Today's Project e-Tip comes from Glen Alleman. Glen is quite a good thinker and writer taking on tough subjects and making sense for others. His book reviews are among the most complete I've read. When Glen offers his opinion he also shares how he has come to that opinion. I learn from his writing. I'm sure you will to. Here's his tip:

The Project Reformer's e-Tip of the Week

018: Never confuse efforts with results…

…when's this pig gonna fly? The concept of "we're working" hard toward the goal is not to be confused with the delivery of the outcome. This is a common mistake in the software development domain (and throughout the project world). One simple way out of this dilemma is to have "testable" outcomes that results in 0% or 100% credit for being complete. If the A-6 of VA-145 was in flyable condition then the maintenance crew got the credit. If not, then no credit. Defining what "done" means or what "complete" means BEFORE starting the work is the simple way of avoiding the confusion between effort and results. This project e-Tip courtesy of Glen B. Alleman, VP, Program Management Office, CH2M Hill, Rocky Mountain Flats, CO. Visit his personal site at http://www.niwotridge.com/

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

Take a look at more of Glen's thinking. He writes a monthly column for PM Forum titled IT PM: Herding Cats (complete listing of his columns). His latest piece was published yesterday, The DIPP Formula Project Control Flag, An Assessment of the DIPP Indicator.

Glen selected The Portable Coach from my bookshelf as his gift for having his Project e-Tip published. There's more where that came from. Share your wisdom with readers.

This article was written by Michael Sheerin, P.E., Healthcare Division Director TLC Engineering for Architecture, Orlando, Trust Is Crucial in Project Coordination.

Sheerin opens his article this way:

The key ingredient of any successful project is trust: the owner must trust the building team to envision and create the owner's goals; designers must trust the contractor's ability to work within the framework of construction documents to build a living environment; the contractor must trust that the design team has developed a plan comprehensive enough to get them all out of the jungle without too many snake bites.

Great start, unfortunately, there is no more. He has the right idea, but doesn't offer insight into how to do it.

Certainly, the best method for keeping on track throughout the course of a project is communication � the unambiguous, respectful, formal kind as well as the inquiring, personable, informal kind.

He goes on to speak about compromise in the coordination of design documents:

…every coordinating agent should seek to balance the competing interests of all of the design and construction team members to achieve ownership � and acceptance � of sometimes difficult decisions.

He shows his cynical side here:

(A) contractor may take some satisfaction in button-holing a designer for some area of flawed thinking. In the face of concrete dimensional data, designers must drop their egos at the door.

Aargh! I can't go on.

Right title…no understanding of trust. Trust is nurtured and preserved on teams. It starts as compound assessments of each other's competence, reliability, care for the other, and sincerity. Once we spend enough time with each other, trust can be elevated to a central component of a relationship. The problem on projects in the AEC world is we start out as strangers and too often end the project that way. [Strangers, Friends, and Partners]

Yes, trust is crucial in project coordination, just as it is important in all project endeavors. Leaders have the greatest opportunity for intervening where trust is insufficient for the task at hand. The rest of us have the responsibility to see that our leaders do just that.

Great teleconference today. Tom Peters was his usual candid, outrageous, provocative, and not-to-be-trapped self. Here are some representative questions and my best attempt at capturing his responses:

"What are you passionate about?"

My passion is passion.

"How many CEOs really get it?"

Jack Welch is the most youthful human being that I've ever met in my life. He is one rare duck. (But most leaders) are guys without nerve.

"Why don't you like Jim Collins?"

I love Jim Collins. He's a good friend. Jim says what we really need is quiet stoic leaders who can reform companies quietly. My problem is Jim describes companies who transformed companies financially, but they have not set the world's agenda.

"How do we work with people who are passionless?"

Avoid them like the plague. Life is too short to work with dorks.

In answer to the question, "Which leaders do you admire?" Tom refused to be pinned down. Instead, he answered,

My hero is a person who is willing to risk a stable life to do something entrepreneurial.

"What do we do in this time of outsourcing?"

Raise hell. They'll send your job to India anyway, so you might as well make some noise along the way.

Catch Tom's interview Rants with Tom Peters for the next few days.

Let's hope Greg and I can do a respectable job when we interview David Schmaltz and others next year.