The Regenerate Web

Akio Toyoda is on the hot seat. Reportedly, he is a forward-thinking guy who is intent on bringing the legacy of the family to the design of the future of the company. Unfortunately, CEO Toyoda is being tested beyond that of any of his recent predessors. Toyota is in trouble…in the market for cars…in the financial markets…and as as model for managing companies.

Last week I was speaking with Norman Bodek, Godfather of Lean, about Taiichi Ohno and Shigeo Shingo for my up-coming book. Norman knew both of them. He was their English-language publisher and he introduced 100s of people to them on his more than 75 study missions to Japan. I had just finished my weekly staff video conference where our consultants lamented that Toyota must have lost their way. I asked Norman what he thought.

Confront this reality: Electronic hardware and software is not bug free.The conventional wisdom about Toyota's quality issues is that they got distracted while pursuing a goal to be the world's largest car company. Norman didn't think they were ever pursuing that as a goal. At one time Toyota's CEO Watanabe predicted that it would happen, but it was never the goal. Yet, we can't ignore their rapid expansion into many new markets across the world. Norman speculated that too many of Toyota's managers of today weren't influenced by Engineer Ohno and Dr. Shingo.

Another contributing factor is the complication in today's vehicles. I read an article in the last week that said there are upwards of 100 computer chips controlling everything from emissions and speed to real-time fuel economy and handsfree cellphone capability. All that hardware requires software. Programmers will tell you that no software is bug free. Ever see the Windows blue screen of death?

One of my good friends wrote a short note to me this morning asking,

"WTF is up with Toyota? How did this happen? I thought they set the standard for quality control?"

Great questions. My answer:

"It's not as bad as Secretary Ray Lahood and the media have made it.
"It's worse than anything that has happened before at Toyota.
"Toyota's solution to the sticking accelerator is elegant.
"It took Toyota way too long to put the pieces together to get there."

It's the same question my colleagues have been asking me. I haven't known how to answer any of them until this morning. Today, something clicked.

(...)
Read the rest of What Is Going on with Toyota (422 words)

©2010 Hal for Reforming Project Management, . | Permalink | No comment | Add to del.icio.us
Post tags: Akio Toyoda, Norman Bodek, Shigeo Shingo, Taiichi Ohno, Toyota

Feed enhanced by Better Feed from Ozh

Erik Gfesser posted a lovely review of Manage Your Project Portfolio. Thanks, Erik!

Tweet This Post

Three years ago, Drew McLellan approached me about writing a project management post a couple of times a month.  About a year after it started, the Iowabiz blog moved under the ownership of The Business Record, and Todd Razor.

Last week, the Iowa Newspaper Association named Iowabiz the best newspaper blog in the state of Iowa.  I've been honored that I get to play in their sandbox.

Congratulations to Iowabiz, Todd, and my fellow contributors on creating and maintaining an awesome community to improve the state of business in Iowa.

Carpe Factum!

From the Ask Tom mailbag:

Question:
Can you expand on the "Time Span" "compensation banding" approach? I am not familiar with this concept and do not fully understand what is meant by either term.

Response:
Time Span is a recurring theme in this blog and in our leadership program (Working Leadership Online). Time Span is the cornerstone of the management research conducted by Elliott Jaques from the early 1950's until his death in 2003. This research is documented in 26 books written during his lifetime and remains the most coherent and potent foundation for organizational design on the planet.

If you can see a goal, as a "what, by when," then you can understand Time Span. Time Span is the time element in any goal statement. All behavior is goal-directed behavior, so Time Span touches everything we do. Most importantly, for managers, Time Span helps us understand the complexity of any goal. The longer the Time Span of the goal, the higher its complexity. The shorter the Time Span of the goal, less complexity.

We can also understand the complexity of any role in the organization by examination of their longest Time Span tasks (goals). The Time Span of the longest tasks in a role are a direct indicator of the complexity of the role. By calibrating the Time Span of the tasks in the roles inside your organization, you will be able to accurately identify and rank those roles according to complexity.

Pay banding looks at the those Time Spans and recognizes fair compensation. The longer the Time Span of the tasks (goals) in a role, the higher the compensation. Pay banding is a straightforward correlation of fair compensation for increasingly longer Time Span roles. Once you have determined fair compensation based on Time Span, discussions related to the value of roles can be put to rest and we can get back to work.

