Awhile back I got a book in the mail with a polite request to review it. This happens about once a month. While I was curious about the title, Rainbows & Ratholes, I kept shuttling the book from bedside table to briefcase to the corner of my desk and back to my briefcase. As luck would have it, a 3-hour flight-delay coincided with the book being in my briefcase. I finished the book. Dan M. Kothari wrote the book as he says, "…to bridge the gap between theory and practice." It seems to be a common theme.

There is much to like in the book, starting with the introduction.

"Successful organizations embrace a projectized culture that is founded on the principles of customer focus, committed sponsorship, trusting relationships, outstanding teamwork, and continuous improvement."

Kothari offers good advice and distinctive perspectives throughout his book

I was struck that Kothari didn't speak about WBS, ROI, CPM, and risk management. But I didn't have to read far before that stood out in his writing. Kothari bounces back and forth from writing an introductory book explaining WBS, etc. to offering real insights on the five issues raised in his Introduction.

I really like the structure of the book. Read the rest of this entry ¶

The manufacturing world is quite familiar with the term "hidden factory"¹. It points to the extra resources — people, material, energy, tooling, etc. — that are required to rework and repair the variances coming from the production process.

Projects have plenty of variance. Much of it requires rework. Some work is inevitably scrapped. One source of rework results from work that gets out of sequence. One work step proceeds without the appropriate precedent tasks being completed. When the intended precedent task does complete the other task(s) must be reworked. Or, there's no budget available for rework, so someone on the team decides to make do. Or, there's no time available for rework, so someone decides to make do.

iSixSigma ran a cartoon today, Hidden Factory, that got me thinking about what we can do about the hidden project factory. I've been Unsettled About Variation before. While I ponder in my unsettlement, I want to get you thinking with me.

What do you systematically do on your projects to minimize the wastes associated with poor quality?

Please leave a comment. I'll write more about this throughout November.

1. Armand Feigenbaum introduced the idea that there is the equivalent of an additional factory hidden within a factory to handle the defects of production. Later, Jeffrey G. Miller and Thomas E. Vollmann popularized the idea in their paper for HBR. [ ⇑ back ]

How many project management books are there? 1,000? 2,000? Would you believe 16,199? That's the number of unique results (use quotation marks around the term) I got at Amazon at 8:52 PM EDT last night. So how does anyone find a good book among that bunch? One way is to look at the sales rankings. The top book on the list is Scott Berkun's The Art of Project Management. It's a good book that I've reviewed on this weblog. Somewhere down the list is a book I read on the plane two weeks ago, Just Enough Project Management, by Curtis R. Cook.

"You do not need (the PMP®) credentials to successfully manage the vast majority of projects."

Cook writes a primer targeted to the vast majority of people doing projects. Most projects involve no more than three people. They take anywhere from a few days to a few months. They don't require CPM schedules, let alone work breakdown structures. Project controls is what happens when we just can't seem to get traction on the project. That is Cook's audience…quite a big audience. He claims that projects need just enough project management…no more. Unfortunately, there's just not enough targeted at that audience.

I really like Cook's introduction. He puts the work of projects in perspective. He closes the introduction this way, "You do not need (the PMP®) credentials to successfully manage the vast majority of projects." I couldn't agree more. He then goes on to describe the just enough world in four steps:

Read the rest of this entry ¶

There are a bunch of good blogs on project management. Read about them in Karen Klein's story Project Management Goes Blogging. Better yet, pay them a visit.

Construction safety needs to be everyone's concern working in the industry. Great strides have been made by many companies. Yet people are being injured in roughly the same numbers as they have been for the last 15 years. OSHA issued these violations¹ in the year ending September 2006:

