People like to be busy. It seems like it is built into our DNA. A recent post from Joitske Hulseboch has me thinking about this again, Busy is the new smoking and she links to an earlier post with some advice, Only suckers are busy (in Dutch - thank you Google translation) by Annemiek Leclaire.
There is a strong need in our culture to "contribute." For many people, this gets translated into doing something. And for people who manage other people, this gets translated into some version of "if you aren't busy, I can give you something to keep you busy." And many organizations have a real or implied threat: if you aren't busy, you are likely to be outsourced / fired / made redundant. And what are you supposed to do instead of "be busy"? Sit around and "do nothing" while waiting for that key piece of information, or that key activity to start?
This sounds like a classic internal conflict: On the one hand, find things to do in order to always appear to be contributing (and keep your job). On the other had, be available and ready in order to support the bigger picture in your organization. People have a strong tendency to fall towards the "keep busy" side of things because of those underlying assumptions about job security. And surely, doing something has to be better than doing nothing.
However, one of the side effects of the "keep busy" side of this is that it means people are not available when they are really needed to contribute to a key activity. Particularly in the context of knowledge work, it is very difficult for people around you to know whether you are engaged in a key business activity, or if you are doing something of lower priority to fill time - like writing a blog post. And if people aren't available for a key activity, that key activity ends up takes longer due to all the waiting. And the waiting and restarting and then waiting again for someone else often generates errors or mistakes and rework. All of this ends up extending the overall effort by massive amounts.
Improvement programs that focus on fixing the work process - optimizing the activities themselves - often don't create that much of an overall improvement because they miss the time lost due to flubbed handoffs, waiting, and rework. This time is significant - on the order of 25% or more of the duration of a project.
The improvements that have a lot of success here tend to emphasize getting the work out in the open: shared workspaces, visual boards, kanban, etc. These create a collective understanding of the work and what needs to be done on a regular basis. I find the exercise of learning what people are really doing to be instructive: often even the managers don't have a good picture of everything that people are doing. Even for solo contributors or self-employed consultants, having that visual display of what is happening can be helpful in prioritizing and getting "busy" on the right things.
An analogy: We often operate as if we have a large lake to swim in: many places to go and things to do. But in reality, in any kind of project, we are rowing down a river to meet an objective. The group must row in the same direction and seek to remove barriers as they arise, or the project doesn't get done. Activities required will present themselves as the river flows - there will be times of intensity and times of calm. Of course, the analogy breaks down because those times of intensity will be different, depending on the participants' roles.
[Photo: "stream at Lake Dennison" by Jack Vinson - me!]
I see a lot of projects within business support organizations that look like "implement this tool." And then the organization is surprised when the project takes much longer than expected and the tool doesn't get used to the extent expected.
This shouldn't be a surprise. The organization is often focused on the tool, rather than the larger purpose and how the work gets done.
This comes up nicely in an article from Davide "Folletto" Casali, The Three Speeds of Collaboration: Tool Selection and Culture Fit:
Choosing the right tool is a weird thing to do, because it’s at the same time the most important choice and the least important choice you can do. It’s a paradox because without a tool you can’t collaborate – and mind that: a tool isn’t necessarily a software tool – but at the same time if you have clear what you are trying to do you might find yourself choosing something that isn’t even software, or isn’t even specific for collaboration.
The article focuses on collaboration tools, but remove the collaboration concepts and apply your favorite job that software should do. The idea still make sense. The tools have to fit with the way the organization works - both the formal and informal processes for getting things done. Has the tool been constructed with assumptions that fit with the way things are done in your organization?
I still go back to the Theory of Constraints "questions for technology" related to this conversation. ("Technology" doesn't just mean software, it could be anything new and different - like putting bigger wheels on a mountain bike.) The questions go along the lines of this:
- What is the power of the new technology?
What's the big idea? Why is it so great? But also, where is it expected to fit? Where doesn't it fit? Related to the Casali article, what are the assumptions behind the technology?
- What current limitation or barrier (that exists today) does the new technology eliminate or vastly reduce?
This is a classic TOC phrase, but the idea: What problem does it solve? How would the value proposition of the organization change if that problem were to go away?
- What policies, norms and behavior patterns are used today to bypass the limitation?
The limitation is there. What do we do because of it? What policies, practices, structures are in place because of the limitation?
- What policies, norms and behavior patterns should be used once the new technology is in place?
Using new technology in the "old way" will likely not unlock the full value of the technology. If the limitation goes away, wouldn't many of the behaviors and policies no longer apply? Do we still need to do monthly financial close if we have real-time data in our financial systems?
- In view of the above, what changes/additions to the new technology should be introduced?
I love this question. Now that we understand the situation into which this the technology is applied, what must be added/changed/removed to make it even better? This could be core in the technology, or it could be something about how it is applied to the problem at hand.
- How to cause the change?
How to fit the new technology into the overall organization?
The Questions for Technology are nicely discussed by Eli Schragenheim in this video conversation with Christian Hohmann from last year. Schragenheim was involved in the original development of the questions for technology in the book Necessary but not Sufficient (my latest review).
I received a review copy of Osama A Hashmi's upcoming book, Innovation Thinking Methods for the Modern Entrepreneur. Subtitle: Disciplines of thought that can help you rethink industries and unlock 10x better solutions. It is to be released on 23 March 2016.
It's a short book, meant to be a quick read and guide to start thinking about thinking. Or maybe, more accurately, to get people doing something differently about thinking. (And do so while drinking coffee - a frequent side joke throughout the book. It's hard to fault a guy who likes coffee so much.) The tone is light, but insistent - new ideas don't come about with the kind of thinking that got us where we are now, to paraphrase Einstein.
What is "innovation thinking?" It's in the subtitle and first chapter - creating 10x better solutions. In my mind it is ways of thinking that challenge the status quo. Challenge the assumption that small tweaks are all that you can do. Challenge the belief that the problem is already "solved" or maybe that it "can't be solved." He also explicitly talks about Innovation Thinking as different from incremental improvements and small changes that have become de rigueur in the startup community (i.e. Lean Startup).*
Hashmi uses the book to describe 20 innovation thinking methods - briefly introducing each of them and then providing some examples. The methods ranging from adopting different mindsets and points of view, to framing sentences and techniques, to concepts borrowed from other disciplines. Most of the examples draw from the technology world where Hashmi works, though the methods apply to any industry.
A number of the methods resonated deeply for me in connection with the work I do in Theory of Constraints, particularly the Thinking Processes. The surface of many problems are just the visible symptoms of an underlying system(s). That system consists of many things - the physical world, the policies and practices of the industry, the history of what came before, etc. As I read the book, it struck me that many of the thinking methods seek to understand the system at a deeper level. Changes at the deeper level of the system will have much more significant impact - and are often harder for others to replicate, particularly if they have built themselves into the existing system. I liked how these methods give additional means for digging deeper or trying to understand how the system generates the current effects.
Hashmi doesn't spend time describing the theory or diving into the supporting research for the various thinking methods - this is both an advantage and disadvantage of the book. The advantage is that it keeps the book short and fast, and helps Hashmi maintain his conversational tone throughout. The reader can pick as many or as few of the methods as they want to try them or explore further. The disadvantage for a curious guy like me is that I want to track down those references. Over some coffee, of course.
* Hashmi tries to walk a line here. Lean (and other) methods are not wrong - they can be quite beneficial in the right settings - it's just that in the context of "innovative thinking" the way these methods are employed do not create 10x changes. And of course I have to say that it really depends on how people apply any of these approaches to thinking. Theory of Constraints and Lean can be used to help people think very differently about their world and their situations to create very different results. I also agree if the goal is incremental improvement, that is all one will get, no matter how they are thinking.
The past is a foreign country, they do things differently there. - L. P. Hartley, The Go-Between, 1953.
I ran across this quote in a podcast talking about how an historical event still has repercussions today. But the thing that rang for me is related to another book I have been reading about the way we think about the world. In our minds, we tend to think things are very much like they are today -- that the way we do things and the way we think about things now is the same as it was 5, 10, 100 years ago. But it is not the case. The world changes. Technology changes.
Think of all familiar practices and policies - written and unwritten - that govern the way we operate. All those things that people say, "That's the way it has always been" are only true because they don't know (or don't remember) what it was before. Does it need to always be that way?
If we can understand some of the reasoning behind these things, we can ask whether those policies or practices should still be in place.
Why? Because those policies and practices often block improvements. Your classic claim that "people resist change" often comes from these hidden beliefs about the world -- on both sides.
Put on a different hat, and think about how things are different in the past. What was the currency, the language? This can help see why these practices and policies came about.
I have been following Clarke Ching's efforts to write Rolling Rocks Downhill over the years, including reading one or two early versions. But somehow the final published version felt very different from the earlier versions. One thing that hasn't changed - I could hear him in the voice of the main character I read the book to myself. I've noticed the same thing when I've read other books by people I know in real life.
In some sense, the book is a classic business novel in the Theory of Constraints vein: the main character (Steve) has a major problem: the software project that he thought had nine months gets pushed to finish in six and then even faster due to market pressures. The situation seems hopeless, but then he begrudgingly asks for help from a "guru" (on an ultimatum from his boss). In this case, though, the guru isn't positive that he can solve the immediate problem - though he does think he can help Steve in general. The guru leaves Steve alone for long stretches with various things to ponder - come to think of it, this isn't too far from "Jonah" in The Goal. One thing that was interesting about this guru is that he often didn't have the answer - not that he didn't want to say, it seemed he truly didn't know (and was willing to admit it!).
The story develops, and Steve learns a lot. The guru introduces some TOC and Lean concepts, and some of Steve's business partners introduce some new ways of thinking as well. He learns about the constraint and why it is important to identify it. He learns that forecasts are always wrong and spending too much time refining them is often time wasted. He learns ideas about smaller and smaller batches to create speed.
In the end, the team pulls off amazing feats and pulls the company from the brink of irrelevance. One of the biggest things they do is break a huge conflict that sat at the bottom of their reality: take actions for the short term or take actions for the long term. Do it fast or do it right, and they couldn't see a way to do both.
While the story is about the struggles of the development team and the larger business, one of the biggest take-aways for me is the way Clarke describes the Evaporating Cloud (or Conflict Diagram), which is a classic of the Theory of Constraints thinking processes. He also combined it with some thinking from Kelvyn Youngman that brings in the 4 views of change. Clarke has this available on his website as well.
Classically, the Evaporating Cloud is a diagram to help articulate the logic behind conflicts that occur. One describes an overall goal (A) and two needs of the system (B and C). Each of the needs generates and action (D and D'). The two actions are where the conflict resides. One reads it: In order to meet the goal, we must meet needs B and C. In order to satisfy B, we believe we must do D. In order to satisfy C, we believe we must do D'. And D and D' cannot exist at the same time. Just as important, taking action D puts need C in danger, and doing D' puts B in danger. We are in a conflict. Often organizations will find themselves swinging between actions as one need or the other becomes predominant. But both needs are important - but we compromise to get less that full amount of each need. A central tenet behind TOC is that all conflicts (of this type) can be removed - "evaporated." The key behind these diagrams is what connects the lines - the process of building the diagram helps to expose the assumptions underlying the "we believe". Why must we do D? or D'? What makes them conflict? As you (and the team) think through this - talking it out often helps - the reasoning behind why one action or the other comes into play. Could there be different actions we could take that allow us to meet both needs?
Conflicts are sometimes articulated with statements like, "On the one hand ..., but on the other hand ...." What Clarke has done in the book (through the guru) is to take this kind of statement and make the conflict cloud more physical. Turning the cloud, so that "A" is on the top, he draws a stick figure with D and D' in each hand. B and C on the shoulders - representing the "weight" of each need. And then the common goal is the head. He even take the idea of actions jeopardizing the opposite need: poke yourself in the opposite shoulder with your index finger. I really liked how this description of the conflict diagram has a physical feel to it - much more visceral than the dry cloud on a white board or a piece of paper.
The other thing he brings to the cloud is from Kelvyn Youngman. The cloud can be mapped to the four views of change: the benefits and hazards of a change, and the benefits and hazards of not changing. (This is best illustrated in the entertaining video on "resistance to change".) In Clarke's setup, below each hand you add the pro's and con's of the action. Understanding these pro's and con's helps to articulate the needs. And it helps to draw out the assumptions underneath the arrows in the conflict diagram. This is all described much better in chapters 13 and 14 - go read it there.
In the story, Steve and the guru develop the conflict diagram for Steve's software project. But then later on, there are a couple other conflicts that don't get their own diagram. What Clarke does though is describe Steve weighing the conflict in his hands and wriggling his shoulders as he thinks through the needs. There was even the line, "My shoulders ached from the weights I carried with me that day." This language, for me, makes the conflict feel much more visceral. (I've heard that TOC for Education encourages children to draw the conflict on the playground and stand in the boxes to discuss interpersonal conflicts.)
Another classic "problem" in software or any knowledge-work environment is Parkinson's Law: usually formulated as "the work expands to fill the time allotted." Clarke took another direction with this one in the software development world, "The scope of the project always expands until it's too big to fit in the time available to deliver it." When development happens in big batches, people throw more and more into the project until it bursts. He gives some great examples of this as he discusses the problem with a colleague (in Chapter 11). They also suggest the opposite: if you cut the scope to make the delivery date more reasonable, people might relax or slow down. This is the Student Syndrome: I don't need to worry because I have plenty of time. (Note: People aren't bad, this is a natural reaction to the environment we are in. And the extent of either of these varies by person / company / group.)
One final item: I've known for a while that Clarke has a sense of humor. It's in the writing - the little things like the coffee jokes or the expensive-looking pen that the guru carries. Or the fact that the book website is Clarke Ching www.Rolls.Rocks. And his humor shows up in the sub-titles of the book. On the Amazon page for the book, the subtitle comes up as "How to Ship YOUR Software Projects On Time, Every Time." But on the cover of the paperback it says "The Agile Business Novel." And the Kindle on Amazon, the cover says "The Agile Business Novel (which never mentions Agile)". But then on my Kindle device, it says "Accelerate AGILE using Goldratt's TOC." And in the book itself, the subtitle shows up as, "Read this when your AGILE implementation sucks."
Here is a quote for the day:
A schedule defends from chaos and whim. It is a net for catching days. It is a scaffolding on which a worker can stand and labor with both hands at sections of time. - Annie Dillard in The Writing Life from 2009
Heard on a the Manager Tools podcast* recently
One-time events create change like dieting only on your birthday and expecting to lose weight.
I love this statement, whether it has to do with the performance review process, or just about anything else.
When we think of a change, the outward sign is that behavior or some other measurable signal has changed. Attending a training course - or dieting for one day - will not create a lasting change. The event must be followed by a regular course of action, coaching, check-ins, ... whatever is appropriate for the type of change desired.
* I am fairly certain I heard it on Manager Tools. The quote appears in a section of a book that discusses performance reviews. And this suggests that I probably heard this on the Manager Tools podcast on performance reviews from the beginning of the year.
I have known Kevin Fox for over fifteen years. I first learned Theory of Constraints through him in a couple Critical Chain implementations and later worked on a manufacturing (drum-buffer-rope) project with his company. He has a new book out this past fall, Aligned & Engaged: Hidden Keys for Turning Teamwork into Profit.*
Overall the book is split into two sections that cover the dimensions of Alignment and Engagement. And the bulk of the book is set up as a set of 29 "practices" around teamwork, each of which are linked to four key topics: Creating Time, Doing the Right Things, Doing Things Right, and Magnifying Impact. The practices are written for leaders, not the teams - leaders have responsibility to create the right environment that enables the company to achieve more and more of its goal.
Many of the practices Kevin describes are ideas and elements I am familiar with in my own consulting practice, but I haven't always thought of them in the ways he describes. And many of the concepts come right out of Theory of Constraints, though it is nice to see that he talks about the ideas in ways that do not require deep TOC knowledge.
The introduction sets the stage. Companies are made of people, and those people have to work together well for the company to work well. Just like an athletic team. But it is not teamwork itself that a company should strive for - it is results. Ineffective teamwork is strongly connected to poor performance, but the classic "teamwork" solutions to the problem like retreats or team-building activities don't address the core problems. Ineffective teamwork is a symptom of deeper problems in the organization - it won't be solved by going on a retreat.
How do you recognize a problem with Alignment or Engagement? Chapter three provides a nice discussion of the likely effects. Alignment issues will appear in things like strong (internal) silos; problems that show up late; internal measures look good even though company performance is poor; local improvement efforts don't impact the bottom line; end-of-the-month syndrome is strong; and mismatches between supply and demand. And issues with engagement appear as things like low employee participation; few new ideas generated; a lot of time spent explaining problems, rather than solving them; blaming; and people keep regular hours. This last one struck me as odd, but Kevin's explanation strikes a chord: it's not that we should demand long hours of people, but we should expect people will do what it takes to get things done, which might mean starting early or staying late from time to time.
The 29 practices that make up the bulk of the book are those practices that link to the bottom line. Some practices help create more time for the leader or the team to focus on the right things - they might even help the teams discover the right things to do. That gives you better effectiveness. There are also that help up in doing these things well - once you know what to do, how do you do that better (efficiency). Interesting that "not doing the wrong things" isn't mentioned explicitly, but it goes without saying that clear goals and clear ways to achieve those goals will have people doing much less of the wrong thing too.
While the book doesn't explicitly claim to be a Theory of Constraints book, many of the practices have elements borrowed from TOC ideas and practices. So, for me many of the deeper explanations behind the practices weren't necessary for me. The language is intentionally removed from the details of TOC, so that anyone could pick up the book and make use of one, two or all 29 of the practices.
The list of practices with my quick comments in italics
- Communicate the goal - If people don't know the goal, how can there be alignment?
- Share company results with everyone
- Replace local measures with global ones - This one is obvious and not-so-obvious. What does it mean from day to day for people? Most people shouldn't be busy all the time in order to have protective capacity to deal with variability, uncertainty, surprises. Local measures drive busy-ness, rather than effectiveness. "Accountability is overrated if what you are holding people accountable for doesn't help your company reach its goal."
- Find the constraint of your business
- Blue light your business - I've used versions of the blue light story many times. "Putting people in charge of somethings is not the same as having them care."
- Use T, I and OE to align decisions to the goal - This comes from TOC and is a much better way to use financial information to help make decisions.
- Routinely review and re-align your measures
- Map what good alignment looks like - Another idea i've used many times: What does good look like for you, for your business, for the team?
- Spend most of your time and energy on today
- Use Pareto to stop wasting efforts
- Stop the multi-tasking - Nothing more to say here!
- Relate everything back to the big picture
- Focus on throughput - Very specifically, focus on those activities that will generate more money through sales. Not more production. More sales (and profits from them - big discounts to ship more product doesn't get you more profits).
- Use measures to provide fast feedback on ideas
- Picture what engagement looks like - More what good looks like thinking.
- Innovate on process - If you ask people for suggestions, ask them to focus on the areas that are creating the largest problems in your business.
- Use images to show 'what good looks like' - The third entry on this topic. What good looks like is a strong way to help people think about how things could/should work.
- Reward the good more than you punish the bad
- Share your ideas last - Leaders influence people by everything they say and do. Let people have their say first, before injecting your own ideas.
- Provide opportunities for growth
- Don't kill ideas, use questions - Ask questions about any suggestion: What problem are you trying to solve? Is the problem worth solving? Will the solution (idea) solve the problem? Will the idea create unintended consequences?
* Review based on a complimentary galley copy when the title was Teamwork for Profit. Some of the specific practice names and titles may have changed in the final book, but the overall concept remains.
I read a pair of Gary Klein books that look at decision making and intuition, which seems to be the core of his work. I started with The Power of Intuition: How to Use Your Gut Feelings to Make Better Decisions at Work (from 2004). And then I backed up to his Sources of Power: How People Make Decisions (from 1999), which describes more of the background research.
The basic idea is that human decision making is governed by a lot of processes from the snap decisions people make in emergencies to longer, considered decisions. Klein's argument is that people rely on "intuition" a lot more than we might acknowledge. These intuitions are based primarily on past experiences as well as some amount of knowledge. His concern, at least in The Power of Intuition, is that many decision-making frameworks rely almost exclusively on using logic and analysis to define the process. And in certain situations, the decisions are not governed by the analysis. One might be able to review the situation and devise a logical explanation as to why and how a decision was made. The conversation in the books is that in the moment of decision, people don't rely on analysis but on their intuition.
He developed a term for this: recognition primed decision making (RPD). Source of Power describes how this model of decision making arises in situations where there is no time to do analysis, such as firefighting or medical emergencies. Power of Intuition then takes this and develops a model around helping people develop their own intuitions better.
And how to develop this expertise? Not by sitting people in a classroom and teaching to them. It's always a challenge because there is some aspect of "knowledge development" that people (me!) believe is best done through a stand-and-deliver style. But getting quickly beyond the basic knowledge and embedding that into people's psyche must allow for real-work application and practice in situations where it matters.
Klein makes an important clarification here. It's not sufficient to throw people into an experience with their new knowledge and expect intuitions to develop. The whole point of intuition is that it has to be fast and primed by recognizing the right queues. When a concept is new, we don't know what queues to look for, even if we have been "told" what to do. The experience has to be reviewed - debriefed - with a specific eye to the key points where a queue was helpful in successes (or missed in failures). There has to be a deliberate intent behind the practice. Maybe this isn't such a surprise with our current understanding of multiple modes of learning and the Agyris concept of double-loop learning. Of course, I still hear plenty of assumptions that training gives people enough knowledge, experience, insight, and drive to change the way they operate.
Klein presents a number of methods for developing intuition, whether through the above practice or by the every day life of business. Take action, review it. Plan an action, do pre-mortems. Clarify the goals. Every day, there are "opportunities" to develop better and better intuitions.
As an example of this in the TOC community, Eli Schragenheim introduced the idea of a mystery analysis at the TOC ICO conference in 2013. When reality differs from expectations, there must have been some underlying assumption or belief that wasn't what we expected. What was the logic behind the actions we took and the expectations? What happened instead? What else must have been happening that we didn't expect? This is a reasonable way to do an after-action when something bad happens, but it should be used equally well when something "good" happens - when an effort works out much better than expected.
Of course, as I read, I highlight quotes and other interesting ideas. These books seem to be loaded with more than usual. Or I was particularly heavy with the highlighter. Here are some of those.
From The Power of Intuition (no page numbers, as I was reading an ebook...)
- "The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honors the servant and has forgotten the gift." - Nice way to say that intuition has been given a bad rap. Klein also references Herbert Simon's concept of "bounded rationality" that suggests for more complex decisions, the level of complication is such that "rational" approaches to decision making are less and less useful.
- There is a nice discussion about how intuition becomes so innate that we forget how we thought before we had the intuition. We forget how hard it was to get a concept, once we know it. (Unless you have children who are trying to learn similar things.)
- Ways to tap into intuition: "you aren't restricted to asking people what decision they would make. You can ask them what information they would gather, or what questions they would have, or how they would assess the situation. You can ask them what problems they might anticipate, or what they would expect to happen in the future. You can ask them what guidance they would offer. These are all ways people use their intuitions. "
- I love the idea of a pre-mortem: asking questions about what might cause an activity to fail or go awry. Basically an after-action-review in reverse. Imagine the effort has failed, what might have caused that to happen? Again, this taps into intuition, and it can make your plans even better.
- "The five sources of uncertainty are missing information, unreliable information, conflicting information, noisy information, and confusing information. Just because they are all called by the same term, 'uncertainty,' we should not treat them as equivalent." And there is some discussion for tolerance of ambiguity that is important in decision making as well. We can't allow ourselves to be paralyzed by lack of information, but we need to develop the intuitions to know when we have sufficient information to move.
- Maybe we should be careful about being too specific in our instructions to people. We need to allow them to develop their intuitions as well. "If you just tell subordinates what you want them to do, without telling them why you need it done, you have kept things simple, but you have also made your plan more vulnerable."
And some from Sources of Power:
- Another version of the fog of war from the first page: We try to understand how people handle all of the typical confusions and pressures of their environments, such as missing information, time constraints, vague goals, and changing conditions.
- Falling in love with our ideas? "We can ask what evidence you would need to give up your explanation. Sadly, the answer is that if you are determined enough, you might never give it up." I think of Occam's Razor in reading this section - at some point the justifications just become too much, and we have to break our love for our ideas.
- There was an interesting discussion of problem solving that made me think of the value of Agile development ideas. "[Researcher Karl] Duncker found that as his subjects worked on these problems, they simultaneously changed their understanding of the goal and assessed solutions. A subject might think of a solution, try it out, realize it would not work, realize what was missing, and then add to the definition of the goal. This new definition would suggest new approaches, and when these approaches failed, they helped to clarify the goal even further." This seems almost a perfect example of Agile - and the research was reported in 1935 and 1945.
- Klein formalized the idea of commanders intent in terms of the information one might provide" "There are seven types of information that a person could present to help the people receiving the request to understand what to do:
- The purpose of the task (the higher-level goals).
- The objective of the task (an image of the desired outcome).
- The sequence of steps in the plan.
- The rationale for the plan.
- The key decisions that may have to be made.
- Antigoals (unwanted outcomes). [I particularly like the discussion around this one for some reason.]
- Constraints and other considerations."
The (Australian) Financial Review has a list of 12 things that kill innovation in your organization. For people that pay attention to this space, the entries should sound familiar. (Discovered via retweet on Twitter.)
- A culture of fear
- Lack of meaningful mission and vision
- Too much hierarchy
- Old-School HR practices
- The blame game
- Overly prescriptive job design
- Lone wolf thinking
- Low autonomy
Reading through this list and the brief description of each, one can see some familiar conflicts, in particular the effects that happen when organizations swing between strong vs loose structure. And Blame and Fear are two big killers of just about any kind of organizational initiatives. They have very little place in organizations which are trying to understand how they tick and how to respond to the pressures they are under.
Two that made me wonder there the "old-school HR practices" and "filtering". For HR the list suggests that "new school" is more flexible and diverse in hiring and promotion decisions than in the past. I suspect there is more under the surface of that one. The "filtering" entry is about filtering and limiting the flow of information. Strongly connected to Silos - and to fear and blame and micromanagement for that matter.
A quick article with opinions from six people on project killers: 6 Experts Share the #1 Thing That Derails a Project | Smartsheet. Of course, there are six different things listed as "the #1 thing." And there are a few more listed in the comments.
I mention this article because my friend, Johanna Rothman is quoted as suggesting multitasking is the killer, "The silent project killer, and in my experience the thing that kills more projects, is multitasking." Of course, I had to smile, seeing this. I often talk about this in my discussions of project management and Critical Chain Projects - specifically I talk about multitasking killing flow. Too much switching from task to task to task without getting anything done. This means we can't hand something to the next step in the line (without it getting stuck as well).
Please note: Having a queue of work is not multitasking. It's when I am forced to pull things into active mode before I finish what is in front of me.
A couple of the other suggestions in this article in my mind have to do with understanding what the project is. When there isn't alignment or agreement on what we are doing in a project, it almost guarantees that the project will get stuck in swirl and scope creep. Which often leads to even more multitasking as we try to figure out what it is that we are really supposed to be doing.
Lean Learning Center has a nice article on a familiar topic, creating more time for what is important. Click "Like" If You Have Enough Time
Time is the only resource we have that we cannot get more of. Yet time is squandered at an unbelievable rate. Organizations manage money with obvious structure and measures of return on investment. When it comes to time, individuals are left to Darwinian survival mode. Hundreds of emails daily, multiple meetings with unclear return on time spent, and administrative tasks consume high percentages of time. Studies have shown that management spends 10-20% of work time on current priorities, coaching, and identifying improvement opportunities. The remaining time is spent on other stuff.
I find that it isn't only management where this happens. It could be the salespeople meeting with decision makers 5-10% of their time. Or project team members spread across many activities and several projects. If these people could increase the focus - have dedicated time for their most important activities - what would be the benefit to them? What would be the benefit to the organization?
The post goes on to recommend some specific actions around observing how one's time is spent today. Essentially: are people doing that which is most important, or are they doing whatever happens to be in front of them at the moment.
Reflect back to Covey's 4 Quadrants (Urgent + Important; Not Urgent + Important; Urgent + Unimportant; Not Urgent + Unimportant): Clearly, dropping those activities which fall in the "unimportant" quadrants can make a big difference. Most people who talk about this topic also suggest that doing better with focus means that the level of "urgency" also drops - when people have time to focus on the important aspects of their work, many of the urgent activities get handled correctly and with much less fanfare. Time gets created by not wasting it.
One big area I always check: how much multitasking are people doing? How much of the unimportant or the last-minute urgencies get in the way of being able to focus on very few things at one time. How often do people get started (hurry, hurry, this is really important) only to discover that there are incomplete preparations that stall the effort? How much benefit would be gained by giving people mechanisms - and the organization trusting those mechanisms - to enable focus and finish, rather than start-stop-start-stop of multitasking.