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.

Wednesday, April 30, 2003

What were those boxes and arrows all about? -- In a comment, Joe Ely asked me to expand on Saturday's posting -- the one with the boxes and arrows. All righty, then...

As I mentioned in the post itself, it came out of a partial interpretation of Mitch Ratcliffe's essay on Invisible Dogma. As mentioned in my original text response, the idea of unverbalized paradigms is common to the analytical approach to problem solving known as the Theory of Constraints Thinking Processes. I started "thinking" about the existence of invisible dogma and its implications. The graphic depicts possible cause-and-effect relationships (the arrows) between the various situations described by the boxes. The little ellipses through which some sets of arrows pass through imply an "and" relationship. For example, if I have a sense of "doing the best I can," and if I attribute success to certain skills and actions, and if I suffer from unexpected setbacks, then I would likely blame external factors.

What you actually see there is a very rough fragment of a Current Reality Tree (CRT) related to the subject. To make it less "rough," the boxes would have full sentences, and there would probably be more boxes, fleshing out additional boxes (so far unverbalized) assumptions, and ellipses that would make the cause-and-effect logic "air-tight." A full CRT would also have a set of UnDesirable Effects (UDEs) that would reflect symptoms of a problematic system. It would also have a more formal base, that expresses a conflict or dilemma that can be seen as a perpetuating core (root cause) problem for the whole dysfunctional system.

But even without the rigor of a nice "dry" CRT (as opposed to one, like this, held together with logical "spit"), I think the logic holds up good enough as a little exploration of a piece of the invisible dogma dynamic. Maybe someday, I'll get around to digging into it deeper, particularly to develop an understanding of the conflict/dilemma that perpetuates invisible dogma. For certain domains, like production managment, project management, marketing, and others, the specific core conflicts and their unstated assumptions are well understood and can be exposed to organizations that suffer from them. But the idea of a general theory of the perpetuation of the assumptions/dogma is intriguing.

posted by Frank - Permanent Link - |

Saturday, April 26, 2003

Invisible Dogma -- Visible? -- Riffing off a previous post of 3 days ago, and Mitch Ratcliffe's original essay...

(Start down here, with the dogmatic assumptions, work your way up the arrows...and back.)

posted by Frank - Permanent Link - |

Friday, April 25, 2003

Quick Quotes --
"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."
-- Howard Aiken, Computer Scientist

"Any system which depends on human reliability is unreliable"
-- Roger L. Bauer, Safety and Health for Engineers
More quotes start here.

posted by Frank - Permanent Link - |

Thursday, April 24, 2003

You can do anything - but not everything. -- "Much of the stress that people feel doesn't come from having too much to do. It comes from not finishing what they've started." -- David Allen, in a Fast Company article and interview.

posted by Frank - Permanent Link - |

Wednesday, April 23, 2003

Invisible Dogma -- Perpetuating Paradigms -- When you have time to sit down with a longer article, check out Mitch's essay on why, the more things change, they stay the same; that is, the more things change, the more we are often disappointed in the effects of that change. Some snippets...
"...Herein lies the importance of the invisible dogma: If a bias changes the performance of a tool and the tool will change the performance of a group of people, then we, managers, need to be very conscientious about the choices we make with technology..."

"...The very act of defining an organization requires managers invent a bit of dogma, a dollop of determinism in an otherwise chaotic environment -- after all, we can't be in the business of doing everything. A deterministic system is purposeful and supports goal setting. However, it that system eliminates the organization's ability to make choices in the future it writes failure into the DNA of the organization..."

"...The scientific method, which demands rigorous self examination by scientists of their data, their analytical choices and the final results, is the model for abolishing -- or, at least, substantially reducing -- built-in biases and limitations that can have a negative impact on the groups using technology for learning or management. It takes practice and is a practice that cannot be carried out by a corporate librarian or even a chief technology officer working on their own..."

"...Invisible dogmas -- unstudied and facile management fads or simple faith in a particular way of doing business imposed at some stage in an organization's life -- are akin to the religious fervor that laid civilization low in the early fifth century. Rigorous thinking was replaced by faith reinforced by dogma, which became unquestioned truth, very much like the company that, when asked why it does something one way and not another, responds "Because that's the way we've always done it."..."