An in-depth explanation, along with defined pay bands can be found in Social Power and the CEO, on pages 55-56. If you have more questions, Ask Tom.

John Goodpasture has a post on estimates from Fred Brooks. Fred's quote, which I'll repeat for effect, from John's site is

It is very difficult to make a vigorous, plausible, and job-risking defense of an estimate that is derived by no quantitative method, supported by little data, and certified chiefly by the hunches of the managers.

In many domains, estimating is performed in ways similar to Fred's description. Here's some phrases found in RFP's from the Defense Department:

• The estimate must be easily traceable from the lowest level at which the Offeror’s estimate was substantiated to the CLIN.
• When using historical data, the Offeror should describe why the system is comparable to the proposed program. This includes a functional and technical comparison explaining the differences as well as similarities between the historical and the proposed system. Also include an explanation of the relationship between the analogous element cost and the total program cost.
• Adjustments to derive the proposal estimate relate to reasons and justification for any adjustments made to programmatic, technical and actual cost data for the historical system. The Offeror should provide the basis and document any adjustments applied to the historical data (e.g., complexity factors and normalization methods) that reflect the characteristics of the proposed system. This includes an audit trail sufficient for the Government to reconstruct the proposed estimate and judge its credibility.

Now these are heavy duty words, probably not applicable outside the procurement of similarly heavy duty weapons systems.

But as John points out through Brooks' quote, to do otherwise is complete nonsense on anything but a trivial project.

So wjy does this continue to be the practice in many areas? Some would say, it's because IT projects are software projects and you really can't estimate software projects. To this I say frankly - BS. The program we work int he defense are predominately software development projects. Software development with emerging requirements, changing requirements, state of the art technology, all the things IT project managers encounter.

My personal opinion is

Project estimating, and project management is hard work. Software development is fun work. Still hard but fun. Project Management is hard work, with almost no fun.

So why work on something hard if it's not fun? Secondly, there is no real downside for missing estimates in the commercial IT world. Oh sure, there is hell to pay, people get fired, the project gets canceled. But the company rarely goes out of business, people never die, launch dates are rarely missed. I'm not talking about silly commercial product launch dates, I'm talking about launch dates to Mars, launch dates for NRO (National Reconnaissance Office) launch dates. Those kind of launch dates.

What's missing is the discipline - at appropriate levels of course - to "do the right thing." That's the root cause of most problems in the commercial world - pure missing discipline.

It's the Micky Rooney school of management. Where Micky and Judy Garland are in the alley behind a NYC theater, when they say to each other and their friends...

Hey guy, I have an idea, let's put on a show

It's that, let's get started and see where this goes, kind of approach to project management. Where it goes many times is straight into the ditch.

OK, so the word "beauty" is not often paired with the words "your employees" unless you are having a difficult harassment-related conversation with your HR manager.... but that is not the type of beauty I am talking about.

And before I get into the main point of this post, let me throw out a few other words: love, fan, admiration, extraordinary.

I was training in Wash DC this week (got out just in time to avoid getting stuck!) and I noticed that whenever I talked about believing in employees, my training participants looked and acted differently.

(beauty in our back yard in Cincinnati)

We want to believe that our employees have the capacity to do amazing work. We want to see the beauty that lies within them - beauty that defines their desire to make a difference and to do great work. We want to feel a connection with our peers and employees that is deep (get your mind out of the gutter) and special.

But many managers don't seem to believe, don't seem to see, don't seem to feel, don't seem to connect. What has happened?

• Stress?
• Being too busy?
• Extrinsic rewards and reinforcement systems that has sucked the life out of us all?
• Lack of confidence?

Yes. All that. And yet, I am moved by the possibility that we can again believe, see, feel, and connect. Every time I talk to groups about this, I see their eyes shine and their hopes come alive again. Talking about it can reawaken what's inside and provide a beneficial nudge toward a better way of managing.

The Training Salon:

At the upcoming ASTD International conference in Chicago, I will be talking about using the Salon concept for training (I will also be talking about training middle managers in a second talk at the conference):

• According to wikipedia, "A salon is a gathering of intellectual, social, political, and cultural elites under the roof of an inspiring hostess or host, partly to amuse one another and partly to refine their taste and increase their knowledge through conversation."
  

Salons are great vehicles for learning and perfect for developing managers and leaders. Salon-type conversations offer a deepness that can transform how we look at our work and each other and I think can be a great way enliven the best that is within each of us - our beauty.

