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

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

Monday, September 29, 2003

Assume You'll Have Problems... -- An out of context quote from IBM's computer designer Bill Pulleybank in a Fast Company article...
"Assume you'll have problems, assume you'll have errors, and build in the ability to deal with them and keep working."
...that fits very nicely with Hal's recent thread on breakdown-tolerant project environments.

posted by Frank - Permanent Link - |

Saturday, September 27, 2003

Can I put you on hold? -- "Yeah, I'd love to talk to you about aluminum siding/wireless phone service/getting another credit card/your survey/financial planning/long distance/etc. But could I just put you on hold a bit? I'll be right back."

Or not.

heh, heh, heh

(A suggestion from Seth Godin at the Fast Company weblog.)

posted by Frank - Permanent Link - |

Friday, September 26, 2003

Global Virtual Classroom Update -- Earlier this month, I mentioned my involvement supporting the Global Virtual Classroom project. Just thought you might be interested that as we approach the deadline (September 29) for application to the GVC Contest, which will involve teams of three schools from three different countries in web design projects, we've got almost 60 schools from 22 countries signed up. They range from the Upper West Side of Manhattan and Hong Kong to Mali to Uzbekistan to Australia and Belgium. Cool. I can't wait to see what they all put together. We're still looking for corporate sponsors that would allow us to add features for next year's contest and for the "clubhouses" to be opened later next month by helping us get out of a near-free co-op server we're using, and to offer the schools better prizes. If anyone out there has any clout with your company's philanthropic side, send them to the GVC site so they can see for themselves.

posted by Frank - Permanent Link - |

Why More Is Less -- From CIO Magazine, a superb article on one of my favorite topics - multi-tasking...
"Unfortunately, even in the face of the mounting scientific and anecdotal evidence (not to mention individual blood pressure and stress levels) that multitasking doesn't work, companies cling to it like shipwrecked survivors to flotsam. They believe that asking employees to multitask saves them money and time when chances are good that it will do neither. This unintelligent intransigence is all the more troubling because most of us intuitively recognize the problems multitasking can pose. We cringe at the thought of someone operating a lathe while scanning the crawl on CNN or a teenager talking on a cell phone while driving. True, none of us are going to lose a digit or rear-end a minivan because we're typing, listening to voice mail and reading instant messages simultaneously. But as Greenberg says, when one's attention is divided, something's got to give. Companies that see multitasking as part of the solution to their staffing issues are actually making their problems worse and are not, finally, doing more with less. They are doing less with less."
...'nuff said.

I rant on enough about this topic.

And you should get back to your most important unfinished task. And finish it.

posted by Frank - Permanent Link - |

Friday Fun: The Interview Game -- An interesting exercise.

posted by Frank - Permanent Link - |

