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

Frank Patrick's Focused Performance Business Blog
This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.

Friday, August 29, 2003

Friday Fun: Cheezy book -- An excellent review/interview about a certain business best-seller. A brief excerpt...
"I'll try to put a positive spin on this. Who Moved My Cheese? is beyond any shred of doubt the worst and most useless thing in print. It's trite, dull and insulting. So far this year, I can say with some confidence that I've learned more from Snapple bottle caps and Eminem album lyrics."
My sentiments exactly.

(via Internet Time Blog, which is quickly earning a spot on my blogroll.)

posted by Frank - Permanent Link - |

Thursday, August 28, 2003

A Message to My Email Subscribers -- While you have probably been receiving my recent posts fine, the system that does this for me -- Bloglet -- has been inaccesible to me and to new subscribers for several weeks now. If this doesn't improve soon, there is a good chance that I'm going to shift to a YahooGroups distribution system instead. It won't be an email discussion list, but a one-way newsletter that will allow you to give feedback to me but retain your privacy from the public and other subscribers.

If, sometime in September, you get a notice that I've added you to such a maillist, I hope you'll accept it. I'll try not to overlap the Bloglet and YahooGroups deliveries too much.

posted by Frank - Permanent Link - |

The Future of Knowledge by Verna Allee -- I'm beginning to see a pattern in the weblogs that I read. There are the project management blogs, the internet/social software blogs, the political blogs (which are starting to influence my personal Unfocused blog), and a new category seems to be congealing in my bookmarks -- Knowledge Management. In that category, Jay Cross of the Internet Time Blog points to this book, catching my attention with the statement, "There is really only one management question: What do we need to pay attention to in order to be successful?" Jay takes notes on the book in public, and includes a pointer to the author's site. One of the key takeaways from this and my other KM reading is that, knowledge is a network thing. No one can really grow knowledge alone. It's one of those things that requires and benefits from interactions, interdependencies, and all those other inter-things.

posted by Frank - Permanent Link - |

Wednesday, August 27, 2003

A Good One on Certifications --

Given the proliferation of 3- and 4-letter addenda on business cards these days, doesn't that suggest the differentiating commodity is uncommon sense?

posted by Frank - Permanent Link - |

Tuesday, August 26, 2003

Unappreciated -- Quotes of the Day reminds me of a quote I've used elsewhere in my site as the epigram for a page...
"The trouble with being punctual is that nobody's there to appreciate it."
  - Franklin P. Jones
Project schedules that rely on interim task due dates and the calendar to assess and manage progress against promises set up a whole series of opportunities to be unappreciated. If the person that is going to use your outputs in their task focuses on the due date/start date as the border between the two tasks rather than the handoff itself, then if you are early in delivery, odds are they'll use the extra time for other work, squandering the extra time that you've provided to the project. As a result, your expeditious delivery is, in the end, unappreciated. As a result, you start pacing your work to deliver to the date. As a result, projects managed in this way almost always take longer than they need to, and very often, longer than expected.

Prescription: Get out of the "project schedule as train schedule" mentality and into the "project as relay race" mode of operation, focusing on assuring that resources are there to pick up and run with the hand-offs as soon as they are ready instead of having hand-offs there when the resource plans to start.

posted by Frank - Permanent Link - |

Sunday, August 24, 2003

On Compromise and Integrity -- Two short pieces, one from Jim Vornov...
"Look at where you place the boundry of the system. If the border is around self, you act in self interest always without regard for people and things without. That is ego and that is pride. Every choice that fails self is a compromise."
and another from Robert Martin...
"Sometimes we feel bad when the rules must be broken. They're just rules though. What's important is that we have a moral center, a professional core, that refuses to compromise the quality of our work."

posted by Frank - Permanent Link - |

Best Sellers (and others) -- In late June, I added links to the books I recommend in this weblog and in my site's reference page. One of the benefits is that I get a small kickback from Amazon if you buy through my links. To those of you who cumulatively bought almost 90 items in the last two months, I thank you for supporting my efforts here and for funding my recent Babylon 5 Season 3 DVD purchase. Another benefit is seeing not only what you choose from my recommendations, but also what you buy in the same visit. (Don't worry. I don't know who buys what...just what is bought.)

