News aggregator

Here's an offer you can't refuse. Make a donation to Nerd Vittles this month and we'll purchase on your behalf and provide you with a complimentary copy of one of the world's very best integrated scheduling and appointment systems at no additional cost to you. It's perfect for any business or profession that schedules appointments by individual, by venue, or by reservation of some facility. This commercial software normally retails for $299.

Twitter ended supported for basic authentication this morning putting Tweet2Dial and TweedleD in the graveyard. Today we restore TweedleD to the living using Twitter's new OAuth authentication scheme. When new calls arrive on your Asterisk server, TweedleD generates Twitter and SMS messages to alert you.

My friend (and neighbor) Johanna Rothman has a piece in her newsletter which she calls, Park Projects You Can't Staff, For Now.  It's a very good way of describing the common problem businesses put themselves into: too much work in process.

How many projects are you working on now? If you're like most people, groups, and organizations, the answer is more than one. You, your group, and organization are suffering from multitasking. That means that you have more projects than you have people to staff them. It's time to park some work.

Of course, people are working on multiple projects.  From management's perspective, we push projects into the system to ensure that people are "always busy" under the belief that people are a waste.  (Which itself is a belief that if someone isn't ON a project, they must be idle.)  And from the individual contributor's perspective, they cannot say "no" or otherwise refuse once management activates a project that requires their expertise. 

The solution: park those excess projects.  The project isn't canceled or stopped, it's just in park until the system can afford to pick up this project and put it in high gear.  And parked means that no work is done on that project until management puts it back into drive.

By the way, while cutting work-in-process is a good idea in itself, organizations have interesting ways of pushing more work back into the system.  To make this stick, this needs to be part of a larger effort to improve management of the organization.

[Image: "PRND321" by Taylor Nelson]

If you’ve never been to Alaska, you really should add it to your Bucket List. No, I couldn’t see Russia… even with binoculars. But, after being out of the travel loop for the better part of this decade, it was an awakening experience on many levels: air travel, airport security, cruise travel, Internet connectivity, national [...]

I just finished both the classic book on "change management," Leading Change by John Kotter.  Next on my list is Kotter's companion set of examples and stories of successful changes, The Heart of Change: Real-Life Stories of How People Change Their Organizations.  Leading Change has been sitting on my should-read list for quite a while, particularly since my association with the MS-LOC program at Northwestern.  It's also come up a number of times on a Theory of Constraints mailing list as a must read to get a better understanding of why change implementations get stuck and what to do about it.

Leading Change has its familiar eight stages of change.  But the clear message is that big changes can only happen through leadership, taken on by people throughout the organization, not just the CEO and a few titular leaders.  For a change effort to work, the organization has to grant people leadership capabilities and let them run.  Organizations that want to change cannot work from command-and-control and "the old ways" of doing things.  Kotter makes reference many times to the 20th Century way of doing business that generally assumes everything will stay the same - business that just needs good management.  It is clear that everything will not stay the same, and that change demands leadership appear in many places.  In the closing chapters he talks about how to create those leaders and makes a strong tie to the idea of lifelong learning - allowing people to learn from their mistakes, their work, their curiosity and grow into leadership roles.  The book is both inspirational and somewhat fear inducing.  But then, no one ever said this should be easy.

Kotter's 8 stage process for change is as follows with some of my thoughts on each point.  I can't possibly cover the whole thing here.  If you are curious, go read the book.

