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.

Monday, March 31, 2003

Cutting Bait -- From Corante's Ideaflow, Renee Hopkins points to When Bad Ideas Won't Die by Isabelle Royer, describing a situation that I've run into more than once...
"Royer describes how "collective belief" can set in, as the project's champion spreads the success gospel throughout the organization until "faith blinds you to increasingly negative feedback from the lab, from vendors and partners, from customers," a phenomenon many in the tech world recognize as drinking the Koolaid.

"The dangers: Problems won't be seen as signs of failure, or even as issues that should be resolved before moving on to the next stage of development; misplaced enthusiasm can lead to an unrealistically tight development timetable; and lenient review procedures."
I've written in the past about the failure to face reality, but Hopkin's/Royer's message reminds me of the frustration of presenting a project plan to someone who agrees with all its components, can't argue with what it says, and then goes on and ignores the warnings of diminishing buffers, saying "but we can do it" or "we have to do it" or "we've promised it," and refuses to face reality, driving the project to a predictably disasterous conclusion.

I had seen references to the Royer article before, but today's encounter with it shortly followed a contact with a friend at an old client that was being "led" in such a direction. Our engagement with them at least forced them to take a serious look at the unrealistic expectations and revise the direction of the project. They also chose, inexplicably, to use a different mode of PM; one I suspect told them what they wanted to hear rather than paint a realistic picture. I asked how things were going, commenting on my expectation that they were in the throes of Release Three. But noooo...They didn't even make it to Release One, and killed the project...for the second time. (And to rub salt in the wound, I'm a customer of this company, and was recently advised that their prices would be going up 10% this year, after a 25% bump only two years ago!!!)

Kool-aid, anyone?

posted by Frank - Permanent Link - |

Saturday, March 29, 2003

Batches -- Laurent's been reading The Goal: A Process of Ongoing Improvement recently, and has seen past the surface story of manufacturing to apply it to the issue of batching in software environments. His post talks about batching issues for meetings and batching bug fixes for concentrated attention. Insightful stuff, especially about the meetings. He also asks...
"What other processes are there in software development work that involve varying "batch sizes?""
One that comes to mind, that we've been discussing in these pages recently, is the unnecessay batching of requirements. The agile thoughts on this are out there loud and clear, pointing to the "batching" of requirements in poorly designed "waterfall plans" as a source of problems. These concerns are consistent with the preferred practice in the Critical Chain community to understand the knowable dependencies of the effort in question, so that things like requirements can be planned and developed in a "just-in-time" manner.

posted by Frank - Permanent Link - |

Friday, March 28, 2003

Multiple Responses on Multi-tasking -- Yesterday, following up on a recent theme, I wrote about the role of effective project management in the effort to deal with pressures to multi-task. Similarly, Joe Ely and Johanna Rothman (both with highly deserved spots on my blogroll) chimed in on the topic at a more down to earth level with thoughts for dealing with smaller distractions and disruptions. There's also another one of my slightly older pieces that touches on the subject as well, with a bit of humor, to boot.

posted by Frank - Permanent Link - |

Thursday, March 27, 2003

Weblog Commenting Problems -- You might notice longish page loading times and/or unavailable commenting. My comment processing service, (Haloscan -- you may have noticed it's name in your browser status bar while waiting for the page to load) says that they are "currently experiencing an extremely high amount of traffic because of a couple war and politics-related weblogs that use our commenting system that have skyrocketed in traffic because of the war. So at peak hours, the site may respond slower than usual because of the high server load." Sorry if this reduces the quality of your Focused Performance weblog experience. Keep in mind, if you use a news reader (my Mac-based favorite is NetNewsWire) and the XML/RSS link (provided over on the right) instead of a browser to read this and other blogs, speed of access is significantly enhanced.

posted by Frank - Permanent Link - |

Point/Counterpoint -- In Multitasking might make you stupid, but that doesn't mean you have a choice, Jim McGee, appreciating the preference to single-task asks...
"...but does that mean you really have a choice? The research is intriguing. What I'd like to see next is some advice about making good choices about what and when to multitask and when and how to go after flow...I sure don't expect to get back to a world where I have the unfettered freedom to always single thread."
Alright, absolute single-tasking is probably utopian, but in the real world of organization efforts, aka projects, the bulk of really debilitating, capacity and throughput destroying multi-tasking can be dealt with through effective project management. As I wrote on March 13, and elsewhere, if project management is to be seen as an answer, the primary question is "What should I be working on?" Effective project management makes sure that...
1) Resources are not pressured to multi-task by overfilled in-boxes, by synchronizing the launch of projects with the ability of the system of resources to take them on, and

2) There are clear priorities, or better yet, there is a process to determine a clear priority for the use of a resource's single-tasking time when s/he has a choice of tasks to work. Note that this is not necessarily based on some questionable and ever-changing "priority of project," but more appropriately a priority based on the relative health of project promises at the point in time in question.
This doesn't create a perfect world of uninterupted single-tasking, but once in place, the benefits of striving for single-tasking become apparent to all involved, including the less-stressed resources and the managers surprised by the enhanced reliability and throughput of project completions.

posted by Frank - Permanent Link - |

Publishing a Project Weblog -- By Jon Udell in Infoworld...
"If you're managing an IT project [or any other kind of project - FP], you are by definition a communication hub. Running a project Weblog is a great way to collect, organize, and publish the documents and discussions that are the lifeblood of the project and to shape these raw materials into a coherent narrative. The serial nature of the Weblog helps you make it the project's newspaper of record. This kind of storytelling can become a powerful way to focus the attention of a group."
If you're reading this page, you've probably seen some value in weblogging, whether you've recognized it or not. If you're reading this page, you probably have an interest in project management. Jon makes a good case for putting the two together.

posted by Frank - Permanent Link - |

Wednesday, March 26, 2003

Blogorrhea -- A new word, inspired in part by that last post, and in part by one of my favorite real words...logorrhea.     ;-)  

posted by Frank - Permanent Link - |