When New Policies Move the CCR -- (Note: For those of us from the "classic rock generation," this CCR has nothing to do with Suzy Q Rollin' on the River.) David Anderson, author of the new book, Agile Management... (and recent addition to my blog roll), writes about the need to carefully consider changes to project systems. When they have been fine-tuned around the existence of a particular capacity constrained resource, new policies applied anywhere in the system can have surprising effects.
"Introducing a new policy can move the system capacity constrained resource (CCR) and create problems throughout an organization. These problems are foreseeable when a manager understands the effect of policies on the CCR. Policies are a type of constraint. The introduction of a new policy might make it the overall system constraint...When the CCR moves, everything changes. New policies can move the CCR. Changes in CCR should be planned and the overall system-wide effect understood in advance, otherwise chaos ensues, leading to accusations, blame and loss of trust. The introduction of new policies cannot be made locally. New policies should be agreed system-wide after being fully understood by the value-chain of line managers affected."
The key statement in the excerpt from David is that the described problems are "foreseeable when a manager understands the effects of policies on the CCR." Since such a potential constraint is at the core of the ability of the system to do what it does, identifying it, managing it carefully, and considering anything that might impact it need to be among the first things attended to when a proposed change or policy comes up.

This may sound like something new to worry about, but in reality, when constraint and CCR awareness permeates an organization, management simplifies considerably due to the new focus on the leverage point for system performance.

posted by Frank - Permanent Link - |

Tuesday, September 23, 2003

PMI Congress Notes: Managing Software Development Using Extreme Programming (James Goebel) -- Original scope of on-time, on-budget, on-scope is rarely the right scope and rarely results in real project succes.

Kent Beck's simple strategy - Do more of what is working. Do less of what is not working. Perform experiments instead of guessing, measure results.

War room. Pair programming. The process is not intended to solve problems. It's intended to highlight them so that they can be addressed.

Fundamental culture shift, deviation from intention highlighted by comparison with extreme "practices."

Challenging thoughts...

Increase communications by having fewer meetings. (One meeting a day, from 8-5 -- working together. Brief (90 sec per person) daily status stand-up session plus all day interaction.)

Interruptions of bottleneck experts is desirable -- to spread knowledge. (fp - hmmmm...As I've suspected, confirmation that the team is the resource, not the individual; get more out of team by subordinating exploitation of sub-bottlenecks. Iteration is task (project?) Team is resource!!!)

Analysts as stand-ins for users. Answer programmers' questions in real time. (They're in the room, too.)

Work authorization a key component of project control.

Budgeting/Planning process - 1 sheet, 2 people for 2 weeks. Tasks 2 weeks or less.

Developers love to estimate, but fixed-bid commitment estimates get in the way. Clarity of story cards aids estimation (fp - equivalent to clarity of task definitions in CCPM) Update estimate everytime you do something -- you've learned something new.

Break unnecessary continuity!!! Spreads knowledge. Avoids loss of learning.

Completion criteria translates to tests. Must be testable. Write test first.

Effectiveness is not a natural outcome of being efficient. (very small font on big white slide)

Most important part of extreme programming is delivering early and often. A six month project is at least six phases, each delivering more and more of the solution.

Change is documented as storycards are changed, eliminated, and/ore replaced.

PMBOK Guide talks about products and services "progressively elaborated." Do something. Use results to learn and move forward.

Identify things that do not work well. Replace them with something else. Do not assume that the fix is more complex. Try simple experiments and measure results. Effective change often involves cultural change. Cultural change is scary, but you can succeed.

posted by Frank - Permanent Link - |

PMI Congress Notes: Requirements Management for Improved Project Performance (Victoria Kumar) -- Requirements - capabilities that a product must meet to satisfy a user's need to solve a problem. Functional (what it does), non-functional ( quality of doing: performance, usability, reliability). Leading cause of project failure...ineffective requirements management processes (inability to manage scope creep). Requirements -- features, functions -- product scope. Work to deliver them is project scope.

Recommended Requirements Processes - Development (Gathering, Definition, Analysis), Verification, Change Management.

Development - Gathering - Identify stakeholders. Collect known reqs (needs and constraints), clarify, organize, prioritize, record, document. Result...common understanding of users' expressed needs. Tools...workshops, facilitated meetings, interviews, focus groups, JAD performed by skilled reqs analysts and facilitators.

Development - Definition - Requirements Definition Documentation (specs), statement of work, WBS, Use case

Development - Analysis - Discover unknown reqs. Uncover users' needs not expressed. As early as possible in project life cycle. Stakeholder analysis, RDD review/approval, Reqs Traceability Matrix (linking RDD to development plan, functional specs, tests), skilled Reqs Analyst.

Verification - Assures stated reqs satisfied. Analsys of how reqs are addressed in development plan, user acceptance testing (old functions as well as new), validation. Formal acceptance required. Early, continuous, sufficient customer involvement.

Change Management - Change Control Procedure, Board. (fp - More necessary the more detailed you develop reqs up front as opposed to in a JIT manner. I'm beginning to appreciate the agile message more and more.)

Challenges - Unavailable users, too many user groups, no reqs skills, no clear business processes, users can't articulate needs. Can't get out of test mode. Lack of clear acceptance criteria. Buy-in to change control. Enforcement.

Benefits - Opportunity to cross train staff. Discovery of new reqs. Collaboration...

posted by Frank - Permanent Link - |

PMI Congress Notes: Modeling Tough Scheduling Problems with PM Software (Alex Brown) -- Tough problems defined as:

Resource Leveling
Hard and Soft Dependencies
Maintenance of the Schedule

(fp - This presentation was heavily dependent on group case studies, not conducive to note-taking. It's just as well, since the "tough problems" covered are not significantly major concerns in my chosen PM methodology -- Critical Chain. Resource leveling and soft dependencies are dealt with in CCPM through its respect of resource dependencies. The presentation's emphasis of durations that don't coincide with work effort are also less of a concern in the single-tasking, relay-race environment of CCPM. The emphasis on capturing actuals likewise have little to do with scheduling management in a CC project, other than to support learning about estimate accuracy of completed tasks and for capturing costs -- two things that have little impact on the decisions necessary for making decisions about the future remaining part of the project. Rolling estimates of duration to complete active tasks is all that is needed to maintain a schedule. That said, this was a valuable presentation for people who are stuck in non-CCPM environments.)

posted by Frank - Permanent Link - |

PMI Congress Notes: Will Agile Development Change the Way We Manage Software Projects? Agile from a PMBOK® Persepective (Nathalie Udo, Sonja Koppensteiner) -- What is agile?
Intro - usual "agile" list of forces driving change, including "shift of power" from tech to business to partnership regarding acceptance of when things will be ready. Agile core ideas..ability to both create and respond to change..., Chaordic (chaos and order), trust as basis for relationships - cooperation, focus on people and interactions first and on processes second. Agile Manifesto.

Common Agile Characteristics - Ability to respond to change. High priority features first. Short iteration cycles. Testing built in. Product focus over artifacts. Customer focus...

Paper reviews various agile development approaches. Presentation focuses on DSDM and Lean Development.

DSDM - Feasibility -> Functional Model Iteration -> Design/Build Iteration -> Implementation

Lean Development - Strategic focused, eliminate local optimizatin, focus on reducing waste, push/pull - team members pull work from. Seven Principles - Eliminate waste. Amplify learning (by just starting). Decide as late as possible (keep architecture open). Deliver as fast as possible (incremental deliveries). Empower the team. Build integrity in. See the whole (Tour de France not won by winning all stages, not by optimizing every piece.
Contrast with PMI "methodology"
PMBOK - product-oriented processes, PM processes. Claim that PMBOK requires detailed up front planning phase (fp - ???), while agile describes planning as planning of iteration and product increments.

Main difference in planning - PMBOK fixed scope and change control of versus continuing conversation about scope.

Main difference in execution - PMBOK execution/control of plan vs execution of features.
Influence on PM role - More emphasis on external relationships. More people management. Focus on change-tolerant design practices. Eliminate waste. Ensure testing and integration are part of development. Involve deployment, training, and support from start. Leadership skills are key. Remove daily roadblocks. (fp - These are differences???)

Cultural Fit - Emphasis on group, not individuals. Performance focused on team performance.

Embracing change - Requires discipline
Focus on simplicity and waste - Requires interaction with customer
High customer sat - Potential for scope creep

(fp - This presentation made a lot of the same mistakes I did in the early days of promoting Critical Chain Project Management, comparing good practices to common (not necessarily good) practices, and reading too much between the lines of the PMBOK that suggested that those common practices were encouraged by the PMBOK approach.)

posted by Frank - Permanent Link - |

Monday, September 22, 2003

PMI Congress Notes: An Observation -- I was not aware the PMI had a "Troubled Projects" Specific Interest Group. I'm just trying to figure out if it's a recruiting component or if it's an admission of failure of the rest of PMI. ;-)

posted by Frank - Permanent Link - |

PMI Congress Notes: Select and Prioritize Projects with the MESA© (Matrix for Evaluation of Strategic Alternatives) (Michel Thiry) -- Why do we select to pursue the projects we do? They should be based on improving an organization's competitiveness and effectiveness. The MESA© approach assesses projects in terms of benefits and achievability.

Benefits are not automatically available as deliverables of projects. Benefits come from the use of those deliverables. Achievability deals with demand and supply of resources necessary to deliver against the portfolio of beneficial projects.

Decision Science - Typically involves a mix of computer tech, math, statistics, behavioral science, but tends to be process oriented and not get involved in the measurement of the results of decisions. It also tends to use analysts to guide the decision process, who are too often isolated from the actual people/managers tasked with implementing their output. MESA© is designed to be a group process (not based on analysis and decision by an elite staff or management) and based on qualitative value concepts; a systems view of decisions and a big picture framework developed by the stakeholders involved.

Projects need to start thinking not in terms of what the project product is, but what it does. A solution is not the objective...resolution of a problem is. They are not the same.

Value - Two factors. Satisfaction of needs (offered benefits (including options) greater than or equal to expected benefits (critical success factors)) and resources expended (available resources vs required resources).

"It may not seem very important, I know, but it is, and that's why I'm bothering telling you so." - Dr. Seuss

Stakeholder Analysis - Identify and classify stakeholders. Measure their influence on program and its implementation (power and level and area of interest). Determine their needs and expectations: details for key stakeholders, defined and undefined reqs. Axis of questions: why? vs how? Theory and strategy vs means and details. (fp - equivalant to "in order to..., we must..." necessity logic used in TOC) These analyses result in identification of CSFs, which can then be prioritized via paired comparisons (sharing 5 points between each pair), normalized to a total weight of 100.

Identify Alternatives/Elaborate Options - First cut, scored options against weighted CSFs, ranked 1-10 on expected benefits. Options improvement for those not clear winners or losers.

Once relative values are assessed, achievability must be considered.

Achievability factors - Financial, parameters and quantitative constraints, human resources/people capabilities and competence, complexity (innovation, interdependence, number of stakeholders) Use up to 5 sub-factors for each, with clear definitions of high, medium, low scores, translating to scores of 10, 5, 2.5, and weighted for importance for the portfolio being considered. For each option, sum of products of subfactor scores times weightings.

Consider thresholds for benefits and achievabilty. Compare weighted benefit scores (x2) to weighted achievability scores. Grid provides guidance for thinking and actual decision making.

(fp - Not a bad process for weighted matrices, which I usually find too arbitrary and subject to manipulation. Worth looking into further.)

posted by Frank - Permanent Link - |

PMI Congress Notes: Managing Project Maps for Enterprise Application Integration Repeatable Projects (David Davis) -- Maps. A tool to help you plan a journey, make sure you're not lost. Not a compass. Not a GPS. Not an automated checklist. Only useful if current and accurate. Directions, guidelines, topology, landmarks along the way. Helps get around construction detours, unexpected stuff.

Landmarks different for hikers than for drivers than for airplane passengers.

Maps have legends to help you use it, allowing people with different perspectives to translate the map to their needs.

Repeatable project (oxymoron) - combines core business functionality with PM. Uses the same PM principles to bring many customers onto a defined service or business offering. Same thing, but different customers. Same thing, but different service/products. Efficiencies gained from reuse of major project artifacts (items of enduring value). Paradox -- walking the line between projects and operation. Projects supposed to be unique with defined beginning and ending.

Enterprise Application Initiative - Supply chain management. Tying technology and business processes. Electronic bonding. Overlapping functionalities across selling and buying enterprises...account team/vendor manager, PM/PM, sponsor/sponsor, process engineers/process engineers, tech support/app development, customer service/procurement sme. Project info across enterprises and within enterprises. Overlap of internal with internal = damage control.

PMs use project communication to meet needs across various communication systems. Current, consistent, clear, concise, comprehensible content.

Challenges in EAI - Similar but different, language of docs, testing challenges, vocabulary. Distance communication (web/net meetings have improved over conference calls considerably), but still not used day-to-day.

A Project Map - The path, the landmarks, and the legend.The means to define artifacts for business service provided. Definition and workflow of documentation and templates to allow repeatability. Project plan, contact list, template consistency. Relates function to artifact. Assembled from smaller specialized components. Process steps with checklist. Optional diverging/converging paths from which particular projects are built.

Maps used to build a project from a collection of common processes.

Map components - Templates...guidelines. Forms...fixed values, prompts, tags, input of info from external source. (Is this form more complex than just asking the question?) Requirements...record of necessary details, flexible, but with strict rules for use and identification. Storyboard...mock up walk-through, examples of new environment, business centric supported by tech specs. Documentation...static info, usually published, need to help team member focus on what they need to know, challenge to be useful and useable for many circumstances.

Assemble vs Decomposition - Build from components, vs delete from big map.

Developing and Managing - Maps need care and feeding. Depends on support infrastructure. Tracking completion needs audit trail guided by PMO management, sometimes supported by email acknowledgments.

Building your own maps - Audience. Define journeys independent of artifacts. Milestones, Major variables and relationship to artifacts. Major landmark, 30,000-ft view. Needed data, sources. Legend.

posted by Frank - Permanent Link - |

PMI Congress Notes: OPM3 - PMI's Organizational Project Management Maturity Model (Steve Fahrenkrog, William Haeck, Fred Abrams, David Whelbourn) -- (fp - This presentation turned out to be a discussion of the model and its format, and not really about its content. You can stop reading if you're looking for "the beef" of OPM3.) In 1998, PMI recognized that talking only about projects is not enough, launched effort to cover "organizational" project management. Developed in a "maturity model" format, defining a framework for understanding level of development of a process, providing methods to facilitate assessments, identify deficiencies, representations of improvement paths. Hence, OPM3, aimed at meeting challenge of linking organizational strategy to successful consistent predictable project completion.

Organizational Project Management definition (fp - presenter quickly glossed over and moved on to rationale. Seems to be a selling presentation rather than descriptive.)

(fp - Theme of the day) -- OPM3 is something to fill gap between Strategy and Project Management. Three elements: knowledge - the model, best practices and use of model; assessment - methods for evaluating best practices and capabilities; improvement - recommended sequence to develop capabilities, aggregating to best practices ("real strength" of OPM3).

(600+) Best practices defined in terms of (2400+) capabilities. Capabilities demonstrated by existence of particular outcomes linked to key performance indicators. (fp - seems to be yet another linear hierarchy in the xBS mold, but does claim to link dependent capabilities across best practices. If so, that's a positive.) Best practices mapped to domains - projects, programs, portfolios. Capabilities mapped to 5 process groups from PMBOK guide (initiating, planning, controlling, executing, closing). Improvements mapped to four stages, standardize, measure, control, continuously improve. Result is a 3x5x4 cubic matrix to assist in assess, plan for improvement, implement improvements, and review results of OPM efforts.

posted by Frank - Permanent Link - |

PMI Congress Notes: Using Risk Management for Strategic Advantage (Dr. David Hillson) -- Why do projects fail despite risk management? Because we aim risk management too low.

Strategy: Vision --> change --> benefits
Tactics: Projects/Programs --> deliverables --> benefits

There is too often a gap between strategy and tactics. Projects fail because they're not linked to strategy and vision. Projects also fail because benefits of project deliverables are not truly, fully usable, operational to achieve strategic benefits.

Gap is "filled" by clarity of project/program objectives. (fp - Strategic Future Reality Tree?) Contention of the presentation is that risk management sits in that "objective" space between strategy and tactics. Businesses/projects are characterized by uncertainty. Multiple sources of risk. (fp - Coming soon to the PMBOK Guide -- yet another BS. RBS...Risk Breakdown Structure).

Uncertainty is not equal to risk. Risk is uncertainty that matters. It matters in context of having an effect on the achievement of objectives. Plato on the future..."More things might happen than will happen." (fp - And more things will happen than things that matter.)

Business benefits, delivered by objectives, affected by risks, addressed by risk management.

Scope of Risk Management - Tradtionally: processes, technical risks; performance, functionality; people, health and safety; Risk is bad for you. Resulting in focus on tactical threats. Typical RM process - risk planning in terms of objectives, risk identification, risk analysis, risk response planning, risk monitoring and control, feedback.

But problems in limiting RM to tactical threats. Disconnects from strategy and benefits; Deliverable focus; One-way street for responses, back to original plan, and only partial in ability to deal with only threats that take us away from our plan.

Broaden RM Scope to include strategic opportunities. Use standard RM processes to address strategic risk, but different objectives; business case, benefits, corporate, stakeholders. Performing Strategic RM with different people: process owners, risk owners... Build 2-way communication between strategy and tactics. Some things to do. Common language and definitions, common process and formats, supportive risk-aware culture, committed competent professional people. (Risk "maturity.")

Risk dimensions: probability and impact. Impact can be positive. We believe that there are "good risks." Opportunities vs threats. Use familiar RM processes to address opportunities as well as threats. Avoiding, transferring, mitigating/reducing, eliminating become exploiting, sharing, enhancing, assuring. Tweaking standard RM tools, techniques to embrace the positive possibilities as well as the threats. Proactively looking ahead to see opportunities while they're coming and there's still something we can do to capture them.

posted by Frank - Permanent Link - |

PMI Congress Notes -- This is one in a series of notes from the 2003 PMI North American Congress. They will likely highlight things I agree with, although might occasionally trigger my own comments favorable and unfavorable as well.

How to Best Use the PMO to Facilitate Project and Organizational Success (Ginger Levin, Parviz Rad) -- Even organizations that do not consider themselves project oriented organizations are actually project oriented. Are we achieving results? meeting objectives? satisfying customers? Did we get what we wanted, when we wanted, at appropriate cost?

PMs usually describe projects in terms of doing. These are the 10 things we have to do/did. Clients describe projects in term of the end result...what we got.

Typical PMO duties are project oriented, not necessarily results oriented. Two sets of functions...
-- project-oriented (consult, validation and assistance; mentor, side-by-side tutor; augment, fill gaps, "temp agency," aid with non-technical content aspects of project, firefighter)

-- enterprise-oriented (promote, PM culture advocate, making PM "easy;" archive, performance, lessons learned; practice, standards (process cop), best practices customized to environment; train, ongoing training) Project Selection...Portfolio/Pipeline Management as connection of projects to strategy (changing strategies). PMO needs to be placed high enough in organization to have influence on "PM culture." Organizations signal what is important by the top ten people running and influencing the show.
Motivations for PMOs...usually because of project pain, too often resulting in fire-fighting, band-aid modes of thinking. Must transform to forward-looking, strategic mode for real success. Cost of setting up PMO should be thought of like "cost of quality" -- cost of managing for success versus cost of fixing defects and firefighting.

WBS for PMO -- typical hierarchical view (fp - does not define interdependence between the roles), emphasizing ability to track cost of functions (fp - without talking about project throughputs or value)

Lessons Learned -- PMO is a Culture Change; don't downplay difficulty of dealing with culture. Clarity of of functions to be performed and not to be performed is necessary for optimal performance. Metrics and Maturity Assessments make data collection useful for PM process improvement. Acquire Stakeholder Support of PMO from executives and PMs. PMO life cycle...a plan for implementing and improving.

posted by Frank - Permanent Link - |

Saturday, September 20, 2003

A Good Question -- Taken out of context from Jim McGee, but worth asking anyhow...
"All the evidence I'm familiar with says peak performance depends on 'flow.' So why is so much of the practice of management day to day about control?"
hmmm...Perhaps the real role of management is to "facilitate" flow and throughput, and stop worrying about "controlling" (with the linguistic implication of "limiting") it. What deserves "control" is the range of things that get in the way of flow.

posted by Frank - Permanent Link - |

On Knowledge --
"Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information on it."
  - Samuel Johnson
(from QOTD)

posted by Frank - Permanent Link - |

IEEE Members - Read This -- I'm not 100% sure about the makeup of my readership, but if you are a member of the IEEE, please consider this issue from Cory Doctorow. It's not often that the techies among us have such an obviously important social role as making sure our electoral process is safeguarded.

posted by Frank - Permanent Link - |

Friday, September 19, 2003

Live and in Person -- I've been invited to present at the Annual Professional Development Day of the Keystone Chapter of the Project Management Institute, based in Harrisburg, Pennsylvania. The date is October 18th, and I'll be doing two presentations.
Project Management Math Myths - 1+1 Doesn't Necessarily Equal 2 - This highly interactive presentation reviews the impact of natural variation associated with estimates, the schedules derived from them, what happens when they hit reality, and why many projects start out "in a statistical hole" if the scheduling and promising process does not take it into consideration. The presentation walks through the statistical help that a singe chain of tasks can benefit from but often doesn't, the statistical hell of integration points and resource dependencies, and the exacerbating impact of task due dates and Parkinson's Law on the ability to make reasonable project schedule promises.

Enterprise Project Management - Links and Loops from Strategic Planning to Project Management and Back - This presentation discusses the three “meta-processes” that are required for Enterprise Project Management: strategic planning, resource management and project management. It discusses how the development of strategy and determination of priorities are crucial for successful implementation of Enterprise Project Management. It also demonstrates how project management is required to successfully support the organization’s strategies. (If you'd like to see a "graphical outline" of this presentation, you can find it in this post.)
Check out the PMI Keystone site for more information. (And by the way, these presentations are available for other venues as well. Let me know if you're interested.)

posted by Frank - Permanent Link - |

Commitments -- In Hal's current thread on breakdowns, he suggests a rule to...
"Make commitments at the last responsible moment."
As my regular readers know, Critical Chain-based project management has a lot to say about commitments.

Project Buffers are about giving a commitment to a client in terms of a range of time that is refined as the project progresses, or that reflects in its upper limit a not-to-exceed commitment that should be manageable and meetable.

Once piece of CCPM not talked about as often as others -- Resource Alerts -- are perfect for giving the crane provider in Hal's example the appropriate notice at the appropriate time. As Hal points out, the crane provider does not need 5 months notice for a 6 week lead time against a date that is sure to change anyhow. Resource Alerts (some call them resource buffers, but they're significantly different from project and feeding buffers) serve as an "alarm clock," going off at the appropriate time -- in this case, when there's about 6 weeks of estimated work between today and when the crane will be needed. And this is not a one time alarm clock. There's a "snooze button" feature that keeps the crane provider notified of possible changes during those 6 weeks.

Finally, perfectly in line with "committing" at the last responsible moment is the recognition inherent in CCPM that the only dates that matter in the long run are those associated with the Project Buffer-protected commitments. Along the way, short-run (but still malleable) commitments associated with near-in task handoffs (necessary to allow the next resource to prepare to pick up their "baton in the relay race that is the project") are made "at the last responsible moment" are also built into CCPM though regular and frequent (ideally daily) updates on estimates of currently active tasks.

Last night, on the season premiere of Survivor (one of my guilty pleasures, I'll admit), it was pointed out that the contestants should not worry about being voted off the island until they actually are. It ain't over 'til it's over. Commitments may be in concrete, but prudent commitments -- and the prudent planning of subsequent actions that count on them -- must recognize that it isn't necessarily quick-setting concrete.

If the provider of commitments is allowed to commit to best speed possible (and work in a way that supports it) along with appropriate quality, and if s/he provides rolling updates refining those commitments along the way, then specific commitments of when something will happen in the future will be of minimal concern.

posted by Frank - Permanent Link - |

Good (if vague) Advice -- Randall, author of one of my favorite non-business weblogs, includes in his site several photo galleries. This one caught my fancy today, as it's related to recent comments here and here.

posted by Frank - Permanent Link - |

Thursday, September 18, 2003

Managing for Murphy, Satan, and Yourself -- OK gang. I suppose that's what I get for sharing that big pretty picture the other day. I got so caught up in discussing the metaphor of the medium, I almost missed the message. This week Murphy's Law comes in the guise of someone named Isabel. As a result, I just spent a few days at my south Jersey shore house battening down the hatches for the coming storm. Fortunately for me and my neighbors, it looks like we'll get by a lot better than those down in North Carolina. Best of luck to y'awl.

Coincidentally, this week, thanks to some wide-ranging wanderings in weblog-land, I came across an interesting piece that also fits with Hal's discussion of breakdowns. In a discussion of designing for security as well as for accidents, Bruce Schneier writes in his Crypto-Gram...
"At a time when we're worried about attacks -- by terrorists, hackers, and ordinary criminals -- it's worth spending some time talking about accidents. [...] Some years ago computer-security researcher Ross Anderson described the difference as Murphy vs. Satan. Defending against accidents, he said, means designing and engineering in a world ruled by Murphy's Law. Things go wrong because, well, because things go wrong. [...] Security is different. In addition to worrying about accidents, you also have to think about nonrandom events. Defending against attacks means engineering in a world ruled by Satan's Law. Things go wrong because there is a malicious and intelligent adversary trying to force things to go wrong, at the very worst time, with the very worst results." (via Universal Rule)
Murphy and Satan are two very real sources of breakdowns, but there is a third. It's you...

You've fixed something in the past, but conditions have changed, and you didn't adjust your fixes.

You feel caught between a rock and a hard place and either compromise, creating threats from both sides, or attack the hard place, only to have the rock roll on over you.

You recognize a risk, but fail to do anything about it, hoping that if you ignore it, it will go away.

You continue to do the same things that got you into trouble before, hoping that you'll get different results this time.

You've done something very worthwhile to address a hot problem, but failed to think about possible side effects.

You storm down the hill to inevitable success, but fail to consider what could go wrong if you actually succeed...or succeed beyond your wildest dreams...into a nightmare.

You feel compelled to provide an answer and, with false bravado, take a (hip)shot at one, only to think about why it was wrong...way wrong you're ashamed to face up to it...after everyone starts taking actions on your answer.

Do any of these sound familiar? I know some sound familiar to me. Whether you call them foot-shootings or iatrogenic reactions (I love that word), it's not really effective to blame poor Murphy or Satan. It may make you feel better to think that the undesirable outcomes were inevitable or that someone was out to get you, but if there were things that you could/should have done and didn't, you miss a great opportunity to learn...and to avoid making the same mistake again later.

posted by Frank - Permanent Link - |

Wednesday, September 17, 2003

On This Date in History --
"Signed on this date, September 17, in 1787, a document embodying the fundamental principles upon which the American republic is conducted." (via
Now there's a plan worth sticking to...or amending as necessary.

posted by Frank - Permanent Link - |

Sunday, September 14, 2003

Deep Thinking About Variation and Breakdowns -- Hal Macomber has started an interesting series of posts on the subject of "Variation as an Enabler." After considerable commenting going on about his first part of the series, the second points out that...
"We call an event or incident a breakdown when we are interrupted in the midst of going about fulfilling our commitment."
Exactly. Breakdowns (problems) only exist in terms of getting in the way of achieving a goal. Additionally, they always involve some sort of dilemma or conflict, forcing us to consider doing something we would prefer not doing. A deeper question is whether that dilemma is real or illusory; whether the rock is immovable and the hard place impervious, or whether they only seem so in terms of a faulty understanding of the situation.

Hal promises to continue with a discussion of "avoiding breakdowns." It'll be interesting to see where he's going to go with that topic, as I would contend the vast majority of avoidable breakdowns are encountered due to iatrogenic sources, induced by previous "good intentions;" a source similar to that that makes the aforementioned dilemmas seem real.

posted by Frank - Permanent Link - |

Friday, September 12, 2003

Predicting Uncertain Futures -- James Vornov points out a beautiful example of talking about prediction in an uncertain situation.

When I explain modeling and simulation I often use as an example the atmospheric models used for forcasting. Here's a nice graphical representation of how uncertainty can be represented graphically. You can see the deterministic historical event which is a line through space. At the point representing "now" the line becomes an area. The degree of uncertainty is represented by the increasing area with times further in the future.
Translating to project management, the deterministic line is equivalent to completed work. Looking into the future, we move from points in time to ranges of time within which we can expect completion of a project. The further out we look -- the more work subject to uncertainty that remains -- the wider the range of promises needs to be. As the leading edge of the projected path of the storm starts touching land, that could relate to having the maximum of the range of project promise exceeding the desired due date.

The same way that prediction associated with the map above is important to those living in the potential path of the storm, prediction associated with projects is important to the business and it customers, users, accountants, and lawyers. This is exactly what buffers are all about in a Critical Chain schedule. They represent a range of possibilities for the duration or cost of a project, reflecting best current guesses about an uncertain future with a current, dynamic view of buffer needed for remaining work versus an original buffer and target due date for the entire project. And like the map, provide an easy-to-understand picture of the currently understood cost and/or schedule risks associated with the project.

posted by Frank - Permanent Link - |

Thursday, September 11, 2003

Two Years Ago - A Goal for Our Time -- My piece from the time of the attacks includes a quotation from an earlier time of conflict and closes with...
A clearly stated and consistent vision and goal, such as this from [FDR] 60 years ago, is critical to the management, support, and success of any effort, whether in our personal lives, our companies, or this larger context. It may never be reached in absolute, but is worthy of focused striving. The terror that is the current constraint inhibiting this goal is a self-supporting symptom of the difficulty associated with attaining this goal in the complexities of a modern multi-cultural world. In dealing with the immediate symptom, we must do so keeping in mind the larger, long-term goal of universal freedom.
And as has been demonstrated in the two years since, this universal goal can best be achieved if we can learn to work together with others and avoid over-obsessing on our own short-term, local objectives of power and politics.

[Later...An eloquent comment from Wil Wheaton]

posted by Frank - Permanent Link - |

Wednesday, September 10, 2003

Wally as Project Manager -- 'nuff said.

posted by Frank - Permanent Link - |

Friday, September 05, 2003

Global Virtual Classroom -- A while ago, I mentioned a project I was getting involved in. It's the Global Virtual Classroom project of Give Something Back International. It's a program that is aimed at providing opportunities for cross-border, cross-cultural collaboration and communication between primary and secondary school students. The cornerstone of the initial launch is a website design contest in which teams of three schools from three different countries will work on web projects from October through February. In another month or so, we'll be launching the second piece of the project, a Clubhouse that will allow for similar projects, but without the restrictions or structure of a contest.

We are particularly interested in drumming up participation from outside the US (we expect plenty from these shores, and need at least twice as many non-US schools to form the contest teams without duplication of country in a team). So I am calling upon my international readers to please consider passing information about the Global Virtual Classroom to teachers and schools in your part of the world.

And fellow bloggers...since we're trying to get the word out widely, a link would be appreciated. It would be very cool to see the Global Virtual Classroom make it into Technorati's top stories.

posted by Frank - Permanent Link - |

How to Look, Where to Act -- This 1997 Whole Earth article by Donella Meadow (actually titled Places to Intervene in a System) ties in nicely with my other posts of today. The idea of looking both ways, and then going through the red light anyhow is reflected in the following excerpt...
"Folks who do systems analysis have a great belief in 'leverage points.' These are places within a complex system (a corporation, an economy, a living body, a city, an ecosystem) where a small shift in one thing can produce big changes in everything.

"The systems community has a lot of lore about leverage points. Those of us who were trained by the great Jay Forrester at MIT have absorbed one of his favorite stories. 'People know intuitively where leverage points are. Time after time I've done an analysis of a company, and I've figured out a leverage point. Then I've gone to the company and discovered that everyone is pushing it in the wrong direction!'"
I've felt the same frustration -- quickly identifying the constraint, and then observing everything wrong being done to mismanage it. Sometimes it is hard to see the forrest when you're bumping into trees every time you turn around. Until and unless you get in the habit of thinking in terms of whole systems, it often helps to have someone else pull you out of the woods a bit so that you can identify where it is you want to go and compare it to where you're going.

Meadow offers several breadcrumb paths to start thinking about managing your system (summarized by Ross Mayfield, who aimed me at the article)...
(in increasing order of effectiveness):

12. Constants, parameters, numbers (such as subsidies, taxes, standards)

11. The size of buffers and other stabilizing stocks, relative to their flows

10. The structure of material stocks and flows (such as transport network, population age structures)

9. The length of delays, relative to the rate of system changes

8. The strength of negative feedback loops, relative to the impact they are trying to correct against

7. The gain around driving positive feedback loops

6. The structure of information flow (who does and does not have access to what kinds of information)

5. The rules of the system (such as incentives, punishment, constraints)

4. The power to add, change, evolve, or self-organize system structure

3. The goal of the system

2. The mindset or paradigm out of which the system - its goals, structure, rules, delays, parameters - arise

1. The power to transcend paradigms
That last one -- the most powerful, by the way -- is the theme for the day. The ability and willingness to question what one is doing is the source of all improvement.

(Something tells me this is not going to be the last time you see the Meadow piece mentioned here. Plenty of good food for thought.)

posted by Frank - Permanent Link - |

Questionable Practice -- The Big White Guy offers the following observation...
"In Hong Kong, a good driver is defined as someone who looks both ways as he goes through a red light."
How often do managers suspect there is a better way, collect all sorts of possibilities, but then continue on through their red light?

Way too often.

posted by Frank - Permanent Link - |

Working Smarter - Managing Smarter -- David Anderson, author of the forthcoming book, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (due to be released September 22, but available at amazon for pre-order), has started his own weblog. In today's entry, he asks a couple developer friends...
"'If costs in Bangalore are about 1/4 those in Seattle then all you need to do is improve productivity 4 fold to compete.' One of the developers was stunned by this. He is a hard working, smart, diligent guy. How could he possible work 4 times harder? Good question.

"I replied that if you have an initial quality metric of 3 bugs per Feature and you cut that to say 0.5 bugs per Feature by spending 15% of your effort on design reviews, code reviews and unit tests, then you will increase productivity 4 fold - easy! And this is just scraping the surface of what is possible. Eliminate all sorts of waste such as - queuing and waiting time, conflicts, use automation on repeating process and non-value-added activities such as reporting, improve analysis techniques to focus just enough and no more, improve flow in the value chain and reduce work-in-process. With all of these things it is possible to see up to 10 fold improvements with initially immature teams."
Actually one of the former units of Lucent -- one of the units with enough value to attract a buyer at a good price a while ago -- tripled their project throughput by with no significant increase in resources by implementing effective (TOC/Critical Chain-based) multi-project management in the first year, before any further continuous improvement efforts, which were now feasible due to the lessened overload stress.

Two of the items that David mentions -- queuing and waiting time, and conflicts -- are huge capacity killers in most project environments. Their major sources -- multi-tasking, Parkinson's Law, mismanagement of resource expectations, ineffective pipeline management, and unclear and conflicting priorities are things that management can deal with to make outsourcing an unattractive alternative. Add in a bit of common sense at the technical task level, and David's prescription of a 4-fold improvement in productivity is well within reach even of relatively mature team.

It's not a matter of how to do it. That has been demonstrated in a range of environments.

It's a matter of the will to question what hasn't really worked to date...

   ...before the people to whom you outsource beat you to it.

posted by Frank - Permanent Link - |

Not So Funny Friday Fun --

posted by Frank - Permanent Link - |

Thursday, September 04, 2003

Quote of the Day - On New Ideas -- (from
"New ideas come into this world somewhat like falling meteors, with a flash and an explosion, and perhaps somebody's castle-roof perforated."
  -- Henry David Thoreau
Look out below!!!

Speaking of Thoreau (and his contemporaries), check out the Christopher Lydon's audio weblog. Lydon was my favorite Public Radio interview show host a few years ago when he was at the helm of "Connections." He's moved to the web and has been posting mp3 files of interviews with an interesting collection of folks, ranging from a series on weblogs to James Gleick (Chaos, Genius, Faster) about his new Isaac Newton book, to the Howard Dean campaign (Take Back America!). Today, he adds Harold Bloom, my favorite curmudgeonly Yale literature professor and defender of the dead white man's canon of western literature. The topic with Bloom is Ralph Waldo Emerson -- hence the connection to Thoreau. Check out Lydon. and download a few of his mp3s. They're better listening than Christine Aguilera or Justin Timberlake -- way better.

posted by Frank - Permanent Link - |

Wednesday, September 03, 2003

Finally Found It -- Been looking for this old Utne Reader cartoon for a very long time. Serendipitously stumbled upon it on a day that it fits another one of my posts...

posted by Frank - Permanent Link - |

Quote of the Day - On Assumption Busting -- From today's QOTD...
"There is absolutely no inevitability as long as there is a willingness to contemplate what is happening."
  -- Marshall McLuhan (1911 - 1980)
The TOC Thinking Processes includes tools for contemplation of what is (or might be) happening -- Current Reality Trees, Future Reality Trees and Negative Branch Reservations. By describing the anticipated system of cause-and-effect in a way that can be easily scrutinized, assumptions of inevitability can be surface and validated or invalidated. That's good news, considering the things to worry about these days.

posted by Frank - Permanent Link - |

Live and In Person -- If you're reading this blog from the Southeast Pennsylvania area (near King of Prussia), you might appreciate knowing that I'll be speaking next week on September 10 at the APICS Pottstown Tri-County Chapter dinner meeting. The topic is Taking Advantage of Resistance to Change. Info about logistical details and reservations can be found at the chapter website.

posted by Frank - Permanent Link - |

Bloglet Back Up -- If you've been trying to subscribe to this weblog via email, the service is back up. Someone even subscribed yesterday.

posted by Frank - Permanent Link - |

Fuzzy Lines -- From The Tragedy of Coloring Books by Dave Weinberger...
For the past couple of years, I keep coming back to edges: how few of them there are in the world, how digital technology is founded on bits that are nothing but edges, how the online world overcomes the edginess of the technology that enables it, and how messiness is an ontological property: Reality is a mess.
The sharp focus that many try to apply to edges, and the desire not to go outside the lines that they form, carries over into the management of organizations and projects as well. The sooner everyone realizes that the search for precision where there is none, be it in profit projections or project management, the better. One of the phrases that I find myself using a lot is, "Face reality!" And as Dave points out, that "reality is a mess." Describing it as otherwise doesn't make it so.

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