"...Simply put, the source of dogmas is our own laziness about addressing systemic issues in our organizations and in recording the reasons we do things within a company. We opt, for instance, for "collaboration" software to make people collaborate instead of teaching them to work together respectfully and constructively. We fail to appreciate how these tools change the requirements when hiring new employees, and often blame the employees when they fail to thrive in the stunted learning environments we've created. If management wants to take credit for success, the institutionalization of critical thinking about our choices of information tools is absolutely essential to the role of a manager in the information age..."
Good stuff. (And a tip o' the hat to Doc for pointing me to that last critical paragraph.)

I've still got to digest the whole piece more for the full impact (and look forward to follow-ups on it), but a lot of what Mitch is saying feels like it's in synch with the TOC (Theory of Constraints) notion of the holistic nature of organizations and the need to manage them as such. Regarding his focus on the relationship of technology to learning organizations, the message that Eli Goldratt points out in his most recent book about technology and management, Necessary But Not Sufficient, is simlar. It's the paradigms (invisible dogma), policies (visible dogma or litany), and practices or processes (decisions and behaviors supported, and more and more institutionalized, by technology), IN THAT ORDER, that will define what an organization accomplishes in terms of fulfilling its purpose or goal. Technology must be subordinate to appropriate processes, which are, in the end, rationalized through the view of the current dogma. If it is understood -- if that dogma is made visible -- then there is the basis for real improvement in terms of achieving more "goal stuff." If it remains invisible, then a critical link in the design of the value chain is missing. Technology may be necessary today, but it surely isn't sufficient to assure organizational learning, growth, sustainability, or success.

In my world, the "scientific method" found embedded in the TOC Thinking Processes (a set of logical tools for analysis and communication that encourage scrutiny and feedback) is a way to make the invisible visible. And the common sense (to me at least) starting point of the core concept of the system's constraint serves as the most effective focal point for management attention and application of technology, or, for that matter, any effort aimed at real systemic improvement.

posted by Frank - Permanent Link - |

Examining Just-in-Time and Theory of Constraints -- From Lean Directions, SME's "e-newsletter of lean manufacturing."
"The TOC model of drum-buffer-rope would be used to create the operating system for manufacturing. Application of JIT and other lean tools would increase the throughput velocity of the DBR model."
Yet another short piece pointing out the same thing Joe said about improvement in our recent series..."TOC tells you where, Lean [or in this case, JIT] tells you how." Come to think of it, that's the same message I've tried to get across about Six Sigma as well.

posted by Frank - Permanent Link - |

Baseline - The Project Management Center -- A new (to me) Ziff-Davis web and paper magazine on project management. I've only had a chance to skim it, but it seems to be primarily focused on IT projects. Joel Spolsky (who brought my attention to it) has taken a closer look and likes what he sees. Comparing how Baseline and InformationWeek cover the same story...
"While the InformationWeek article is just a poor rewrite of bland warmed-over press releases and vague generalizations, the Baseline article is detailed, interesting, and specific. For example Baseline noticed that Delta's new information system crashed for two hours at the worst time possible: when I was in New Orleans trying to reschedule my flight home during last month's blizzard. InformationWeek didn't mention the outage. In fact the whole Baseline article looks like it was written by an investigative journalist. It's about time the industry press got its act together."
I've got it bookmarked, and will probably check it out some more. You might see some links to its articles here in the future.

posted by Frank - Permanent Link - |

Tuesday, April 22, 2003

Reversing the Definition Game -- Dale Emery raises some interesting questions...
"What are we trying to communicate? Meanings. Not words. Meanings. Our words matter only to the extent that they convey our meanings. Meaning is primary; words are secondary. If meanings are more important than words, why do we play The Definition Game the way we do? Why do we hold the word fixed and try to assign it a meaning? Why not hold the meanings fixed, and assign words to them?"
Meanings:Words = Ends:Means = Objectives:Solutions = ?:?

Some food for thought.

posted by Frank - Permanent Link - |

Personal Productivity -- An Excuse? -- In Programmer Productivity, Laurent calls to question an oft-thrown around "postulate" that suggests that some programmers are 20 (or 10, or whatever) times more productive than others. His unease is related to issues of how "productivity" is measured, whether there is a path that a "1" might take to become a "20," and the difficulties of defining a group by the extremes of its range (which is no better than defining it only by it's mean, median, or mode). A couple things come to mind.

First, I'm reminded that, in providing implementation training for CCPM, we discuss, as one of the sources of variation and uncertainty, the range of resource skill level that might be encountered in a project. After all, if you plan to use Sue Superstar, and Anna Average shows up six months later when the task is ready for work (or if the superstar wins the lottery or gets hired away by the competition), you need to be able to deal with the difference in keeping project promises (one use for range estimates and their derivative buffers in CCPM).

Second, as an example of the existence of entropy, there are often pressures on the perceived superstar that come from everyone clamoring for his/her time on a variety of projects. If this results in split attention or multitasking or muddy priorities, superstardom can quickly become a fleeting status. (hmmm...That could partially explain what might be seen as the low incidence of high productivity levels in a group.)

Finally, one of the pointers in Laurent's piece aimed at a discussion list thread on the topic, in which Dale Emery points out that...
"The 10x in Peopleware is about people across the industry. DeMarco and Lister say, "Two people from the same organization tend to perform alike." (Peopleware 2nd ed, p 48). I don't think they measured the productivity range of people within organizations."
This may be a key to the conumdrum. After all, the system has more to do with performance than the individual.

One of Deming's points was that it is managerial laziness to blame people or their individual variation for performance problems, and that instead, attention should be focused on the system in which they work. Along the same lines, Goldratt is often heard to say "Tell me how you'll measure me, and I'll tell you how I'll behave." And what is performance but the results of behavior in relationship to a goal.

It's my suspicion that while there might be some minor contribution of technical capability to the question of differences in productivity, the vast majority of that difference is in how the people are used -- what sort of paradigms, policies, and practices drive their performance. It's clear from the results encountered in CCPM implementations as well as from what I read of effective agile/extreme/scrum implementations that a couple simple changes in work rules and expected/enforced work practices can have significant impact on project performance without wholesale changes, additions or upgrades in staff. If there's a claimed 10:1 or 20:1 ratio in personal performance, and if there's a significant noise factor coming from things outside personal control, I would question the validity of the postulate myself.

If people are inappropriately assigned from a technical standpoint (to keep them busy, or to tie them to a project), if plans and promises are based on either averages or extremes, if superstars are overworked while at the same time less experienced people are not given a chance to get experience -- all situations related to policy (formal or informal), practice, or project mis-management -- there should be little wonder that there are some people able to play the game better than others. I would bet that those identified as "10s" or "20s" are not all that better technically, but are better at fighting (or at least working in, through, or around) the dysfunctional systems within which they find themselves working.

posted by Frank - Permanent Link - |

Monday, April 21, 2003

US News adds RSS Feed --The US News and World Report is among a growing number of major media to add an RSS feed to their site (pointed out by David Fletcher). I mention this not to promote USNaWR (although they are a good read), but to promote to my readers the use of RSS feeds and NewsReaders to get things of interest from the web without the distraction and slower response inherent in old-fashioned browsing. It has transformed my use of the web. The link mentions a few Windows-based tools to take advantage of this technology. If you're a Mac person like myself, check out NetNewsWire.

posted by Frank - Permanent Link - |

I guess I'm a specialist in generalism -- Keying off a classic 1989 essay by Paul Saffo, which points out that "...we still prize the ability to recall specific information over the skill of making connections among seemingly unrelated information.", Azeem Azahr looks at the impact on those with that lesser prized skill...
"Being a generalists can be tough: generalism is something that isn't often valued by firms because of three pressures.
- Firm's processes are so specialised that they need to slot in someone, in Adam Smith's terms, to hammer the head of the pin. (Ironically, these processes are often designed by generalists).

- There are more specialists around because of the system that was created by increasing urban density, mass education and rigid command-and-control systems in organisations. This is a perfect substrate for growing specialists, not generalists.

- Generalists who can, in the words of Jed Bartlett, "see the whole board" can be threatening to specialist managers worried about limited fixed objectives." that's my problem. As a friend of mine often points out, it's not the links, but the linkages that make the system. You can't focus on both, so while the specialists focus on the links, we generalists can stand back and see, in the bigger, "holistic" picture, how they work together.


...or how/why they don't work together well.

posted by Frank - Permanent Link - |

Saving Customers From Themselves -- From Business Week Online, a column on what to do with clients who demand products unsuited to their needs. A bit of "Socratic Method" might be called for...
"Remember, customers might occasionally say things that are wrong, but using questions to lead them to see the errors of their thinking keeps the conversation rolling along, hopefully toward a signed purchase order."
I guess the customer is not always right, but there are things one can do to help them think about where they might be wrong.

posted by Frank - Permanent Link - |

(A non-TOC/PM posting for a change) Bloggers to be sighted near New Jersey, eating -- Like Britt...
I'm down for the dinner Doc and Halley are planning [in NYC] on May 1, my favorite date.
But in today's vernacular, is that "down for" or "down with?" (Be sure to see why Britt likes that date. It's a classic.)

posted by Frank - Permanent Link - |

Thursday, April 17, 2003

Down 'n Dirty with TOC and PM (Part 5) -- In this final set of postings in the series, Hal summarizes with a set of practices for day-to-day consideration, to each of which I'll add my two cents...

"Planning is a practice that runs throughout the life of the project" -- And planning, whether in the initial broad view, or in the later, just-in-time fleshing out of details, is a matter of understanding future dependencies - both necessary logical handoffs and "resource dependencies." For a task to be able to move ahead "as planned," it need both the inputs to the work and the necessary resources to do the work.

"Have an everyday focus on doing what you said you would do." -- If the first point of this summary translates to "plan the work," the second point is to "work the plan" to the extent that Murphy's Law and the limits of clairvoyance will allow. Be prepared to make course corrections to keep things moving, but do so with an eye on where you are going in the end, and how they might impact the work remaining to get there.

"Shield the constrained resources from variations in the release of work to them." -- In making project promises, pay special attention to the constraint as the critical chain of dependent tasks. Doing so will allow you to subordinate the "promise" of other work and its uncertainty in order to avoid having a critical task waiting for input from a non-critical task.

"Conduct the project anticipating that you and the team will learn." -- Just-In-Time planning of details is a way of taking advantage of this learning. And it is best done with a planning roadmap that identifies and lays out the major dependencies and dynamics of resources and work which is supports. Detailed planning can be best performed as needed if there is a framework that has the space (time) to drop in the details, and buffered flexibility to absorb learning (aka deviations from original expectations) that occur en route.

"Measure your planning reliability." -- Accept the inevitability of uncertainty and variation, make your promises with it in mind, and use your experience to address its sources, especially where it provides the biggest bang for the buck -- in the major constraints to your projects.

And unless he's significantly altered his draft version, Joe also summarizes with a few key points...

"A continuing conversation is based in daily workgroup meetings." -- Even when the "workgroup" for a task is a single resource, a bit of daily time to consider risks, requirements, and any adjustments to expectations of the future, and to communicate them as appropriate, is a prudent suggestion.

"Metrics must be made daily" -- Whether, as Joe is talking about, the metrics are about production in unit terms, or translated to terms of time remaining to completion of the effort at hand (the basis for task status reporting in a Critical Chain environment), more frequent is "more better" to highlight deviations from expectations.

"Assessments are the missing link." -- Not only must project systems collect learnings (good, bad, or neutral); mechanisms must be developed to take advantage of them in the future, so that better understanding of sources of uncertainty and variation can be applied to future promises.

"The goal is what drives the assessment." -- The goal is what should drive all actions and decisions. And the best way to understand what is blocking the goal is to understand the constraint(s) of the system that we are counting on to deliver it..

In this series, both Hal and Joe have emphasized resources (and the policies and paradigms we use to manage them) as constraints, and in the down and dirty dealings of day-to-day doings, that is what it boils down to. But my role in this series is to remind you that the reason we're doing the day-to-day work lies at the end of a string of days -- at the end of probably more than one chain of tasks -- and that while dealing with the current and immediate constraints, how we do so must take into consideration their import and impact on the larger constraints of the project as a whole.

I hope you've enjoyed this multi-blog series from the three of us. Feedback will be appreciated.

posted by Frank - Permanent Link - |

Wednesday, April 16, 2003

Down 'n Dirty with TOC and PM (Part 4) -- If the previous set of entries in this series was about dealing with excessive work waiting for resource attention, then this fourth set is about resources waiting for work, or similarly, tasks waiting for inputs. As such, Hal has introduced what might be considered "planning conversations," which he is putting forth as a solution for short-term, detail-level, even on-site planning performed weekly, and looking out for a month or so. The "conversation" is, as one should recognize, all about dependencies (handoffs of outputs that become inputs, and resources) and, if a structured conversation is desired, it might be worth focusing on the following questions....

1. Looking out as far as you are comfortable planning, ask "What's the last thing we need to do to deliver what is needed at that point?"

2. "Who needs to be involved in it?"

3. Turning to someone associated with the answer to number 2, "What inputs are needed to start [the task of number 1]?"

4. Once a list of inputs is developed, confirm they're enough; "Are these [from number 3] sufficient to do [the task of number 1]?" Add anything else that this triggers.

5. Pick one of the inputs and repeat the four questions.

6. Repeat for a single chain of inputs and tasks until the answer to number 3 is "Nothing...we can start it now."

7. Go back to any inputs that need stuff to be done and complete remaining chains of needed inputs and tasks to deliver them.

8. If you get the sense that any of the possible parallel work will result in resource contention, either from explicitly estimating and scheduling this plan, or from intuition, be prepared to determine whether any and which of the tasks should be assigned a sequential priority.

This approach to planning can be used, as suggested for fleshing out details of near term events. It is equally effective in planning the bigger picture of the whole project at its outset. In either case, its emphasis on inputs and outputs, preparations, and resources -- what is needed to do subsequent work -- helps to assure that key dependencies won't be missed, which can happen if planning is focused on individual components of the work at hand.

- - - -

An aside -- So far in this discussion, I've tried to stay away from promoting specific aspects of Critical Chain-based project management as solutions for what we're talking about, although readers familiar with the approach can probably read between a lot of my lines, I'm sure. But at this point, our general discussion of constraints in projects combined with the topic of assuring that inputs are ready when needed to keep value-adding work moving will force me to dip into CCPM for a bit.

Specifically, the concept of the Feeding Buffer is a scheduling mechanism to allow the project to "keep the critical critical." In the language of this series, this piece of a Critical Chain schedule allows the project's managers and team to focus on a consistent project constraint -- a consistent chain of dependent tasks that, if it is allow to move apace, will assure that the project is done in the minimum feasible amount of time. It does so by assessing the foreseeable uncertainty or variation in a non-critical chain of tasks, and by assuring that that chain starts early enough to protect the ability of the critical chain to keep moving without having to wait for inputs coming from the "non-critical" tasks. But this series was not supposed to be a Critical Chain tutorial. For more on the specifics of the Feeding Buffer's role, click here or here.

- - - -

posted by Frank - Permanent Link - |

Tuesday, April 15, 2003

Down 'n Dirty with TOC and PM (Part 3) -- In this little collaboration with Hal Macomber and Joe Ely, I wonder if I really have to say more about multi-tasking, the subject of a lot of my recent weblog postings, and I will admit, something that is a bit of an obsession with me. Maybe I should simply address Hal's closing admonition and question...

"Do not let them start one task before they finish the task they are working on. Sound crazy?"

...with a suggestion to carefully consider the implications of the following simple picture...

In which a simple "third of a headcount" assignment to three tasks of similar duration doubles (at least) the completion time of the first task, delays the completion of the second despite getting started on it earlier than if it waited for the first to complete, and does nothing to help the completion of the third. Actually, once the effect of context switching is added to the picture, all three tasks will be delayed even more before they can hand off their outputs so that those who use them as inputs can do their bit for the project.

Actually, in a lot of project situations, especially multi-project environments, but also in single projects, multi-tasking can be pointed to as the biggest waste of time and source of delaying constraints. In a multi-project environment, where resources are shared across a number of projects, the most common source of multi-tasking is an uncontrolled launch of work into the system, and as Hal suggests, the desire to keep everybody happy.

In individual projects, however, we come back to the discussion of dependent tasks I introduced in the first day of this series. Most people, when laying out what is involved in a project, will draw a network of dependencies that link tasks by the hand-offs -- the outputs of predecessors that are inputs for successor tasks. In order to assure that the promise of a project is not erroneously made with "resources in contention," setting up pressure to multi-task and exacerbating the inability to deliver on that promise, the identified constraint of the project -- the critical chain of dependent tasks leading to the project goal -- must include both hand-off dependencies and resource dependencies.

On the day-to-day level, it's important to remember not to pressure your resources to split their focus, and instead, provide as clear a set of priorities as possible for them, so they don't have to come back and ask "What DON'T you want me to work on?" After all, one of the most important questions that is answered by effective management in general, and project management specifically, is "What should I/we be working on?"

posted by Frank - Permanent Link - |

Monday, April 14, 2003

Down 'n Dirty with TOC and PM (Part 2) -- In the second installment from Hal Macomber in our series on the Theory of Constraints, he rounds out a taxonomy of constraints, adding "policies and paradigms" (Joe Ely, the third in our little trio, makes a nice point by referring to them as "traditions.") to the more obvious "physical" constraints of people, equipment, and space. Hal's discussion of the lift, or probably more accurately, the way the lift is used to get workers to the work on upper floors, as a possible contributing factor to the existence and persistence of project constraints makes a good point. While the obvious stuff will get watched and managed, it's possible for some otherwise "invisible" factor, if misused and mismanaged, to become, or at least contribute to the constraint on the project.

Here's another example, from a white collar, product development environment. A particular office might be subjected to a range of outsourcing and downsizing of "non-value-adding" functions that might include, let's say, the mail room. As a result, mail runs are cut from four per day to two. Sounds reasonable, at least until the chief designer (whose scarce skill and experience, combined with the fact that a lot of projects depend on her input, makes her the locus of a potential bottleneck or constraint for the firm's product development efforts), has to leave her workspace to trek down to the receiving dock to expedite delivery of a prototype for which she is waiting. This too common, penny-wise, pound-foolish mode of "management" has just moved a possibly significant company-wide constraint -- the ability of the organization to develop new products quickly and frequently -- to the shipping dock. Trust me, this is not exactly where I would suggest a company's competitive advantage be located.

How Hal's lift is managed could be a similar situation. The solutions that he suggests in this example, staggering crew starts or limiting lift usage to longer trips, are ways of "subordinating" policies in administrative or supporting aspects of the project. As a result, the real "value creators," and especially those that might be associated with the critical constraint of the project, can be fully "exploited," in the best TOC sense of the word.

Watch for part three from the three of us tomorrow, and again, please use our comment links if you are so moved.

posted by Frank - Permanent Link - |

Sunday, April 13, 2003

Down 'n Dirty with TOC and Project Management -- This is the first of a five-part series written in collaboration with Hal Macomber and Joe Ely (I guess it'll really be a 15-part series between the three of us.) on the idea of using the Theory of Constraints (TOC) to help address day-to-day issues, decisions, policies, and practices in project endeavors. You might want to check out Hal's contribution first, since I reference what he has to say about the nitty-gritty of getting stuff done, emphasizing the fact that TOC thinking has more to bring to the realm of projects than just Critical Chain Scheduling and Buffer Management. Being more of a "big picture" kind of guy, myself, I'm going to put some of what he is talking about in a larger context. The reader might want to bounce back and forth between Hal's, Joe's and my weblogs for the next few days to get both the micro and macro views of the story.

While, as Hal points out, "in simplest terms, [one can] think of a constraint as a restriction to flow...[as]...a bottleneck restricts the flow of liquid," one must remember that constraints in a project (or in any other system) exist in terms of a goal. If there is no sense of objective or goal, the idea of a constraint probably does not come into play. But we do projects to accomplish something, and the situation of being "bogged down" is meaningful because we feel that objective or goal is threatened.

If one thinks in terms of the goal of a project as the achievement of its objectives through the delivery of a collection of deliverables, then the primary constraint blocking those objectives is the longest set of dependent tasks required to be performed in their delivery. If that objective has some sort of "ringing cash register" associated with it, then the time associated with those dependent tasks can be considered a measure of the constraint's effect. After all, for many projects, if it can be delivered sooner, a resultant earlier ring of the cash register (or faster "flow" of "rings" in a multi-project environment) equals more "goal stuff." Time is, very often and in many ways, money.

In Hal's first piece, he introduces the idea of a crane as a possible constraint if it is managed in a way that "restricts the amount of work that can be performed in the day." At the day-to-day level, this is an example of a piece of the nature of systems and constraints that is worth expanding on -- that of the layers of "constraints" within the project. These layers might be pictured as...

Layer 1 - The project's "critical" chain of dependent tasks

 Layer 2 - Obstacles dealt with by individual tasks

  Layer 3 - Today's active task/obstacle

   Layer 4 - Resource availability for and effectiveness in the task

Within an individual project, as mentioned above, the primary constraint is the longest set of dependent tasks taking us from today to the end of the project, also often known as the "critical" tasks of the project. At a finer level of granularity, the obstacles that are dealt with by the individual tasks can be seen as components of that constraint. And at a particular point in time of the project's life, the ability for waiting tasks to be started is limited by its predecessors and by the resources doing the work. So on the day-to-day basis that we're talking about in this series, the way that currently active tasks (especially the current "critical" task in a formally planned and scheduled effort) are managed and worked can be seen as the immediate constraints to the completion of the project.

As Hal points out, physical resources in terms of people, space, and equipment can be seen as the finest degree of the constraint that needs to be managed appropriately. And as Joe points out, while TOC and constraint awareness can help direct one's attention to what to improve, "Lean methods" can contribute a lot to how one may carry that improvement (exploitation, subordination, and elevation) out, especially at that level of systemic detail.

I hope you find this week's multi-weblog experiment interesting and of value. Don't forget to read Hal and Joe. If any of what we write triggers a response for you, be sure to note them using the comment feature on any of our sites.

And c'mon back tomorrow for part 2.

posted by Frank - Permanent Link - |

Saturday, April 12, 2003

Alignment, Accountability, and Priorities -- Yet another from Dale Emery...
"First, if you want alignment, you will have to prioritize. In my experience, the biggest threat to alignment is that everything is top priority. The people who are doing the work can't do everything at once. So when you make everything top priority, people work to their own priorities. If you're lucky, their priorities will match what you most want. How lucky are you?"
Go read the rest. If Dale keeps this up, there's going to be another item in my blogroll.

posted by Frank - Permanent Link - |

Friday, April 11, 2003

Theory of Constraints Perspective for Projects
Blogging, Blogging and Blogging on Theory of Constraints

Hal Macomber writes...
I am embarking on a series of postings next week on the Theory of Constraints created by Dr. Eliyahu Goldratt. I've made minor postings before. This series will be geared for people who find themselves making choices on projects. I am aiming for something practical, concise, and in a form you will want to share with others.

I've decided not to do this alone. I started this weblog with the intention for me to learn about project management and how to speak about project management. In that spirit I will write each day to continue my learning. While I've been a proponent and student of the TOC for many years there are others who can speak more authoritatively about the subject than I. I've invited Frank Patrick to post along side of me, but to do so in his own weblog Frank Patrick's Focused Performance Business Blog.
[That's me. -- fp] Frank is an expert on conducting projects on a TOC basis.[That's me, going "aw shucks" and blushing. -- fp] He maintains a good website with a special section on projects. I am sharing the postings with him ahead of time so he can post at the same time I do. We will link to each other to make it easy on readers.

To make this a even more interesting, my friend Joe Ely, who writes the weblog Learning About Lean
[Readers here at Focused Performance will also recognize Joe's name. -- fp], will be joining in by posting alongside us on his weblog. His postings are often based on real experience pursuing a lean approach in a project-based fabrication setting. Joe has been using the TOC to provide focus to improving activities at his firm.

If you aren't subscribing to my weblog via Bloglet, then now's the time to do so. (See the subscription box in the left column.
[My Bloglet subscription form is on the right. ---->> -- fp]) This way you won't miss a posting. You will receive an email each day with the previous day's posting. For all of you who are subscribing, Frank's and Joe's weblog postings are available the same way. If you subscribe to their weblogs you'll get all postings in the same email message. All three postings neatly grouped together. (You can always unsubscribe at the end.)

We plan on having some fun with this. I hope you enjoy it.
Should be interesting.

posted by Frank - Permanent Link - |

Iraqi Information Minister Syndrome -- From "The Joy of Tech!"

The example is a CEO, but I've known similarly afflicted project managers -- and even worse, project "leaders" -- who fail to face reality. (Talk about a joy-killer.)

posted by Frank - Permanent Link - |

Joy, Value, and Meaning -- From a "conversation" with Dale Emery, more about joy as a day-to-day statw -- or maybe accomplishment.

Dale also has some things that should be said to managers that insist on playing Rob Newbold's old game mentioned yesterday.

posted by Frank - Permanent Link - |

Thursday, April 10, 2003

Old and New Games (Cutter 5) -- The final article in the Cutter IT Journal issue focusing on Critical Chain Project Management (CCPM) is entitled "Bridging the Reality Gap," and is written by Rob Newbold, CEO of ProChain Solutions (a provider of software and services supporting CCPM), and author of "Project Management in the Fast Lane." The basis of the article is a comparison of an "old game" and a "new game" for projects.

The gist of the "old game" is a management demand for an unrealistic project and the gyrations, risks, and "dishonesty" that accompany them. Newbold summarizes the "new rules" as...
1. Insist on honesty.
2. Need can't win over reality.
3. Account for risks.
4. All players should be asking "How can I help?"
5. Focus on business objectives.
6. Use the process on the game board. (A process for requesting, planning, assessing, promising, accepting, and "facing reality," delineated in the article.)
7. Hold people accountable for following the rules.
The connection that is drawn to CCPM is based on the explicit understanding of risk in terms of buffers, shorter project lead times when "safety" is aggregated and concentrated in buffers instead of spread among tasks, and other cultural aspects common to CCPM environments.

I'm sorely tempted to jump on Rob's bandwagon, as I agree with his connections, but I fear that he may be taking a few liberties with a comparison of CCPM with common, but not recommended processes associated with non-CCPM environments. While Critical Chain processes and outcomes will likely facilitate the "new game," most (maybe not all, but most) of what he proposes for the new game should be achievable with "good PM practice" of the non-CCPM flavor. Hopefully, this will not be translated by readers as "hype."

But on the other hand, the real problem may be that "good practice" is not really "common practice."

So why not consider a management philosophy that makes "good practice" and integrity easier to swallow?

posted by Frank - Permanent Link - |

Wednesday, April 09, 2003

Critical Chain Stories (Cutter 3, 4) -- The third and fourth articles in the Cutter IT Journal' special issue on Critical Chain Project Management (CCPM) are case studies by members of organizations who have implemented the approach, Douglas Brandt of Abbott Diagnostics Division (ADD) and Matt Gelbwaks of Segway (the high-tech scooter folks).

The first of these reads like a typical CCPM success story. At Abbott, CCPM was first piloted three years ago and is now the standard for all projects at all Diagnostic Division locations. Prior to then, the primary constraints faced at ADD were those common to most product development organizations...
" resources, poorly allocated resources, and conflicts between tasks for shared resources."
To address these presenting issues, the Cutter article reiterates the development of a PMO based on CCPM concepts, emphasizing the importance of dealing with the informal policies -- the culture -- associated with the previous approach to projects. The new culture, including a new respect for "planning, cross-functional cooperation, and the ability to say no when necessary" allowed the PMO to use CCPM to advance their mission of
"...ensuring ADD's leadership by getting quality products to market first [through] excellence in project management. [Brandt affirms that, at ADD, they] "believe that many of these improvements are due to employing the principles of the theory of constraints in our PM methodology."
All in all, a pretty picture of a typical CCPM success story, but not much new.

The Segway CCPM story, chronicled by Matt Gelbwaks, on the other hand, is the first that I've seen that publicly talks about the application of the approach in an "Agile Development" environment. Consistent with my own developing understanding, Gelbwaks points out the common and mutually supporting nature of agile efforts performed under a CCPM umbrella. Pointing out the differences in the approaches, primarily agile's usefulness when final, full details are unclear, but developed over time through "stories," versus CCPM's preference for clarity of dependent tasks throughout the project, Segway creatively combined the two.
"...we created a network of [dependent] stories rather than tasks. The value here is that it was possible to start with the ultimate story -- Mass produce a Segway HT on our assembly line -- and then back all the way up to the initial stories such as Complete proof of concept and Secure funding. Once this network existed, it was clear what the critical chain would be...All other chains of stories would be subjugated [subordinated?] to this one."
Segway came to understand that along the way in a project, one can think of consumption of buffers as symptoms of bottlenecks in the flow of value creation, and that that pinchpoint needs to be addressed to keep things moving. Combining the "network of stories" and the creation of "detail only for those tasks needed by the Critical Chain at the current point in time," appropriate attention is paid where needed.

As I read the article, I realized the serendipity of its message, because in a special series of weblog postings planned for next week, Hal Macomber and I will be discussing this idea of following what could be understood as the constraint of a project as it passes through the Critical Chain tasks and using the TOC focusing steps to manage it. That is exactly what Segway did in their 18 month project from design through production of their unique, innovative product.

posted by Frank - Permanent Link - |

Monday, April 07, 2003

The Art of Worldly Wisdom -- suggests, in chapter 151, that one...
"Think ahead: today for tomorrow -- even many days ahead. The best providence is to have hours of it. To those forewarned, there are no strokes of bad luck; no tight spots for those who are prepared. Don't save your reason for difficult situations; use it to anticipate them. Difficult points require mature rethinking. The pillow is a tongueless sibyl, and it is better to sleep on something than to lie awake when things are on top of you. Some act, and think later: this is to look for excuses rather than consequences. Others think neither before nor after. Your whole life should be a matter of thinking out your destination. Rethinking and foresight are a good way to live in advance.
   -- Balthasar Gracian (1601-1658); translation, Christopher Maurer
Gracian was a Spanish moralist, whose little book of aphorisms sits comfortably on my bookshelf along with Lao-tzu's Tao Te Ching, Tsunetomo's Hagakure: The Book of the Samurai, Sun Tzu's The Art of War, Miyamoto Musashi's A Book of Five Rings, and Dogbert's Top Secret Management Handbook, all of which are frequently browsed. (And to think that Hal said today that I sometimes link to strange things. Where'd he get that from?)

posted by Frank - Permanent Link - |

Ten Ways to Guarantee Project Failure -- From, yet another "ten ways to..." list. Allow me to suggest another...

11. If you do bother to plan your project, plan it and promise it as if it were the only thing going on in the organization. Don't let the possible need of resources by other efforts or other the existence of other business objectives sway you from a laser-like focus on your project and only your project. Be prepared to connive, cajole, and coerce technical managers into letting you hoard resources, using experienced, skilled people for grunt work so that other projects can't get their grimy paws on them. (More about project failure and multi-project impacts here.)

posted by Frank - Permanent Link - |

Sunday, April 06, 2003

Impatient with precise methods -- Here's a great example of the growing small world of weblogs. Perusing my blogroll, Creative Generalist point to this post by Alan Francis.

I resonate stongly with Alan's resonance with his posted quote from "An Introduction to General Systems Thinking." (He starts with "I've never seen myself so accurately summed up...") So I check out Alan's main blog page, and pick up on another post of interest on the "buzzword of the moment." (I'm waiting to see SixSigmAgiLean show up in print one of these days...hmmm, maybe I should trademark it.) Amused by that, I go back to Alan's page and check out who else he reads regularly, listed in his list of weblinks, and there I find most of my blogroll, including Creative Generalist, Esther, Hal, Johanna, and Laurent. And lo and behold, there, fifth in his alphabetical list is your's truly (don't click that last link...Alan really point to the page you're reading now. I'm going to have to check out the others he points to. (One of them, Keith Ray has an interesting-looking piece on requirements in XP, which seems to be in synch with something from these pages.)

This self-organizing system of community is starting to get a bit spooky. Now, if I could just leverage this growing network of like thinkers into a paying gig or two...


This post got my vain self (cue Carly Simon here) thinking about the silent, predominantly one-way network embodied in those who subscribe to this weblog via email. I'm up to 56 subscribers, and the growth is keeping me just in the top 100 weblogs served by

If any subscribers have their own blogs, or even just a basic webpage, let me know, and I'll set up links to them if you would like.

posted by Frank - Permanent Link - |

Getting Projects Out of Your System: A Critical Chain Primer (Cutter 2) -- This is a review of the second article in the recent Cutter IT Journal issue focusing on Critical Chain-based project management (CCPM). Disclaimers first. I personally know the author, Richard Zultner, as both a TOC student of mine and as a former colleague, so my expectations were high going into this article. He has worked in a wide range of software arenas, and is comfortable with iterative development methodologies and should be able to make a good case for CCPM to Cutter's software-centric audience. But it turns out the article is an adaptation of an earlier piece that I thought was good three years ago. And it remains a quite good intro to CCPM, covering in one piece similar ground to the introductory CCPM and multi-project management papers I did for the PMI back in '99. That said, I particularly like Richard's description of estimate-to-completion task status reporting as a "countdown." I'll have to remember to attribute it to him when I steal it.     ;-)