1. Establish a sense of urgency.  If people in the organization don't believe the change is worth it, then they will be much less likely to get behind it.  And they will be more likely to drop the focus when the next shiny idea comes along.  And those shiny ideas come along frequently.
2. Create the guiding coalition.  Major changes cannot be accomplished by fiat, nor can small groups successfully complete the change.  But a guiding coalition or steering committee has to be built and committed to helping drive the effort across the organization.  It wouldn't hurt if one or two skeptics are in this core group.
3. Develop a vision and strategy.  What is the organization going to look like when this change is done?  What does it look like while the change happens?  I like that Kotter places a lot of importance on making the vision be something that makes sense to everyone, not just the people who wrote it.
4. Communicate the change vision.  One friend commented that Leading Change is all about communication.  It's a huge component all the way up and down these eight stages.  One thing I see in companies is that while top management believe they've told their people about X, most people in the organization haven't heard about it or recall only small pieces of the idea.  Kotter has seen this as well and reiterates the idea that important ideas have to be communicated many times in many ways.  More importantly, if it's such a big effort, people's daily communication needs to reflect the new way of working.  Internal leaders must "be the change they wish to see," quoting Gandhi.
5. Empower employees for broad-based action.  More leadership.  People throughout the organization must be able to take actions that they see is in line with the vision and the authority that they have to do something about it.  No more claims of "it's not my job." 
6. Generate short-term wins.  I was a little surprised to see this so far down the list, but then Kotter's discussion makes sense.  Many of the eight stages happen in parallel, and the short-term wins have to be clearly linked to the efforts made to get to the vision.
7. Consolidate gains and produce more change.  The core element of this chapter was, "Don't rest on your laurels" after a few good things happen.  Sure, you can celebrate, but you also need to redouble efforts, lest the progress you've made gets lost in the excitement of the Next Thing on the agenda.  Kotter also addressed an important aspect of procedures and policies that are tied to the "old way" of doing business.  These policies can be buried deep in the fabric of the organization and must be found and removed/changed to bring the organization in line with the new way of doing business.  And it's not a bad idea to write down the new policies, so you know why they are there.
8. Anchor new approaches in the culture.  While this is last on the list, I have to believe this comes into play with the development of the vision.  Once you know where you want to be, you also know how you want people to start behaving and what policies are in the way of the change.  As with Stage 7, the sooner the cultural and procedural barriers can be identified and removed the better.

One question I had while reading Leading Change was around the size and type of change under discussion.  Most of the examples were of major changes to the underlying structure or philosophy of a business.  But then as I read into the examples and stages of change, I can see the same problems appearing in seemingly smaller and smaller implementations - nearly anything that requires change to dive into the culture of a business could be under consideration of this model.  And this is where a link to Theory of Constraints appears.

In TOC, there is a set of "layers of resistance" or "layers of buy-in" depending on your point of view.  The layers of buy-in go something like this (layers of resistance are the opposites):

1. We agree on the problem.
2. We agree on the direction of the solution.
3. We agree that the solution solves the problem.
4. We agree that we can overcome any potential negative ramifications.
5. We agree that the obstacles to implementation can be overcome.
6. We commit to move forward.

This progression can be a helpful gauge to see where people are in a change effort and what actions need to be taken to help move the effort along.  Maybe it's because I am an engineer, but I like their logical progression on building an overall consensus to dealing with change.  However, all that is built into the layers of buy-in are the logical transitions.  There is very little in here directly about creating leaders and baking the change into the culture.  And depending on how you look at this model, it is all within the first few stages of Kotter's model (coalition and strategy, mainly).  That said, Kotter's model is probably not the be-all and end-all of change discussions either.

[Photo: "Inde Statue Gandhi" by laurent KB]

The Incredible PBX: a turnkey PBX in a Flash-based system designed for Zero Internet Footprint with free inbound and outbound calling throughout the U.S./Canada and dozens of free Asterisk applications to handle every imaginable PBX task. Rock-solid security, randomly-generated extension passwords, free Skype calling, and more...

Meet Gobble for Google docs: a wget and curl-like utility to programmatically download publicly-accessible files from Google docs. And it's yours to embellish as you see fit thanks to its GPL2 license.

Do you want to do things well, or do the right things?  The difference between efficiency and effectiveness is exactly this difference.

Today, I came across this interview with Keivan Zokaei of the Lean Enterprise Research Center from last year where he says the same thing. Moving from efficiency to effectiveness using adaptive systems thinking.

