In the world of product development and software development, customers often come to you with a request for specific things. "It should be green with four wheels." or "Build me a web site to sell my origami." or "It should work just like Google." The thing is, these are specifications or requirements. They could describe just about anything, and often the result doesn't quite do what the customer was thinking of. Why is that?
Partially, this is due to the very familiar problem that people don't know what they want until they have it. One of the reasons that Agile development methodologies have taken hold is to try to solve some of this. Work with the customer directly, create prototypes and iterate, iterate, iterate.
Another direction, inspired for me by Theory of Constraints, is to develop an understanding of why they want these features. Rather than describe the solution - a description that is always going to be lacking - understand what problem they are trying to solve. What limitation or barrier do they need to overcome? And why do they want to do that? Knowing this, it is much easier for everyone in the process to understand what features / capabilities are truly needed to solve the problem and which might be nice-to-have. This doesn't eliminate the need for iteration - it helps people focus on the customer's needs.
[Photo: "scope" by ben dalton]
Clarke Ching has been working in public on his book, Rolling Rocks Downhill, for quite a while. I've read at least one version of it. Last week, he posted an update of one of the chapters where one of the ideas of the book come together: That (software) developers are creating recipes for a cake, rather than baking the same cake over and over. This implies one should be careful about applying manufacturing concepts in such a world.
Here is a quote from Where it all went wrong:
'Okay. Here's the bit that puzzled me. Development teams in other industries start iterating - and therefore testing, since testing is an intrinsic part of iterating - very early in their development processes. They cook version 1 of the cake, test it, tweak the recipe, then cook version 2, and so on. They test throughout the entire development process, but you computer people don't start testing - or iterating - until mid way through a project. Why is that?'
Why do (software) developers act as if the recipe is fixed, when it clearly is not?
Dave Snowden has written and talked about a parallel to this problem many times in the context of knowledge management. Are we asking people to simply pick up an item from a knowledge repository and re-use it (like we might see from someone following a recipe)? Or do we want people to develop enough expertise and understanding to be able to see the key bits of many recipes and create their own (the chef)?
"Knowledge is a treasure chest and its keys are questioning." -Ibn Shihab
I like the sentiment here. You can't just put knowledge somewhere (knowledge repositories anyone?) and expect it to be useful. People learn through asking questions and a back-and-forth process with others.
[Thanks to Boris Jaeger (and Twitter) for helping with the sleuthing on the source!]
What holds your efforts at improvement down?
Big Visible posted a great photo / poster a few weeks ago with their article Velocity Is Like A Helium Balloon. While their focus is Agile development, the thinking behind it can be applied to just about any area of improvement.
Attempting to directly manipulate team velocity is risky and often counterproductive. It can result in the team simply increasing their story point estimates or in taking shortcuts of quality and design so they can get a better number. Such actions damage the utility of the velocity as an input to planning and hide reality from the decision making process. Rather than worry and work over making velocity go up, remember this: [Velocity is like a helium balloon. It will rise on its own, if nothing is holding it down!]
In this case "velocity" is a measure of how fast things are getting done. It is one way to measure the output of the system in which the team is operating. Of course the real measure is value delivered to the customer. (All sorts of assumptions about working on the right things and the larger process in which development is happening.) Similarly, in other environments, there are internal measures that provide a signal as to how the system is operating. But they had better be tied back to creating value. Making more products that just sit in the warehouse to improve "machine efficiency" ratings does not create value. Activating more projects into the portfolio to keep people busy doesn't help - finishing projects is what your customers care about. These, and many other examples, tend to create knock-on problems related too much work in process. You need measures that relate to systematic benefits, not local optima.
The reason this graphic struck me is the last part of the caption, if nothing is holding it down. As I mention above, the measure MUST look at the right thing. But with that, what kinds of things prevent your measure from improving? What actions are you taking to change the system so that your measure improves? Did the action have the expected impact? If not, what made it better or worse than expected? Is the process working as anticipated? Are their policies that prevent the process from working as smoothly as expected?
What is it about the system that prevents your balloon from rising as fast as you want it to do?
One of the many people I follow on Twitter, Richard Cushing, has been interviewed by "find accounting software" and the results posted as Where Does Your ERP Selection Fit with Your Continuous Improvement Efforts?
Richard's discussion follows very familiar territory for people who are interested in Theory of Constraints and other continuous improvement concepts: Focus on the few things that are truly limiting your performance. Use something like the calculations provided by Throughput Accounting to determine if a change is going to be beneficial or not. He even describes the Thinking Processes, and the written interview goes to some lengths to describe how these begin to work to help people understand their system.
Maybe it is the name of the website, but I kept a wary eye on the language. And I was not surprised by the last several questions, which all seem to be of the form, "But isn't ERP software great?" I think Richard did an excellent job of answering - better than I would have done. Essentially, the way most ERP software is setup does not help companies ask useful questions when they begin to think along the lines of TOC (or Lean!) with respect to their organization.
Is ERP or accounting software ever the weakest link in an organization? No.
How does one evaluate ERP software? The same way as any other question in a business. What is the real power behind the opportunity? (Is it different from what we have already?) What limitation does the new software remove? How are we going to change the business if that limitation were to be removed?
Can ERP help identify or manage the constraint? No. I love Richard's response here. "The very best computer to identify system constraints is human intuition applied in a systematic process of understanding the cause-and-effect relationships between activities within the enterprise."
Sometimes I have a technical issue that is surprisingly difficult to solve by the normal methods, usually because the search terms are not specific enough to uncover the solution. Or the solutions that I do uncover aren't relevant. This is one of those cases. Nothing to do with knowledge management or continuous improvement - other than I want to have this recorded somewhere, so I don't have to go through it all again.
The steps to change password settings:
- Type "cmd.exe" in the search area on the "Start" button
- Right click on the "cmd.exe" that appears, and select "Run As Administrator"
- The Command window opens
- Now all the "net accounts" settings will work, including setting the maximum password age to unlimited: "net accounts /maxpwage:unlimited"
If you are interested in the details...
My situation: My password on a Windows 7 machine expires every so often. It's a personal machine, and I don't want to have to re-set the password. Or I want the option to set the policy myself, rather than taking the default.
- I am running Windows 7 Home Premium.
- I am the only user, and I am an "Administrator"
- I am not a slouch when it comes to these things
Most of the help I found told me to start the "Local Users and Groups Manager" or find the "Local Security Policy" editor. Unfortunately, these tools aren't available in Windows 7 Home Premium.
Then, I saw the suggestion to run a function directly from the Command window. I know how to do that, so I dutifully opened cmd.exe and tried
net accounts /maxpwage:unlimited
And got a message that I am not allowed to do such a thing. ("System error 5 has occurred. Access is denied.") But I am the Administrator, what the heck?!
Then it turns out that even though I am an Administrator, I need to be "elevated" somehow. No, that doesn't mean breaking out my old 2" creepers. It means that I have to "run as Administrator" on the applications. I'm sure there is a logical explanation as to why that is, but it seems rather obscure.
Follow the steps above.
Here is more information on running applications in Windows 7 as Administrator with Full Elevated Rights.
And here is information on the "net accounts" options, if you are interested in other policy settings, like password length and the like. Customize the Password Policy in Windows 7 - This page has the same information I just typed here, but searching for it is rather frustrating in the results that come back often don't get you to useful content.
Yishai Ashlag's new book, TOC Thinking: Removing Constraints for Business Growth, is a good overview of the Theory of Constraints approach to thinking about running organizations. Yishai Ashlag is a senior partner at Goldratt Consulting and brings experiences across many different types of project into short anecdotes in the book. And he is Eli Goldratt's son-in-law.
The intro describes the aim of this book as articulating Eli Goldratt's management philosophy through the lens of many key topics. As such, this book covers a lot of familiar ground for people familiar with TOC, along with bringing in the more recent thinking that can be seen at TOC conferences and hasn't been published as widely. Even though much of the content is familiar to me, I have dog-eared every 3rd page with notes about interesting aspects and useful pull quotes.
I had heard an early version of this book back at the Chicago TOCICO conference in 2012 (my notes), particularly the first section on the challenges (fears?) of dealing with uncertainty, conflicts, and complexity - and our strangely strong fascination with overly-sophisticated "solutions" to these challenges. The first section - and really the whole book - is a discussion of where management attention should be focused and how these challenges tend to divide attention while the TOC way of thinking tends to focus attention.
Where to focus attention? Many books and thinkers will tell you - on the most important things. Not on the urgent or the current fire. (But please do evacuate the building.) Less Is More and many others tell you that there has to be a guiding light. Theory of Constraints completely agrees. TOC's body of knowledge contain a number of ways to think about focus, which may be a focus problem of itself. There is the classic TOC Five Focusing Steps that creates the process of ongoing improvement. And in the past ten years, long-term TOC implementations have preferred to build business strategy with the Strategy and Tactics Trees that define how to Build the capability, Capitalize on it, and Sustain it for the long term. And more recently, or possibly in parallel with the S&T Trees, are the Four Concepts of Flow that talk about what a manager / organization should do. All three of these are interconnected. It might be helpful if they were more clearly related to one another.
My take is that once an organization decides on its Goal and the key Constraint to getting there (Five Focusing Steps), the Four Concepts of Flow help put the Exploit and Subordinate steps into context. How do you exploit? Get salable work to flow across the constraint. How do you subordinate? Make sure nothing gets int the way of flow. They are inter-related. The connection to the S&T Tree isn't as obvious because in Theory of Constraints, the thinking processes are a separate line of thinking from the Five Focusing Steps. However, the S&T Trees work under the assumption that the market is the true constraint, and that the operational capacity must always be kept subordinate to this fact.
[Disclaimer: I received a free copy of the book, as I am doing a large project with Goldratt Consulting. My opinions are likely to be swayed.]
Charles Duhigg's The Power of Habit: Why We Do What We Do in Life and Business has a lot of familiar material in it. The concepts he discusses have come up in the popular media over the last couple of years, and people have expressed amazement at the things science has found in terms of how we form habits. Duhigg puts it together in a compelling story that talks about why we get stuck in ruts - in personal life and in business life - and the paths to breaking out of the rut.
The pattern that shows up again and again is the habit loop: There is a cue, which triggers a routine, which leads to a reward. It's a habit when the reward isn't even there, but we follow the routine anyway. Classically, this is the gambler or the alcoholic. But in business life, its the organization that continues to follow a practice long after the need has gone away. Or its the person who constantly checks their email - is the reward the distraction or the one in 100 chance that the email might be truly important?
There is a lot of fascinating detail in the book about how the various aspects of the habit loop work. Duhigg uses anecdotes to draw in the reader and then jumps to the scientific literature to develop a deeper understanding, and then uses that back to the same or other anecdotes. He does the same with mechanisms people have found for changing the habit loop.
Science has found that once a habit exist, it is baked into the pathways of the brain (or the organization). It is only by training the mind to prefer a different response or to focus on a different cue that the habit can be "broken." It is not simply a matter of "will power" or "strength of character." The admonition to "change" or "stop doing behavior X" doesn't work, if it is a habit. The underlying link between the cue and the routine needs to change.
How does one change the habit loop? Duhigg describes people and organizations that have changed the habit loops by attacking it at various points: change the response to the cue; change the social system so that the response is different; change the belief system; re-focus people on different cues; and others aspects.
I liked the epilogue that suggested there was one more element to changing the habit loop: One might have all the knowledge in the world about hows and whys of a habit, but if there is not a desire to change, it will likely not happen.
The evidence is clear: If you want to change a habit, you must find an alternative routine, and your odds go up dramatically when you commit to changing as part of a group. Belief is essential, and it grows out of a communal experience, even if that community is only as large as two people.
Throughout the book, I found a lot of elements that parallel the Heath brothers' Switch (my review). The habit cycle has its Cue - Routine - Reward. And the Heath's talk about three aspects of behaviors: the Elephant, Rider and Path. While they aren't perfectly parallel, I see the Rider as taking an intellectual look at things - maybe like the person who has the habit looking at her cues and routines. Both the Elephant and Path are linked to the routine: there is a path/routine that people follow in response to the cue.
The title "Less is More" has several hits on your favorite book list website these days - weight loss, simplifying your life, etc. But Jason Jennings version of Less Is More takes this line of reasoning into business. What are the things that super-productive companies do that help them stand above the rest? (Are there any such companies? Do they last?) Of course, this kind of question is fraught with problems - mainly, there better not be non-productive companies that do the same things.
The main idea: focus. Focus on one thing - one thing for the long term, not one thing this quarter. And that one thing is the big idea of the organization - why is the organization on the planet? That big idea sets the direction and the yardstick by which everything is measured.
Of course, it would be a short business book if it didn't have a list or a set of principles below this idea of focus. Jennings has a chapter on each of these topics, some with even more lists, but I'll leave those for your own reading pleasure. These items all seem to either relate directly to the idea of focus, or they create the conditions in which focus can happen:
- Trust / Openness: "People only trust someone to lead them if (they believe) everything they say is true." This extends out to customers, suppliers and partners - they won't come back to an organization they don't trust, or the working relationship will be gummed up with bureaucracy.
- Destroy bureaucracy (simplify): This sounds a familiar theme to the Four Principles of Flow - specifically, eliminate those local measures so that the work can flow.
- Get rid of the wrong people (executives and managers) fast and No Layoffs. I like this pairing, as it says the people in leadership positions need to be on board, and if they can't they should go. But the people in the organization who do the work should stay through thick and thin. This also links back to the long-term vision implied by the BIG idea.
- What's the good business reason for doing this (WTGBRFDT)? This question and variations on it link to that BIG idea. In my consulting work, one of the questions we ask is "What is the significant limitation to be overcome" by taking some action. If that can't be answered in a useful way, what is the point of the action?
- Understand the real financial drivers. For many people, financial statements are gibberish. I don't think Jennings is suggesting that everyone needs to become an accountant - he's saying that everyone needs to understand how the company makes money, and where money goes within the company.
- Systematize everything. This is a classic: if you don't know how it works, you can't change or improve it. And Jennings makes another point that if the system isn't defined, then anyone can monkey with it and the results will be similarly undefined.
- Continuous improvement. Just as you can't improve what you don't understand, if you don't have an object (that BIG idea), you don't know in what direction to change.
- Compensation should be directly linked to productivity. This is an interesting topic, as it requires many of the topics above to be working well: Trust/Openness, reduced bureaucracy, understandable systems. And of course, this creates an impressive drive to improve the systems in which people work to enhance productivity.
- The plug-in myth: Technology doesn't create a competitive edge - neither does knowledge(!). These can be copied. It is more important to understand the flow of value and how the technology (or other change) are going to significantly change that flow - and the change had better offset the required investment and additional operating expenses.
- Motivate: Keep everyone on the same page. Keep people aligned to that familiar objective - the BIG idea. This section also talks about the motivational effect of setting up an us-against-them environment, which I've mentally linked to the idea of tribes.
- A lean spirit. The book references Lean obliquely - it seems that Jennings' example companies all use many ideas that embody the spirit of Lean. This closing chapter lists 11 traits of leaders of highly productive companies - many of which reflect back on the preceding chapters. Many of which are good traits of any leader. The idea here is that they come together around their BIG idea.
- "Expensive solutions to any kind of problem are usually the work of mediocrity." (from Ingvar Kamprad of IKEA)
- Unfortunately, most corporate leaders act as though they suffer from ADD when it comes to keeping their companies focused on mastering a simple BIG objective.
- Closed-door conversations are a sign that something needs to be hidden, and people jump to the conclusion that its bad. Even if it is just a personal call to your doctor. Closed management structures are even worse.
- If you trust people to do the right thing, you will largely discover that they do.
- All bureaucracies are a case of "mine is bigger than yours."
- Employees (of highly productive companies) play as much a role as management in deciding what the systems will be. That's real empowerment.
- The real challenge (to motivation) is to spend less time trying to design motivational programs and more time figuring how to get out of the way of people trying to do good things.
- "The danger is when the financial objectives of an organization are placed in front of its mission or purpose." quoting Frederick Taylor - a man who is oft-maligned for creating Taylorism and turning people into robots.
A theme has emerged for me at TOCICO 2014 across many of the talks and discussion this year.
Theory of Constraints implementations generate big changes in organizations. And those big changes by their very nature create conflicts - between new behaviors and old behaviors; between new requirements and old requirements; and even between new mindsets and old mindsets. If the implementations don't seek to resolve these conflicts in some way, they are bound to not reach their full potential. Rob Newbold's talk clearly highlighted this. But it also came up with Sanjeev Gupta and many others.
Do we respond by ignoring the inconvenient conflicts and push ahead with the implementations? Do we build the conflict clouds and look for erroneous assumptions? Do we move in the direction of relative values and balance the conflict by guiding people in the preferred direction? Maybe there are other ways to resolve them?
Good food for thought. And maybe some food for thought on your current projects?
As usual, I'm exhausted after four days of listening and thinking and talking about the Theory of Constraints. Today was loaded with shorter sessions and more interesting conversations.
The day started with two TOCICO International Achievement Awards, presented to Omron Healthcare (Japan) and Godrej Security Solutions (India). Both companies have implemented TOC in multiple areas of the company, and they both have brought their success to the bottom line - enabling growth and surviving downturns with innovative solutions to the challenges in their industries. I particularly liked an insight from the Omron speaker,
It is not Gemba to be changed, it is management to be changed; if management changes, Gemba will also change.
"Gemba" is the place where the action happens in a business - where the value is created. If management changes the way they operate, the way value is created will change as well.
John Koehler talked about a new strategy for business development that he is developing, called Nu-Business. He used a TOC framing to talk about some of the challenges that new businesses find themselves running into, and he has developed some injections to resolves several of these. For example, he has found that many new businesses fail because it takes too long to get to positive cash flow. And that takes too long because they invest too heavily at the outset: they create far too much capacity before they know that the business will be viable. I heard a lot of similarity to the "lean startup" concept of starting small and testing ideas. Koehler has created a phased approach with Nu-Business that acknowledges the changing constraints a business owner has to face as the business grows. I'm curious to learn more as he develops the concept. Koehler is applying the concepts of Nu-Business to his own craft distillery.
Retail operations aren't my forte, but it was interesting to hear Guilherme Almeida and Mathias Fischer of Goldratt Consulting talk about Deep and Narrow Seasonality Strategy work at a large retailer. During peak sales times retailers struggle keep up with sales, so they often push massive amounts of stock to the stores, in hopes that it will sell. Unfortunately, they often end up with excess stock and then massive discounts after the peaks. They did analysis of SKU sales and discovered that the strategy of pushing everything doesn't work - it is only the top sellers that people want to buy, no matter if it is the peak selling period or the off-peak times.
Patrick Wilson presented some thinking about some of the underlying ideas within the TOC Thinking Processes. In the Evaporating Cloud, for example, we talk about the Goal, shared Needs, and conflicting Actions that result. But one can think about this from a different perspective as well. Any action has behind it some measure, which is established by a rule or heuristic, which is created by a belief, which is based on a need, which ties back to the goal. The actions are tangible manifestations of intangibles. Actions are physical (tangible) manifestations of a need or goal. Wilson is hoping that this might be the start of some additional developments of the Thinking Processes.
James Holt and Skip Reedy introduced a CCPM Maturity Model and a mechanism for evaluating CCPM implementations. The maturity model is based on the CMU maturity model, going from (0) Chaos to (1) Initial Steps to (2) Repeatable to (3) Defined to (4) Managed to (5) Optimizing. And they suggest five key areas that a full portfolio management with CCPM implementation will cover: Initiation, Planning, Execution, Recovery, and Evaluation. An important note here is that CCPM primarily covered the Execution and Recovery aspects, though I would argue that one should acknowledge the impact of CCPM on project planning and pipeline planning. The end result of this is a mechanism for evaluating an organization on these five dimensions with a spider chart - over time one should see maturity growing in these dimensions, and it might be a sign of problems if maturity stagnates or reverses.
Dimitar Bakardzhiev talked about another take on the issues of CCPM in software development, where the primary project consists of a number of small tasks (develop a feature) which don't have explicit interdependence. He suggests Project Planning using Little's Law. The thing that was new for me was the "z-curve" (or s-curve) of completed tasks on the cumulative flow diagram (CFD) has a defined initiation, productive, and close-out phases. The overall project should be sized based on the rate of completion in the productive phase, while the buffer should be sized to account for the higher variability initiation and closeout phases. This applies for specific types of projects, though I bet it could be incorporated into larger projects that include this type of work. He's got a slideshare and video posted that follow a similar discussion.
David Ojeda, Matias Birrell, and Salvador Peña presented a case study from Más Capital. In particular, they embedded the use of the TOC Thinking Processes to enable better problem solving. I love how they talked about breaking the familiar challenge in large businesses where people see issues, but don't have a standard mechanism for resolution - usually resulting in slow decision-making. Embedding the TOC thinking processes in their organization helped them speed up the process.
Steve Holt followed on his talk from yesterday with a discussion of Breaking the Management Constraint: Using Mission Command and TOC to Create a Culture of Action. I missed the bulk of his talk, but my ears pricked up when he talked about the fascination we have with "management" (ensuring the right resources at the right time) vs "leadership" (skilled and motivated people). His wide reading of military strategy points out another key element of "command," which is the capability that creates the right strategy. It is this lack of command which creates an environment where people often have no idea why they are there - imagine if that were the case in the military.
Silvério de Souza and Guilherme Almeida spoke about a familiar element of TOC implementations - choke the release. Choking the release is often one of the first steps taken in both manufacturing and project management implementations. They focused on manufacturing and the hidden assumptions under which choking the release creates positive effects. I'll leave the details behind, but the goal of choking the release is to unstick the flow of work on the manufacturing floor, which should reduce lead time and improve due date performance. However, if there are already a high percentage of late orders or if there are work centers full of WIP, the basic guideline won't be sufficient to get the desired effect. Knowing that there are some special cases, they have proposed a couple additional elements of the guideline.
I attended a number of talks on CCPM today at TOCICO, as that is work I am doing these days. And these weren't even all the material that was available on CCPM. There were also some interesting hallway conversations.
David Brown-Brulant talked about extending CCPM with concepts from Lean and Six Sigma. He talked in particular about implementing in a high uncertainty environment like R&D, where the projects themselves aren't guaranteed to deliver the hoped-for result. In these cases one needs to extend the standard CCPM work to include better mechanisms to kill projects that aren't getting to where one would like. The big challenge is always the "one more experiment" mindset. I've also liked other suggestions around developing "killer experiments" that should be done early on in these environments.
Kaoru Watanabe of Hitachi talked about a user-centric design methodology they had developed within their CCPM practice that has helped them develop applications that better meet the needs of their users. In particular, they describe the use case from the perspective of the "flow of desirable effects" - pulling on two threads that are familiar in the TOC community: Flow and Desired Effects.
Chizuru Soejima of NTT Data talked about their enterprise-wide implementation of CCPM. She focused on the mechanisms they created for promoting and supporting CCPM within the organization, but I found most interesting the fact that CCPM project execution is one of the 8 engines of growth for NTT Data that they have acknowledged in their annual reports.
Duncan Patrick and Jack Warchalowski of CMS Montera presented a last-minute replacement on the schedule on a challenging topic: the hidden costs of CCPM - "too big to change". They talked about the issue that public companies which make their money selling projects have to report their financials on a regular basis - and those financials must include actual and expected revenues from projects: revenue recognition and revenue forecasting. This includes reporting the "cost" associated with people allocated to projects. Cost allocations and forecasting is normally an anathema to TOC professionals, but it appears to be a reality. Complicating this reporting in a CCPM environment is the idea that CCPM seeks to shift from scheduling people to scheduling tasks and then executing those tasks as quickly as possible. That's great from a project execution perspective, but from the finance perspective the calculations still need to know how much effort was expended by which people over a given time period. They don't have a specific solution, but they hinted at a few. I prefer the one that relates to the other part of the current reality: most "project management" software that does financial reporting isn't used for project execution - let's keep it that way.
The day closed with Sanjeev Gupta of Realization talking about a high level recommendation to combine CCPM and Kanban in order to deal with the situation I have seen in many project environments where there are activities that must be completed, but they have no a priori interdependencies. Simplify the project network to represent the 20 percent of the work that is truly sequentially linked, and put the remainder of the work into a "task list" and have the work owners manage the work in a Kanban mechanism. This has been done by many people in the CCPM community, and Gupta wanted to acknowledge that it is a valid way to operate.