I've got only a couple concerns with the piece. First, as a rework of an older article, it retains some dated language about "a new and exciting conclusion;" OK for 2000, but maintaining the hype level a bit much for 2003. It also emphasizes the shorter project lead time benefit, that the previous Higgins article points out as a possible Achilles heel of CCPM promotion today. And given the audience -- an IT crowd -- Richard's description of a project as a system that "isn't finished until all its tasks are completed" might draw some ire from the agile/extreme/etc crowd. I wish Richard had connected CCPM as a PM envelope for modern software methodologies -- he can probably do that better than I'm managing in this weblog. I hope the few concerns I mention don't prevent readers from getting the core message.

posted by Frank - Permanent Link - |

Friday, April 04, 2003

File Under Agile, but Cross Reference Under Other PM Approaches As Well -- Damn...I just put down the Projects@Work magazine and planned to point folks to an article, but Hal beat me to it. The point that I was going to make is the same one that Hal makes. A lot of the more uncommon in PM, be it CCPM, or Agile, or simply doing "Good PM," is in response to the failure of common (non-recommended) practices that are often highlighted in Dilbert. It's all about behaviors, and setting up systems of management that drive the right behaviors for the project. Most are pretty universal, no matter what kind of lifecycle they live in.

posted by Frank - Permanent Link - |