Doing things efficiently is pointless if they are the wrong things. Here, we interview Keivan Zokaei of the Lean Enterprise Research Centre about how the best organisations, such as Toyota and Tesco, are adaptive to the market's needs whilst maintaining both quality and efficiency within their business processes.

Effectiveness is all about doing the right things.  Doing things that help bring money to the bottom line of the organization - or to help the organization achieve what it wants to achieve. 

But isn't "being efficient" a good thing?  Of course it is.  the problem is that most organizations focus on being efficient under the assumption that if everyone is efficient, then we must be successful in the end.  It should be obvious that this isn't true - but it isn't.  Organizations are complex beasts.  Doing things really well in one area might actually degrade the ability of the entire organization to do well.  

If you don't believe me, check around your organization for the way it is measured.  Is your plant equipment measured on "uptime?"  How does uptime everywhere relate to selling more product?  (No, not MAKING more product.  SELLING more product.)  Are you project team members measured by how well they are able to hit internal milestones?  Does that translate into projects finishing on time?  Are the sales people measured (rewarded) when they hit their targets?  Are they rewarded even more by exceeding targets?  Are they punished if they don't hit the targets?  I wonder how high their targets would be if these reward schemes weren't in place?  And how much does the organization suffer in lost sales because of it?

The best organizations know what the right things are, and then they have focused efforts on improving the efficiency of those things.  All the while, monitoring their business to check for other things that may get in the way of overall effectiveness. 

I'm looking forward to reading more of Bob Sproull's new blog on this topic, Focus and Leverage.  [Both this link and the link to the article above were mentioned by @Kallokian.]

[Photo: Excellent descriptive graphic, "Efficient VERSUS Effective" by Laura Dantonio]

Welcome to the August 2010 edition of The Geeks and God Podcast. In this month’s episode, ChurchTechGuy reports on the Gurus of Tech Conference, a couple of pieces of quick Drupal news, and in the Drupal Spotlight, part two of Going Live with your Drupal Website.

read more

I'm inspired here by Seth Godin's Getting unstuck: solving the perfect problem, where he suggests dealing with constraints by eliminating them:

The way to solve the perfect problem is to make it imperfect. Don't just bend one of the constraints, eliminate it. Shut down the factory. Walk away from the job. Change your product completely. Ignore the board.

If the only alternative is slow and painful failure, the way to get unstuck is to blow up a constraint, deal with the pain and then run forward. Fast.

What do you think of when you hear about constraints?  Do you want to eliminate them, as Seth suggests?  Do you want to change them?  Do you want to know why they are there?  Or do you know that they are a fact of life?  It all depends on your perspective and what you think those constraints do.

I'm a chemical engineer by training.  Constraints go into equations and set the boundaries of an optimization: temperature must be between 300 and 350 Kelvin.  Pressure must be ___.  Operating time must be ___.  Material of construction.  Ratio of materials.  Speed of addition.  In this scenario, constraints must not be violated for safety, regulatory, physics, and many other reasons.  They are just there.

In the world of business, we  run into a lot of other types of constraints (or roadblocks) to getting things done.  There's the classic "that's not how we do things here" that can hide layers and layers of decisions and behaviors and cultures.  There is the pointy-haired boss who creates artificial constraints.  There are market conditions that feel out of our control.  There are also things that seem similar to the previous paragraph: the factory can produce X widgets per week, or we can finish about 15 projects a quarter. 

The question is still: what do you do with them when you find them?

But first, how do you decide that a constraint is even worth looking at?  The obvious answer seems to be that if the constraint is preventing you from getting somewhere, you want to deal with it.  In the optimization world, this is an "active constraint."  From the Theory of Constraints, there is only one constraint "active" at any given time.  (Even in optimization circles, a solution where several constraints are active at once is undesirable because small shifts in other variables can push you beyond the edge into undesirable territory.)  For any system, the only interesting constraint is the one that is preventing that system from getting more of what it wants.  In business, that's typically sales.  In personal life, it could be all sorts of things.  But the constraint is the thing keeping you from getting more of what you want.