The training I did last week was not a salon - per se - but the conversation had some qualities of a great salon experience.

When I was getting my MFA from Goddard College, we had 10-day residencies twice each year. My pals in the program and I started the practice of holding evening salons and it was wonderful. Anyone could come and anyone could participate, read, perform, share, provoke. Since then, I have enjoyed business-oriented salon type gatherings. 

Last week, I shared my travel schedule on this blog. Check it out again. I would love to get a few salon conversations going. Let me know if you want to participate. And give the training salon a try at your workplace (or start with several professional pals).

We need to do whatever it takes to catalyze the more compelling aspects of management and leadership - the aspects that demonstrate that being a manager is a privilege and an opportunity to make a difference in the lives of those who work for and with us.

I got my new laptop this week... which meant a quick trip to Ed Snuffin at Iowa Computer Repair to do all the set-up and security work before I start to use it.  Now I can rest assured that my "sidekick" is optimized and will run smoothly for years.

I had a few clothes that needed mending, so a trip to Frederick's Tailors in Clive.  They always make all of my clothes look like new when they're done.

Next was a trip to the dry cleaners, Executive Cleaners in Urbandale, who get my clothes looking excellent every time.  Never a quality issue, unlike many other cleaners in town.

Hungry for Italian, I always make an effort to stop at A Taste of Italy on University Avenue.  The guys behind the counter frequently introduce me to new meats and cheeses (much to the chagrin of my wife).

But for the taste of the day, it was a chance to catch up with a friend over the best onion rings in Des Moines at Maxie's Restaurant.

And when it came time to pick up my prescription, John Forbes' Medicap on Douglas Avenue is a no-brainer for me.

Why am I telling you all of this?  Is it just a shameless plug for some of my favorite service providers?

Well, yes and no.

Our accomplishments are a living testament.  The outputs we as service providers produce are the inputs for somebody else (customers).  Ang guess what?  They are the feedback loop for our outputs.  If we produce great outputs, they will tell lots of people how great we are.  If we produce poor outputs, they will tell even more people how bad we are.

For me, I always try to provide my clients, my students, and my audiences with the best value possible.  I want them to come away saying "Wow - I got more than I bargained for!"  My accomplishments, my outputs exist to make their inputs (and therefore, their accomplishments) better.

So what are your outputs?  Who is using them as inputs?  Are they excited enough to tell everybody?

Now it's time to assemble my financial records to pass off to the world's best accountant, Lambert Blank.

(Disclaimer:  None of these service providers knew I was writing about them, and I received no compensation for my telling you about them.)

I spoke again this year Carnegie Mellon University on the topic of project management in the software development world.

Not matter what method you use to develop the software needed by the project, for success these principles must be in place

I would like to collect a story from you.

There is a brew-ha-ha brewing over at Aubrey Daniels' blog about such things as reward vs reinforcement vs motivation. This got started as Dan Pink's Drive hit bookstores. Aubrey was puzzled over some of Pink's observations.

"Contrary to what Pink asserts in his book, the surprising truth about what motivates us is that reinforcement always works, but not always as it is intended. The science of behavior has validated that fact in thousands of research studies over the last century. You don’t always get more of the behavior you reward, but you always get more of any behavior that is reinforced. That is true today and it was true thousands of years ago. If creative behavior is reinforced, you (the company, the person) will do more of it. Count on it. When work environments are properly arranged to produce positive reinforcers for highly productive, creative outcomes, they always do produce such outcomes."

So, here is the story I would like to collect from you. What reward system have you tried in the past, that produced unintended consequences? Post your story at Ask Tom and then we can kick the can around.

• moon bases
• jet packs
• 200 mph cars 

but has no...

• cell phones,
• Internet,
• and no laptop computers

Over the long haul, dramatic things happen to change the equation.

Sunil Paul, quoted in The Atlantic, “Better Luck This Time,” July/August 2009.

Via Wayne Abba's PMI Baltimore Chapter address, September 17, 2009. A former senior contract performance management analyst in the Office of the Secretary of Defense from 1982-99.

Forecasting the impact of the latest gadget, process, or method is very sporty business.

For every complex problem there is an answer that is clear, simple, and wrong. - H. L. Mencken