Project Lifecycles -- Johanna Rothman has a nice summary of "types of lifecycles" for projects...
* Linear: Waterfall and waterfall with feedback
* Iterative: Spiral, where the whole product is up for grabs each time
* Incremental: Where you add to the product in pieces
* Agile: cycles (iterations) of chunks (increments): Add to the product in pieces, where each iteration you can deal with the whole product.
* Random: code and fix
She continues with some suggestions for uses of each, which I still have to absorb a bit. But I'm sensing uncommon sense in her conclusion...
"Once you've got your head wrapped around lifecycles, remember that different parts of the entire project can have different lifecycles. If you're doing an iterative lifecycle for development, the testers can still use an incremental lifecycle. It's harder to plan, but if it works, that's all that matters, right?"

posted by Frank - Permanent Link - |

RSS Feed Fixed -- I've been advised by a couple readers that my xml/rss feed was not working with either their news aggregators or their browsers. I just narrowed the issue down to the "bullets" I've used to introduce new topics. While I liked their look, if they are causing Windows news readers to choke, they've got to go. So they're gone. If you've given up on my feed in the past, you might want to try again. (A tip o' the hat to Esther Derby for helping me diagnose this.)

posted by Frank - Permanent Link - |

CCPM's Visibility Problem (Cutter 1) -- Last week, buried in a comment to a post, I briefly alluded to a recent Cutter IT Journal issue focusing on Critical Chain-based Project Management (CCPM). It's a $50 purchase, unless you're a client of or subscriber to Cutter, but out of deep interest and curiosity in something I decided not to contribute to, I sprang (sprung?) for a copy and have finally started to get around to seriously reading it. The first full article in the issue, by David Higgins, is entitled "CCPM's Visibility Problem." It's written from the point of view of someone interested but not involved in CCPM and the low level of visibility is has in the larger project management community. As a result of his exploration, Higgins concludes that...
"...the market for CCPM dried up virtually overnight in April 2000 -- and the answer to the riddle suddenly clicked into place: the economy. You'll recall that April 2000 was about the time when everyone finally realized that the tech bubble of the 1990s had burst and that the longest bull market in history was indeed turning into a bear. The adoption of CCPM, which had begun promisingly enough two or three years earlier, ground to an abrupt halt."
This makes sense to me, and matches my personal experience, to a point. But he explains this as due to the fact that...
"Since CCPM is primarily a technique to help organizations shorten development time, interest in the method quickly evaporated when corporate emphasis suddenly shifted from decreasing time to market to cutting costs. Not only did the marketplace stop spending so much on consulting and on implementing new concepts, it completely lost interest in a method that was principally about saving time, not dollars....Critical chain project management's scheduling philosophy was never about cutting costs; it was about cutting actual time to delivery and developing schedules that didn't slip. Unfortunately, CCPM's chief selling point of "reducing time" involves the one project variable that CFOs are least interested in decreasing right now."
Again, on the surface, and in the way that a lot of my fellow CCPM promoters promote the approach, this makes sense, but it is based on only a partial piece of the CCPM picture. If one focuses on the aspects of Critical Chain introduced in Goldratt's introductory book -- the idea of "50%" estimates, and the benefits of aggregating and concentrating "safety" in buffers, the emphasis on speed and reliability of promise of individual projects could be construed as the raison d'etre of the approach.