For what it's worth, the following constitutes a bakers dozen of the top sellers from my recommendations so far, with the top two far and away in a volume class by themselves...
- Strategic Navigation: A Systems Approach to Business Strategy
- Advanced Project Portfolio Management and the PMO
- Good Business: Leadership, Flow and the Making of Meaning
- The Measurement Nightmare
- The Art of Worldly Wisdom: A Pocket Oracle
- Throughput Accounting
- Critical Chain
- Critical Chain Project Management
- Execution: The Discipline of Getting Things Done
- The Goal: A Process of Ongoing Improvement
- Breaking the Constraints to World-Class Performance
- It's Not Luck
- Deming and Goldratt
Kind of predictable, since two of the top three have been featured in my "currently reading" list over on the right for a while. And I mentioned "Strategic Navigation" on a TOC-intensive discussion list I participate on as well. That said, it's heartening to see the dominance of TOC-oriented books in the list as well, especially my favorite "Deming and Goldratt" sneaking in at number thirteen, since part of my mission here is to introduce more people to constraint management thinking. (Yeah, yeah...You caught me. I expanded the usual Top 10 format to the "baker's dozen" to get that last one in.)

But what is really interesting to me in the Amazon report are the other books that you have bought along with those that I'm aware of. They include (in alphabetical order)...
- Alchemical Active Imagination
** Business Dynamics: Systems Thinking and Modeling for a Complex World
- Connecting the Dots: Aligning Projects with Objectives in Unpredictable Times
- Creating the Project Office : A Manager's Guide to Leading Organizational Change
- E-Commerce Logistics & Fulfillment: Delivering the Goods
- ERP For Dummies
- Executive's Guide to Web Services
- Google in 30 Pages or Less
- Harry Potter and the Order of the Phoenix (Book 5)
 I'm glad to see we're not "all work and no play" around here.
- Living the 7 Habits: Stories of Courage and Inspiration
- Logistics & Fulfillment for E-Business
- On Divination and Synchronicity: The Psychology of Meaningful Chance.
** Simplicity: The New Competitive Advantage in a World of More, Better, Faster
- Simultaneous Management: Managing Projects in a Dynamic Environment
- The Balanced Scorecard: Translating Strategy into Action
** The Blind Men and the Elephant: Mastering Project Work
- The Heart of Change
- The Professional Service Firm 50
- The Project Management Scorecard
- The Weblog Handbook: Practical Advice on Creating and Maintaining Your Blog
hmmm...Maybe I've inspired someone with the idea of "blogging." Cool.
** Work 2.0: Rewriting the Contract
The ones marked with "**" have particularly caught my attention and will probably get a review or further mention here someday. Maybe others will catch yours.

posted by Frank - Permanent Link - |

Friday, August 22, 2003

Friday Fun -- Just finished the DVD set for Babylon 5, Season 3 last night. Eight years later, it's still some of the best television ever, including my favorite quote from the series...
"You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe."
   - J. Michael Straczynski, via his Babylon 5 character, Marcus Cole
(More memorable quotes here, and suggestions for watching the DVD set here on my non-business blog.)

Somehow, I get the sense that Marcus' mindset could serve a project manager well.

