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.
Multitask -- It's been a while since I've posted here on my blog...been distracted by Twitter and Facebook. Too easy to drop snippets and links in those sites. But given my history of ranting about multitasking in a work context here, I just had to point you to this game simulation. How many activities can you split your time attention among?
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.
Evidence of Critical Chain in the Wild -- One of the heartening things I've discovered during my job search is that of the two firms that I've had sufficiently successful conversations that they might be in my future, one manages their multi-project organization "the TOC way" and the other is seriously considering doing so. I knew about the first going in, the second was a pleasant surprise sprung upon me in an interview.
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.
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.
Implementing the new approach has boosted performance of clinical supply operations:
Lead times were reduced from 8-12 weeks to typically 3 weeks, a reduction of about 70%.This is substantially lower than the industry average of around 6 weeks.
Due-date delivery was over 90% (for five consecutive months).
Without additional resources, about 50 studies were now packaged every month, a throughput increase of 150%.
Besides the quantitative improvements, there are also qualitative benefits felt by project participants. Managers feel in control of operations and now make decisions proactively to stop problems before they become problems. Another benefit seen is that as the rank and file do not need to multitasking (because they get clear task-level priorities), they can focus on delivering highest quality output. This is extremely important in clinical trials, as any quality problems can lead to the whole clinical trial results being rejected by FDA.
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."
(I need to say thanks to Heath Row (I smile every time I say, think, or write that name) over at Fast Company for sending a lot of traffic to the series.)
OK. That was September.
A lot of October's going to be a bit slow for blogging here while I head off for a bitof awalkabout next week, although I might blog my travels over on my more personal Unfocused weblog. In the meantime, allow me to direct your attention to Tony Rizzo's soap box, where he seems to be fleshing out a nascent book on Robust Project Design (tm) with a coupleposts on Robust Project Planning (tm). As I've gushed entirely too much recently, Tony's one of my compadres and influences in the world of TOC, Critical Chain, and Multi-Project Management. I leave you in his capable hands while I refresh and rejuvenate on the other side of the world.
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.
Promises and Prescriptions
Part 4 - Multi-Project & Mixed-Function Multi-Tasking -- One of the major impediments to doing one's best work on the task at hand is not related to lack of ability, but rather to the fact that there are, too often, too many tasks at hand.
Software projects are usually delivered as one of a portfolio of efforts and often share resources with others in the pipeline. Even if some critical technology resources are dedicated to specific projects, there are always some shared resources. It is not unusual for scarce, highly skilled contributors to support multiple projects. It is also common for certain functions, such as testing, that are heavily used across many projects to become overwhelmed with work.
The usual response to having a lot of work in one's inbox is to use the squeaky wheel method of prioritization. Whichever project is squeaking the loudest in the morning gets attention for the day, whether the previous day's task is completed or not. Multi-tasking is, unfortunately, often seen as a laudable talent. In reality, bouncing back and forth between unfinished tasks in an effort to show progress merely delays all the handoffs involved and wastes valuable capacity in unnecessary set-down, set-up, and "Where was I?" questions at every restart.
Best case multi-tasking situation...
Add context switching delays for real impact.
This is really an issue of understanding pipeline capacity. Most software projects do not exist in a vacuum. Software organizations are often responsible for at least two functions -- development/deployment of new systems and production/maintenance of existing systems. While major maintenance efforts can be added to the project portfolio to-do list and managed as projects, there are still day-to-day issues that need to be addressed to keep the business running. Even when projects are carefully defined in terms of resource requirements, unplanned emergencies can affect progress.
(Prescriptions for multi-tasking are next in the series.)
Ever think of Capacity Planning in terms of what your Project Management team can handle?
[...] Utilizing Capacity Planning in the PMO would help to optimize resources, and review a PM team's opportunities to take on another project. The ability to check a PM's capacity would enable management to accurately predict the prioritized projects of each PM. Each PM would report their capacity %, and enable project prioritization...
While Christian is headed in the right direction here, trying to support prioritization and to avoid overloading the system with more projects than it can handle, my sense tells me that his implied acceptance of project managers as the limiting factor is misguided.
Any organization sophisticated enough to be involved with PMO efforts should also be sophisticated enough to be conscious of and manage its constraints with some common sense. Any organization that lets the availability of such a generic skill as project management constrain its ability to launch valuable projects is unnecessarily hobbling itself.
The basis for the TOC approach to multi-project management is that to avoid to pressures to multi-task and then suffer its debilitating effects, you launch prioritized projects based on the availability of some skill that is commonly used, heavily used across the project portfolio. While, on the surface, PM skills fit this definition, the only reason to live with a constraint -- a limit on project throughput -- is difficulty in acquiring more of that skill. If you limit your throughput to that that the PMs can handle, then you are living with a strategy that says that PMs are the reason you are in business. Rather than rely on such a generic strategic constraint -- one that can be easily copied by the competition -- the system should be managed around a constraining resource that more directly reflects the core, differentiating competency of they system/organization -- its true strategic constraint.
Do you want your project throughput to be limited by lack of PMs or do you want to use your PMs and PM processes to maximize the capacity of scarce, valuable skilled resources that reflects the real value of your projects' products?
"I occasionally come across the phrase 'project portfolio management', or sometimes just 'project portfolio', but so far it has failed to convey much concrete meaning to me. Perhaps because it is often found in the company of ethereal buzzwords like 'enterprise architecture', or perhaps because it is difficult enough to survive single projects, the agile crowd seems to be likewise unconcerned with the topic."
...and goes on with an insightful discussion of the commonly faced issue of whether to "redesign our product or rewrite it from scratch." He is quite correct that this is a portfolio management issue -- a product portfolio management issue. And it is one that needs to be driven from a strategic viewpoint. The process for upgrading and/or replacing product offerings must be tied -- through a clear strategic roadmap -- to the organizational goals, and communicated clearly to those doing the work.
That said, what got my attention was his comment that "...because it is difficult enough to survive single projects, the agile crowd seems to be likewise unconcerned with the topic." On one hand, this rings true with me, and makes sense in the context of my view of agile processes being most concerned with what I view as task-level practices, less so with project-level interdependencies typical of more complex projects, and somewhat oblivious of bigger picture issues of strategic import like portfolios and pipelines. But on the other hand, those very agile processes are also a not-unreasonable response to living in an ineffectively managed multi-project environment. The short-term planning horizon and the closely operating teams focused on moving from point to point in the effort is not unlike what we in the Critical Chain Project Management community refer to as "relay race behavior" -- the minimization of intra-, cross-, or extra-project multitasking in an effort to accelerate completion of handoffs through the projects. The focus that both agile and "relay race" brings to an organization's culture is a significant contributor of the benefits derived from both agile and CCPM, which, by the way, can work together nicely.
To a large degree, the pressures for agility come from the lack of project portfolio and pipeline management. When there are no clear priorities driven down from strategic plans, through product portfolios, to project portfolios and pipeline management, then individual project managers, resource managers, and resources are left to fend for themselves to answer the question "What should I be working on?" And if project management is the answer to anything, it is the answer to that question.
A picture that should be familiar to readers of this weblog...
Project Portfolio Management is the process of turning a (hopefully related) list of initiatives that come from a strategy into a prioritized collection of projects and programs that are funneled through a pipeline. The result of doing it right is a process that both maximizes benefit for the organization and minimizes undo pressures on the resources expected to deliver them. Too many organizations fail to recognize the major reason that it is "difficult enough to survive single projects" is that those single projects and the people that are working on them are buffeted by the needs of other projects, planned and otherwise. Unless and until shared-resource, multi-project shops, like R&D, Engineering, IT, and Product Development understand the impacts of living in such a system, they will continue to struggle with their individual projects.
For such organizations, getting particular single projects done quickly and reliably is good, but not enough. What is important is to synchronize the organization for delivery of an accelerating flow of valuable projects through the pipeline and to the bottom line.