I'm attending a National Defense Industry Association conference on Program Management. I took a break to read some emails - you can only take so much of Earned Value, probabilistic cost modeling, a DCMA self assessment audit guidelines.

There's a discussion going on about how agile software development methods can be applied to safety critical systems. First I earn my living working on programs that contain safety critical system. As well I designed and deployed a safety critical system - the Tricon a classic 80's product name.

The discussion from the agile point of view is typical agile - we've got this really cool way of doing things, you can use it on your problem too.

In the absence of a domain and context, probably not. I spoke for two nights this week at Carnegie Mellon University, San Jose on the 5 immutable principles of project management. My co-speaker is a senior manager at Pay Pal, which make very good use of Scrum in the development and maintenance of its code base.

One of the learning from that series of lectures is that a software development method needs to have a domain and context for it to be effective. If we say a development method is valuable in the absence of that domain and context, we are following Mencken axiom

I wrote a little article about Barriers to Agility in the most recent version of PragPub, the online magazine from the Pragmatic Bookshelf. There’s a bunch of other good articles in there, too. Andy Lester has a great article about speaking as a way to practice interviewing, a bunch of comments/thoughts/rants about the iPad, and much more. Take a look!

Tweet This Post

From the Ask Tom mailbag:

Question:
I learned today that my salary, as a manager of a department, is less than the people on my department team. My boss told me that adjustments will be made during my review. What is the best way to deal with this without feeling betrayed by my employer? I have been with the company fewer years, but promoted twice and my skills far exceed those on my team.

Response:
Your situation is not unusual. Most companies have only an intuitive idea about appropriate compensation and much less of an idea when asked to explain their compensation structure. Curing a compensation structure that is out of whack is quite difficult.

This is complicated by the fact that compensation gets wrapped up in the self concept of a person's value. Not the case. Compensation must be based on the contribution of the role. The person may have higher capability and the potential to play a higher role, but it is the role that commands the compensation, not the person.

Elliott Jaques was quite specific and clear on the subject of compensation. He offers a simple basis for compensation banding with Time Span as the metric. Compensation, in Jaques model, is directly tied to the effective Time Span responsibilities in the role. And in your case, as a manager, your task assignments (goals) would necessarily have longer Time Spans associated. This would command a higher pay band than those on your team.

Your employer gets the benefit of the doubt on this one, acknowledging that an adjustment is appropriate. And it is likely to take some time to fix this systemic misunderstanding. And an even longer time for your boss to understand why.

Yesterday, we kicked off our new Subject Area in our Working Leadership Program, Goals, the Essence of Time Span.

This community is growing. We currently have 81 members with an additional 72 people participating in the Free Trial. This activity level is unbelievable and we would like to share it with you. We are going to hold our Free Trial open for two more days. Follow this link to Working Leadership Free Trial.

Here is what we know about our community.

1. Our participants have a day job, as a manager.
2. Our participants are really busy.
3. Our participants want to be more effective, now.

This is Real
Working Leadership Online is practical. There are no quizzes or tests. There is no make-work. This is not extra work. The Field Work is real.

At Your Pace
Participants login on their schedule.

Unforgettable
The problem with most training programs is they stop. After a few classes, it's over, good luck. Working Leadership Online goes year-round. It changes the way you think about your role as a manager.

How This Works
Your first Subject Area is on us. Then you decide. We are holding the next 50 slots. Word is already on the street, so we expect to close this offer in the next few days.

Here's Some Feedback

This program is anti-matter to today's barage of costly management solutions. The program covered a great deal of critical leadership material that managers can immediately benefit from. -Cathy Darby

Some people live online and I'm not one of them. I'd much rather be in a human presence. Having said that, after Tom's first response he won me over. His honesty and feedback is invaluable. -Jane Hein

There's a lot of valuable information in this course that isn't easily available elsewhere, and the coaching from Tom in addition to accountability for actually carrying out the assignments makes for a solid learning experience. Keep up the good work. The online format makes the course accessible, and makes it easy to put into practice directly in a work environment. -Erik LaBianca

www.workingleadership.com

Here is the schedule for the coming year.

2010 Subject Area Schedule (Total 15 Subject Areas in 2010)