(By the way, 10 bonus points to the first person who writes a comment with the quickest connection between the Babylon 5 series and the Theory of Constraints. You don't even have to go through Kevin Bacon.)

posted by Frank - Permanent Link - |

Thursday, August 21, 2003

PMI Congress - September 21-23 -- I just decided to register for the PMI's annual Conference Global Congress 2003 - North America to be held in Baltimore this fall -- not presenting this time, just attending and networking. If any of you reading this are also planning to go, let me know and maybe we can hook up for a face-to-face birds-of-a-feather gathering, informal or formal, Critical Chain focused or crab cake focused. Leave a note in the comments to this entry if you think you're interested.

posted by Frank - Permanent Link - |

A Construction Constraint -- Joe Ely, of Learning About Lean fame, reports on a recent visit to one of his firm's construction sites.
"After some pleasantries, I eased carefully into what I saw at his site on Monday afternoon; activity but no progress. He sighed. 'Yes, that's what you saw. And you know why? The concrete subcontractor only owns enough forms to set 45 lineal feet of concrete wall at a time.'

"Indeed. That was exactly what I saw. One end wall of the basement was about 70-80 feet long and only half of it was formed up. This is a classic illustration of constraints. The crew I saw working aimlessly had a physical constraint limiting their ability to create value for the customer; they had a fixed amount of concrete forms. What do you do when encountering a constraint?"
(read on for Joe's answer, and the deeper questions he brings up...)
It's interesting that once you start to appreciate the concept of constraints and the all-important effect they have on what you are trying to accomplish, you start to see them everywhere. The one that always gets my goat is the decision to set up a buffet against the wall, cutting in half the potential throughput (and delaying my dinner) by eliminating the possibility of two lines serving themselves from either side of the table. (Can you tell I'm on day two of a diet?)

posted by Frank - Permanent Link - |

Wednesday, August 20, 2003

Quote of the Day -- On Systems and Subsystems --
"Always design a thing by considering it in its next larger context -- a chair in a room, a room in a house, a house in an environment, an environment in a city plan."
  -- Eliel Saarinen
That goes for processes and plans, organizations and strategies, as well. (via

posted by Frank - Permanent Link - |

It Ain't the Tools -- Interesting. I just got finished writing a response to a request for a "tool for project prioritization" with the advice not to rely on tools, but on conversations to do such important stuff, when I visit good old Hal's blog, in which he says something along the same line...
"It's time we stopped acting like good technical wisdom is what makes for good project management. It doesn't. Likewise, accountability, authority, and responsibility (someone needs to explain the difference between accountability and responsibility for me) don't make a project manager. Let's try care, guidance, attention, listening, and openness. Now we're getting somewhere!...

"...What might we be able to accomplish on our projects if we put our attention on learning to increase the relatedness of people on our projects rather than studying for the PMI certification exam? Does anyone really think that doing better work breakdown structures will make our projects successful? No one. That's what I thought. How about learning to repair trust between two important team members? Now that would make a difference. Not the role of a project manager, you say? Then who's role is it?"
The incessant online requests for project management tools and templates drives me to distraction as well. The example of the project prioritization tool request implies something that you apply to an undifferentiated pile of projects and delivers a prioritized pile. There ain't no such animal, in my opinion, unless it involves a collection of human brains.

Effective prioritization involves understanding first what is important to the organization in question...its goal(s) and the strategy that has been determined to be the path to achieve it. Very often, I go into a client that has brought me in to help with project management processes, and one of the first things we need to do is to back up a step and get clarity on the interdependent tactical objectives that make up a viable strategic plan. We need to do this in order to prioritize (in many cases, kill and replace) the projects they have on their plate.

So the first cut of prioritization is alignment with strategies and tactics. If designed to ba a useful, living document, the strategy will also include aspects of interdependence and dependence between tactical objectives and the projects and programs that will put many of them into place, relative to one another. Without being able to have meaningful conversations about goals and strategies, many prioritization processes result in situations in which 80-90% of projects land up in the quadrant of "most important/ highest priority."

This is a common symptom of organizations for which what is important globally is not clearly defined by a strategy. Everything is important to some local part of the organization, but as a result, nothing is recognized as important to the organization as a whole. But we can't say that my silo is important and yours isn't -- it's just not polite -- so I scratch your back by not questioning the value of your desires and you scratch mine. A clear strategy will go a long way to getting leadership on the same page, and understand why it is best to delay "my" local interests in order to use scarce resources for "yours."

Again, we come back to the lack of a strategy as the source of this. Such a strategy needs to recognize current organizational constraints, and where the constraint needs to be in order to move to a defined desirable future. The individual silos then can recognize that their important role is to support the plan to address the constraint (which may not be their area, in which case many local "improvement projects" are a waste of time), and come to an honest understanding and agreement on priorities not for local doorknob polishing or phony cost reductions, but for real global improvement in the ability to achieve more organizational "goal stuff."

Without such real understanding of the interdependencies and dependencies of the projects in a portfolio, too many "tools" end up relying on a "weighting factor," some multiplication factor applicable to some ranking process. Personally, I'm not too keen on any such process. If they have any value at all, it is in the inevitable arguments about the factor -- at least then we're getting into what people really think is important. But it you've already got a handle on your vision, values, goals, and strategy, you already know what is important.

Yes there are important considerations and collections of data/information about the individual projects and programs to take into account, beyond strategic alignment, and there is an excellent summary of such useful information in a book I've recently read and that I am recommending all over the place...Advanced Project Portfolio Management and the PMO, by Kendall and Rollins...but such spreadsheets and grids, no matter how useful they are, are not "tools" that produce appropriate decisions. They are only inputs for a decision/prioritization process that best takes place as a facilitated "conversation." that takes into account cost/benefit, risks, use of critical resources, etc. If you need to rely on a "tool" to avoid having the frank, open, and honest conversations about what is important, then the first step -- definitely -- is to assure the clarity of agreed upon goals, strategies, and tactics.

posted by Frank - Permanent Link - |

Market Segmentation -- An example from the computer industry, triggered by the 100,000 orders for the new G5 Mac...
"Apple is Porsche and, I guess, Alien is BMW....That makes Dell the General Motors, HP the troubled Ford and IBM the Chrysler, so to speak...Style rules for a certain buyers, just as in cars..."
How does your company differentiate itself? Who are your target customers? What do you do to appeal to them?

posted by Frank - Permanent Link - |

Monday, August 18, 2003

WaterfallIsSilly -- One last thing for today, before I get back to my project du jour. [A question for Laurent -- What is French for "month?"] WaterfallIsSilly is a wiki-based discussion of the use, misuse, and abuse of "waterfall" project lifecycles. If you've been reading my blog for a while, you'll recognize a number of familiar names providing thoughtful discussion on the topic. This wiki is part of the AYE Conference site. I wish I had the time and funds to join these folks in Phoenix in November. The conference sounds very worthwhile.

posted by Frank - Permanent Link - |

Three Laws of Nonsense -- James Robertson passes along (from his Uncle Noel) "Three Laws of Nonsense"...
1. The source of nonsense is that for every piece of nonsense there exists an irrelevant frame of reference in which the item is sensible.

2. The persistance of nonsense comes from rigorous arguments from inapplicable assumptions.

3. The diffusion of nonsense results from the fact that people are more specialist than problems.
As Sébastien Paguet, who provided the pointage, says, "this is profound."

Number 1 feels like it's related to the conflicts between local and global optimization. Number 2 is reminiscent of previous mentions of invisible dogma and superstitions. And regarding Number 3, I've recently been describing my specialization as "being a generalist."


posted by Frank - Permanent Link - |

Management by Baseball -- While on the subject of metrics, this is the start of an entertaining and wise weblog essay on...
The Seductions (& Giant Sucking Sounds) of Metrics

In business endeavors w/quantifiable results (manufacturing and sales for example) there's a near-erotic fascination with 'metrics'. Measurement with numbers is a great idea I endorse thoroughly, but too many of the folk who create them are not numerate. Those who have a 'tin ear' for numbers are likely to grab onto the most measureable factors or the most well-known numbers or the most obvious (the most obvious are usually the most well-known).

And those numbers frequently are JPI (just plain irrelevant), sapping the organization's mojo and torque in a myriad of ways... on...

posted by Frank - Permanent Link - |

Characteristics of Great Project Managers -- From a well that I go to frequently, Johanna Rothman offers up the best concise list that I've seen in a while of things a project manager needs to do. My favorite is the suggestion that a PM be "able to manage ambiguity."

posted by Frank - Permanent Link - |

Ah, But What to Measure? -- Keep in mind that every process has one or very few (less than 2?) active constraints that limit its performance at any point in time, and that performance is a matter of maximizing throughput -- the rate of attainment of "goal stuff" -- of the system/process. Therefore, while it is true that every link of the process chain is necessary to deliver more "goal stuff," if working at nominal performance -- if there are no out-of-the-ordinary issues in some part of the chain -- the performance of the entire chain is limited by very few key aspects. It's the good old "weakest link of the chain" analogy.

The purpose of measures should be to encourage all the links to do what will help the constraint (or other near constraints) maximize it's (their) throughput and to discourage links from doing things that sub-optimize system performance by hindering the constraint. So measurements of non-constraint sub-processes need to be focused on their support of the constraint's ability to deliver what it delivers.

Measurements of constraints, on the other hand, need to focus first on maximization of throughput (to the extent it is demanded by the processes customer/market), since the throughput of the system is directly related to the throughput of the constraint.
(In project terms, if the goal of the system/process that is the project is to deliver beneficial value, then the time until that valuable ring of the cash register is the constraint, limiting the ability to accrue project benefit. This is usually defined by the longest set of dependent tasks and their anticipated durations to get from today to the cash register, so it's no wonder that much of project management focuses on the critical path or critical chain of the project.)
That said, since the initial question was about measuring processes, be careful to remember that processes generally live in the context of a larger system as well -- the business unit or company. One needs to be careful not to push for measures at the lower level -- the process -- that will get in the way of the ability of the parent system's constraint to do what it needs to do, or for that matter, get in the way of other sub-systems' ability to contribute effectively.

posted by Frank - Permanent Link - |

TOC World 2004 -- My friends at the Goldratt Institute have announced their next big gathering of practitioners of and persons interested in the Theory of Constraints, its applications, and its successes. April 14-16, 2004 at the Mohegan Sun in Connecticut.

The big presentations are usually impressive, but last year, in my opinion, the breakout sessions were the real value of the conference, providing a substantial range of familiar and new tools and techniques that made attendance well worth it for both newbies and experienced practitioners alike. If you like what you read here at the Focused Performance weblog, you should consider attending. (If you do use the web form at the above address to get on their list for more info, use the comments section to tell 'em I sent you.)

posted by Frank - Permanent Link - |

Sunday, August 17, 2003

Tell Me How You'll Measure Me -- and I'll tell you how I'll behave. Over at the Gantthead project management discussion site, a question came up on how to measure processes. After someone else started going off with a cost-focused response, I just had to get up on my soapbox and offer an alternative view, repeated here...

There are two kind of measures, performance and operational. Performance measures are primarily historical (and often calculated well after the fact) and only really good for hitting people over the head well after the horse is out of the barn (cost is an example of this). Operational measures are more about short- and medium-term predictions about the expected outcome of a currently operating process and have the objective of guiding people and sub-processes to do what is right for the future performance of the larger system/process.

An easy example related to the operation of an automobile. Fuel consumption -- miles per gallon -- is a performance measure. Miles per hour, oil temperature, tire pressure, and fuel level are operational measures. For that matter, engine noise can be an operational measure as well, as deviations from the usual noise (deviations like pinging, rattling, exploding) indicate something about the future viability and performance of the car. Additionally, you can obsess about MPG (a cost metric, by the way) to the point that other critical functions -- acceleration and safety -- could be hurt.

Since the past is under the bridge (I'm not saying you can't learn anything from it or use it -- recent fuel consumption rate plus fuel level can give you a rough idea of the current possible range of distance you can go before needing to fill up -- but it does often take too long to be immediately useful), operational measures of active processes are the ones that will do you the most good for impacting the future.

Note my example of variation in operating noise. An excellent book about measuring systems and processes comes from the statistical process control world is Understanding Variation, by Wheeler.

Ahh... but what to measure? A few thoughts tomorrow...

posted by Frank - Permanent Link - |

On Technology Management -- From Quotes of the Day...
"Technology is dominated by two types of people: those who understand what they do not manage, and those who manage what they do not understand."
  -- Putt's Law
But on the other hand, from the same source...
"Have the courage to be ignorant of a great number of things, in order to avoid the calamity of being ignorant of everything."
  -- Sydney Smith (1771 - 1845)
Spoken like a true consultant -

posted by Frank - Permanent Link - |

Tuesday, August 12, 2003

List-o-Links -- Don't have time for extended comments (barely had time to skim and bookmark for future careful reading), but here's a handful of links that I suspect might be of interest to those of you who read this thing of mine...
The Future of Product Development, from the McKinsey Quarterly. A lean, constraint-focused, conversational future. Sounds a lot like Seagate's implementation of critical chain-based project management, via the rss feed of CNET

The Supply Side of Design and Development, from Strategy & Business. What to rely on suppliers to design for you, also via the rss feed of CNET

Agile Project Management: Creating Innovative Products, the start of a set of pdf chapter previews of a new book by Jim Highsmith.

The Threat of Pigeons and Other Fundamentalists, from Fast Company. I've talked a lot in this weblog about erroneous assumptions and invisible dogma that inhibit organizational performance. Seth Godin talks about the same things and calls them superstitions.

Knowledge Center for IT PM, from Hi-Impact Project & Portfolio Management, a growing collection of links and sources for various aspects of IT PM.
I hope these hold you until the weekend.

posted by Frank - Permanent Link - |

Sunday, August 10, 2003

Reason 58 for not Trusting Earned Value Metrics --

posted by Frank - Permanent Link - |

Saturday, August 09, 2003

Projects and Programs Require Managers -- Johanna Rothman links to my recent abridged "Top Ten" list and adds project manager. (I do worry about executive attention to a Top 11 list, given the reason for the restating of the original.) If one is asked deliver without someone identified with the PM role, Johanna wisely suggests asking...
"'What value does this project have for you? Have you ranked this project among the other projects?' Once we start talking about relative value, the other person has a chance of understanding whether it's worth fully investing in the project or not.

"If you have projects you're not willing to fully invest in, stop doing them. Cancel the project. But if you are willing to invest in the project, make sure you've got a project manager or program manager able to manage the project to completion. One person (not a committee) takes the responsibility for organizing, steering, and managing the project. If you're not willing to hire a project manager, don't do the project. Spend your money on something else."
Kind of ties into my #9 (#9, #9 -- sorry, flashed back to 1968 there for a moment); working the wrong project. If it ain't worth doing, it ain't worth doing.


In a related vein, Anders Jacobsen's Dakota Indian tribal wisdom on project management adds nicely to the conversation.
"The tribal wisdoms of the Dakota Indians, passed on from generation to generation, says that 'when you discover that you are riding a dead horse, the best strategy is to dismount'."
(via High Context via McGee via Cubicle Dweller, who I found linked to me on Isn't blogging grand? Sometimes it's like the old childhood game of telephone, with less excuse for distortion and misunderstanding. And if you scroll down on Anders' page, the comments lead to a previous source as well. Would you believe Tom Peters? For some reason, I would.)

posted by Frank - Permanent Link - |

Thursday, August 07, 2003

Giving Something Back - A Global Virtual Classroom -- This is a heads up to my regular weblog readers to expect a lessening of output from me for the next few weeks. I've taken on the role of Project Manager for a new “Global Virtual Classroom” project.

In the late 90's, almost 300 schools participated in an internet-based international program linking elementary and secondary school classes from around the world in collaborative "virtual classrooms." What remains of the old site can be found at this

The original sponsor, AT&T, has turned the Global Virtual Classroom project over to the Give Something Back International Foundation, an international non-profit educational organization. AT&T has graciously given all the rights to the name and legacy materials to the GSBI Foundation. While AT&T will not continue as the primary sponsor, the AT&T Foundation has provided us with a small grant to restart the Global Virtual Classroom project.

We are currently in the process of searching for additional corporate support, but with or without it, later this month, we will be relaunching the program. Admittedly, unless a corporate angel appears, we'll probably be a bit more modest with program features and prizes for the best multi-national team projects, but in any event, we believe the real prize is in the learning and the collaboration of the students.

Focused Performance Weblog readers can help with the effort as well. If you could suggest organizations associated with education in your district, state, territory, country, or region that we might approach to solicit wider participation, it would be greatly appreciated. You could also assist us by helping us identify potential sponsors. If your company could provide support (perhaps through the donation of a few gigs of web hosting space), or if you have any suggestions and contacts for potential sponsors, please let me know.

Admittedly, this is going to stretch my technical abilities (What is MySQL and "server side scripting" all about? And how does one set up controlled ftp access to about 100 individual directories? Threaded forums?), but it should be fun...and rewarding. Wish me luck.

posted by Frank - Permanent Link - |

Top Ten Sources of Project Failure -- The Executive Summary -- A few weeks ago, the Channeling Cupertino blog linked to my old Top Ten List about sources of project failure, and said...
"Given certain . . . constraints in my communications with my immediate superiors at work, I need to find some way to bring this little bit of wisdom to their attention.

"On the other hand, the probable response would be "It's got too many words.""
Far be it for me to prevent my message from being shared due to my verbosity. Hence...the "fewer words" version...
1. Trying to put 10 pounds of projects through a 5 pound pipeline.
2. Expecting perfection.
3. Mistaking 1+1 for 2.
4. Forgetting something.
5. Micro-managing trees while the forest burns.
6. Creating a Parkinson's Law environment.
7. Not using "good enough" resources.
8. Over-using great resources.
9. Working the wrong project.
10. Multi-tasking, multi-tasking, multi-tasking, multi-tasking, and multi-tasking. (Use as few as necessary to be read.)
If that's still "too many words," just give your attention deficit management numbers 1., 3., 6., 9., and 10., or any other combination that sounds familiar to you.

And be assured that Critical Chain-based project management can help deal with all of them.

posted by Frank - Permanent Link - |

Creativity - A Definition -- Embedded in a piece on the frustrations of dealing with the aftermath of nature's fury, Steve Pilgrim offers the following...
"By nature and personality profiling I'm a rather creative type. Don't confuse creative with 'artsy.' I have no artistic skills to speak of. For me, creativity entails pursuing things others say 'can't be done that way.' Often, my response is, 'but what if they could?' In other words, what competitive advantage would you or your business achieve if you actually could find a way to do something that appears unlikely."
This is related to the use of the layers of resistance that says that a vision of value should first be painted before worrying about the obstacles associated with making that vision reality. Only then will one be able to judge the costs of overcoming the obstacles (and the necessity for creativity) relative to the outcome.

posted by Frank - Permanent Link - |

Wednesday, August 06, 2003

A Schedule is Just a Schedule -- from Jack Vinson regarding a previous posting here...
"...explicit acknowledgement of uncertainty in the schedule helps build shared understanding of the health of the overall project."
A nicely turned phrase.

posted by Frank - Permanent Link - |

Project Uncertainty Principle --

...from you know where (08/06/03).

posted by Frank - Permanent Link - |

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


posted by Frank - Permanent Link - |

PMO Themes and Models -- I've recently finished the book I mentioned awhile ago; the subject is PMOs and the title is Advanced Project Portfolio Management and the Project Office, by Kendall and Rollins. I've had time to incubate on it a bit, so I'll start my comments, playing off my recent post about the lack of impressive results from PMOs.

There's a chapter in the book -- What is a PMO and What Should a High Value PMO do? -- that contains excellent descriptions of two "themes" for PMOs (cost containment or throughput improvement) and four basic PMO Models...
1. Project Respository Model (a low or no value model)

2. Coach Model (a tactical model that can provide some value for a short time)

3. Enterprise Model (a strategic model oriented to central control of all major projects)

4. "Deliver NOW" Model (a high-value strategic model focused on throughput, delivery acceleration and choosing the right projects)
These descriptions of what a PMO might want to be when it grows up are worthy input for consideration. It's clear that the PMOs of the Forrester study are likely in the Project Repository Model, serving masters, but not necessarily strategy, and definitely not projects. Obviously the book goes on to focus on putting a "Deliver NOW" model into place, but it does do a good job of describing what can/should be expected (and not) from the other models as well.

posted by Frank - Permanent Link - |

Monday, August 04, 2003

Creativity Techniques -- At a New Address -- A while ago I posted a link to a comprehensive compendium of creativity tools and techniques. The original collector had abandoned it for some philosophical reason, but fortunately, the folks at mycoted (Creativity & Innovation in Science & Technology) have taken in the orphan, and sited it here. If you revisit the list, wander around the parent site a bit. They've got a equally interesting collection of puzzles there as well.

posted by Frank - Permanent Link - |

The Meaning of "Schedule" -- This exploration of the uses and misues of the word "schedule" by Sheryl Smith from (may require free registration) is closely related to what I was going to write as a follow-up to yesterday's piece on late projects and PMOs...the one on the Forrester study that defines project failure in terms of only one factor -- lateness.

This implies lateness of something specific, something planned, something promised -- a product scope, for want of a better term. The agilistas among us are probably going into apoplexy about such a survey, as they tend to do with the hoary old Standish "chaos report" that gets trotted out every time anyone want to point a finger at project management failure in the IT context.

The idea of a fixed scope with a fixed budget and a fixed schedule and due date seems to be anathema to those of the Agile/XP persuasion. Now don't get me wrong. I like agile methods -- they address very nicely a range of issues common to environments characterized by high uncertainty. Some of my best friends are agile. And for that matter, from where I sit (in the Critical Chain PM world located somewhere between the perceived - by agilistas - rigidity of "traditional" project management and the perceived - by traditionalistas - chaos of agility) the idea of fixed scope, budget, and schedule is something that doesn't exist in my reality either. And apparently, it doesn't exist for Smith either...
"An honest, real schedule won't be gospel, and will still slip...A real schedule is hard to predict, and puts a focus on accuracy that some of us don't want to see ahead of time. In our high-stress community, sometimes we expect rewards for busyness and speed, not for accomplishment and quality. People want to believe that longer hours mean more work gets done, whether this is true or not. Managers want to believe that a pushed project finishes faster, whether this is true or not. Studies have cast doubt on both these notions, but the notions live. We're not quite ready yet to give them up."
There may be, or rather, needs to be an initial target scope, budget, and schedule to define an effort as a project and to determine whether or how much of it to pursue. Part of the scope may involve discovery along the way, some of the schedule may seem rather nebulous up front, and the delivery budget may be based on range or as a "not to exceed" target, but they constitute a specific scope, schedule, and budget nonetheless. And they need to be considered as promises until and unless there are rational reasons to do otherwise. As such, they are models of expectations, subject to necessary and appropriate change.

When I hear some of the agile persuasion saying things along the line that when something gets done "doesn't matter as long as it meets business needs" and proudly claiming that this viewpoint is more "agile" than otherwise, I get confused. One one hand, I agree that, in many cases, if the effort is worth doing, it is worth doing. But on the other hand, "business needs" include aspects of timeliness and predictability. As Deming has been known to say, "Management is prediction." Projects -- even IT projects -- don't live in an isolated world of their own, and the highly uncertain parts are being pursued with the idea of delivering something reasonably certain in a reasonably certain timeframe to support a range of business needs, from external promises to customers to the internal means to manage resource capacity and the ability to deliver other projects as well. From Smith...
"High-tech projects are criticized for being "slow"—they're never criticized for being unpredictable. Yet aren't accurate predictions what business needs most? When there is no realistic schedule, people in the trenches conspire to invent one. They have no other choice because they need to do so to plan their work. The actual users want to know what the team in the trenches knows."
And the only way for either to know -- as well as they can at any point in time -- is to compare the reality of the current situation to the model of expectations that is the overarching schedule or plan for the effort.

Sheryl's piece is a definite keeper. The only thing I have to add is that, in her "Schedule=Schedule" section, part of an "honest, real schedule" needs to include explicit acknowledgment of the uncertainty that separates the expectations along the way from the ability to make a reasonable promise regarding final completion of the effort and the ringing of the project's cash register. Things will and should slip or pick up along the way from those interim expectations due to uncertainty and variation, but these slips and pickups are most likely within a reasonable -- and unmanageable -- range of "noise" that is not worth obsessing over. As a model of those expectations that includes a factor to recognize an acceptable noise level (and when it is exceeded), the schedule is a tool for assessing the health of what matters -- the final project promise.


posted by Frank - Permanent Link - |

Sunday, August 03, 2003

Markets - Conversations about Problems and Solutions - From the Linux Journals "Suitwatch" series, in which Doc Searls (co-author of The Cluetrain Manifesto), muses on the use and misuse of the market metaphor, concluding that...
"In the modern world, truly productive companies are staffed by resourceful and inventive employees that strive first to solve problems with available tools and materials, holding costs down as much as possible. They go to vendors as a second, third or even a last resort.

There's a symbiosis between the supply and the demand sides of real markets. But we won't fully understand it as long as "market" continues to mean too many things it's not."
While I enjoyed the etymological excursion about the confusion of markets with demographics and regions, and of my favorite confusion -- that of marketing for "pushing goods" or advertising, the bit about going to vendors caught my attention. The rush to the outsourcing of skilled work is nothing more than reliance on vendors to serve customers -- each of whom someday may start "conversing" themselves and discover they don't need the "middleman" to translate for them.

posted by Frank - Permanent Link - |

Five Lessons You Should Learn from Extreme Programming, which include...
1. Code for Maintainability
2. Know Your Status
3. Communicate Early and Often
4. Do Things That Matter
5. Fix Your Most Important Problem First
The full article (from the O'Reilly site) does a good job of laying out these aspects of Extreme Programming, although if one would consider "maintainability" as part of the objective/scope of the project, the same lessons could also have been learned from the serious application of effective project management as well. (Link via Olivier Travers' Web Voice.)

posted by Frank - Permanent Link - |

Good Agile/CCPM Conversation Continues -- in the comments associated with a recent post. The comment conversation has grown to stand alone from the original post. Join in if you are so moved.

posted by Frank - Permanent Link - |

PMO Effectiveness Questioned -- by this Computerworld article reporting on a Forrester Research survey...
"Most companies have now established project management offices (PMO) to help them enforce standard IT processes during IT/business projects, according to a recently released report by Forrester Research Inc. But many PMOs continue to focus too much time on compiling reports for senior management and not enough on ensuring that projects are delivered on time and within scope.

"That could explain why nearly one-fifth of all new IT project implementations are delivered three or more months late."
Too many PMOs seem to be taking on the role of process cop or high-level recording secretary without getting into what is really needed -- the development of a deep change that brings the "business" and the "IT" together in a holistic culture of projects and project management.
"For purposes of this study, Forrester classified a project as a "failure" if it was delivered one to three months late and affected at least 3,000 end users. According to survey respondents, 19% of their enterprise application initiatives were delivered at least three months late, and another 17% were between one and three months overdue.

"For his part, [Forrester researcher] Pohlmann doesn't expect any dramatic improvements in IT project delivery rates because of what he attributes to IT management apathy. "I think there is improvement that can be achieved, but not from a project management methodology standpoint, because those have been around for years," said Pohlmann. Instead, he said business units have to remain much more involved with IT departments on project requirements throughout the entire life cycle of the project."
Too many PMOs are isolated in the IT shops. They need to come out of their server closets (or they need to be taken over by the "business side") so that they can take a more visible and productive role in the facilitation of the transformation of business strategy into portfolios of programs and projects managed consistently and with coordination.

posted by Frank - Permanent Link - |

Friday, August 01, 2003

Friday Fun - Efficiency Commission Report To Be Late -- From
"HARTFORD, Conn. -- A new panel charged with finding ways to make Connecticut government run more efficiently will release its report six months later than scheduled."
heh, heh. I'm from the government and here to help...real soon now.

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