Dependencies - Violent Agreement -- Laurent Bossavit, in comparing my comments on project planning with those of James Grenning [pdf] (an XP advocate)...
"...can't decide whether James and Frank are in complete contradiction or in violent agreement."
From where I'm standing, I'll say "violent agreement."

Or maybe separated by different uses of a common language.

Reading Laurent's blog, I think I bruised my forehead when the heel of my hand thumped it and a Homeresque "DOH!!!" escaped my lips. It (the blog, not the forehead-thumping) helped me expand on my view of the source of the dilemma in the use of heavyweight WBSs in traditional project management. Read on.
"One all too common way of planning a software project does involve breaking down the work into technical components (as opposed to features). So many weeks for the persistence framework, so many for the domain model, so many for the "presentation layer". The required features of the system are supposed to "drop out" of the integration stage when the components are assembled."
(...with heavy details for each of these pieces, but with little useful information about their real interdependencies; hence the "whoops's" or "aw-s#!t's" in the execution of the project.)
"Many Agile processes recommend breaking down the work exclusively according to "features" - new capabilities available to end users."
This is where my "a-ha" starts to come together. Agile's "features" are directly related to the "deliverables" of Critical Chain Dependency Network's starting point of "objectives, deliverables, and success criteria." The focus of CCPM planning is first on the whats (at the end, and in terms of what is needed to be handed-off along the way), and only then on the hows, and then only if assumptions about how those hows are needed to be narrowed down to understand cross-task whats. (Yeah, read that last sentence again; it's ugly, but it does reflect what I'm trying to say.)
"Extreme Programming recommends that technical dependencies should play almost no role in planning the work to be done. It seems to me that if this is the case, business dependencies (in the form of priority ordering of features) will be reflected in the planning."
Yes. Very often when I go into a client, the first order of business is to get rid of the existing, over-planned, over-detailed schedules and plans that reflect an attempt to micro-manage the efforts of resources and teams, with strings of tasks reflecting pseudo-handoffs from A to A to A to A, without input or outputs to B (or anyone else). These kinds of plans only serve the paranoia and distrust of the PM when tha PM thinks s/he needs to "control" the details of the project.