You know what you want, right?

Now if you know what you want, and you know what is keeping you from getting there, the response is obvious, right?  Follow Seth's advice: Just get rid of that constraint and get what you want. 

The funny thing about constraints, though.  There is always another one waiting for you: something else will keep you from getting more (maybe even your own limits in how you define your goal).

Another way to look at this from a process perspective is to try to get as much through the system in spite of the constraint.  Build (or rebuild) the processes around it so that you don't smash up against the constraint so hard.  Your machine can only make X widgets a week (and you can sell many more than that), then you had better not be making sub-par widgets.  Don't give the machine crummy materials.  Don't drop the widgets that its does make.  Make sure everyone knows what the constraint is, so they can work it into their operations.  And keep a vigilant eye out for the situation where the constraint moves.  (You've bought another machine, and now the constraint is in Sales instead of Operations.)

[Photo: "Friend or Foe?" by Jenn and Tony Bot]

How many times to you or a colleague have a brilliant insight that will solve the world's problems?  Does that insight go anywhere, or does it sit on the pile of other insights?  Or you try to do something with it but run into roadblocks that make the idea harder harder to implement.  Welcome to the half-baked idea. 

I thought about this today because of Holly Green's piece in Blogging Innovation, What If You Asked "What If?".

Every time you have a thought bubble that says, “I am right!”, deliberately pause and ask, “What if I’m wrong? What if there’s a different way to see this?” Innovation doesn’t mean you walk around wondering if you’re wrong all the time. The idea is to force yourself (every now and then) to open your mind, suspend your assumptions and judgment, and simply ponder, “What if…?”

While Holly is thinking about innovation, I think this has connections with any kind of idea: improvements, new hires, rearranging the furniture, etc. etc. 

