This website covers knowledge management, personal effectiveness, theory of constraints, amongst other topics. Opinions expressed here are strictly those of the owner, Jack Vinson, and those of the commenters.

Necessary but not Sufficient, again

Some of the Theory of Constraints books bear re-reading, particularly as I continue to work in this area of business and consulting.  This time it is Goldratt's Necessary but not Sufficient, which I posted about a few years ago as well.

One of the most lasting elements from this book is a way to think about technology in light of improving an organization. Quite often, new tools or technology are promoted as being "the solution" to a organization's problems. Often those problems are described in terms of what we don't have.  "We don't have an ERP system." or "We don't have a TPS report." or "I don't have an iPhone."  These are not problems. They are the absence of a solution that someone has already decided they want.  What damage does the lack of that thing cause?  (And what causes that to exist?)

At one point in the story of the book, a technology vendor is surprised to learn that his super-advanced software is used only weekly or monthly, when they think it should be used daily. It turns out they haven't fully understood how the software would impact their customers' operations. Once this is better understood, the software (and its implementation) could be modified to really benefit the customer. And this leads to the Questions for Technology:

  1. What is the power of this technology?  Why is it so great?
  2. What business problem does it solve? What limitation does it remove? Is it valuable to remove this limitation?
  3. What rules/policies/practices/measures are in place because of this problem today? These could be formal or informal, but there are ways of doing business that must exist because of this limitation.
  4. How should those existing rules be changed or removed? What should replace them? If the old way of operating doesn't change, then the new technology isn't going to make a significant impact on the business.
  5. With the changes to business, does the technology also need to change to better support the new way of operating?

A couple other elements stood out in this reading.

  • A big area of conversation in systems thinking circles is the idea of local optima: optimizing a local operation may not be good for the overall system.  But why do people do it?  A lot has to do with the way organizations are siloed and measured. But another aspect of it arose in the book: In the past, most organizations didn't have the ability to see across the whole operation, so improvements had to be local. But now the claim is that we do have the requisite information, and yet we still focus on the local.  Another example of following old rules, even though new capabilities are available.
  • As I had just read Rackham's Major Account Selling Strategy (my review), I was amused in the first few pages to hear essentially the same strategy described.
  • One of the challenges for software developers, as described here, is a battle between "keep it simple" in order to have good service levels and "more and more complexity" in response to market demands. This connects to the questions for technology above: it seems easy to write more and more code, but if it doesn't actually solve a business problem, is it really necessary?
  • There were a number of discussions about "value" of software or technology. Most people focus on intangibles like "efficiency" or "visibility" or internal cost reduction. What really matters is whether the change can lead to true business benefit.  The story walks through several frustrating experiences where "efficiency" has zero impact on the bottom line.
  • What does a good project manager look like?  Among other things, I loved this line: "The right project manager means early warning about potential problems. Early warning means early resolution, and early resolution means happy customers." (p. 59)
  • Toward the end of the book, I was surprised to see a description of a possible service that a technology provider could offer.  It sounded a heck of a lot like cloud computing / software as a service.  And this from a book published in 2000.  The concept had been around, but it's only really taken off in the last ~10 years.  

Another good, fast read of a "standby" book on Theory of Constraints, technology sales and thinking about real business problems.

Kris Cox on the 7 Essentials for Breakthrough Results #UtahGCCon

Do nothing for a while