1. Scaffolding, General Requirements (7895 violations)
2. Duty to Have Fall Protection (5746 violations)
3. Hazard Communication (5586 violations)
4. Respiratory Protection (3410 violations)
5. Lockout/Tagout (3068 violations)
6. Powered Industrial Trucks (2582 violations)
7. Electrical, Wiring Methods, Components, and Equipment for General Use (2396 violations)
8. Machine Guarding, General Requirements (2296 violations)
9. Ladders (2115 violations)
10. Electrical, General Requirements (1791 violations)

Trenching hazards, while not on this list represent an additional big problem for the industry. There is something you can do. Use the Last Planner System®² on your project. Anecdotal evidence suggests safety incidents will fall by 30%.

1. BLR statistics [ ⇑ back ]
2. The Last Planner System is a registered trademark of the Lean Construction Institute. [ ⇑ back ]

Whether you are doing construction projects, software projects, or any type, current common sense about succeeding at projects suggests going through a PMI certification process to learn the best practices. The agilists and leanies might disagree. However, there's one guy who offers recommendations — 15 of them — that just might produce better project results. His name is David Schmaltz, True North pgs, Inc. You might know him as the author of the fine book, The Blind Men and the Elephant, Mastering Project Work. David is not your ordinary guy. His views on projects — and life — are unconventional. And those views will help you succeed on your projects.

In 1993 David wrote a little book(let) where he shares his best advice. He titled it, This Isn't a Cookbook, The Elements of Project Style. I'll introduce you to the basic ideas. But don't stop with my commentary. Get his book; it's a gem.

"If you can't manage yourself, what business do you have managing anyone or anything else?"

Create Tangible Boundaries

When the world (client) doesn't provide tangible project boundaries you'll need (want) to provide them for yourself.

ScheduleSpaceAlongWithTasks

We can't predict the future, so allow for some slack time to be able to respond responsibly to what happens.

Read the rest of this entry ¶

LPSThe Last Planner System® is a lean approach to planning and delivering projects. It is based on a hierarchy of planning: should, can, will, and did. LPS is not a computer system. It is a set of protocols corresponding with the four above items: pull planning, look-ahead planning, task planning, and daily coordination. The Last Planner System is a registered trademark of the Lean Construction Institute. Last Planner SystemThe Last Planner System® is a lean approach to planning and delivering projects. It is based on a hierarchy of planning: should, can, will, and did. LPS is not a computer system. It is a set of protocols corresponding with the four above items: pull planning, look-ahead planning, task planning, and daily coordination. The Last Planner System is a registered trademark of the Lean Construction Institute.

Create the situation on your project where people will speak.

Project slippages happen on all types of projects. Johanna Rothman, writing for Projects @ Work, offers advice in her article You're Slipping. As usual, Johanna offers practical advice. While she is writing about software projects, projects of all types are more alike than they are not. There's plenty to learn from software and from Johanna. Have a look.

Here's my additional advice: create the situation on your project where people will speak. In most cases, someone on the project has at least had an inkling that something was not going right. Too often the environment is not right for raising the concern…for whatever reasons. When we create the situation for speaking and then we listen we will get the most advance notice that some action is required. In the end it results in less slippage.

Productivity Press has a blog…a good one. Lean Insider is written by Ralph Bernstein. His early postings have plenty of data along with some crisp opinions. In Ralph's posting The Real Problem with US Automakers he shares the results of a new study on the profitability advantage Toyota has over its competitors:

"Toyota has a profit-per-vehicle advantage over competitors ranging from $1,570 (over Chrysler) to $2,985 (over GM). The advantage over Ford is $2,165."

Lean Insider is just the fuel we need to create a big lean fire.

He goes on to share how Toyota produced that advantage and the role kaizen plays in the long term success. Ralph finishes with this opinion:

"(U)ntil Detroit’s leaders genuinely become true believers in lean, they’re going to have difficulty…design(ing) exciting cars and earn(ing) back a quality reputation."

Not only does Lean Insider make for good reading, but I suspect you'll be sharing Ralph's work with those on your project teams and with your management. It's just the fuel we need to create a big lean fire.