Instead, PMs should be focused on the dynamics of the project. Tasks in Critical Chain are defined by handoffs between resources, and if, in an agile/xtreme/etc. environment, those resources are teams or pairs or whatever, the technical aspects of the project -- the "hows" are, to a very large part, embedded in the tasks. In CCPM, as in the agile methods, these are managed by the resources and their technical managers and only require (for Critical Chain's Buffer Management process) reporting out to the project manager status of expected time to completion or actual completion. This minimal reporting is necessary so that successors can be ready to run the next leg of the relay race and so that management can maintain confidence in the larger, meaningful promises of the project. Of course, some understanding of the impact of these tasks needs to be taken into consideration up front so that big-picture promises can be made, but the "range estimate" process of CCPM makes that a comfortable and quick aspect of the planning exercise.
"If we are to understand a software project as "a system of interdependencies supporting the project objectives" - a chain of mutually supporting, intermediate objectives in pursuit of a larger, farther off, overarching obective - then technical dependencies are mostly irrelevant...."
I'm glad to see the word "mostly" in there.   -)
The objectives of a software project are usually not technical, i.e. the software is not built for the sake of building the software, but to achieve some other business objective. So I'm pretty sure that it's not technical dependencies which are worth focusing on in a project plan. I'm less sure how well XP, or various software development processes, measure up to handling business dependencies"
I may need a bit of additional clarity on Laurent's/XP's use of the term "technical dependencies," however, because in the context of promising the necessary aspects of a project, there may be a need to model dependencies between the "hows" of features that have inter-dependent predecessor/successor relationships. But on the other side of the coin, if certain features/deliverables have no interdependencies (other than maybe the use of common, shared resources), and they are truly useful in a standalone delivery, there is no reason not to model such deliveries separate from and prior to the end of the larger project (or even manage them as separate projects in a larger program or portfolio). In CCPM, we do that all the time with "deliverable project buffers" for such situations.

oooh...That's a good word..."model."

(Please forgive this stream of consciousness. I hope it isn't rambling too much.)

If agilistas have a problem with the word "plan" as it might be associated with non-CC "heavyweight" project management, laden with rigid (but irrelevant) dates and milestones, I think they might be more comfortable with the Critical Chain concept of the dependency network and schedule as a "model" of anticipated dependencies and expectations that support the ability to promise uncertain outcomes within an acceptable range of certainty.

I really have to thank Laurent for helping me refine what I've been trying to say on the subject. These weblog interactions can be a true learning process.

[ Warning! Blatent commercial mode engaged]

Now, if there are any agile managers out there interested in overlaying CCPM on their efforts, bring me on in, and we'll make your agile promises happen together.

[Standard pseudo-non-commercial mode re-engaged.]

posted by Frank - Permanent Link - |

A New Focus for Conferences -- From Doug Fox's "Future of Meetings" weblog...
"If there is one theme that conference organizers, tradeshow producers and adult educators should be focusing on is: "How do we make attendees the main event?""
I've often noted how some conferences I've attended over the years end up with the same folks up on stage over and over, while the power/knowledge/value of the audience far outshines the spotlight, but is not really allowed to share its light effectively.

posted by Frank - Permanent Link - |

FTC Announces Calendar for Implementation of the National "Do Not Call" Registry -- OK, I admit that on the surface, it may not be purely related to the usual topics of this weblog, but...
"The Federal Trade Commission today released its schedule for creating and implementing the national "do not call" registry, first announced in December 2002 as part of the Amended Telemarketing Sales Rule (TSR). The registry will give consumers a choice about whether to receive most telemarketing calls. Beginning in July, consumers will be able to put their telephone numbers on the national registry, which telemarketers subsequently will be required to access. As of October, it will be illegal for most telemarketers to call a number listed on the registry." does have some implication for reducing interruptions and maintaining flow of attention to tasks at hand, especially for those working in home offices. (Unfortuately this will not apply to political and charitable solicitations. Remember all those automated, recorded calls from Giualani, Laura Bush, and even the Pres last November?)

posted by Frank - Permanent Link - |

Important to Remember --
"There is no duty we so much underrate as that of being happy."
    - Robert Louis Stevenson
What's constraining your happiness?

posted by Frank - Permanent Link - |

Tuesday, March 25, 2003

Congress for Progress -- I'll be attending the APICS Mid Atlantic Supply Chain and Resource Management Symposium in Atlantic City on April 9-10-11, and, as someone familiar with the area (I've still got a couple weeks available for rent this summer on my Ocean City, NJ condo), I'm willing to coordinate a TOC/Constraints Management "birds of a feather" gathering. If you're going to the conference, let me know if you're interested in attending such a get-together.

posted by Frank - Permanent Link - |

Lean Years -- (No, not that kind of lean.) From a two-minute speech by Stewart Brand...
"Lean years are not just punctuation between periods of fat years. They are the discipline years when civilization consolidates its gains and invents its way out of trouble. In the long now, THESE are the good years. Don't waste them."
(via Andrew Hinton's memekitchen)

posted by Frank - Permanent Link - |

IT worker burnout gets critical -- In an article in The Register, John Leyden writes that...
"Morale among IT workers is at rock bottom, with workers struggling to cope with increased workloads.

"That's the main conclusion of Meta Group's annual IT Staffing and Compensation Guide. It found the majority of managers believed their techies are close to breaking point. Increased pressure, due to recession-induced staff cutbacks, is increasing the workload of remaining workers who are beginning to show the strain.

"Among IT managers surveyed, more than 71 per cent indicate that IT employee burnout is currently a serious issue in their organizations. Unless the problem is addressed, turnover, productivity, and shareholder value will suffer, Meta warns."
Little wonder, when, in last month's issue of PMI's PM Network magazine, a project that conned its staff into working over 12 hours a day for 18 months was lauded for "teamwork" on the part of the poor exploited schlubs and "project leadership" on the part of it's "managers." Something's got to change.

posted by Frank - Permanent Link - |

Monday, March 24, 2003

Why I Write / George Orwell -- Sometimes I wonder how and why this weblog has taken over my time and attention to the extent it has in the last few months. My recent foray into Orwell has led me to his essay on why he wrote...
"Putting aside the need to earn a living, I think there are four great motives for writing, at any rate for writing prose. They exist in different degrees in every writer, and in any one writer the proportions will vary from time to time, according to the atmosphere in which he is living. They are:
1. Sheer egoism. Desire to seem clever, to be talked about, to be remembered after death, to get your own back on the grown-ups who snubbed you in childhood, etc., etc. It is humbug to pretend this is not a motive, and a strong one. Writers share this characteristic with scientists, artists, politicians, lawyers, soldiers, successful businessmen -- in short, with the whole top crust of humanity. The great mass of human beings are not acutely selfish. After the age of about thirty they almost abandon the sense of being individuals at all -- and live chiefly for others, or are simply smothered under drudgery. But there is also the minority of gifted, willful people who are determined to live their own lives to the end, and writers belong in this class. Serious writers, I should say, are on the whole more vain and self-centered than journalists, though less interested in money.

2. Aesthetic enthusiasm. Perception of beauty in the external world, or, on the other hand, in words and their right arrangement. Pleasure in the impact of one sound on another, in the firmness of good prose or the rhythm of a good story. Desire to share an experience which one feels is valuable and ought not to be missed. The aesthetic motive is very feeble in a lot of writers, but even a pamphleteer or writer of textbooks will have pet words and phrases which appeal to him for non-utilitarian reasons; or he may feel strongly about typography, width of margins, etc. Above the level of a railway guide, no book is quite free from aesthetic considerations.

3. Historical impulse. Desire to see things as they are, to find out true facts and store them up for the use of posterity.

4. Political purpose -- using the word "political" in the widest possible sense. Desire to push the world in a certain direction, to alter other peoples' idea of the kind of society that they should strive after. Once again, no book is genuinely free from political bias. The opinion that art should have nothing to do with politics is itself a political attitude."
I suppose they're valid reasons for myself as well.

That said, please excuse me while I go try to earn a living. It's something that can't be "put aside" for too long. I do hope my readers find it worthwhile. As of today, I have attracted 50 subscribers via email (I hope you guys aren't just using it to test spam filters), and there's more than a dozen other weblogs that have picked up on my stuff, so I'm encouraged, and will persevere.

[Later...] Came across an interesting unattributed quote from this week PC Forum conference...
"Without billing, it's just a hobby."

posted by Frank - Permanent Link - |

Assuming the Worst about Requirements -- More on a recent theme...

For requirements to succeed, they must be clearly defined and enough time must be allocated to complete them. This is crucial to preventing team clashes and to creating a positive work environment. Writing the correct requirements and following them, is the key to producing a quality product. In this column (may require free registration), Becky Winant explains why properly assigning requirements is important to creating project deliverables. In the piece, she mentions three way in which "requirements become suspect.."
"We believe in miracles. Ever hear a story about how some genius sold his idea based on a napkin sketch? I think sometimes we expect our analysts to do the same. Hey, once the sketch is down, we're done! Time to hand the napkin over to production.

"We get carried away by sports analogies. In some organizations, the requirements stage feels like the warm-up before a game. We spend just enough time to loosen up, because we are saving time for the real work. So, requirements becomes all about establishing the customer relationship and maintaining a friendly mood.

"We believe in components. This is good, because once we really have requirements this could buy us time and produce reliable results. Without clear requirements, we risk assembling a van instead of the sedan that was requested. We heard "vehicle for the family," started thinking about which components to use, and went to work."
She goes on to provide some reasonable advice on the subject, which, to my mind, can be related to many kinds of projects, not just the software-centric ones to which the issue of "requirements" are usually considered.

That said, I want to add that I particularly resonate with Winant's third source of problems -- belief in components. The common use of a detailed WBS (work breakdown structure) is one way of trying to deal with it, but, as many of those involved in agile methodologies like to point out, a lot of those details are unknown and unknowable in the early days usually associated with planning. In addition, even if one could lay out a detailed WBS to define the project, its local, partial, component-focused nature can easily lead those assigned to work on the individual components to think and work within a too narrow range of focus. The hierarchical, "leggy" nature of a WBS makes it too easy to miss dependencies and opportunities across the legs, and therefore make project promises (as well as requirements) suspect.

This is why, in the Critical Chain community, if a WBS is used at all, it is only used to one or two layers of detail to define high level objectives, deliverables, and success criteria. The typical critical chain planning process quickly moves to the building of the project's dependency network, so that, even if details of how components are to be delivered are fuzzy, at least the required interactions between components can be defined. In this way, the project is understood not as a sum of components, but as a system of interdependencies supporting the project objectives.

posted by Frank - Permanent Link - |

The 101 (almost) Dumbest Moments in Business -- Business 2.0 has put out their third annual send-up of what they consider the most ill-conceived, embarrassing, and downright appalling developments of the past year. Worth a checking out for a chuckle, but my comments from last year's version still hold.

posted by Frank - Permanent Link - |

Sunday, March 23, 2003

A Lesson --
"Perhaps the most valuable result of all education is the ability to make yourself do the thing you have to do, when it ought to be done, whether you like it or not; it is the first lesson that ought to be learned; and however early a man's training begins, it is probably the last lesson that he learns thoroughly." - Thomas H. Huxley
...applicable to both the issues of multi-tasking and priorities discussed in this weblog, as well as to current global issues not generally discussed here.

posted by Frank - Permanent Link - |

Saturday, March 22, 2003

Dilbert on Requirements -- I hope this is more than a two day series. (Strip archives here and here, which I hope persist beyond the Dilbert page calendar.)

posted by Frank - Permanent Link - |

Friday, March 21, 2003

Breakthrough Thinking on Worker Productivity -- More on multitasking, from Esther Derby...
"...when someone is working on four tasks, he is spending 10% of his productive time on each task. That adds up to 40% of his time. Where does the other 60% go?
That missing 60% goes to:
--breaking concentration on the task A
--picking up task B
--organizing materials related to task B
--remembering where you were last time you worked on task B
--establishing concentration on task B
--overcoming emotional inertia
--recreating the train of thought that got you to the current point on task B....
and so forth and so on."
That fourth item -- remembering where you were -- brings to mind a story from a Critical Chain Multi-Project workshop I did a few years ago in a software-centric product development organization. I used the usual example of the "Where was I?" question as one of the reasons for lost productivity. From the back of the room, one developer pointed out that if she's in the middle of coding something, and gets pulled away for something else, the question that comes to here is in "Where was I?," but rather, "Who the hell wrote this crap?"

posted by Frank - Permanent Link - |

Requirements Churn -- A Question of Ends or Means? -- In a comment to a recent post (What is a Project?), someone who signed in as "DP" asked...
"I wanted to see if you'd comment sometime on how you'd handle "requirements churn." The heavyweight process that the agilists want to unseat start from the assumption that there is a well defined set of requirements (or that one is possible) and proceed logically from there. This is probably proper for most kinds of physical deliverables, but it fails to address the "softness" of software. I think this is one of the main reasons those non-agile processes fail so often in software. In my experience, the project promises are almost exactly as stable as the requirements - the whole notion of a moving target."
My immediate response (and this is an immediate, "rough draft" response, so please spare the flamethrowers for now...although I would like to engender a discussion on this with those who are more deeply involved in software development, so please make use of the comment feature below if you are so moved by what I have to say) is that this issue of requirement churn is embedded in a confusion of means and ends. When I advise clients on developing project plans, the starting point is the endgame...the objective, key deliverables, and success criteria that define the reason and output effects of the effort defined as the project. The output of a "software project" is not just "working code," but rather it is either A) a software product that is sold, installed, and solves some problem for a customer to the degree that they are willing to pay for it, or B) a combination of a system and business process change that enables the oganization to do something of value that it isn't able to do without embarking on the project. From my point of view, the objective -- the "ends" -- must be defined sufficiently so that a reasonable plan to achieve it can be devised, and promises can be made to the market, to shareholders/owners, and to other stakeholders.

When we move into the realm of software projects, "requirements" are seen as the basic link between the "ends" and their "beginnings" -- the design of the necessary work to produce it. What confuses me, as someone who has been exposed to just enough software-related projects to be dangerous, is to what extent requirements are "ends" or "means." The project objective is a very high level "requirement," one that if it is allowed to churn indicates serious management problems beyond the realm of project management.

I would suspect that there is a second level of requirements that remain quite stable once determined, probably related to basic/core functionality and user requirements associated with the objective. If these are allowed to substantially change, there had better be a darn good reason for it -- more than just the excuse of "softness of software." That said, a robust project management methodology, combined with good task mangement practices that I associate with my passing knowledge of agile development methodologies, should be able to highlight when those deviations are occurring and the impact on the original project promise. Good change control practices, tempered with an awareness of the potential for real added value, and supported by a planning/scheduling process that allows flexibility for such things deal with these.

The third set of requirements that I suspect is the source of concern about churn are probably in the details. It's my sneaking suspicion that these, even more than the second set, are related to the means of achieving the ends of the project rather than being ends themselves. Yes, they relate to the ends of tasks, but only as stepping stones to the complete system. Programmers and engineers focus on them, rightfully, but they are only local components of the larger effort, and must be dealt with as such. (There is also the "good enough" rule, and its propensity to be broken in tech/software projects. Sometimes, there is pressure to change a requirement to address some new technology or to make the solution more "elegant" or "perfect," when, to meet the needs of the customer, the original plan is "good enough." Sometimes I think tech/software projects are overly susceptible to such self-induced churn, unnecessarily. But that's a whole 'nother topic.)

A project can be planned with good enough results based on an overarching view of the system, probably at the level of the second level of requirements. The detail requirements, taking a cue from both lean manufacturing practices, and the process of network building associated with Critical Chain Project Management, are planned to occur "just in time," when needed to support the rougher view of the project. And if the schedule is a Critical Chain Schedule, the duration/effort uncertainty of the higher granularity pieces of the project are already taken into consideration and deviations from expectations do not become cause for undue concern; the schedule and the promise associated with it is buffered to absorb such deviations.

Fix the core requirements that define the ends, monitor the intermediate requirements for risks or opportunities, and develop the detail requirements (the means) when needed, and not before. Promise the effort based on a robust respect for risk and uncertainty, and don't worry about deviations along the way until and unless they threaten the project promise.

So asked whether to fix requirements up front or let them slide loose until more details are known about the project, my answer is a resounding "yes". That may sound like a bit of fence-straddling, but then, where I come from -- Critical Chain land -- is, I believe, a place that lies on the border, straddling the fence between "heavyweight" and "agile," and therefore gets minimal respect from either.

One of these days, that will change.

(Again, I need to refine my thinking on this, so comments are heartily solicited.)

posted by Frank - Permanent Link - |

Projects vs Operations -- Over on Gantthead, someone asked about the difference between projects and operations, beyond the usual "temporary and unique" descriptor for projects. There are two things that I take into account when distinguishing projects from operations (which I'll translate to production-like operations).

The first is the relative range of uncertainty associated with the component tasks/jobs being performed as part of production or projects. If you were to assess, for example, the possible anticipated range of duration for a production/operations task, it might be around +/- 10%, max. (Think about the nature of Industrial Engineering time studies to define standard performance in production.) Project tasks have a range of typical possibility more like -20% to +200%.

Another differentiating characteristic is the usual nature of queing of work in well managed project or production operations. The amount of "touch-time" on a project would typically be a much higher percentage of total time in a project than in a production-like operation. In operations, a common objective is to make sure that key constraining resources are not allowed to sit idle, so work waiting for resources is a common and relatively accepted situation. In projects, the speed of getting to the final deliverables is usually more paramount, so the preferred situation would be resources waiting for work. Admittedly the application of leanish manufacturing practices brings production operations closer to the latter situation, but the basic disctinction will still probably be valid for the foreseeable future.

posted by Frank - Permanent Link - |

Thursday, March 20, 2003

Politics and the English Language, a 1946 essay by George Orwell, calls to mind two messages to me. The first is about the need for clarity of communication. (Don't be put off by the title, "politics" is just another word for "getting things done through others" and the process of getting buy-in to one's aims.) While that topic alone is enough to recommend the essay, there's another message embedded within it...
"I am going to translate a passage of good English into modern English of the worst sort. Here is a well-known verse from Ecclesiastes:
"I returned and saw under the sun, that the race is not to the swift, nor the battle to the strong, neither yet bread to the wise, nor yet riches to men of understanding, nor yet favor to men of skill; but time and chance happeneth to them all."
"Here it is in modern English:
"Objective consideration of contemporary phenomena compels the conclusion that success or failure in competitive activities exhibits no tendency to be commensurate with innate capacity, but that a considerable element of the unpredictable must invariably be taken into account."
The message in there is the need to have a healthy respect for chance, uncertainty, and variation as a significant portion of performance, both predicted and achieved...something that must be taken to heart for effective project management.

[Later] Two additional thoughts...

Another version of the message from Ecclesiastes might be "s#!t happens."

A couple books in my "sounds interesting" list...
Fooled by Randomness: The Hidden Role of Chance in the Markets and in Life, by Nassim Nicholas Taleb.
Against the Gods: The Remarkable Story of Risk, by Peter Bernstein.

posted by Frank - Permanent Link - |

Multitasking makes you stupid, studies say -- From the Wall Street Journal, through the Dallas Star-Telegram (and to me through Mark Woepell on the TOC Experts discussion group, this article points out the obvious...
"A growing body of scientific research shows that one of jugglers' favorite time-saving techniques, multitasking, can actually make you less efficient and, well, stupider. Trying to do two or three things at once or in quick succession can take longer overall than doing them one at a time, and..."
... the not so obvious fact that it...
"...may leave you with reduced brainpower to perform each task."
Stupidity enhancement aside, this too common practice is at the root of a lot of poor project performance and difficulty in managing their successful delivery, as the task delays derived from context switching, and set-up/set-down activities force successor tasks to start later then they would otherwise be able to start.

Both Agile Software Methodologies and Critical Chain Project Management recognize this and both address the support of appropriate behaviors in their own way, which is one of the reasons I believe Critical Chain is an appropriate approach to manage projects that use agile approaches for managing tasks.

posted by Frank - Permanent Link - |

Tuesday, March 18, 2003

ASAPM -- A not quite new, but maturing alternative to PMI. I like the acronym. And they've got a quality collection of articles on the site.

posted by Frank - Permanent Link - |

A bit more on Xpertweb -- from it's instigator and from some others who have given considerable thought to the more far reaching possibilities of web-enabled markets. The idea of quality judgements impacting remuneration is an interesting one, especially since my own version of "unrefusable offers" for smaller businesses includes the unilateral option of the client to stop the stream of payments at any time that confidence in my work drops. And since that offer involves balloon payments at the end of the engagement, timed to coincide with increased client performance and ability to pay...well, let's just say I better deliver.

posted by Frank - Permanent Link - |

Securing Reliable Promises -- While I'm woolgathering for the next big post on promises, predictions, and priorities (interrupted to address an upcoming promise to the IRS), Joe Ely reminds me of an excellent paper on the subject (pdf download link) by Hal Macomber. (There's a reason both these guys are listed in by blogroll.)

posted by Frank - Permanent Link - |

Monday, March 17, 2003

CCPM and Project Success -- This link leads to an interesting academic paper (downloadable in PDF format) by Neils Schieman. I've only skimmed it so far, and it's PDF format is not copy/paste friendly, but the section entitled "The Role of CCPM in Project Success" will likely provide substantial input to a future weblog posting. Watch this space.

posted by Frank - Permanent Link - |

Project Alliteration -- While I catch my breath from the last few days of big entries on PM, I have to mention that my favorite hackneyed mechanism in writing is alliteration. Whenever I find myself with 2 or 3 words with similar starting sounds, I often end up looking for more to fit into the sentence. Building on some of the common words of the past few days...
... I'm starting to feel pressure to prattle on about "priority" as a prominent prerequisite for project management.

Watch this space.

posted by Frank - Permanent Link - |

Project Determinism -- An interesting thought from an announcement of a lecture by Daniel Dennett...
"A widespread bad habit of thought is supposing that whatever is determined is inevitable."
I know it comes from a different source, Dennett being a philosopher known for his on the workings of mind and consciousness, but it seems like one thing that an "agile" thinker might say that I agree with.

The non-deterministic nature of projects that is, I believe, at the root of the agile movement is also at the root of Critical Chain-based project management. While many agilistas prefer not to make promises beyond a week or two, as noted in a comment to a recent post, those of us in the "chain gang," recognizing the need to make bigger, longer-term promises to support business needs, prefer not to worry about date-specific intermediate promises.

The basic "requirements" of those needs can be and are known, and actually remain quite stable through the life of a project. The "means" of achieving them may be open to uncertainty, but once that distinction is understood, and is addressed in the overarching structure of dependencies and interdependencies and in the use of buffered schedules that can absorb non-trivial variation from "plan," the concern associated with "churning requirements" can be minimized.

When both traditional PMers and agilistas see a traditional project plan, they see concrete dates and milestones, each one to be met in turn. One tries to enforce it, the other recognizes the futility. A Critical Chain plan is not dates and milestones, but dependencies and deliverables leading to a final outcome that will occur in a range of possible calendar time, and manged not to exceed the outer boundary of that promised range.

. . . Later . . .

. . . More, upon reading Promises and Predictions, in which Laurent Bossavit (I found Incipient's name...right at the top of his blog), rises to the bait of my provocative proposition regarding "agile" and project management. Laurent writes...
"Part of the problem, perhaps, is that often we are lumping "promises and predictions" together, and Frank's phrase is of interest to me precisely because it calls attention to the fact that they are different aspects of project planning. We cannot predict in detail the future states of a complex system (if we could, it wouldn't be a "complex system" in the sense that attracts scientific attention). So at least in some of the ways we understand the term, "prediction" is of limited value on software projects."
In order to maintain some semblence of managing promises, which is the role of project management, prediction at the system level is necessary to assess the health of the project (it's promises). That system is made up (like, for example, a pool of health insurance policy holders) of components that are tougher to predict in an individual pinpoint fashion, but can be judged sufficiently so that there is some level of confidence in their aggregate result. To make promises, all you need is a way of aggregating the local uncertainties into a reasonably certain global whole. To manage (and dare I say, control?) execution of the effort, short-term detailed predictions, developed when appropriate, of local completions can be used to develop a current view of the health of the promise, modifying priorities if necessary.

I have to dig a bit more into some of the specifics, but in the XP flavor of agile methodologies, I understand there to be something known as a "release plan," which I have to assume contains the overarching direction and "big picture" of the real effort -- the cumulative effect/deliverable of the individual pieces of "working code" that together serve to provide some real, non-trivial, meaningful, bottom-line business result. This release plan is the real project, and as such, is the domain of the project manager, while developers and their techincal managers focus on performing tasks, and on appropriate use of their time within tasks. (I do have to give a nod to the agile folks for insisting on task (although not necessarily project) dedication of resources in what we in the critical chain gang refer to as "single-tasking," as a model for effective resource utilization. Again, we're more in line than with common practice of traditional PM.)
"Frank suggests a strong argument in this direction by pointing out that the things we most often try to predict are not directly relevant to what is at stake: "Software tasks, appropriately managed via agile processes and organizations, almost never deliver the actual end result of the effort. They deliver supportive components of business processes or products that require coordination with non-software components."Most of the time, these non-software components are human components, in fact, and decidedly nonlinear and difficult to "predict" in the sense of anticipating future states in any detail."
Interesting, I thought software folks looked upon things like roll-out and implementation of business processes, training of users, preparation of marketing materials and events, installation into customer sites, etc., as the trivially simple things that could be left to traditional PM approaches.


I guess, as in all things, it's a matter of perspective.

posted by Frank - Permanent Link - |

The Xpertweb Talent Co-op -- Interrupting the current thread on project management, this is an intriguing model for today's "free agent" economy; a service connecting customers to "experts," developed as an "open source co-op." It seems to be a take-off on the B2B supply systems that arose during the dot-com bubble, but focusing on the exchange of human value.

posted by Frank - Permanent Link - |

Sunday, March 16, 2003

Provocative proposition
-- Agile methodologies are about task/work managment, not project management.

posted by Frank - Permanent Link - |

What is a project? -- A weblog I've stumbled across, Incipient.oO{}, has a couple good posts this weekend. One is on the idea of a Software Factory which includes an story that demonstrates the predictable slide of effective managers into cost-world thinking -- predictable unless they have been enlightened to its futility.

But the one that I really want to get into here is on the idea of a project. The author (I can't quite find his/her name in the weblog) takes on a set of common descriptors of projects, such as start and end dates, defined scope, specific end result (deliverables), etc., and responds saying...
"This fits the way we use "project" in software work, but only in the way an incompetently tailored suit might fit.

"Defined start date? Well, except for the "fuzzy front end", that zone before a project where people are negotiating for the go-ahead, funding, contractual arrangements, etc. Defined end date? Which date is that - the ship date, which is often missed by miles? Or is it the date when the stream of "bug reports" finally slows down to a trickle? The date when the system is finally put into production?"
The idea of an end date -- a targeted completion date -- is related to an event. While any of the events mentioned could be used, the one that makes the most sense -- the only one worth the effort to manage -- is the "ringing of the cash register," from either the delivery of products to paying customers or from the accrual of real bottom line benefit to the owning organization. While managing the software aspect of such efforts may be a critical portion, and worth considerable focus, it is almost always only part of the project.
"There is also an interesting tension between what seems to be an Agile principle, that "projects" must be sustainable, or the XP notion that maintenance and development are indistinguishable; and the above start-stop definition of "project"."
I have similar disconnects with the discussion of projects in "agile" software environments. While the Incipient writer and others of the agile persuasion bemoan the lack of ability of traditional project management methods (often combined with traditional cost-world thinking) to deliver on promises, what they tend to talk about is a lot more related to the management of tasks and detail work than the necessary aspect of delivering against promises. I've still got to incubate on this some more, but I get the feeling that as a reaction to tradtional PM's erroneous attempts to try to micromange details and tasks and dates rather than the deal with the uncertainties, the dynamics of the interdependencies, the agilistas seem to be saying "don't bother with promises or predictions; just let us get to work on delivering value bit by bit."

While I'd be the last one to question the rapid delivery of value as a laudable objective, I do reject the notion that planning and predictions are a waste of time, effort, and energy. Businesses (and business value) rely not only on speed, but on reliability of the delivery of valuable functions and products. Software, the core and focus of most agile theory, is often said to be a special case, and while, to some degree, there are special issues associated with its management, it does not live in a vacuum. Software tasks, appropriately managed via agile processes and organizations, almost never deliver the actual end result of the effort. They deliver supportive components of business processes or products that require coordination with non-software components. The use of functionality or scope as variables may, in some case, be necessary, but the idea of a project as something with real business value at its end, requires the pre-identification of the pieces that must be striven for in the effort.

Like I said, I still need some incubation on this subject, as this rambling rant attests, but there are ways of planning, predicting, and promising...The Incipient entry closes with something with which I can agree.
"To me, "project" in the sense I want to use it, e.g. for software projects, is all about an invented future. A prediction we make come true."
But to predict implies targets for scope and schedule for it to mesh with the reason it exists. And to manage that prediction effectively, allowing for modification along the way if necessary, uncertainty of effort, and the fact that Murphy's Law has not yet been repealed, allows for neither traditional rigid command-and-control practices nor ignoring the need to coordinate efforts and plans, but can be addressed with planning and control processes that are robust and flexible enough to manage with confidence (or at least within confidence levels) in an uncertain environment.

posted by Frank - Permanent Link - |

Saturday, March 15, 2003

"A customer keeps asking when we'll deliver..."
-- Enough said for a weekend entry.

posted by Frank - Permanent Link - |

Thursday, March 13, 2003

If Project Management is the answer, what's the question? -- On Wednesday night, I had the pleasure to talk to a Project Management Institute gathering in Harrisburg, PA. I gave my usual talk on Critical Chain-based multi-project management, based on the addressing the need for processes and policies to prevent the prevalent practice of multi-tasking resources across project tasks. But this time around, I tossed in an additional spin on the subject. One that I sensed was well-received by this seasoned audience.

One of my basic beliefs about project management is that it's first and foremost about promises -- making reasonable promises and keeping them. As I've written elsewhere, effective project management is about turning significantly uncertain efforts into reasonably certain outcomes. That's the outcome. That's the "why" associated with project management. But the question that I had in mind with this new spin was more related to "how?"

If project management is the answer, what's the question? My contention is that it's "What should I be working on?"

Since most of the effort associated with making projects happen is in their execution, it makes sense to me that a key role of project management is to provide resources appropriate information so that they use their time for best benefit for the organization. A portfolio of projects needs to be based on and subordinated to the needs of the organization. Projects need to be subordinated to the objectives of that portfolio or program. And resources assigned to project tasks need to subordinate their actions to the needs of the projects. Project management is the thread that ties these layers of needs together. And whether we're talking about the portfolio, project, or task level, "what we work on" is key to its success.

This question, "What should I be working on?," is related to the idea of priority. The roots of the wasteful practice of multi-tasking are found in a combination of too many things in one's in-box and a lack of clear priority about which of those things one should be concentrating on. Based on this view, the first role of project management is to define and limit the launch and assignment of work to that necessary to the needs of the project, as well as to the capability and capacity of the resources expected to deliver it. The second key role is to provide guidance on priority of the use of one's time and attention when two or more tasks contend for the attention of a resource.

Project managers should not get into the details of how resources work within tasks, but should instead maintain focus on what they work on. If project managers (and, for that matter, managers in general) focus on the question "What should I be working on?" by limiting the opportunity to multi-task, and providing clear and rational priorities when it might happen, more projects will get done, faster.

posted by Frank - Permanent Link - |

Monday, March 10, 2003

Throughput Accounting, Illustrated -- Yet another gem from Joe Ely (This is getting to be a habit.)...
"Each of us has some throughput for our activities. It can be estimated either in dollar terms or unit terms. It can be viewed for an entire plant or one individual. I'm convinced understanding it leads to better decisions. Lean Systems are most correctly driven by looking at the costs of flow.

"I encourage you to think about throughput in your world today. Try to calculate what the flow per hour or day might be. What limits it? What might increase it? It can radically modify your decisions...."
The lead-in to this excerpt is a review of weekend activity and a comparison of apparent management decisions made at a Jiffy Lube and a carwash, to telling effect. Another way of looking at the thought process involved is that to achieve maximum bottom line is to focus on the ability to deliver the top line -- to maximize the flow of "goal units" through the system.

posted by Frank - Permanent Link - |

Saturday, March 08, 2003

Lead Softly, but Carry a Big Baton -- More on musical management metaphors, this one from Fast Company...
"A leader is someone who commits to what hasn't happened yet...Don't blame the orchestra...Give people permission to be their best."
Play on, and on, and on!

(I guess I'm feeling better, and had more energy today than I thought. -- Play on!)

posted by Frank - Permanent Link - |

World of Ends -- (Warning: Not a typical Focused Performance blog entry.) If you're reading this, you're interested in communication about issues of management and leadership. If you're reading this, you're reading it on the Internet. If you spend any amount of time on the Net, it's worth a bit of understanding about the media. This link goes to a recent essay by a couple very influential netizens, known as part of the team responsible for the 95 theses that make up 1999's Cluetrain Manifesto...
The Nutshell
1. The Internet isn't complicated
2. The Internet isn't a thing. It's an agreement.
3. The Internet is stupid.
4. Adding value to the Internet lowers its value.
5. All the Internet's value grows on its edges.
6. Money moves to the suburbs.
7. The end of the world? Nah, the world of ends.
8. The Internet's three virtues:
a. No one owns it
b. Everyone can use it
c. Anyone can improve it
9. If the Internet is so simple, why have so many been so boneheaded about it?
10. Some mistakes we can stop making already
and embedded within the details is..."All we need to do is pay attention to what the Internet really is. It's not hard. The Net isn't rocket science. It isn't even 6th grade science fair, when you get right down to it. We can end the tragedy of Repetitive Mistake Syndrome in our lifetimes and save a few trillion dollars worth of dumb decisions if we can just remember one simple fact: the Net is a world of ends. You're at one end, and everybody and everything else are at the other ends.Sure, thats a feel-good statement about everyone having value on the Net, etc. But its also the basic rock-solid fact about the Net's technical architecture. And the Internets value is founded in its technical architecture. Fortunately, the true nature of Internet isnt hard to understand. In fact, just a fistful of statements stands between Repetitive Mistake Syndrome and Enlightenment ..."
There's something about NEA -- No one owns it, Everyone can use it, and Anyone can improve it -- that speaks to me very loudly. It's that kind of thinking that can and should be applied to the use and management of all kinds of human-based systems, even if they are, technically, owned by someone. If that could be translated beyond the Net, then maybe some real meaningful avoidance of the "Repetitive Mistake Syndrome" can be brought about.

posted by Frank - Permanent Link - |

Concidence -- After a few days of an ugly stomach flu, I've got just enough energy to pass along this...
"An event that happens to but one in a billion people in a day happens 2000 times a year. A day when nothing weird happened would actually be the weirdest day of all."
-- John Allen Paulos (mathematician)
Hence, the need for buffers and robust systems. What appears to be an effect of Murphy's Law may simply be an effect of getting pulled over and ticketed for a violation of the law of large numbers. But then of course, right now, I may be in no position to effectively judge weirdness.

posted by Frank - Permanent Link - |

Wednesday, March 05, 2003

SAP Expands Small-Business Push -- From CNET News.Com...
"Business software maker SAP expanded an initiative to target small and medium-size businesses Tuesday with five new software packages and plans for at least 20 more by the end of the year...SAP also offers software for companies with as few as 10 employees with a product called Business One, which just recently became available in the United States.
My first (admittedly knee-jerk) reaction is "uh-oh."

Then I got wondering whether the relationship that Eli Goldratt (of The Goal fame) has tried to develop with ERP firms has had any beneficial influence yet on the design of such systems and the processes they are supposed to support. If so, maybe this effort isn't the time- and energy-sink I fear.

posted by Frank - Permanent Link - |

Tuesday, March 04, 2003

Project Management as Journalism -- From Phil Wolff (via Fabio Caballero)...
"You heard of storytelling in project management. Let's refine the idea. PM as journalism..."
Tell me a story.

And if you haven't "heard of storytelling in project management," check this out, from Hal.

posted by Frank - Permanent Link - |

Start a Journal -- From Managing Product Development, a weblog by Johanna Rothman that Hal put me onto yesterday.
"if you're not yet keeping a journal or log, consider it. Write down your decisions and why you chose to make them. Write down your problems or defects. See if you can discover the root cause of the problem. After a few months, you'll know more about how you think and act at work -- which, for me, is a Good Thing."
As it is for me. In addition to this weblog, which is constitutes my shared learning journal, I also document for myself the variety of conflicts (clouds) and concerns (NBRs) encountered in day-to-day activity.

posted by Frank - Permanent Link - |

Something to ponder from Thought of the Day --

"Intellectual "work" is misnamed; it is a pleasure, a dissipation, and is its own highest reward." -- Mark Twain

posted by Frank - Permanent Link - |

Monday, March 03, 2003

New Book -- The Agile Manager's New Work -- I've finally gotten around to start reading the pre-publication web preview of this new book by David Anderson of Sitting in the mall waiting for my wife yesterday, once I got past an unusual opening 10 pages, I couldn't tear myself from the first three chapters...
Managing Accounting for Systems
[T, I, and OE -- I told you the kick off was unusal]

Theories for Agile Management
[A nice comparison and synthesis of TOC, JIT, Quality, Lean, TPS, Six Sigma in terms of software development]

Constraints in Software Production
[Now we're talkin']
One of the things I think I'm seeing in Davids' book is a distinction between "agile" work methodologies and practices and project management that can wrap around them to make promises...a distinction that I've come to myself. The things that fall into the agile approach are about work/task management for a certain type of work, and don't really meaningfully address the promise-making and promise-keeping aspects inherent to project management. Where I think David is going matches my belief that the uncertainty-embracing nature of the TOC/Critical Chain-based approach to project management makes an effective wrapper for work performed "with agility." We'll see if I'm right as I get deeper into the book.

Since this week kicks off a series of repeats of CSIs, Laws and Orders, ST:Enterprise, West Wing, Andromeda, and The Agency, leaving only 24, Survivor, Cook's Tour and Mr. Sterling with new episodes on the tube (which I'll let my VCR handle), there's a darn good chance I'm going to get through a lot more of this book, and give David some feedback and encouragement on his discussion list. (The book has been put out chapter by chapter in pdf (Acrobat) format.)

posted by Frank - Permanent Link - |

Sunday, March 02, 2003

If you've got nothing better to do... I've been drafted as a last minute speaker at the Harrisburg, Pennsylvania chapter of PMI (Proejct Management Institute). I'll be out there the evening of March 12, but as of yet, I don't have details on time and place. If you're in the area, and you're interested in Multi-Project Management, watch this space (or maybe this space, although I can't vouch for them) for those details.

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