Project Management Operational Problem Solving Implementation & Change Management Strategy & Alignment

Frank Patrick's Focused Performance Business Blog
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.

Friday, August 14, 2009

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?

Labels: ,

posted by Frank - Permanent Link - |

Tuesday, May 26, 2009

Just Say No -- Doing less gets more done.

From Godin today...
"...Saying no to loud people gives you the resources to say yes to important opportunities."
Read the whole thing.

Labels: ,

posted by Frank - Permanent Link - |

Monday, April 27, 2009

Zen Habits | Simple Productivity - A new (for me) blog I've added to my feed reader. It's from the author of The Power of Less: The Fine Art of Limiting Yourself to the Business and in Life, the tagline of which...
"Do Less. Get More Done."
...sounds real familiar.

Kind of a mantra for me.

Labels: , , ,

posted by Frank - Permanent Link - |

Tuesday, February 10, 2009

So Many Links - So Little Time -- It's link-a-palooza time...
  • What Would Google Do? - The PowerPoint - excerpts from the book.

  • Epiphany: Virtual Teams And Social Media Tribes Are The Same - Yup. That they are, but only if the tribes have some sort of goal that ties them together.

  • 2009 - The Year of SMS, Again - An underrated, under-appreciated, underused channel for communication with your customers.

  • again mobile - Where I'm at these days, working on SMS text campaigns, "mobilizing" web sites, and iPhone/smartphone apps.

  • Mobile Couponing - The Time Could Be Now... - From Mark Taylor, my previous boss' boss' boss.

  • Top 10 Dumb Project Management Questions - Questions from Hal Macomber.

  • Dumb Project Management Questions - Glen Alleman provides some answers to Hal's questions.

  • Why You Shouldn't Copy Us Or Anyone Else - A nice piece related to one of my favorite pet peeve subjects (no, not multi-tasking) - the lack of value in benchmarking and following others' "best practices".

  • Which Comes First? The Product or the Marketing? - From Seth Godin - "Marketing is not the same thing as advertising." True, very true. (My take on shooting sitting ducks from 2006.)

  • 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.

  • The Human Feed - How Twitter and Networks Filter Signal from Noise

  • The New Work Ethic: Just Paying Attention - Your knew I couldn't finish a list like this one without an anti-multi-tasking link? Of course you did.
  • There's more in the queue, but that's enough for now.

    Labels: , , , , ,

    posted by Frank - Permanent Link - |

    Sunday, January 11, 2009

    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.

    Labels: , , , ,

    posted by Frank - Permanent Link - |

    Sunday, August 10, 2008

    Serial Monogamy -- Related to my perennial topic of the problems of multi-tasking, a great line from Johanna...
    Dan said, ďOh, you want them to commit to serial monogamy project management!Ē I cracked up.
    Read the rest.

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Thursday, January 10, 2008

    The Myth of Managed Multi-tasking - More on multi-tasking, via Jack Vinson.

    Labels: , ,

    posted by Frank - Permanent Link - |

    Thursday, August 30, 2007

    Open Office Layouts: Interruption Incubators -- Food for thought on "interruption incubators". . .
    Working closely together ain't productive

    Firewall your attention at the office

    Both via Why proximity kills productivity
    Headphones at the office aren't for listening to music, but for blocking out distraction.

    Labels: , ,

    posted by Frank - Permanent Link - |

    Friday, March 30, 2007

    Task Fragmentation -- A good clarification of multitasking as "task fragmentation" by Jack Vinson.


    posted by Frank - Permanent Link - |

    Tuesday, March 27, 2007

    Karma Korrection -- I just realized why the idea of priority conflict avoidance as a cause of multi-tasking came to me so easily yesterday.

    I probably subconciously stole it from Jack Vinson's The pernicious thinking behind multi-tasking and Johanna Rothman's response to it, Multitasking is Conflict Avoidance.

    There...I feel better now.

    Labels: ,

    posted by Frank - Permanent Link - |

    Monday, February 05, 2007

    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.

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Friday, November 17, 2006

    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.

    Labels: , ,

    posted by Frank - Permanent Link - |

    Wednesday, September 06, 2006

    Blasts from the Past, Sep 3-9 -- Four years ago, a couple more pointers to pre-blog writings - Ax or Slack, Break Rules to Make Rules, and Six Sigma and the Theory of Constraints.

    And in 2004, the multi-project management series continued with bits on resource effectiveness and multi-tasking.

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Monday, November 21, 2005

    Three Bad Habits that some people think are positive attributes...
    - Multi-tasking
    - Competitiveness
    - High Utilization
    ...only get in the way of clarity of thought required for effective efficiency.


    posted by Frank - Permanent Link - |

    Sunday, October 16, 2005

    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.

    Labels: , ,

    posted by Frank - Permanent Link - |

    Monday, September 19, 2005

    Say No to Multi-tasking! - Chunk and dash.

    OK, got that done...

    Labels: ,

    posted by Frank - Permanent Link - |

    Thursday, June 30, 2005

    Critical Chain Case Study - Pharma -- Over at CCPM software provider Realization's site is a case study on the implementation of Critical Chain-based multi-project management in a pharmaceutical environment...
    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.

    Tags: , ,

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Sunday, April 24, 2005

    On Multitasking --
    "We rightly consider keeping many balls in the air a circus stunt. Yet even the juggler does it only for ten minutes or so. If he were to try doing it longer, he would soon drop all the balls."
        -- Peter Drucker (1966). The Effective Executive.


    posted by Frank - Permanent Link - |

    Tuesday, March 08, 2005

    Multi-thinking -- In Innovation Tools, Jeffrey Baumgartner offers good advice for those who feel compelled to multi-task...
    " 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."

    (Via Jack Vinson; File under , Getting Things Done and Productivity)

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Sunday, November 21, 2004

    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...

    Labels: ,

    posted by Frank - Permanent Link - |

    Friday, April 23, 2004

    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.

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Thursday, February 19, 2004

    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.)

    Navigate this series: First Part -- Previous Part (3) -- Next Part (5)

    Labels: ,

    posted by Frank - Permanent Link - |

    Wednesday, February 11, 2004

    Project Management Capacity Planning -- Christian Connett recently discussed the topic of Capacity Planning for the PMO, asking...
    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?

    Labels: , , ,

    posted by Frank - Permanent Link - |

    Wednesday, August 06, 2003

    Two Years Ago Today -- Multitasking -- Revisiting the early days of my weblog, I find that my obsessions have been consistent over the years, with this link to an NPR feature on multitasking (RealAudio required for the clips). I don't remember noticing it then -- perhaps because I wasn't familiar with Dave Wienberger back then, but a clip from him points out that slicing time and attention is not like slicing a potato, but more like slicing a're bound to lose some juice.


    posted by Frank - Permanent Link - |

    Tuesday, July 29, 2003

    Project Portfolio Management -- Over at Incipient(thoughts), Laurent recently started a piece with the following...
    "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.

    Labels: , , , ,

    posted by Frank - Permanent Link - |

    Sunday, July 27, 2003

    Zen and the Art of Corporate Productivity -- In my regular rants regarding the wasteful practice of multi-tasking, I often find myself suggesting that people "Don't just do something. Sit there!" so that they don't waste time, energy and effort on make-work activity or allow themselves to be bounced from task to task willy-nilly. This article (might require free registration) suggests what one might do while sitting there. For another view of the subject, try this.

    Labels: ,

    posted by Frank - Permanent Link - |

    Current Posts (Main Blog Page)

    Previous Posts

    It is a common delusion that you make things better by talking about them. - Dame Rose Macaulay

    What's this XML thingie all about?

    View Frank Patrick's LinkedIn profileView Frank Patrick's profile


    FP's Recommended Reading
    - From the FP Bookshelf...

    ...from My AStore

    ...and some ideas from Amazon...

    Best of the FP Blog Archive
    - The really good stuff...

    Strategic Thinking and Improvement

    Enterprise PM - It Starts with Strategic Interdependence

    Face Reality

    How to Think With Your Gut

    Hugger-Mugger and Helter-Skelter

    Managing for Murphy, Satan, and Yourself

    More of the Same (Local/Global)

    PMI Congress Notes: Using Risk Management for Strategic Advantage

    Tell Me How You'll Measure Me and Ah, But What to Measure?

    What's in Your Strategy?

    Why Can't We All Just Get Along?

    Why TOC Works
    Project and Multi-Project Management
    Critical Chain and (not or) XP

    Defining Project Success (But for Whom?)

    Down 'n Dirty w/TOC and PM (Part 1 of 5 consecutive posts)

    End of Project Review

    If Project Management is the Answer, What's the Question?

    In Defense of Planning

    It Ain't the Tools

    Lessons Learned, Revisited

    Predicting Uncertain Futures

    Project Conflicts

    Project Determinism (and other myths)

    Project Portfolio Management

    Promises, Predictions, and Planning

    Removing Bottlenecks - A Core Systems Design Principle

    Stage Gates and Critical Chain

    Ten Top Sources of Project Failure (The Executive Version)

    The Meaning of "Schedule"
    Leadership and Change Management
    Consistent Leadership Behavior

    Invisible Dogma - Perpetuating Paradigms

    Nothing But Value

    On Assumption Busting

    Personal Productivity - An Excuse?

    The Psychology of Change Management

    FP's Blogroll
    - Other weblogs and sites I read

    FP's Ryze Page

    FP's Technorati Profile
    - Click the pic

    Who links to FP?

    For Your Charitable Consideration:

    Give Something Back Foundation

    Global Virtual Classroom

    FP's Link List
    - Selected Sites and Resources

    Critical Chain Discussion Group

    Lilly Software: Visual DBR

    Sciforma PS (Critical Chain Software)

    Spherical Angle (Critical Chain Software)

    Synchrono Supply Chain Planning Software

    FP Blog Archives
    - All the oldies, but goodies...

    10/09 | 09/09 | 08/09 | 07/09 | 06/09 | 05/09 | 04/09 | 03/09 | 02/09 | 01/09 | 12/08 | 11/08 | 10/08 | 09/08 | 08/08 | 07/08 | 06/08 | 05/08 | 04/08 | 03/08 | 02/08 | 01/08 | 12/07 | 11/07 | 10/07 | 09/07 | 08/07 | 07/07 | 06/07 | 05/07 | 04/07 | 03/07 | 02/07 | 01/07 | 12/06 | 11/06 | 10/06 | 09/06 | 08/06 | 07/06 | 06/06 | 05/06 | 04/06 | 03/06 | 02/06 | 01/06 | 12/05 | 11/05 | 10/05 | 09/05 | 08/05 | 07/05 | 06/05 | 05/05 | 04/05 | 03/05 | 02/05 | 01/05 | 12/04 | 11/04 | 10/04 | 09/04 | 08/04 | 07/04 | 06/04 | 05/04 | 04/04 | 03/04 | 02/04 | 01/04 | 12/03 | 11/03 | 10/03 | 09/03 | 08/03 | 07/03 | 06/03 | 05/03 | 04/03 | 03/03 | 02/03 | 01/03 | 12/02 | 11/02 | 10/02 | 09/02 | 08/02 | 07/02 | 06/02 | 03/02 | 02/02 | 12/01 | 11/01 | 10/01 | 09/01 | 08/01 | 06/01 | 02/01 | 01/01 | 12/00

    Powered by Blogger

    If you are interested in adding an easily updated weblog to your site, I would suggest you look into the free service provided by Blogger.

    Who is FP?
    Contact Focused Performance