This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Thursday, April 30, 2009
Twitter - Not Just Oprah and Ashton -- Some linkage on getting some hits of value and productivity from Twitter...
"So just how does a brand use Twitter to further its aims? A few recent anecdotes can help demonstrate how companies need to think about Twitter and its impact on their brands."
"Individually, many of those 140-character “tweets” seem inane.
But taken collectively, the stream of messages can turn Twitter into a surprisingly useful tool for solving problems and providing insights into the digital mood. By tapping into the world’s collective brain, researchers of all kinds have found that if they make the effort to dig through the mundane comments, the live conversations offer an early glimpse into public sentiment — and even help them shape it."
1. Instant, Real-Time Search Results...
2. Monitoring Something You Care About...
3. News Updates...
4. Instant Communication with Friends...
5. Twitter as a Productivity Command Line...
6. Ask Questions, Get Answers...
And from Kottke, there's nothing wrong with a bit of trivial diversion now and then...
"...you'd like to think that most of your daily conversation is weighty and witty but instead everyone chats about pedestrian nonsense with their pals. In fact, that ephemeral chit-chat is the stuff that holds human social groups together."
Rocks Into Gold - A parable for our time from long-time blog buddy Clarke Ching.
Sopranos, Uncensored - NSFW - A little diversion featuring very bit of foul language from every episode of HBO's classic series, but not including the curses coming from the audience at the end of the final episode, when they thought their cable had gone out at the most inopportune moment possible. Someone somewhere has too much time on their hands. Surprised, though, that it's only 27 minutes long.
Project Monogamy, Revisted - Serial Monogamy Project Participation is an important post from Johanna Rothman. Success in projects in an organization is less about how the individual projects are managed than about how the multi-project system of shared resources are managed.
What I’m finding interesting in my work is that people who have some slack can commit to one project much more easily than people who are 100% “committed” to a project. The people who are 100% committed have no slack to provide other projects some consulting or provide future projects some thinking. The people who are only 80% committed to one project (and not committed to something else, slack is key) are more able to finish their work and accommodate the inevitable interruptions.
When people multitask, they are not committed to a project. They have no slack. They have no time to innovate. They are always behind."
Not only do resources need slack, but project promises need to me made in a way that includes "slack", allowing for those times when things don't go as planned and for those times when one project impinges on the progress of another.
The behaviors and expectations that Johanna describe allow that latter situation to happen less frequently.
On a related note, Deviant Behavior in Project Management from the Project Shrink blog includes a story on the risks of acting on the third bullet above...
True story: on a project where I was one of several PMs, weekly progress reports had to be written and send to all other Project Managers. After a while I got the impression that no one was actually reading these things, because of the kind of questions I was getting (answers were all in the reports).
As I was not fond of reporting just for the sake of reporting anyway, I started little irritating experiments like issuing identical reports with different dates, adding nonsense risks, just to see if anyone was paying attention. As you might have guessed, no responses what so ever. So, I stopped writing the reports. All hell broke loose...
...What I was experiencing is called deviant behavior, not performing the behavior that is considered normal within society or a particular social group.
Not really the same thing, but this reminds me of a weekly status report I saw years ago that essentially said "there will be no status report this week."
"It’s all about solving business problems. Real value comes from innovative ways of meeting business or staff needs in new ways. These improvements often target one area of the organisation, or a single key group of staff."
Everyone Left, Go Faster - From my favorite new blog and podcast, some thoughts on productivity and unemployment:
"...the workforce looks more productive because it included fewer people. Workers just turned it up a notch. (Feel like you're doing a job and a half? That's the feeling.)"
This Planet Money site is great for keeping in touch and understanding the current economic crisis.
Back when I was Director of Industrial Engineering at Nabisco's Planters-Lifesavers Division, one of my duties was to deal with the wide range of stuff that my boss (the VP of Operations) kept throwing in my direction to research, review, or report back to him on. Recognizing that he was about as curious and inquisitive and attention challenged as myself, I quickly realized that not everything he passed along to me was really top priority. Rather than go back to him and ask "What don't you want me to do?," I often found myself using my judgment to simply prune my to-do list without action. I rationalized this with the theory that if really was important, he would bring it up again. I never really got burned by doing this, so I guess my judgment was good enough.
"Zero is easy to measure and observe. Impossible to fudge. And, I have found, amazingly liberating."
If you want/need to move things through your system faster, you need to minimize tying up work-in-process in queues (in-boxes). And you can't get more minimized than zero.
"...there are conditions under which it actually helps to have some generalists, especially for fairly small groups, some individuals that you might think of as Jacks- or Jills-of-all-trades or multitaskers,' said Waite. 'You might actually have to pay them more and they might often do the wrong task, but if you don't have them, this whole notion of specialisation leading to greater economic productivity might actually be wrong."
"Carry too many people on the bench, and the company is sluggish. The same as if you carry too much inventory. Carry too little, and the company can't respond to consumer demand."
If services rely on talent the way manufacturing relies on inventory, why not manage them in a similar manner, allowing demand to "pull" on an understood replenishment chain? I think I'm starting to get it.
(Also starting to like that word "talent" as a replacement for "resources".)
"...the point of technology is not to give people more access to an individual, but to give that individual more control over their time. You use your cell phone, remote internet access and/or BlackBerry to manage your job on your own terms. Your focus is on outcomes, not availability."
It's not about how much you do - it's about how much you accomplish.
"Multi-tasking is dead. It never worked and it never will. Intelligent people love to sing its praises because it gives them permission to avoid the much more challenging alternative: focusing on one thing." –- Timothy Ferriss, author of The 4-Hour Workweek
Of course you already knew that.
Also, related, from Michael S. Hyatt...
"Most of us don't spend enough time thinking. We are so busy doing that we have, I fear, almost forgotten how to think. Yet it is our thinking, more than any other single activity, that influences our outcomes.
"The problems we face will not likely be solved by working harder. New gadgets won't really help either. In fact, I sometimes fear that our many gadgets have only added unnecessary clutter to our lives. What we need is better, more profound thinking.
Slacker Work Principles -- I still like the idea of productive procrastination, included as #2 in this list of 16 principles. I'm also getting used to the idea of (#3) ensuring balance by dropping things and saying no or not yet.
Silos: Not Always a Problem -- Jack points out that sometimes silos are merely an artifact of how the work gets done, identifying two flavors...
"The key between these types of silos is that one is imposed by rigid structures and politics, and the other is imposed by demands of personal work styles and needs."
Read When silos work. I like pieces like this, that apply common sense to cliches - that help to avoid knee-jerk reactions due to labels. It's too easy to fall into jargon habits.
The Most Important Trait? -- According to a survey at CIO Blogs...
What's wrong with this picture?
That item leading the survey with 38% of respondents - the ability to juggle multiple priorities - is pathetic. It's management's responsibility to determine the priorities, either by edict or, preferably, by some systematic process, and to provide processes to minimize re-prioritization as much as possible. If left up the the folks doing the work, either juggling and multi-tasking will occur, resulting in dropped balls and unnecessarily extended delivery dates, or those folks doing the work with choose a priority, which may not coincide with the priority best for the firm.
I've got to believe that this survey was put together with tongue firmly in cheek. I want to believe that this survey was put together with tongue firmly in cheek. Please tell me they (including those who responded) were kidding. Please.
Costs of Multitasking - From Johanna Rothman, who list a number of costs associated with flip-flopping from task to task and back and forth. She asks if she missed anything.
She did. Focusing on the set-down, set-up, and defect costs of the practice, Johanna did a good internal analysis of the task costs. But outweighing them, when this is a common practice among a number of people working on dependent tasks, is the cost of delays of hand-offs from tasks to task, which translate into delays of the completion of the final project. It's more than the additional cost of individudals' time. It's also the cost of late(r) delivery of the projects and their benefits.
"I believe that it's crucial for developers to understand more than just their team processes and start learning about business process in general. Two positive things will result from this. First, they will learn how to better interface their process with the higher-level processes. Second, they will get an appreciation for the more strategic efforts of the company and how their development teams can, and do, contribute to higher goals. This knowledge will make them more valuable to their company. For new hires working within lower-level processes, this understanding will help them quickly discover whether they are compatible with the company. There is no shame in admitting that the way you prefer, or are willing, to work is so incompatible with your personal process that neither you nor the company will benefit with you on board. I would rather know this as soon as possible, rather than having it pointed out to me at my performance review, or worse, at my exit interview.
"Process is important, but there is not just one process for all. An enterprise has many processes, at several levels. Understanding how these processes need to work together is a critical awareness, one that is too often ignored. When you understand real process needs, you understand that the specific process you follow is not as important as whether it plays well with the others."
Re-Engineering Interruptions? -- Meet the Life Hackers -- A good article on multi-tasking in the NY Times. Some eye-opening numbers...
When Mark crunched the data, a picture of 21st-century office work emerged that was, she says, "far worse than I could ever have imagined." Each employee spent only 11 minutes on any given project before being interrupted and whisked off to do something else. What's more, each 11-minute project was itself fragmented into even shorter three-minute tasks, like answering e-mail messages, reading a Web page or working on a spreadsheet. And each time a worker was distracted from a task, it would take, on average, 25 minutes to return to that task. To perform an office job today, it seems, your attention must skip like a stone across water all day long, touching down only periodically.
Check it out before it disappears behind the Times' paywall.
Flow On - Over at gapingvoid, Hugh brings together the questions of relevancy and flow, and suggests that Sig might have a point suggesting that "flow" is "next."
Hate to break it to them, but those of us who have been familiar and worked with Goldratt's Theory of Constraints have long emphasized the understanding and management of "flow" as a means to assuring relevancy of activity. Whether in manufacturing, distribution, or projects and multi-project systems (like R&D product development or engineering shops), the goal of the owning parent system is the prime determinant of relevancy of activity.
And for these systems, from those as large as the whole corporation to those as small as a project team or production cell, the means to achieving the goal are a set of interdependent activities linked by handoffs physical, informational, or transactional. The "flow" of these handoffs (think a project task network, or a process flow chart) should be limited only by the capacity of strategically selected constraint functions, which then allow a simplified focus of management on assuring the flow of work to, through, and from these constraints.
Unfortunately, too many organizations ignore or are ignorant of the importance of constraint management, and allow too many irrelevancies -- too many erroneous assumptions -- too many misleading measurements -- to distract from the focus on flow. Too many organizations focus too much on managing capacity and cost of irrelevant parts of the system instead of focusing on managing the flow for the real source of more goal stuff -- system throughput. (If you can grow the top line - the bottom line (the goal for for-profit entities) is much more assured than if you obsess too much on the lines in between. You can only cut costs so much before hurting throughput. Throughput is potentially unbounded.)
Once the idea of flow through the system as the source of organizational goal attainment and relevancy is understood, it's a lot easier to move on to personal flow and relevancy.
Multi-thinking -- In Innovation Tools, Jeffrey Baumgartner offers good advice for those who feel compelled to multi-task...
"...it is inevitable that your mind occasionally turns to one task while you are working on another. A multi-tasker would be inclined to switch tasks at this point. I recommend you stick to the task at hand, but keep a notebook or at least some paper nearby when performing any tasks. (I recommend having a notebook with you all the time). When the mind turns from the task at hand to another task, simply note down your thoughts in the notebook. Then return to the task at hand."
He goes on to suggest that a good time and place to woolgather/brainstorm/multi-thnk ideas and issues for different responsibilities is while in "long, crowded meetings." I've got concerns about consciously doing that, from a missed information perspective as well as from a civil politeness point of view, but I do like the general idea.
Recording mental interruptions to a physical "in-box" (collection of notes) to be processed and addressed later, frees up the mind for attention to "the task at hand."
Yet Another Post on Multi-Tasking -- It's a shame that this topic is still necessary, but Tony Rizzo provides a good description of something so obvious, but so misunderstood.
"So, why is multitasking such a big problem? The answer to this question is explored best in two steps. First, imagine that you’re a customer at a bank. As you wait in an unpleasantly long line, for your turn with the teller, you notice that the teller is doing something unusual. Rather than completing each customer’s transaction, the teller is beginning the transaction of the second customer and even that of the third customer. Then, she is task-switching, from one transaction to another, without completing any transaction. Before long, the teller has four or five open transactions, with none of them close to being completed. The teller is multitasking.
"Would you expect to complete your banking any sooner, given the teller’s multitasking paradigm? Obviously not! In fact, you can probably expect to be delayed further, by the mistakes that the teller’s frequent context switching is sure to create.
"Of course, bank tellers don’t multitask. In such an environment, multitasking is obviously damaging. So, workers simply don’t do it." [read the whole thing]
It's obvious for the bank teller example. Why is it not obvious in other environments? Are the pressures for attention pulling people in different directions for different tasks that strong? Why are they that strong? Is it because things are late and out of control? Why are they late and out of control? Perhaps it might be because of all the little bits and pieces of work that are only partially done. Why do we leave some things partially done and go on to other things? Because of pressure to switch gears and address other tasks...
Rizzo on Speed and Profitability -- This looks like excellent news. One of my former co-workers and friend from the TOC community of practice, a thinker/writer/teacher/consultant well worth knowing (I wish he would start blogging), Tony Rizzo of The Product Development Institute and Spherical Angle, seems to be writing a book. At least there's a series of pages on his PDI website that refer to chapters 1 through 4 (as well as an empty link for chapter 5) of something called Speed and Profitability with the Six Sigma Enterprise. These chapters touch on similar notions of multi-project management that you've been reading here, but with Tony's unique ability to draw pictures in the mind. For example...
For a moment, think of each of your projects as a person. Imagine that you have fifty such people in one room of your facility, and you need to get all fifty into the adjacent room as fast as possible. There is one door connecting the two rooms. Now, imagine that each of these people is rewarded (or punished) on the basis of how fast he/she can make it into the next room. The ones who make it through quickly can expect to receive a reasonable reward. The ones who make it through a bit late get only their base salaries. The ones who make it through very late can expect to be encouraged to find employment elsewhere. Go ahead. Give the order to move, if you dare.
Commonsense tells us that a few of your fifty people will make it through the door immediately, until the crowd arrives. Then, some of them will try to make it through sideways. A few others may become creative and try to take the low route, only to cause others to trip and stumble. Soon, you'll see a mountain of bodies, many of which make it through the door very late, and perhaps with injuries. You may also see a few people standing back, waiting for the mob to clear.
Now, imagine that every few minutes you give the order to 20 or 30 more people to go through, while the mob continues to block the door. It's clear that nearly all will make it through very late. Many of these will suffer severe injuries. The ones who decide to stand back and wait for the mob to clear never go through, because the mob never clears.
This is probably a close description of the way your projects compete with each other, for shared resources. In our little scenario, the door is a shared resource. In reality, the shared resource may be a group of systems engineers or software developers or electrical engineers...
Nice visualization. Tony goes on in Chapter One to talk about unsynchronized multi-project environments and the resulting multi-tasking sickness that he refers to as the "dilution solution". I'll probably be getting deeper into the subsequent chapters as time goes on, but don't let that stop you from digging into Tony's stuff yourself. Now.
, the tagline of which...
View Frank Patrick's profile