Great ideas are only that.  There is no requirement that you take action on them.  But if you do, along with fitting that new project into all the others, you must take another look at the idea with the "What if" thought in mind: "What negatives could come out of implementing this idea?"  (I'm assuming the idea is there because you / the group believe it will have a positive impact.)  You certainly don't want to find yourself halfway through an implementation, only to discover those unintended consequences.

This is not a suggestion to kill ideas simply because there are negative ramifications.  It is a suggestion to verify that those negatives could really happen, and decide how to prevent those negatives from happening while still getting the benefit from the original idea.  This might be part of a risk management practice, or it could be part of being smart about deciding how to do things. 

The Theory of Constraints community has a specific logic tool, called Negative Branch Reservations (NBR) which is used to help understand how the negatives can come out of the great idea.  There are usually things like, "If we do X, then we'll run out of money before the benefits are realized."  Or "If we do that, then I will lose my job."  They aren't always articulated so clearly, so you have to listen.  But then job of the team is to first check the reality of these statements (will she really lose her job?).  If the negative could happen (the budget might run really thin), then you must develop ways to overcome the problems.  And decide whether the idea is still worth it. 

[Photo: "Book of Shadows II {closeup}" from Deborah Austin]

Another book in my long backlog was Ray Immelman's Great Boss Dead Boss (How to extract the very best performance from your company and not get crucified in the process) from 2003.  I finally picked up a copy and thoroughly enjoyed it.  As with many good books, the ideas have me looking at the world in a slightly different way.  Of course, the book has its own website.  (Disclaimer: I know Ray from consulting work he did with my employer around the time he was writing this book and from later interactions in the TOC community.)

I had no real idea of the topic of the book, other than the odd title and the fact that it had been recommended by a number of colleagues over the past few years.  I had assumed the book would cover the general topic Theory of Constraints book, but that is not the case.  It's about how people interact with one another, specifically around motivation and performance.  And it is (another) business novel with a fairly narrow focus on the protagonist and what he learns from his guru and his business.

The general idea beyond the story of the book is that people act in fairly predicable ways around their individual security and value perception - this isn't terribly surprising or new to anyone.  The additional piece that Immelman adds to this discussion is that this individual perception is also strongly tied to the association people have with their "tribes" or groups to which they belong.  People are members of many different tribes in their lives, from family to neighborhood to school affiliations to professional associations to office cliques to functional silos.  And just as people act to protect their personal security and value, they will work together to protect their tribal security and value.  And the individual and the tribal interact.  If you can understand these things and some version of the 5 Tribal Dimensions and 23 Tribal Attributes discovered in the course of the story, you should be able to act in ways to create a very different kind of organization.

Why does this make me see the world in a different light?  It's the way the story developed.  Type types of self and group interests and the attributes were illustrated with familiar stories from the business press, and through application by the protagonist.  I could see examples in my own history and in thoughts about how things work with our clients.  Resistance to change?  It's because the way we approach the change is perceived to threaten something in their security or value.  Or the change helps a different tribe "win" over "my tribe."  Frequently, in management-supported change efforts, it's the workers vs. management tribe - no wonder management initiatives don't get very far.

An element near the end connects back to the ideas of leadership: Along with the familiar discussions of leadership integrity and the like, the leader has to have the psychological "guts" to take the company in the right directions.  They can't be perceived as weak along those lines - even if they don't necessarily have all the answers.  Another piece of this is that leaders need to have mentors with psychological strength to help them grow even further.  I know I have grown and improved much better when I have mentors to help me reach new heights.

Now to ponder how to incorporate these ideas with my ongoing work. 

The book went through the familiar process of a business novel: Setup a big problem that the protagonist can't solve, no matter how smart he is (or has been in the past).  Discover a guru who has solved the problem and who is willing to help.  Grow in understanding as more of the things the guru has been saying are tried and implemented.  Succeed beyond your imagination.  The progression through the protagonist's education was pretty linear.  One thing that might have been interesting would be to have him make mistakes as he went along - not fully understanding what he was learning and applying it "wrong." 

A quick entry on Saturday night.  Update: changed the embed below to link to same docuement on scribd.

I came across Retrieving Projects from Bad Performance (embedded below, assuming Flash works) on LinkedIn, in the status update of the author, Shridhar Lolla.  It's a brief story / case study that describes the initial view of a project environment that is in trouble and poses some interesting questions about how one might start thinking about turning the system.  For Theory of Constraints aficionados, the path of the discussion will be familiar.  I liked that Shridhar doesn't dive all the way into the solution - just providing some things to ponder.  

Retrieving Projects From Bad Performance

How many systems are out there for tracking the status of a project and the tasks within that project?  Whose responsibility is it to gather and compile these status reports?  Is it the manager, project manager, some software?  Is "get the status" the wrong things to consider?

The Manager Tools podcast on Assign Work AND Reporting gives me a new view of this question.  First off, while acknowledging that task status is a valid concern, the Manager Tools guys suggest that the need to “get status” is the wrong view.  Instead, reporting of the task status is the responsibility of the task owner: she is the best person to know when a task is done (including handing off any relevant documentation, code, materials).  And she is the best person to know that the task is going to be done early or late.  And if there are problems, the owner most likely knows who might be able to help.  

The Manager Tools guys touch briefly on why this reporting of status has gotten away from the task owners.  In the world of primarily physical work, the status was obvious: the thing you were working on was sitting there for everyone to see.  But in knowledge work, much of the status is not obvious until the task is done.  And even then, people may not know the work is done until they ask for it.  It makes sense for the person doing the work to report this status. 

But why don't they report status?  The manager tools guys suggest that it's due to the way managers and business talks about tasks.  The tasks are "do X," and there is no longer the assumption that status is part of "X."  Without that assumed need, people naturally do not report the status.  Manager Tools argues that is it not obvious when work is done.  More importantly, it is easy to hide "not done" and "going to be late" if the standard behavior is not reporting the status.  So Manager Tools recommend changing task descriptions to "do X and report on status," where the status is something in the form of a report or proof that the task is complete (or the current state of the task).

So why is this so interesting?  One of the elements of the work I've been doing with Critical Chain Project Management has to do with task management.  Rather than holding people to specific dates, we ask them to to work as quickly as possible (single-task focus) to get tasks done when they start.  And while the task is in progress, report the status on a daily basis in the form of how much time is remaining on the task.  If there are problems / delays, that should be reported as quickly as possible, so the issue can be resolved and the task completed.  The goal is not to complete individual tasks "on time" but to complete the overall project as quickly as possible.  This dovetails nicely with the discussion from Manager Tools: the task owner should be responsible for communicating the status.

Another thing they touch on is the idea of status tracking software.  If it is built and set up with the mindset that it is there to "get the status" of tasks, the organization is going to find great resistance to the software.  This sets up the software as the enemy, and it's even worse if management don't bother using the status information to make decisions.  (Ever hear the argument that people can't get work done because they are spending so much time updating the status?  It's a smokescreen.)  Instead, if software is to be used, it has to be part of a logical response to how task owners can report status / troubles / successes in a standard way that helps them do their job AND helps the organization do something with the information.

[Photo: "Every year is getting shorter, never seem to find the time" by John Harvey]

We are pleased to introduce the latest, greatest PBX in a Flash with 32-bit and 64-bit CentOS 5.5 support and three customizable editions supporting Asterisk 1.4, Asterisk 1.6.2, Zaptel, and DAHDI.

Welcome to the July 2010 edition of The Geeks and God Podcast. This month, we'll talk about Calls to Action, Blogging with Posterous, and Going Live; what to do as you move your Drupal Website from development to live.

Before we get into our main topics, Mark and Micah discuss the Southeast Linux Fest / DrupalCamp, then Ed takes a look at Posterous. We discuss calls to action on your church website, then Hans brings us part one of his series on going live with Drupal.

read more

I've come across a nice article by Bob Sproull that describes how he has combined Theory of Constraints with Six Sigma and Lean to create what he calls the Ultimate Improvement Cycle, Maximizing Profits Through the Integration of Lean, Six Sigma and Theory of Constraints, from Six Sigma IQ (IQPC).  Obviously, this is related to his book, The Ultimate Improvement Cycle.  Sproull is not the only one to talk about this concept, and there are a few pointers in the end notes of the article.

Although I am a huge supporter of both Lean and Six Sigma, the profits realized from these two initiatives, or even the hybrid Lean Six Sigma, pale in comparison to what can happen from an integrated Lean, Six Sigma Theory of Constraints (TOC) (or as I call it, the Ultimate Improvement Cycle [UIC]). In fact, one double blind study of 21 electronics plants has confirmed that an integrated Lean Six Sigma Theory of Constraints improved profits roughly 22 times that of Lean and 13 times more than Six Sigma if these were both singular process improvement initiatives.

The Theory of Constraints community is often given a hard time for the seemingly-blind belief that TOC is the way to run a business.  Maybe one of the elements of that has been the rejection or diminution of many other useful tools in the management toolbox.  Looking across the wider landscape, as Sproull is doing here, should help fit TOC into the big picture.  Where do each of these tools fit best?  How can they bring the most advantage to an organization?  This work clearly focuses on TOC and Lean and Six Sigma.  But there is nothing preventing one from looking at other methodologies in the same light: what can you use in an Ultimate Improvement Cycle of your own?

How do they fit?  Read the article or the book for the details and some explanatory graphics.  But the basic idea is that if you don't focus improvement efforts at the constraint of the business - the thing that is limiting your profits - then that improvement is going to show little to no return.  This is the biggest complaint about applying the improvement efforts to everything in the business.  You might get lucky and improve on the constraint, but you'll also spend a lot of time (and money) improving areas that don't necessarily need it.  This is Step 1 in the TOC parlance: Identify the Constraint. 

In Step 2 of TOC, you look for ways to get "improve" the constraint: get as much of the right thing out of the constraint and as little as possible of the wrong thing.  Ensure that whatever is happening at the constraint is of high quality (low waste, low rework).

In Step 3 of TOC - by far the hardest because it affects everything else - ensure that everything else in the business supports the constraint.  Make sure the constraint is never starved for work.  All work that is delivered to the constraint should be of high quality - get rid of defective work BEFORE it hits the constraint.  Any processes after the constraint should be careful that they don't create a rework situation where the constraint would have to redo what it has already done. 

In my reading of Sproull and other discussions on this topic, it is in Steps 2 and 3 where the improvement methodologies really come into play.  TOC doesn't provide any specific guidance on HOW to exploit and subordinate, it just directs you to do it.  (Clarification: the TOC applications guide you on the HOW at the high level, but there are many lower levels which are left to the specifics of the implementation.)  These aren't the only connection points that Sproull makes to the TOC Process of Ongoing Improvement, as the Five Focusing Steps are known.  But they are some of the most obvious in my mind.

This week we introduce a new, ultra-secure methodology for managing remote phone access to your Incredible PBX. Meet Travelin' Man, a web-based, one-click Asterisk application that automatically reconfigures your Asterisk PBX to enable remote SIP phone access. Supports one extension or hundreds. Setup is simple and takes only a few minutes.

Lisa Scheinkopf's Thinking for a Change: Putting the TOC Thinking Processes to Use came out over ten years ago, but it does a good job of describing and summarizing the Theory of Constraints (TOC) thinking processes.  As is often my bent on reading a business book, I couldn't help applying the ideas to my current business situation.  In this example, I filled up several pages in my notebook with partial trees and other notes inspired by discussions with a colleague this week.

Going along with the applied feel to the book, each thinking tool is treated as a stand-alone topic, with the specific recommendation on when to use the specific thinking tool.  The examples used throughout the book have a real-life feel to them, rather than something polished and perfect.  In fact, several of the examples come from personal life, rather than business life.  And it is only at the end of the book where she describes how the tools can all work together to help think through major changes, helping to understand What to Change; What to Change To; and How to Cause the Change.  Scheinkopf also has a brief section on how to use the Current Reality Tree (CRT) as a device for communicating with others: the Communications CRT, which is an interesting topic.

That said, one quibble I had with the book was that the order of introduction of each thinking tool was a bit random.  This included one chapter where she used an example for a Future Reality Tree (FRT) that came from the Current Reality Tree (CRT) example discussed in a subsequent chapter.  And the graphics used for the example trees felt a little clumsy.  I don't know if this is due to the age of the book and capabilities of the tree-drawing packages.  But that also gets back to the practical nature of the writing: use what you have to draw these things: paper, the drawing package in your word processor

The book has a different feel as compared to Dettmer's more recently published, The Logical Thinking Processes (my review).  Dettmer's book was more academic in feel (and thicker), and it seems somehow more thorough in the treatment.  While both books provided step-by-step instructions, the process for the individual thinking tools was clearer with Scheinkopf.  I also like Scheinkopf's description of the mechanism for challenging the thinking trees: there are challenges associated with what has been explicitly written (the boxes and the arrows), and there are challenges associated with what has not been written (additional causes; insufficient causes; predicted effects).  I preferred Dettmer's treatment and recommendations for the Prerequisite Tree (PrT) better, and I see why he recommends collapsing the Transition Tree into the PrT.  Rather than reiterate my take on all the thinking tools, just have a look at my review of Dettmer's book.  Or search for "TOC Thinking Processes" for other descriptions of the tools.

[Photo: "Thinking is Timeless" by Papyrarri]

Today we review four of the world's best VoIP softphones for use with the iPhone, iPad, and iPod Touch. Included in our roundup are Acrobits SIP Softphone, the WiFone from Snizmo.com, the Media5-fone, and Counterpath's new Bria softphone.