There's a new kid on the block and from his early writing, I'll be paying close attention. Creativity Driving Innovation in Business is a weblog written by Sanjay Dalal. (I learned about him from Chuck Frey, perennial innovation blogger.) One of Sanjay's first postings is titled Toyota's Innovation Factory. He offers a good summary of The Elegant Solution: Toyota's Formula for Mastering Innovation, by Matthew May, just published last week. I haven't read the book yet, but my order is in.

Sanjay describes each of the guiding principles and the blocks to innovation.

Guiding Principles for Driving Innovation

1. The Art of Ingenuity

Lean projects are characterized by innovation and learning.

2. The (relentless) Pursuit of Perfection
3. The Rhythm of Fit

Blocking Innovation

1. Swinging For Fences
2. Getting Too Clever
3. Solving Problems Frivolously

This looks like a book worth studying…not just reading. Sanjay finished his review this way:

"Toyota has become the dominant car maker today based on large part due to the Innovation Factory. A Factory based on a foundation of creating elegant solutions through three guiding principles, avoiding three “temptations” and driving ten production practices."

Lean projects start with lean design. And throughout the project they are characterized by innovation and learning. It's time we all learned how it's done.

Most of us know Adobe for its Acrobat PDF software. Did you know that the firm is green? Business 2.0 calls them The Greenest Office in America. And their efforts pay off. For a cumulative $1.1 million investment Adobe enjoys annual savings of almost $1 million. You won't get those returns in the market.

Lean thinking is closely tied to the green movement. The authors of Natural Capitalism claim lean ideas are the theory from which we can build a sustainable environment. Some of The Best 19 Pages on Lean Thinking are offered up in their book. Have a look. And when you're done, how about replacing one or two incandescent bulbs with CFLs?

Design is hot! The subject has been in numerous publications in the last month. Even US News and World Report has led with stories on design. In the Oct 2 issue they reported on IDEO's influence on new product developement and general design influences, The Deans of Design.

Design is important to all of us doing projects. Tom Kelley, principal of IDEO, claims, "We approach (design) from the point of view that the answer is out there, hidden in plain sight, so let's go observe human behavior and see where the opportunities are." Given that projects are usually one-off creations, design continues throughout the project. We need to get comfortable — anticipating design changes — with the process.

Participating in prototyping can make a big difference in the success of the project. Sometimes I see teams acting like they are at effect of design. They even say, "These guys still don't know what they want us to build." That's not good for anyone, particularly the client. When the project performers participate in design activities the overall project has less rework, delay, and lower cost.

This collaborative effort requires a rather enlightened design team. Designing with those people who will build the item takes a different set of skills. Those skills and practices are exactly what is needed to create products and projects that stand out.

Stay tuned. I'll write more on design in the coming weeks.

Software implementation projects in the business setting can confront a company's business processes. When the project team fails to examine the current business processes the project often fails. Writing in CRM Magazine, Barton Goldenberg warns readers, Business Processes Must Precede Technology. (You'll find the same advice reading The Toyota Way, by Jeffrey Liker.) He urges teams to avoid just adopting the business processes inferred by the software. He goes on to say, Unfortunately, too many organizations depend on CRM software vendors to supply needed business processes. As an alternative, Goldenberg recommends a two-step approach to getting CRM efforts off to a good start:

Pay close attention to the specific business situation for your project.

1. Document the key as-is business processes (e.g., using swim-lane techniques) and make sure to note where they fall short.
2. Review best-practice business processes…that help address these shortfalls and then agree to move as-is business processes to to-be business processes

The author could have been writing about any software implementation project. Good business process can be more important than good software to support it. When there's a mismatch of the business process with the promises to the customers there'll be real trouble.

Why do I write about CRM implementation projects? Because so many companies are implementing CRM software and so many implementations go bad. We can learn something about what makes any project successful by looking at projects failures. Goldenberg's general point is to pay close attention to the specific business situation for your project. That is a lesson that applies to all projects.