• Jan 11 - Planning - Your 2010 Business Plan - COMPLETED
• Feb 1 - Goal Setting - The Essence of Time Span
• Feb 22 - Decision Making - Time Span of Discretion
• Mar 15 - Managing Time - Managing Yourself
• Apr 5 - Spring Break
• Apr 12 - Communication - Mineral Rights Conversation
• May 3 - Delegation - Leveraging Time Span Capability
• May 24 - Control Systems and Feedback Loops
• Jun 14 - Team Problem Solving - Time Span Inside a Team
• Jul 5 - Summer Break
• Jul 12 - Coaching - Bringing Value as a Manager
• Aug 2 - Coaching Underperformance - Time Span and the Employment Contract
• Aug 23 - Coaching High Performance - Time Span and Maximum Capability
• Sep 13 - Fall Break
• Sep 20 - Managerial Authorities - Time Span and Accountability
• Oct 11 - Managerial Authorities - Time Span and Hiring Talent
• Nov 1- Time Span and Effectiveness
• Nov 22 - Break (Thanksgiving USA)
• Nov 29 - Bringing Out the Best In People
• Dec 20-Jan 9, 2011 Winter Break

Reserve your spot today - Working Leadership Free Trial

From the Ask Tom mailbag:

Question:
One of my biggest frustrations, as a manager, is the expectation from the people that report to me that I 'spoon feed' them answers to all of the problems and challenges that they face. Do I have the wrong people? How can I get out of this trap?

Response:
Your solution is in your question. You are spoon feeding them the wrong stuff. When you provide answers to your team, you are creating a co-dependent relationship that you turns you into Radio Shack (you've got questions, we've got answers). You are actually training them NOT to solve their problems, but to bring them to you for solutions.

So, STOP it.

Every team member is entitled to have a competent manager, with the Time Span capability to bring value to their problem solving and decision making.

As a manager, you do NOT bring value by spoon feeding answers. Learning happens through questions, not answers. As a manager, your greatest value is in the questions you ask your team members. And if you are not getting the response you want, then you are asking the wrong questions.

It's Groundhog Day - a day proliferating the myth that a rodent can predict the weather six weeks out.  Personally, the day means nothing to Iowans.  There will almost always be foul winter weather during the high school basketball tournaments in March.  And spring doesn't really arrive until my neighbor, Ann, and I come out of our mutual hibernations and have our first prolonged driveway chat.

But for a moment, let's assume this myth about seeing the shadow thing is true.  We then have another example of how systems ignorance (the opposite of systems thinking) can mess up decision-making.

Dissect this with me.  The groundhog makes a decision to leave his home and go outside.  If he DOES NOT see his shadow, he decides everything is okay, and he can stick around for a while (thereby ushering in spring).  If he DOES see his shadow, however, he freaks out, decides outside is unsafe, and scurries back into the safety of his abode.

Pretty absurd, eh?

A manager (or executive, or any other form of so-called leader) pokes his head out of his organization into the world at large.  Seeing nothing threatening out there, he (or she, to be fair) decides that the environment is non-threateningly great and that he and his organizational can flourish.  However, if the rodent manager sees that his actions (shadow) have had an impact on the outside environment, he becomes freaked out and retreats back into his cubicle, hoping a prolonged status quo will prevail.

OK, that's a little tongue-in-cheek.  As organizational groundhogs, we need to seize the shadow.  We need to recognize our role that our outputs are having on the environment around us.  If we do see those impacts (positive or negative), we need to be accountable for them, embrace them, seize them, and own them.  And if that means fixing them, so be it.

Will you simply see your shadow today?  Or will you also seize your shadow as well?

There is one of those semi-heated discussions on an agile forum around CMMI, Agile and the confusion between them. Here's a summary from CMMI DEV V1.2. Note that the software development activities live in Engineering.

An Update

I'm presenting to a graduate class at Carnegie Mellon West Monday and Tuesday of this week. As well I'm in a loop discussion on an agile forum about CMMI and agile.

It's breathtaking how many people confuse CMMI with a software development method. Much in the same way there is confusion between PMBOK and a project management method.

The chart above - if you in fact take CMMI as a framework for software based product development maturity assessment - shows where "development" activities live and where other activities live. CMMI says you need all these process areas to increase the probability of success.

So agile software development provides methods to fulfill some of these process areas. Specifically the one in the Engineering Process Group. But there are process area where agile has little our nothing to say.

So Agile is not project management in the sense used by those defining the processes of project management. If you redefine the process needed to increase the probability of success of the software project, then maybe you can call agile project management.