Although I think I could get defensive and make a case a strong relationship between "faster projects" and "cost reduction," and that cost reduction is only the flip side of the coin of delivering value faster, that's not my main response to the article. As I said, individual project speed and reliability is only part of the picture. Very few projects, especially in the realms of IT, R&D, product development, and other "knowledge work" areas, live in the world of the "single project." Rather, they are predominantly part of a portfolio, pipeline, or program of projects that are performed with, to one degree or another, shared resources. Cost control comes from getting the most value out of this limited set of resources, recognizing that productivity has both a numerator and denominator that need to be considered.

The CCPM body of knowledge is not limited to the management of single projects. It includes an approach to the management of project-based organizations that drives out the waste of doing unnecessary work, doing work too early that is then subject to rework or abandonment, and doing resource-(cost)-wasting things like multi-tasking. For most of the audience of Cutter, the CCPM-based multi-project management solution is where there is tremendous potential for productivity enhancement and cost control.

The value proposition of Critical Chain-based project management is multi-faceted. It is equal parts speed of flow of value through rapid project completions, reliability of promise keeping, and a significant cost control/productivity relationship for the resources needed to do what needs to be done. The sooner we in the CCPM community learn to market all these benefits effectively, the sooner the approach will shed its "visibility problem."

(Watch this space for a continued review of the other articles in the Cutter IT Journal issue.)

