A Book about Problem Solving

I am writing a book. I plan to finish writing this book by the end of March 2010, and  plan to publish it by the end of March 2011. Those are my big goals.  The book is about solving problems, and not just any problem, but solving a specific class of problems. It is the class of problems that requires a number of diverse leaders to agree on how to solve the problem in order for it to get resolved satisfactorily.  It is the class of problems that an investment of time of weeks or months is worthwhile in order to solve the problem.  What, you might ask, would compel me to write a book about solving problems?  That “what” is simply success, the success brought about by the confluence of two events: 1) Being put in a position, as an engineering manager, where I had to solve problems of that magnitude; and, 2) the discovery of a tool that enabled me to systematically solve those problems with outstanding results and lasting effects. I want to share the experience of that success with others so they may enjoy similar results. That is why I am writing the book.

The reason I mention this book to this kind audience of program and project managers is that one type of problem that appears well suited to this problem-solving method is the alignment of a product development process itself.  Let me illustrate a couple of examples where this process has worked wonderfully.  The first is the M&A scenario, and the second is what I call the “teen years” of a startup company.

Example 1: M&A

I worked at PalmOne, a company that was the combination of two companies, Palm and Handspring, each with a mature product development process and each process different enough so that teams familiar with one were confused when working with those familiar with the other.  You can imagine the frustration and finger-pointing that occurred as some folks fought over the same roles and other roles were left unfilled. Both sides were confident that their product development process was adequate, and neither side wanted to change. But, change they did.  This problem-solving process focused the energies of all these smart people on problems (not the people) and leveraged their many talents to create and implement solutions for the problems. Within 8 weeks, leaders in all groups that participated in product development, from both Palm and Handspring, were in agreement as to how PalmOne would develop products.

Example 2: The Startup “Teen Years”

Those of you who have worked at startup companies may have experienced that phase in the growth of the company at which the company has grown beyond the scope of the generally like-minded founders and their close acquaintances and has gotten to the stage that requires it to draw in talent from other backgrounds and experiences.  I call this the “Teen Years” since it seems to occur when the number of employees is in the teens.  Also, the behavior of the company is a lot like a teenager, with an “I can do it myself” attitude and a company culture that can be characterized as a kaleidoscope of moods and personalities.  Fortunately, the company staff are adults, and they appreciate the need for aligning the manner in which they are all going to work together.  In this situation, too, the problem-solving method works very well, focusing the team on problems and drawing upon their various backgrounds for ideas on which to develop a work flow suited for their size and their unique needs.  Yes, even the teenager can be satisfied.

What is this process? Where did it come from? And, how can it possibly “herd cats” as advertised. In the next blog, I will outline the process itself.  For those interested in reading ahead, you can find the unfinished book in blog form on the Engineering Leadership Special Interest Group (ELSIG) blog site:

http://sdforumelsig.blogspot.com/search?q=matt+schlegel

You will want to read the oldest posts first.

I have told some folks how I discovered this approach to problem solving.  I will write about this in the next blog. In the meantime, after reading the ELSIG blogs, I wonder whether anyone sees similarities between this approach and other approaches that you have seen or used? I would appreciate your replies with your thoughts on this.