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.

Sunday, February 29, 2004

Leap Year Linkage -- So much interesting stuff, so little time for thoughtful commentary. At least there's an extra day this year to look over these links...
- Why Budgeting Kills Your Company
- Rx for Painless Change: How to Avoid Repetitive Change Syndrome
- When Enough is Not Enough
- Goldratt's Goal: Just keep it simple, India, Inc.
- It Was the Best of Practices, It Was the Worst of Practices
- Case Study: Critical Chain at NASA
- Thinking Managers: de Bono and Heller
- Thick as a (Campaign) Plank: The IT Outsourcing Crisis
- Making Marketing Matter
- Setting Requirements Priorities
- Maps vs Directions
- Strategies for Stability
- Prospect, Then Pitch
- Project management vs. managing innovation projects
- Unconscious Choices
- Mad Belt Disease: Over-Emphasis on Certification
- Ten Steps for Cleaning Up Information Pollution
- Solving the real productivity crisis
- The coming information collapse?
- Lean Manufacturing: The 3rd Generation
- What Keep Executives Awake at Night?
- Why CEOs Fail
- Iterative vs. Waterfall Software Development: Why don't companies get it?
- Risk: Living Dangerously
- Beyond the panel discussion
And interesting-looking stuff from
- User Stories Applied: For Agile Software Development
- The Five Temptations of a CEO
- Making Strategy: Learning by Doing
- Having Trouble with Your Strategy? Then Map It
- Dilbert: The Complete Series (1999)
- The Office: The Complete First Series (2003)
- Software by Numbers: Low-Risk, High-Return Development
And, in an attempt to expand my "echo chamber," some new weblogs that I've come across recently and will likely be revisiting, pointing to, and conversing with...
- Humans and Computing - Michael Hamman
- Knowledge Notes - Judith Meskill
- BusinessPundit - Rob ?
- Projectified - Brian Kennemer
- Project, Process & Business Improvement - A. J. Vasaris
- Degrees of Project Management - Christian Connett
- Fresh Inc. - from Inc. Magazine
I'm off to Canada this week for a short gig (and a presentation at the Regina, Saskatchewan chapter of PMI), so expect light blogging from me for a bit. This list o'links should keep you busy enough 'til I get back. Enjoy.

posted by Frank - Permanent Link - |

Thursday, February 26, 2004

Remade in America -- This article from Forbes is, on the surface, a nice story about the common sense of (at least sometimes) bringing off-shored manufacturing back to the US. But buried in the end of this story about a lighting product are some interesting points...
...He solicited five bids for the work. A Canon factory in Newport News, Va. that makes laser printers and cartridges, among other things, won. Within three months LightWedge was back in production...
What the heck is a laser printer plant doing getting into the lighting business?

It's doing something very smart. I'll bet that there's probably capacity available at the Canon facility to absorb most of the assembly and fabrication effort involved. Canon is not limiting the use of its capacity to it's old product line. If my suspicions are right, it's selling its capacity and capability for precision assembly (a classic tactic in TOC strategy when faced with external constraints), creating a top line at the plant that, I suspect, drops almost straight to the bottom line. While your typical American firm obsesses over the middle lines of costs when faced with blocked growth, this Canon facility apparently recognizes that if you creatively take care of the top line, the bottom line is easier to manage.
...It was a costly move: $140,000 in new tooling and $40,000 in dies still in Shanghai. Bennett also took a hit to the bottom line: Unit costs in the U.S. are 20% higher than in China. All worth it, says Bennett, adding that the plant is turning out "beautiful stuff." He is paying $8 apiece for reading lamps that retail (at Barnes & Noble) for $35. He's counting on netting $200,000 pretax on sales of nearly $2 million for 2003.
[Rant Mode On] Unit costs? Bottom line? Aaarrrrggghhh! There is no direct connection between unit costs and bottom lines. For that matter, there is no such thing as a unit cost!

Yes, there are purely variable material costs that translate revenues to "financial throughput" (T), aka contribution margin, but the costs of producing these lights are not limited to what is really non-variable "direct labor." The operating expenses (OE) associated with overhead and coordination (not to mention the volumes of quality, saleable product) all factor in to the translation from Revenue and Throughput to Net Profit (T-OE=NP). No matter what the "unit cost," if you ain't getting quality goods to sell, you ain't gonna make money. In such situations, "lower unit costs" are irrelevant.

American management's obsession with mythical "unit costs," distracting "activity costs," and all those "middle lines" between the top and the bottom only lead to inappropriate off-shoring and out-sourcing, failure to focus on what really matters -- protection and growth of the top line, and downsized (and wasted) investments and resources. Even the usually commonly sensible Forbes perpetuates these obsessions with such silly comments. [Rant Mode Off]

posted by Frank - Permanent Link - |

Are Bloglet Subscribers Receiving This Stuff? -- This note is going out to those readers who subscribe to this weblog via Bloglet. For some reason, I haven't been receiving my own email subscription to my stuff. Are you? If you are, drop me a note. If you're not getting the email you've subscribed, and if you're reading this on the web or via RSS/XML syndication (which is how you would be reading this message outside of email), let me know that as well.

posted by Frank - Permanent Link - |

Wednesday, February 25, 2004

Promises and Prescriptions
Part 8 - Combination Therapy
-- Each of the individual prescriptions in this article is worth considering. Driving out pressures to multi-task, striving for clarity of dependencies between pieces of the project, and continuous refinement of that clarity throughout the life of the project are all common sense aspects of effective project management. Taken separately, they have the ability to provide improvement in project speed and reliability. Combined in a formal methodology, they can form a coherent therapy for troubled organizations, whose old habits and superstitions are at the root of their problems and sometimes conflict with these recommended practices.

One such methodology is the approach known as Critical Chain Project Management (CCPM). The basic premise of a Critical Chain schedule is that task due dates are avoided and uncertainty is managed separately from the rest of the schedule. The safety that used to be wasted protecting task promises from task uncertainty is now aggregated and concentrated where it counts. Some of the safety removed from tasks and iterations becomes a buffer protecting not task promises, but project promises. In addition to providing protection, the consumption and replenishment of this buffer as the project progresses provide feedback control used to monitor the health of promises and to manage accordingly.