posted by Frank - Permanent Link - |

Wednesday, April 02, 2003

Double-Digit Growth in No-Growth Times -- A bit of respite from the recent project management theme, this Fast Company article should sound familiar to proponents of the Theory of Constraints approach to defining real value propositions...
"Slow growth does not have to last forever. We've detected a promising response to the growth crisis. It's being pioneered by a handful of companies and business units with spectacular track records...[that] share one exciting trait: They have managed to create impressive revenue and profit growth in no-growth or slow-growth markets.

"What's their secret? These companies have discovered a new
[? - fp] way to grow. They are focused on creating revenue, profits, and shareholder value by addressing the issues that surround their products rather than by simply improving the products themselves. They have shifted their approach from product innovation to demand innovation. At the same time, they are delivering these innovations by mobilizing assets that reflect their history and expertise: unique customer access, an installed base of products, a special window on the market. They focus on hidden assets that go beyond balance-sheet items such as factories, R&D labs, and real estate."
Sure sounds like the basis of the good old "Mafia offer," described in Goldratt's book It's Not Luck almost 10 years ago (and known in more politically correct circles as "unrefusable, implementable offers"); what I refer to as Market Focus Offer Development.

Combining a view into your customers' constraints and core conflicts and shaping the offering that wraps around your products to address constraint related problems is the way to help them see real solution-based value, and enhance their willingness to pay for it, hence "unrefusable." On the "implementable" side, recognizing that while a well-run organization is limited by a constraint that it understands inside-out, that also implies that it understands the "free" capabilities and capacities of it's non-constraint assets and processes. It's these non-constraints that define hidden assets that can be exploited to support innovative offers and resultant demand. This combination of "demand creation" and "demand fullfillment" are the two sides of a valuable constraint-based strategic coin.

posted by Frank - Permanent Link - |

A Thought on Valuable Creativity, courtesy of Creative Generalist --
"Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep."
   - Scott Adams, cartoonist
If one is to extend this to the "art" of project management (or even general management), clarity of objectives is what allows one to know what to keep, and for that matter, what to strive for in the first place.

posted by Frank - Permanent Link - |

Tuesday, April 01, 2003

Shooting Yourself in the Foot -- From Esther Derby, a good piece on the risks of depending on "actuals" to give meaningful information by which to plan and manage projects. A few quotes come to mind.
"Tell me how you'll measure me, and I'll tell you how I behave"
   - Eliyahu Goldratt

"Tell me how you'll measure me, and I'll tell what damn fool things I'll do to make the measurement look good."
   - Tony Rizzo

"No amount of sophistication is going to allay the fact that all your knowledge is about the past and all your decisions are about the future."
   - Ian E. Wilson
Actuals are water under the bridge. What matters is what remains, and whether the time and money that remain are sufficient for the work that remains and its uncertainty. And when talking about internally resourced projects like most IT shops, funny money costs associated with "actual" resource or PM hours are the last thing I'd worry about in trying to manage a project. Focus on the dependencies, the time, and the behaviors, and the money will be what it needs to be.

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