Similarly, for multi-project systems, the pressure to multi-task in a CCPM environment is minimized through basic constraint (aka bottleneck) management concepts, which boils down to launching projects no faster than one or two heavily used, limiting resources can deal with them.

Much of what I've presented may sound like a basic, common sense (some might say uncommon sense) view of some of the problems faced in software projects. In the end, projects are all about dependent and interdependent efforts, uncertainty every step of the way, and the attention of resources to their component tasks in pursuit of a goal. If those are the things that are important, those are the things that deserve focused attention and common sense management.

(This is the final weblog-based installment of an article published in the January, 2004 issue of Better Software. Even if you don't get the magazine, I recommend you check out their StickyMinds site (free registration required for basic access). They feature a weekly column that often goes beyond the software development domain and is usually well worth a read.)

Navigate this series: First Part -- Previous Part (7)


posted by Frank - Permanent Link - |

Risk Management: An On-going Process -- I've recently come across a weblog by one Brian Kennemer, called projectified (not a typo, it's not capitalized). Brian's primary emphasis is on the use of Microsoft's Project Server, but along the way, he offers some good advice on project management in general. One recent post on risk management in particular caught my attention for my inaugural linkage to his work...
Risk Management in all it's glory (collection, analysis, ranking, planning, etc) is something that should certainly happen before the project starts. It can be a strong part of the go/no-go decision that starts the project. However, it should also be part of a process that happens just prior to the start of each phase of the project if not a part of the weekly status meetings that occur in most project organizations. It is also something that is not the sole domain of the PM or the PMO. EVERYONE on the team should be in a risk management mode from the very start of the project right up to dreaded 'lessons learned' meeting after the project ends. They should be keeping their eyes open for things that might go wrong. Even if they seem remote: put them on the list!

Risk Management is not an event. It is a continuous process that should involve the whole team.
Brian's thoughts are right in line with my view of risk management. As I've mentioned in one of my papers written for PMI, if the role of Project Management is to assist in turning uncertain events and efforts into certain outcomes and promises, then the primary process associated with project management should be that of risk management. How other processes, such as scope, schedule, and spending management support risk management is therefore critical for successful project management and for maximizing the value of our project-based efforts.

I'm tempted to turn the usual hierarchy on its head and say that project management is a component of risk management rather than vice versa. That view can be clarified if one recognizes that from a strategic view, PM is merely a tool for dealing with the risk associated with an organization's meta-project -- its strategy. But getting back down into the trenches of projects, all of our processes and procedures for planning, prognosticating, and performing are about dealing with the risk inherent in the uncertainty of the future in any endeavor. As a result these processes need to be focused on the future and flexible enough to both accept the reality of risks and capitalize on the options of opportunities.

(Oh, and Brian...Maybe the reason "lessons learned" meetings are dreaded is that they are too often limited to being held "after the project ends.")

posted by Frank - Permanent Link - |

Tuesday, February 24, 2004

Promises and Prescriptions
Part 7 - Acknowledge the Unknown
-- Most people are reluctant to commit to delivering a project until they know if it is possible. But that is the nature of projects: we never really know at the start whether it's possible or not. But, However, the business still needs to make plans based on project delivery. The solution is to explicitly acknowledge and actively manage that uncertainty.

Develop plans, schedules, and promises with an open, explicit understanding of the uncertainty associated with the effort. Separate the probable uncertainty that leads you to want to cover your assumptions from the possibility that things will go well. (Include in this identified uncertainty not only ranges of task durations, but also ranges of iterations in those looping processes common to software development.) Estimate a range of identified work efforts from nervous but possible if the stars and planets align just right, to safely committable. Translate those ranges into a range of promises for the project as a whole.

If project management is the art and science of turning uncertain efforts into reasonably certain outcomes, then manage the uncertainty. Practice active risk management so that everyone involved can move those stars and planets, enabling the project to do the otherwise improbable.

Plan for the need to plan along the way. Planning and promising is not a one-time effort but an on-going process of assessment of the impact of reality. Use the previously prescribed notion of a "good enough" project range prediction with tasks that might not all be clear up front, accepting a considerable range of possibilities. Consider the idea of planning not details of work to deliver the specific task outcome, but rather the range of processes involved in the likely outcomes of discovery. Include in the plan tasks to refine those fuzzy future tasks, as well as support tasks to assure that necessary and sufficient information is made available to do so.

(Next -- The final installment - Putting it all together.)

Navigate this series: First Part -- Previous Part (6) -- Next/Final Part (8)

posted by Frank - Permanent Link - |

When Does a Project Start? -- Laurent offers a fable with a great moral...
"[...T]he things we do before we can start a project are part of that project, even when it's not officially started; sometimes the costs accrued to a project have killed it before it starts, maybe even before we know there is a project."
Go read the whole thing, although I have one complaint with Laurent's post - its unexplained title, "The Buridan Project". It sent me on a googled-enabled detour into the wonderful world of medieval (and other) philosophy and non-determinstic planning. Problem is, this week, I don't have time for all this extra knowledge (and don't have any real use for it, since I've already come in third on Jeopardy, partially due to a question for which I confused two other medieval characters). But now, at least, I have solace in the fact that I've now probably distracted others as well.

posted by Frank - Permanent Link - |

Website Housekeeping -- A while ago, I added the "Contact" option to the "Comment" function found at the bottom of each of these postings. The form-based contact page has been a long-standing component of my site, which, I found out yesterday, was broken by my ISP who knows when. If any of my readers have tried using the contact page for Focused Performance, I apologize for the appearance of ignoring you. It seems to have been fixed and is now working again -- I hope.

posted by Frank - Permanent Link - |

Monday, February 23, 2004

Promises and Prescriptions
Part 6 - Fear of Promising the Unknown
-- Between unexpected rework, distractions from other projects or emergencies, and the obvious uncertainties associated with endeavors of discovery, is it any wonder that project promises are made reluctantly or accompanied by a ream of disclaimers? Pressure for faster delivery from those who benefit from the project is met with pressure to assure that enough time is allowed to cover risks—both identified and unidentified. Too often, a relatively rational planning process devolves into negotiation in which no one is truly satisfied, but everyone agrees to do whatever it takes to make it happen.

Making project promises that everyone can live with is hard. Keeping promises that are the result of negotiations is even harder. The fear of promising something with many unknowns leads to all kinds of counter-productive behaviors, like high initial estimates offered with the expectation that they will be cut, and the cutting of reasonable estimates in the name of stretch goals.

Some individual pieces of uncertainty will be significant, especially in aspects of a project associated with problem solving and discovery. Putting together a plan, schedule, and promise for such an effort requires consideration of activities related to something we don't have clear requirements for. The dilemma is to choose between hunkering down over the crystal ball to try to find detailed requirements up front and getting started on the effort and allowing the requirements to emerge over the span of the effort. Neither of these approaches in and of itself is conducive to management's or the customer's need for reasonable predictability on the project outcome.

(Tips for dealing with uncertainty and unknown are next.)

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

posted by Frank - Permanent Link - |

On the Calendar - Regina, Saskatchewan PMI -- If you're reading this from up north, you might be interested in knowing that I'll be doing a presentation on Multi-Project Management at the Regina, Saskatchewan chapter of PMI on Tuesday, March 2. (Just as it's starting to thaw here in New Jersey, I'm off to single digit temperatures.)

posted by Frank - Permanent Link - |

Saturday, February 21, 2004

Increasing Manufacturing Jobs in an Election Year -- From the NY Times, In the New Economics: Fast-Food Factories? (go read the whole article before it disappears into the Times' for-$ archives)...
Is cooking a hamburger patty and inserting the meat, lettuce and ketchup inside a bun a manufacturing job, like assembling automobiles?

That question is posed in the new Economic Report of the President, a thick annual compendium of observations and statistics on the health of the United States economy.

[...] Counting jobs at McDonald's, Burger King and other fast-food enterprises alongside those at industrial companies like General Motors and Eastman Kodak might seem like a stretch, akin to classifying ketchup in school lunches as a vegetable, as was briefly the case in a 1981 federal regulatory proposal.

But the presidential report points out that the current system for classifying jobs 'is not straightforward.' The White House drew a box around the section so it would stand out among the 417 pages of statistics.

'When a fast-food restaurant sells a hamburger, for example, is it providing a 'service' or is it combining inputs to 'manufacture' a product?' the report asks.

[...] David Huether, chief economist for the National Association of Manufacturers, said he had heard that some economists wanted to count hamburger flipping as manufacturing, which he noted would produce statistics showing more jobs in what has been a declining sector of the economy.

'The question is: If you heat the hamburger up are you chemically transforming it?' Mr. Huether said.

His answer? No.
The mind boggles.

posted by Frank - Permanent Link - |

Friday, February 20, 2004

Promises and Prescriptions
Part 5 - Set a Priority to Eliminate Multi-tasking
-- It's easy to fall into multi-tasking, because it sounds like it will make things go faster. It won't. It will only keep people busy—and unavailable for really moving projects along to completion. It's hard to break the habit, but the results are worth it.

At the project task level, don't allow yourself to be bullied into multi-tasking behaviors. Ask those who are treating your time and attention as the rope in a game of tug-of-war to agree on priorities, and work the tasks start-to-finish in priority order. If they won't do that, tell them what priorities you have chosen and get to work on them, one at a time. As the person delivering task outputs, your effectiveness, efficiency, and quality of work-life will be enhanced. More importantly to project success, the people waiting for your outputs will get them sooner than if you had split your time among them, squeaking out small pieces of illusory progress without really completing anything.

At the portfolio level, prioritize and launch projects only at the rate that the system can absorb them. If you try pushing ten pounds of project through a five-pound pipeline, you won't even get five pounds of successful projects through to the end, as capacity is wasted in the context switching. Set clear priorities for the promising of projects. Get an understanding of the capacity limits of your software development system and set up mechanisms to use them effectively and efficiently.

When determining your project throughput capacity, consider planned and unplanned work. Just because we tend to plan projects as if they were in a vacuum doesn't make it so. Take into consideration the other necessary uses of resource time before promising projects and launching them into the pipeline. At the same time, make those promises in a way that is resilient to needs of emergencies and opportunities.

(Next up...the issue of fear of promising the unknown.)

Navigate this series: First Part -- Previous Part (4) -- Next Part (6)

posted by Frank - Permanent Link - |

For Readers -- Yesterday, I sat in on one of Hal Macomber and Greg Howell's Conversations with Authors. The topic was Embracing Uncertainty: The Essence of Leadership, by Philip Clampitt and Bob DeKoch. A free (except for long distance charges) teleconference, we spent an hour and a quarter with the authors exploring the nature of organizational responses to uncertainty, what the costs of denying its existence might be, how to grow opportunities by "embracing" it at the leadership level, and ideas for bringing an organization's performers to accept and deal with it. A well-spent 75 minutes. The monthly series will continue for a while, and will include Dave Anderson of Agile Management fame (at least around these pages) in April and Jim Womack of Lean Thinking in May, among others. You'll want to get on the registration list if you think you'll want to participate.

posted by Frank - Permanent Link - |

Friday Fun - iTunes, Inventions, Insult, and Ice Skating -- A few diversions this week...
- How to improve your odds in Apple/Pepsi's "free music" promotion really free music and leave the Pepsi's without the free iTunes download codes for people who don't care about them. It's too bad I prefer Coke. On second thought, since I own shares of PEP, you really should buy the fizzy sugar water even without the winning caps.

- An invention timeline from a science fiction perspective. I'm still amazed at the prescience of Jules Verne's "From the Earth to the Moon."

- A word that I'm waiting for an excuse to use, but I'm afraid I might be too polite.

- Last night, my wife and I had front row seats (actually on the ice at about the hockey blue line - cool both metaphorically and literally) for Smucker's Stars on Ice in Trenton. Other than merely appreciating the combination of art and athleticism from skaters like Yagudin, Sato, Eldredge, and the various pairs champions, with such a close seat, I could concentrate on the footwork involved, which blew my mind. Can anybody explain the physics of fast backwards skating? It sure looked to me like the feet are moving the wrong way.
Have a good weekend.

posted by Frank - Permanent Link - |

Thursday, February 19, 2004

Promises and Prescriptions
Part 4 - Multi-Project & Mixed-Function Multi-Tasking
-- One of the major impediments to doing one's best work on the task at hand is not related to lack of ability, but rather to the fact that there are, too often, too many tasks at hand.

Software projects are usually delivered as one of a portfolio of efforts and often share resources with others in the pipeline. Even if some critical technology resources are dedicated to specific projects, there are always some shared resources. It is not unusual for scarce, highly skilled contributors to support multiple projects. It is also common for certain functions, such as testing, that are heavily used across many projects to become overwhelmed with work.

The usual response to having a lot of work in one's inbox is to use the squeaky wheel method of prioritization. Whichever project is squeaking the loudest in the morning gets attention for the day, whether the previous day's task is completed or not. Multi-tasking is, unfortunately, often seen as a laudable talent. In reality, bouncing back and forth between unfinished tasks in an effort to show progress merely delays all the handoffs involved and wastes valuable capacity in unnecessary set-down, set-up, and "Where was I?" questions at every restart.

Best case multi-tasking situation...
Add context switching delays for real impact.

This is really an issue of understanding pipeline capacity. Most software projects do not exist in a vacuum. Software organizations are often responsible for at least two functions -- development/deployment of new systems and production/maintenance of existing systems. While major maintenance efforts can be added to the project portfolio to-do list and managed as projects, there are still day-to-day issues that need to be addressed to keep the business running. Even when projects are carefully defined in terms of resource requirements, unplanned emergencies can affect progress.

(Prescriptions for multi-tasking are next in the series.)

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

Labels: ,

posted by Frank - Permanent Link - |

Wednesday, February 18, 2004

Promises and Prescriptions
Part 3 - Work Your Way Out of Rework
-- Rework can add up to a significant portion of total project effort. It only makes sense that reducing rework will improve project performance. It's unrealistic to consider eliminating all changes or repealing Murphy's Law, so let's consider avoiding the things that we do to ourselves.

Get rid of task due dates. The only dates that count are those promised outside the project. Accept the fact that the work is going to take as long as the work takes, and that interim task due dates are distracting, artificial priorities. Without artificial priorities imposed by due dates for individual tasks, the ability to hand off quality output runs into one less obstacle.

Develop a clear understanding of the major interdependencies between tasks and maintain that understanding as the project progresses and changes. Understand the handoffs. Understand the resource dependencies. Don't obsess over understanding the details of different functional parts of the project if you're going to ignore the cross-linkages between those parts. As the project progresses and matures, make sure that new learning, new necessities, and new dependencies are added to that understanding. If a dependency diagram of your project looks like a set of long parallel chains of tasks, go back and look for where those lines really intersect.

Question assumptions about "necessary" handoffs between tasks. You may not need all of the assumed inputs, but separate what you can do with what you have, from what you cannot. Doing what you can in parallel will accelerate project progress. Doing what you think you can but really can't will yield rework and slow the project down.

The key to avoiding rework is in the combination of a living plan of dependencies, the elimination of any idea that an estimate is a commitment, and an environment that allows people to do their best work on the task at hand.
Sidebar - Another Problem with Task Due Dates -- In addition to being a source for rework, task due dates bring another insidious problem to the issue of keeping project promises. They are the source of Parkinson's Law: "Work expands to fill the time allowed."

The implication of finish (and start) dates in a schedule is that if they are met, the project is on track. If that's the case, then the time allowed runs the risk of being filled up with distractions, unnecessary tweaking and polishing of outputs, and other activities not associated with the task at hand.

Similarly, if the receivers of a task output equate due dates with start dates, they might not be there to pick up an early handoff. In either case, time that might be needed for some unforeseen problem down the road has been lost.

If you get rid of task due dates, and enable/enforce focus on the most important task, project quality, speed, and reliability will improve.
(Watch for the multi-tasking issue in the next installment. And by the way, yesterday, Hal Macomber picked on on this series, said some very complimentary things about it, and has started adding his two cents to the subject as well. And Hal's two cents are usually worth a lot more than that nominal amount. Check 'em out.)

Navigate this series: First Part -- Previous Part (2) -- Next Part (4)

posted by Frank - Permanent Link - |

End-State Metrics -- We interrupt the Promises and Prescriptions series for this pointer from Jim Berkowitz to a short Baseline interview with Ken Harris, CIO of The Gap.
Q: What metrics do you use to evaluate bottom-line results?
A: The valuable metrics are the end-state metrics and not the mid-state metrics.

Q: What are end-state metrics?
A: The things that impact the customer, the employee or the company's bottom line. A project is not successful when the technology is installed. A project is successful when the consumer, employee or shareholder gets the benefit because the technology has been installed.
Projects aren't just about deliverables. They are about objectives.
Projects aren't just about implementations. They are about benefits.
Projects aren't just about the "whats." They are -- first and foremost -- about the "whys."

posted by Frank - Permanent Link - |

Tuesday, February 17, 2004

Promises and Prescriptions
Part 2 - The Added Work of Rework
-- "There's never time to do it right, but there's always time to do it over." If you've ever uttered that time-worn sentiment, stated with an air of exasperation (or muttered under your breath), then you're probably familiar with rework. The need to re-do something is rooted in one of two possibilities. Either it was not done right the first time, or something has changed to make the original attempt less than fully useful. While there could be a number of reasons for either (Murphy's Law has not yet been repealed, after all), there are several common practices of project management that can actually contribute to rework.

One source of self-inflicted wounds is the misuse of estimates used to build schedules and make promises. Too often, estimates are single numbers (or are transformed into single numbers by some sort of "best-case-worst-case-most-likely" PERT calculation), that reflect the best guess as to how long a task is expected to take, given available information. Estimates are asked for long before many of the details of the project are really understood. This is the nature of planning and promising in many organizations.

Unfortunately, the foot shooting continues: estimates get translated to commitments, and are published as schedules that link the string of estimated tasks to the calendar. Now there's a due date for every task that, if exceeded, means the project promise is in jeopardy. Pressure to meet that due date--to keep the project on track--can overwhelm even the strongest desire to handoff a quality deliverable to successor tasks. The rush job comes back to haunt you as you do the rework, which takes more time than estimated, plus the additional re-setup; or users do the rework, adding to their effort and the chance of handing off their output late.

A second source of rework is created when work is started too soon. Too soon sometimes means before somebody else's handoffs are ready. If you start without a full set of required inputs, you will find yourself making assumptions. Those assumptions could be wrong.

Too soon can also mean before it's needed. Just because you have all the inputs that were identified in the initial planning doesn't mean you should jump on it immediately. Often, that is the appropriate action, but there are also situations in which you could invest effort prematurely, only to find that some other part of the project has changed circumstances. Your good planned work is now either less than what is needed or something the project doesn't need at all. While that last possibility doesn't directly relate to rework, it is just as wasteful if you had other, more valuable things to do with your time.

(Prescriptions for dealing with rework will be found in the next installment.)

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

posted by Frank - Permanent Link - |

Monday, February 16, 2004

Promises and Prescriptions
Sidebar - Why Projects are Hard
-- All projects are an interdependent collection of tasks, performed by resources, human or otherwise, with various skills and capabilities, all leading to some desired objective. Projects are projects, no matter the domain. Beyond that, things are more complex.

If a project objective is worthy of pursuit, it has some benefit associated with it. Our desire to get something done becomes a desire to get it done either as soon as possible or by a specific time, or even a combination of the two. For instance, if a project is delivered sooner, one might get more benefit. Oil wells and new products are examples of such "ASAP" projects. Similarly, some products lose value if not available by a specific time—an Olympic stadium that isn't ready for the opening ceremony or a new computer game that isn't ready for the Christmas shopping season, for example.

At the same time, resources that can do what the project requires are limited. For every project, someone must consider whether the use of the time and attention of a finite pool of resources is commensurate with the expected benefit. Alternative uses of those resources, like more valuable projects or bank interest on the dollar value of those resources, might provide even more benefit.

Both cost and benefit are related to the time aspect through duration and criticality of due dates. This complicates decision-making about the project in question and other projects that share limited resources.

If the objective is known, but how that objective will be accomplished is not clear, the nature of required research, discovery, problem solving, and trial-and-error create additional challenges. The unknowns complicate the process of promise-making, as it requires you not only to deal with the variation of task performance, but also to address uncertainty of looping iterations and tasks of unknown content.

Is it any wonder projects are hard?

Navigate this series: Previous Part (1) -- Next Part (2)

posted by Frank - Permanent Link - |

Sunday, February 15, 2004

Promises and Prescriptions
Part 1 - Introduction
-- Projects--including software projects--are about promises.

Projects are about turning uncertain work efforts into reasonably certain outcomes. Project sponsors, customers, and stakeholders rely on project promises to carry out and coordinate larger strategies in support of organizational needs. Yet, making and keeping those promises are hindered by common problems: people on projects are reluctant to promise the unknown, plans are disrupted by rework, and schedules are thwarted by contention for resources that are involved with more than one effort.

In his classic business novel, The Goal, Eliyahu Goldratt introduced an approach to managing complex systems known as the Theory of Constraints (TOC). While Goldratt's novel revolves around a manufacturing plant, he offered management prescriptions that can help software projects as well. Later, he refined the application of TOC to the domain of project management with Critical Chain Project Management (CCPM). In this article, I'll offer you prescriptions from CCPM to help deal with common problems encountered in software projects. While there's much more to TOC and CCPM, these prescriptions will help improve project performance even if you don't pursue the full solution.

Within software projects, there are three common complaints. One is rework. Work efforts are designed in a highly intricate, interactive, and interdependent domain. Touching one piece of a work product can impact other pieces, frequently requiring rework of what was thought to have been completed. In addition to missed or misunderstood interdependencies, time pressures that compromise quality, uncontrolled changes in requirements, and miscommunication all contribute unexpected work and tend to extend the timeframe upon which the project promise is based.

Second, software efforts often exist in mixed- and multi-project environments. A limited pool of people and resources are assigned to mixed responsibilities, such as development and maintenance--or are shared across multiple concurrent projects. The resulting conflicts of priorities are a major source of difficulty in promising and delivering projects.

The third issue is a culmination of the first two, plus impacts of project work in an uncertain environment. Projects are about promises--necessary promises that help an organization to manage its future. The fear of promising the unknown results in either irrational promises that stress out those tasked with delivery, or unresolved promises that stress out those who must run the business or sell the product the project is intended to support.

(Watch for the these three issues (and prescriptions for dealing with them) in future installments of this article, originally published in Better Software magazine.)

Navigate this series: Next Part (Sidebar - Why Projects are Hard)


posted by Frank - Permanent Link - |

Saturday, February 14, 2004

National Engineers Week: February 22-28, 2004 -- On engineers...
"A scientist can discover a new star, but he cannot make one.
 He would have to ask an engineer to do that."

    - Gordon L. Gregg, American Engineer, 1969
I was going to say "Kiss an engineer for Engineers Week." Rather, these days, it'll probably be more appreciated if you hire one.

Frank Patrick, BS Industrial Engineering, Rutgers University, 1973

posted by Frank - Permanent Link - |

Friday, February 13, 2004

Friday Fun: Unconstrained Water Balloon -- In zero-g; two more here. Just when I had given up on fun this week, Boing Boing comes through for me with this one.

posted by Frank - Permanent Link - |

Promises and Prescriptions - Heads Up for the Article -- Last month, I mentioned Promises and Prescriptions, an article of mine that was published in the January issue of Better Software magazine. Consider this a heads up that, while I massage a pdf version for future offline consumption, next week I'm going to start a serialized version of it in this weblog. Right now it's in about eight parts (plus one for a major sidebar), so I expect it to take a couple weeks to get it all out to you all. Watch for part one starting on Sunday. (If the current issues with Bloglet are dealt with by then, subscribers through that service will see it on Monday morning in their email.)

posted by Frank - Permanent Link - |

Dilemmas in Software Engineering -- Stephen Norrie points to a paper from John Sambrook, entitled Dealing With Dilemmas In Software Engineering [pdf], and quotes from it's abstract...
"Software engineering is a complex and demanding activity. The degree to which engineering teams are able to recognize dilemmatic situations and resolve them quickly and without compromising important needs has a large impact on the performance of the team and the quality of the developed software. […] In this article we explore the nature of dilemmas and provide actionable advice that individuals and groups can use to improve their ability to recognize and resolve dilemmas in an effective manner."
The paper goes on to describe dilemmas in TOC terms and provides some good information on one of the most powerful of the TOC Thinking Process tools both in general and in a software-related example. As you'll read, conflicts and dilemmas are perpetuated by unexamined assumptions. (More on this Thinking Process tool here and here.)

posted by Frank - Permanent Link - |

Thursday, February 12, 2004

Ad: Build Your Own Multi-Project Workshop -- (File under: "Without billings, it's only a hobby.")

If you've been reading my weblog for any length of time, you might have found some general value in what I've been writing here. If you would like to explore the topic of strategic multi-project management in more detail and in the context of the needs of your own organization, this entry is to provide a heads up on the offering of 1-, 2-, and 3-day workshops designed to be delivered to key project stakeholders.
The Multi-Project Solution - The core of this modular workshop offering is one day to explore your difficulties with and solutions for managing multi-project environments, discussing the ramifications of prioritizing, planning, and promising your project portfolio.

The Big Picture - Strategy and Multi-Project Management - The Multi-Project Solution session can be turned into a 2-day session by combining it with a day that first sets up the context of multi-project management in the strategic picture of an organization and the role of PMO functions in linking strategy to portfolio and project management. (This "Strategic PM" day is also available as a standalone 1-day session.)

The Nitty Gritty Picture - Multi-Project Management in Your Organization - An alternative 2-day session consists of the Multi-Project Solution day combined with a day after it that explores what it would take to multiply your multi-project throughput in your own organization. While the other two days already discussed are primarily tightly structured lecture with space for conversation and interaction, this third "how to do it here" day is more conversation and interaction, with light "lecture" primarily set up as an agenda for key topics in the subject.

The Whole Picture - Strategic Multi-Project Management and its Implementation - A 3-day version combines all three days described above...the strategic context of multi-project management and the PMO, the guts of a common sense solution for multi-project management, and "how to do it here."
If these offerings appeal to you, use the "contact" link below to get in touch with me and start a dialogue on the details of bringing this learning and solution to your organization.

posted by Frank - Permanent Link - |

Wednesday, February 11, 2004

Cool Tools - Shower Slate -- "Ever have an idea in the shower and have no way to record it...and then it's lost forever?" (from Kevin Kelly's Cool Tools site, which, in both tone and content, reminds me a lot of the seminal Whole Earth Catalog of the 70's. But then that makes sense, because digging deeper in into the site, I find that Kevin was instrumental in those big black books.)

[Later...] And Jim McGee points to a collection of ideas for idea collection (suitable for when you're out of the shower), from Charles Cave's Creativity Web.

posted by Frank - Permanent Link - |

Outsourcing One's Existence -- Back in November, I wrote about outsourcing:
"Taking a cue from the concept of a world of ends that so aptly defines the network known as the Internet, Pollard points to the potential of critical knowledge disseminating out into the network of outsourced functions, leaving those at the center with little control over what once was their organization, with little role to play, and with less and less value add associated with their existence."
Recent business headlines about Disney's reliance on Pixar for the core of its most successful creative work (CGI-based animation from Toy Story to Finding Nemo), and the resulting loss of that relationship as Pixar/Jobs realized that maybe they didn't need Disney any more, have struck me as a nice example of the dangers of outsourcing. Today's headline -- Comcast's bid to acquire Disney -- while not related to the Pixar situation alone, provides an interesting continuation of the story. If you don't take care and keep control of what's important to your business, you may find yourself without a business to worry about.

[Later...] Jeff Jarvis raises an interesting question about the Pixar/Disney/Comcast menage.

posted by Frank - Permanent Link - |

The Thinkers 50 -- A survey that addresses the question, "Who is the most important living management thinker?" with 50 answers. The top five are Drucker, Porter, Peters, Hamel, and Handy. Included among the other 45 are executives Welch, Gates, Grove, Dell, Bezos, Branson, and familiar names Senge, Covey, Collins, Scott Adams (!), Kotter, and de Bono. An overall reasonable list, but missing Goldratt. (via Pollard.)

posted by Frank - Permanent Link - |

Waterfall Failure Logic -- Last week, I introduced you to Clarke Ching. He isn't embarrassing me, to say the least. In the subject link, he's included a couple of what we in TOC-land call "Current Reality Trees" (CRTs) that describes the logic of undesirable effects of hard phase-defined "waterfall" plans. A very nice analysis -- both from the point of view of the subject and as an example of a CRT. For me it raises a question about the assumed definition of "phase." It'll be interesting to watch his solution unfold.

(Note that -- at least in my browser -- some of the CRTs seem to be clipped by the format of his blog. If you seem to be missing the right side of them, simply right-click to open the images in a new window or tab.)

posted by Frank - Permanent Link - |

Project Management Capacity Planning -- Christian Connett recently discussed the topic of Capacity Planning for the PMO, asking...
Ever think of Capacity Planning in terms of what your Project Management team can handle?

[...] Utilizing Capacity Planning in the PMO would help to optimize resources, and review a PM team's opportunities to take on another project. The ability to check a PM's capacity would enable management to accurately predict the prioritized projects of each PM. Each PM would report their capacity %, and enable project prioritization...
While Christian is headed in the right direction here, trying to support prioritization and to avoid overloading the system with more projects than it can handle, my sense tells me that his implied acceptance of project managers as the limiting factor is misguided.

Any organization sophisticated enough to be involved with PMO efforts should also be sophisticated enough to be conscious of and manage its constraints with some common sense. Any organization that lets the availability of such a generic skill as project management constrain its ability to launch valuable projects is unnecessarily hobbling itself.

The basis for the TOC approach to multi-project management is that to avoid to pressures to multi-task and then suffer its debilitating effects, you launch prioritized projects based on the availability of some skill that is commonly used, heavily used across the project portfolio. While, on the surface, PM skills fit this definition, the only reason to live with a constraint -- a limit on project throughput -- is difficulty in acquiring more of that skill. If you limit your throughput to that that the PMs can handle, then you are living with a strategy that says that PMs are the reason you are in business. Rather than rely on such a generic strategic constraint -- one that can be easily copied by the competition -- the system should be managed around a constraining resource that more directly reflects the core, differentiating competency of they system/organization -- its true strategic constraint.

Do you want your project throughput to be limited by lack of PMs or do you want to use your PMs and PM processes to maximize the capacity of scarce, valuable skilled resources that reflects the real value of your projects' products?

Labels: , , ,

posted by Frank - Permanent Link - |

Saturday, February 07, 2004

Team-Building Boondoggles - A recent prospective client, who really needs help in getting their project performance act together, had to renege on a planned introductory workshop (aka sales pitch with value) because the budget (for time and money) had been hijacked to support a top-down initiative in "team-building." You of those totally meaningless boondoggles in which people are put in artificial environments that have no real relationship to their actual performance issues.

Allow me to suggest a difference (somewhat circular) cause-and-effect relationship between project success and "teamwork." Rather than rely on silly team-building exercises to try to support project success, I would far more prefer to rely on effective project management to build a groups sense of accomplishment and can-do-ism. After all, the project is only a temporary endeavor. It's likely that the team will need to work together again. If it's disheartened and discouraged by lack of performance, that depression and dysfunction will taint future efforts as well. Sort of the the equivalent of the negation of a pile of "attaboys" by one "aw, s4!t."

There are common root causes beneath both poor teamwork and poor project performance. Lack of team cohesion arises when people's common sense is violated -- when they are forced to behave based primarily on CYA concerns. These violations, conflicts, and dilemmas arise when necessary conditions for an efforts success are out of alignment.

Get rid of the project conflicts between reliability and speed, between one project and another, between resource management and project management, and between local and global optima, (all very doable, once erroneous assumptions are identified and dealt with) and you're well on the way to effective projects, which will lead to a sense of teamness, which will feed back into more effective projects, which will lead to......

Deal with the conflicts at the root, then spend group get-togethers in celebration instead of in outward bound "team-building" boondoggles.

posted by Frank - Permanent Link - |

Weekend Distraction: Warning: Blogging Frequency in Imminent Danger -- Picked up a copy of Apple's iLife suite this week, and finally got around to installing GarageBand Friday night. One hour later, this fragment of my opus 1. Shades of 80's synth/funk. This could be addictive.

posted by Frank - Permanent Link - |

Thursday, February 05, 2004

Introducing Clarke Ching -- I like to think that the example of my weblog has inspired others of like mind to jump into such endeavors. Here's a newish blog from another fan of the Theory of Constraints, Clarke Ching. He's been a frequent thoughtful contributor to various TOC discussion forums like APICS' CMSIG listserve, my CriticalChain yahoogroup, and Tony Rizzo's TOCExperts yahoogroup. (Now if I could only get Tony into blogging.)

I look forward to seeing Clarke put forth his own voice outside of those venues, and I look forward to a continuation of his post today, the start of a TOC Analysis of Software Development. I suspect that before long, he'll show up in my Blogroll (that list of blog authors that I frequently read, found a ways down in the right hand column of this page).

posted by Frank - Permanent Link - |

Team Memory -- A piece from Laurent on the mirage of team memory and the meaningfulness of project artifacts.

posted by Frank - Permanent Link - |

Project Manager Objectives: The Rule of Least Surprise -- Johanna Rothman lays out some good guidance for considering the roles/objectives of project managers...
- The project manager helps the project team focus on the final deliverable, not interim deliverables, so the project team doesn't fall into the 'crossing the desert' mode, where it looks as if the project will never finish.

- The project manager helps the team set the goals and refine the project's goals, so the project team knows what they have to do at all times. ('Does this task help us accomplish the goal?')
And the focus on both the final deliverables and goals is best achieved through a living plan of major dependencies between the currently active work and the desired end state/deliverable/objective. Along these lines, the PM's role is to manage the "arrows" while the techincal performers worry about what's in the "boxes." Some of those arrows that need to be watched and refined along the way are not usually found in schedules and dependency charts -- the logical "arrows" that link planned deliverables to desired objectives and goals.
- The project manager helps make the project state visible to all team members so they can see where they are with respect to the goal. (So the project team isn't surprised by the work remaining.)

- The project manager makes the project state visible and understandable to the stakeholders, so they can see the project's progress. (So the stakeholders aren't surprised by the work remaining and the risks to accomplishing that work.)
These last two can merely be (actually, for integrity's sake, must be) different views of the same information. The buffer management concept recently discussed here is one nice approach to killing these two birds with the same visual management stone.

posted by Frank - Permanent Link - |

Marketing Magic -- Yesterday's Dilbert...

...reminded me of this old one...
A Cajun moved to Texas and bought a donkey from an old farmer for $100. The farmer agreed to deliver the donkey the next day. The next day, the farmer drove up and said, "Sorry, but I have some bad news. The donkey died."

"Well den, just give me mah money back."

"Can't do that. I went out and spent it already."

"OK, then. Just unload da donkey."

"What you gonna do with him?" asked the farmer.

"Ah'm gonna raffle 'em off."

"You can't raffle off a dead donkey!"

"Sure, Ah can. Watch me. Ah jes won tell anybody he daid." said the Cajun.

A month later the farmer met up with the Cajun and asked, "What happened with that there dead donkey?"

"Ah raffle 'em off. I sold 500 hundred tickets at two dollars apiece and made ah profit of $998."

"Didn't anyone complain?"

"Just da guy who won...So ah give 'em his two dollar back."

posted by Frank - Permanent Link - |

Wednesday, February 04, 2004

Think Like Leonardo da Vinci: From Flemming Funch...
"Via Dewayne Mikkelson, the principles of how to think like a da Vinci. From Michael J. Gelb's book 'How to Think Like Leonardo Da Vinci: Seven Steps to Genius Every Day'
Curiosita: An Insatiably Curious Approach to Life and an Unrelenting Quest for Continuous Learning.

Dimostrazione: A Commitment to Test Knowledge through Experience, Persistence, and a Willingness to Learn from Mistakes.

Sensazion: The Continual Refinement of the Senses, Especially Sight, as the Means to Enliven Experience.

Sfumato: A Willingness to Embrace Ambiguity, Paradox, and Uncertainty.

Arte/Scienza: The Development of the Balance between Science and Art, Logic and Imagination. Whole Brain Thinking.

Corporalita: The Cultivation of Grace, Ambidexterity, Fitness, and Poise.

Connessione: A Recognition of and Appreciation for the Interconnectedness of all Things and Phenomena. Systems Thinking.
Hey, I'm not doing half-bad on most of these.
That Lenny certainly had it going on, didn't he? Certainly some attributes to strive for.

posted by Frank - Permanent Link - |

Tuesday, February 03, 2004

The Goal(s) -- A recent piece by Dave Pollard on the important ideas of 2003 for business is sure to offer a lot of fodder for thought. His first "big idea" is one around the idea of going beyond profit. One of the bedrock concepts of the Theory of Constraints (TOC) is that of "The Goal." For for-profit organizations, it is often defined as "to make money now and in the future." I think when we talk about "The Goal," in TOC, it is essential to draw a distinction between the larger "goal" of an organization and "The Goal," which has been chosen as the framework against which we will focus our measures, identify our constraints, and use to define Throughput.

I would suggest that the real "goal" of the kind of organizational system we're probably talking about is to survive for as long as it wants to, or at least as long as is necessary to accomplish it's mission/vision within the context of the values it has decided to operate within.
(Along these lines, there was a fascinating article in Fast Company back during the deaththroes of "the bubble" that looked at organizations that are "Built to Last" versus those that were "Built to Flip," the latter of which may not need to make money in terms of throughput and profit to create substantial economic benefit for owners, employees, and value for customers, but by plan and by nature, have a short independent life span.)
The issue of "goal" become more interesting when considering for-cause (aka not-for- or non-profit) organizations. The mission/vision/values of an organization, and therefore the organization itself, is defined by the conditions it defines as necessary to its survival/success. Are we for-profit or not-for-profit? Are we a slave-based plantation or a cooperative farm honoring economic freedom of its participants? Are we doing art for the sake of supporting the creative expression of our associates or are we in it for the money? Are we a bunch of guys getting together for comraderie through a community softball league, or are we the New York Yankees? Do we want to work at a marathon pace for long haul success or are we willing to operate at a burn-out sprint to create quick-hit immediate high-value returns? Is reward/satisfaction for members of the organization met by a steady base salary, or through a high-risk/high-reward system? At the risk of offering circular logic, in order to survive, it would seem to be necessary to assure its ability to satisfy all the conditions it identifies as necessary to its survival.

These conditions may include (but are not limited to) the usual triad of making money, satisfying customers, and securing and satisfying the human resources necessary to operate the endeavor, but as the questions above suggest, there are probably many shades of definitions of these conditions. In a free society, employees define their satisfaction and determine if the organization they are in is providing it for them, customers define value and the price they are willing to pay for it, and owners/investors define acceptable returns on the use of their resources. If an organization can't meet the necessary conditions it has used to define itself, it either fails or becomes a different organization with different details underlying those conditions. I would think, however, that TOC's holistic/systemic view of such a situation still applies, as it eschews the notion of compromising one necessary condition for another. The "goal" of an organization has to be the intersection of the identified necessary conditions. No necessary condition can be significantly subordinated to another without a change in the "contract" that defines the organization.

Recent articles on outsourcing, layoffs, and the "export of jobs" bring this question home loud and clear. I assume that on the surface in such situations, that there are currently excess resources available for such a layoff, but those resources are also available to create other sources of value. It should NOT be OK (by either moral or fiduciary standards) to go ahead with such a layoff (to violate that necessary condition associated with employee security or satisfaction) without fully exploring those possibilities. When organizations like IBM or Japanese companies recast their interpretation of that necessary condition, it results in a deep cultural change. They are no longer the same organization. That's OK, but it must also be recognized as a failure to live up to the previous "contract" -- a failure of imagination that results not looking to the top line possibilities of using these resources for additive value, but only at their mid-line "cost."

Take the usual for-profit "Goal," related to financial viability and/or reward and usually stated as "Make money now and in the future." Viability provides immediate survivability, while reward can serve to support the retention, satisfaction, and growth of the resources required to accomplish the organization's mission and deliver that financial outcome. The inclusion of a financial necessary condition also implicitly requires providing something of value to someone willing to pay for it. And it's a satisfied customer, obviously, who eventually defines that value.

The three classic necessary conditions are so intertwined that it is not possible to talk about taking an action satisfying a "Goal" without the stipulation that that action will not violate the other necessary conditions. If they are not addressed by the organization, I would guess that they will eventually be addressed in the market or by the courts or legislatures.

(The distinction between owners and employees becomes fuzzier in a corporate organization in which a non-trivial amount of an employee's wealth (future satisfaction and security) is closely tied to the current performance of his/her organization through employee stock ownership and options. Did Cisco employees focus more of their financial attention in 1999 on their paycheck or on their 401-ks and options?)

The goal of an organizational system is a multi-faceted entity that must include the concerns and requirements of all stakeholders.

Very simply, there are "multiple goals," despite the suggestion of TOC that one of these conditions, concerns, and requirements be chosen as "The Goal" for purposes of the primary focus of management. This does not preclude the need to assure that the other "necessary conditions" are satisfied. "The Goal" is simply the necessary condition that the organization has agreed to use to keep score in its game. But a game is more than just score-keeping. Any game, especially non-zero-sum games like those we are concerned with, has additional rules which govern how those scores can be achieved and which make the score meaningful. Without those additional necessary conditions, or rules or the game, there is no meaning to the score.

posted by Frank - Permanent Link - |

Sunday, February 01, 2004

Theory of Constraints in the News -- It seems that TOC is making inroads in the support services of the US Military. At the Naval Base at Port Mugu, California...
...the support for each squadron has also increased due to the implementation of the "Relevant Information For Leadership" - abbreviated as RIFLe - philosophy. RIFLe incorporates the Theory of Constraints, and works to alleviate the impact of bottlenecks within the operations process. By horizontally integrating stovepipe logistics, RIFLe evaluates procedures at the operational level for improvements that will employ less effort, less resources, and increased effectiveness.

"The results have been outstanding," said Cmdr. Carolynn Snyder, Point Mugu AIMD officer-in-charge. "We have a 50 percent decrease in items waiting for repair, a 75 percent decrease in due-in-from-maintenance items and our average customer wait time has decreased from eight days to one and a half days."
(More on RIFLe and TOC here, thanks to Judith Meskill.)

...and from the Marine Corps Logistics Base, Barstow, California...
...even though the process is seasoned, there is always room for improvement. Some of the improvements that have been put into action at the Maintenance Center are the installation of new small overhead cranes, a contractor to maintain the equipment, and the implementation of the Theory of Constraints method.
Hoo Rah!

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