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, May 30, 2003

Friday Fun - With a Tip 'o the Surreal Bowler to Magritte --
This...

... is not a pipe. (Rene Magritte)

The map...

... is not the territory. (Alfred Korzybski)

The schedule...

... is not the project.

posted by Frank - Permanent Link - |

Thursday, May 29, 2003

Executing the Commander's Intent -- Boyd's OODA -- Interesting, in both Marc's comment to yesterday's item on Commander's Intent, as well as in a link in an email response solicited from my Air Force friend, references were made to John Boyd and his concept of "maneuver warfare." At the heart of Boyd's approach is the OODA Loop -- Observe-Orient-Decide-Act (and then Observe again...). From the linked Air Force Major's paper (written by Jeffery L. Cowan as a thesis at the Marine Corp University)...
"...Important to comprehending the OODA loop is an understanding of its components. The first element, (O)bservation, is the process of taking in and absorbing one's environment. This view would be entirely empirical if the observer could guarantee the reliability and objectivity of the sensors viewing the environment. The second element, (O)rientation, is the most important step in the loop. It is the most easily corruptible of the four steps. Orientation requires the observer to yield to frail human qualities, such as culture, heritage, and, most importantly, previous experience. This is one place in the cycle where there is feedback from previous evolutions. Orientation may be drastically altered based on the experience of success or failure from a proceeding evolution. The third element, (D)eciding, is the cognitive process of selecting a course of action among the options that present themselves from the observation and orientation portions. As Boyd wrote, "In short we engage in a complex process of analysis and synthesis before selecting a course of action ? We assess a variety of competing, independent channels of information from a variety of domains to cope with the particular circumstance which confronts us." The final element, (A)ction, is simply doing the course of action selected in the decision portion of the cycle; however, in some instances it is the most difficult to implement..."
All this is more than applicable to basic management, as well as to project management, especially in an environment of changing circumstances. My friend Tony Rizzo, who I have often mentioned as the person at the "I wish he had a blog" list, put OODA into perspective for multi-project management in a Management Roundtable Newsletter article (Scroll down to "Article 3."). In the article, Tony also makes a case for the synergies between a maneuver warfare approach to information gathering for product development and the TOC Multi-Project Management Methodology to enable rapid response/action.

Back to the Air Force article...
"Colonel Boyd described the ultimate objective of using a superior tempo driven system as the break down of the enemy. To do this one must "exploit operations and weapons that: generate a rapidly changing environment ? and inhibit an adversary's capacity to adapt to such an environment." Utilizing those actions paralyzes the adversary's mechanism for dealing with his foe's increased tempo. The goal of the process can be easily stated: "simultaneously compress own time and stretch-out adversary time to generate a favorable mismatch in time/ability to shape and adapt to change.""
The objective of TOC Multi-Project Management is just that...to maximize the throughput of projects through the organizational system deployed to deliver them. It's not enough for small features of single projects to be delivered quickly to keep the competition off balance, but rather, it requires a continuous flow of disruptive innovation to do so.

While touching on the combined subjects of TOC (what to change - to what to change to - how to make the change happen) and maneuver warfare (observe - orient - decide - act), there is also a good article, originally published in the monthly magazine of the Institute of Industrial Engineers, entitled The Transformation Battlefield - Achieving Organizational Change with Corporate Physics (pdf download). It points out that the ability to orient -- the most easily fumbled piece of Boyd's loop; the piece most susceptible to erroneous assumptions and paradigms -- is enhanced with awareness and understanding of the basic system that you are working in. The easiest route to that understanding is through awareness of the system's constraint and how one interacts with it and with the strategies and tactics to exploit it.

[Later...Since I'm pointing to their site for the pdf above, it's only polite that I should point y'all to some other good stuff on Boyd and maneuver warfare applied to business at the Kettle Creek site. Thanks for the pointer, Ken.]

posted by Frank - Permanent Link - |

Word of the Day -- (for May 29, 2003 -- the contents of the link might have changed)
sempiternal \sem-pih-TUR-nuhl\, adjective:
Of never ending duration; having beginning but no end; everlasting; endless.
May you avoid iatrogenic behaviors -- like multi-tasking to keep your utilization high-- that lead to sempiternal projects.

posted by Frank - Permanent Link - |

Wednesday, May 28, 2003

Commander's Intent -- I've recently been reading, writing, and thinking more about vision, mission, objectives, goals, success criteria, etc., both for businesses as well as for projects. (Obviously the latter must be related to the former to be worth taking on.) One of the core issues that I had planned to write about here is the preponderance of fuzzy vision and its connection to problematic execution. Then along comes one of my online compadres, Joe Ely and his recent piece -- not whining about the failures, but offering a great positive example of clarity of objectives.

His reading about Eisenhower's success as a strategist led him to a conversation with his own nephew about what is known in the Marine Corps as the Commander's Intent, a "(preferably) one sentence, plain English statement of the outcome desired for the mission." Joe also suggests a Google expedition on the phrase and points to a group of examples of the concept.

Good stuff. Check it out.

(By the way, tonight I noticed a new name on my bloglet email subscription list that I recognize -- Ken (I think you know who you are) -- Welcome, and if you've got any input on the subject of "Commander's Intent" and if it has any parallel in the Air Force, I'd be interested in seeing it in a comment.)

posted by Frank - Permanent Link - |

Mutually Exclusive -- Food for thought, inspired by a recent thread on the "tocexperts" discussion group (actually paraphrased from a comment by discussion leader Tony Rizzo)...
Maximum resource utilization and maximum throughput (effective, valuable output) of those resources are mutually exclusive objectives.
'nuff said.

posted by Frank - Permanent Link - |

From Bucky -- A Process of Ongoing Innovation --
"...we witness
over and again
in the whole long mural
that ideas first coming
out of the blue
pass by stages to Industrialization
to sensorial objectivity;
after which the instrumental means
and the end-products themselves
employed or consumed
by unit man individually, --
all trend thereafter
again towards more with less, --
ephemeralize, --
mobilize, --
grow progressively and
increasingly exquisite in precision
and orderliness,
faster, -- less friction
more light
cosmic-to-abstract-to-objective-
to-abstract-to --
back to the blue?


-- R. Buckminster Fuller, Untitled Epic Poem on the History of Industrialization (1962)
...yeah, what he said.

posted by Frank - Permanent Link - |

Monday, May 26, 2003

Who Will Pay for Software? -- A bunch of folks in the blogosphere have been talking about a NY Times Op-Ed piece and Dave Winer's response to it. The gist of the discussion is that...
"...our economy is based on software, more and more, [and] yet users don't want to pay for software."
I may have a simplistic view, but as has often been pointed out in the TOC community -- usually in discussions of dealing with market constraints -- people and organizations don't buy products; they buy (and willingly pay for) solutions to problems. If the software in question addresses a real need or problem, or if it's continued existence and support is critical to the ability to address that need or problem in the future, a value, and therefore a price, can be attached to it, and will be paid.

posted by Frank - Permanent Link - |

Painting a Vision -- OK, while I'm on a roll here today, talking about pulling teams together and about the need for the big picture that surrounds that team's work, here's a few pointers to pieces on why that vision is important (from CIO Magazine), and how to pull it together in a way that is easily developed, communicated, and opened to scrutiny and improvement. Such a vision is a living thing, both the precursor and the result of strategic and tactical initiatives and the reality that they bring about along the way.

posted by Frank - Permanent Link - |

Team Building, What a Laugh! -- From Peter de Jager via HR Gateway...
There isn't a corporate employee anywhere in the world, who at one time or another has not suffered through the indignities of a particular type of "team building" exercise. There is this weird myth that if we can play some "fun" game together without killing each other, then this will increase our future ability to work well together on a real life project. Nice idea, but unfortunately team building isn't a game.

Time and time again I hear managers asking for a "team building exercise", usually with the strongly added condition "it must be fun."
de Jager goes on to question the utility of what probably comes to mind when one hears the phrase "team building." I agree, vigrously and vehemently. I've probably written about this somewhere else before. And if I would have checked first, I would have found that I did, more recently than I thought. But it's worth reiterating.

One of the key contributions of TOC and it's supporting body of knowledge and applications is the integration of the "human and the humane" with the "logistical" aspects of management. It isn't about silly team-building games or outward bound exercises. It isn't about building a team to accomplish things, but rather building a team and enhancing worklife by accomplishing things...

Worth repeating...It isn't about building a team to accomplish things, but rather building a team by accomplishing things.

...Between the thinking and communication tools (appositely acronymable as TACT) of the TOC Thinking Processes, the recognized necessity of the system's policies, processes, and practices to allow the people to do their best work, and the enhanced possibility of flow experience through rational project management practices, there is a lot that can be done to enhance the quality of worklife that is found embedded in this holistic approach to management...

...a lot, that is, while avoiding "the indignities" of yet another "team-building exercise."

posted by Frank - Permanent Link - |

Give 'em the Business -- In a weekly StickyMinds (free registration required) column, Elizabeth Hendrickson talks about the need to get out of your silo (or out of your foxhole, whichever metaphor works for you better) so that you can understand the holistic, company-wide, bottom-line implications of your work. Writing for a software-centric audience (but universally applicable, in my opinion), she suggests to...
Think about the project you're working on now. Mentally examine your part of it, then expand your mind to encompass the entire project. Think about all the groups working on it and what they do. Think about the timeline. And think about the anticipated end result. Got all that firmly in the forefront of your consciousness? Good, because it's quiz time. See if you can answer the following questions: 
1. Why is this project important? 
2. How does it contribute to the long term strategic direction of the company? 
3. How will it improve the company's competitive position in the near term? 
4. How much will it cost? 
5. What financial benefits (reduced costs, increased revenues, etc.) will the project bring? 
6. Who will benefit most from a successful outcome to this project? 
7. What will happen if the project fails? 
8. What capabilities will the users find most compelling and why? 
9. If users don't use this software, what will they use instead? 
10. How well would the majority of the technical contributors on the project answer these questions?
My final question is more personal: how did you feel when you were answering those questions?
Unless there is comfort in addressing these questions, it will be difficult to make really effective decisions about what you're doing. There's a lot of talk these days about conversations in projects, and between the customer and deliverer members of the project team. There also needs to be conversations (and plans) conecting the projects with the rest of the business as well. Otherwise, what might "emerge" might not really be in alignment with the larger organization's needs.

(Actually, as I think about it, the first nine of Elizabeth's questions should all be easily answered by looking in the documents that make up the charter and the plan of the project.)

posted by Frank - Permanent Link - |

Tuesday, May 20, 2003

Little Lessons Along the Way to Lean -- I've come across another weblogger out there, Gary Lister from the USAF, with an entertaining view of "lean" and of continuous process improvement. Anyone who features lean lessons distilled from Andy, Opie, and Barney, not to mention Aunt Bee, is someone worth watching. Watching for what, I'm not sure, but definitely worth watching. An excerpt from May 7...
"Will Rogers said "There are three kinds of men. One learns by reading. A few learn by observation. The rest of them have to pee on the electric fence for themselves."

Coarse allegory aside, change agents sometimes have to help folks pee on a fence. You have to help them learn that, despite their natural resistance to it, change can be beneficial.

There are three basic elements in creating successful change:

1. The desire to change
2. The ability to change
3. The permission to change

The Desire to Change

Most humans will not change their beliefs, habits, or behaviors unless they are motivated to do so. Most will not change, even if change is for the better, unless there is come compelling reason. As long as the perceived rewards of staying as we are remain greater than the rewards of changing, we will likely stay as we are. Or, conversely, as long as the perceived risks of changing are greater than the risks for staying the same, we will be unlikely to change.

The Ability to Change

Then even if the motivation for change exists, people will still need some assistance in changing. Those who ignore the dynamics of human behavior, assume that once people understand the need for change, they will miraculously move in that direction.

What holds us back is our ingrained beliefs and resulting behaviors. You may want to become a participative manager but all your previous training has conditioned you to be controlling and directing and, clearly, in charge. And down deep inside, you might really have doubts about this employee involvement stuff. To change your beliefs and ultimately your behaviors significantly, you will need some help.

The Permission to Change

Finally there is the issue of permission. When a change is personal, we only have to give ourselves permission to change. But when the change is in an organizational context, those in power must grant permission.

You may have the desire to change, and you may have the knowledge and ability to change. But if you work in an environment that doesn't enable you to change, very little will happen. Desire and ability are there, but permission is not.

Many people feel they are constrained by those above them and they don't know what to do. Too many of us throw up our hands and ask "What can I do?" rather than say "Here's what I can do."

What you can do as change agent, is help them change. Help them pee on a fence, if you will. The results will be - dare I say it - electrifying."
Zap!!!

I know I'm going to probably go back to "Little Lessons..." from time to time, and suspect that Gary's work will end up on my blogroll sooner or later.

posted by Frank - Permanent Link - |

Monday, May 19, 2003

More Jobs Than Security Clearances -- An interesting constraint from the Washington Post (via Contingent Workforce.org). While it probably won't help a company that has 20 people and needs 700, effective project and multi-project management might help to increase the throughput of limited resources. Or maybe the Feds might be able to use some help in dealing with bottlenecks to assess and grant clearance to the quarter million people in their pipeline.

posted by Frank - Permanent Link - |

Discouraging Generalizations -- Dale Emery's got a good piece today on "resistance to change," pointing out that...
"The way to become unstuck [in the face of resistance] is to let go of my generalizations, to make contact with what is happening here and now. People resist change? No. This person is responding in this way to this change at this time. If I am to find possibilities for moving forward, the possibilities are in the specifics of this situation."
...and in his (or her...I just realized that I don't know Dale in meatspace, nor have I seen a picture. Although the use of the middle initial is more common in males than females, in my experience..sorry for this parenthetical diversion. It's been a long day.) usual style, suggesting some intriguing exercises on the subject.

Dale's piece reminds me of something I often find myself saying..."Resistance is in the eye of the proposer," and something that I've heard Eli Goldratt say..."There's no such thing as resistance to change; only resistance to the way the change is proposed." (or something like that; I'm paraphrasing.)

posted by Frank - Permanent Link - |

Performance-Based Salaries Don't Always Pay Off -- from HBS Working Knowledge, this article discusses the pitfalls of pay for performance. It reminds me of an experience with a client I had to fire once. Our project management process was clearly indicating what needed to be focused on to keep the big promise, but off on one of the non-critical chains was a milestone associated with a bonus that was negotiated before we put together the project plan, and which wasn't mentioned during the planning process. When they realized that the milestone date (which had no basis in reality, negotiated before any planning) was in jeopardy, the team (and the team leader) then decided the bonus was more important than the project promise. They veered off course, missed the milestone anyhow, and ate up so much project buffer in the process that the important promises were missed. As my friend Tony says, "Tell me how you'll measure me, and I'll tell you what damn fool things I'll do to make the measurement look good."

Keith Ray points to similar messages -- in Inc magazine on sales commissions, and in an interview with the author of Punished By Rewards, as well as a few others. Keith's comments come close to the heart of the matter -- whether there is anything such thing as "individual performance" that can be measured for reward by management. At least my errant client was in a mode of rewarding the team for an accomplishment, but in any organizational/team endeavor, the outcome is much more an effect of the interactions, collaborations, interdependencies, and communications between the individual participants than it is of the contributions of those participants in their little part. Long understood by practitioners of TOC, with only one exception, the performance of a system is not so much a matter of the links but of the linkages in the "value chain" and must be managed -- and rewarded -- as a holistic entity.

posted by Frank - Permanent Link - |

Sunday, May 18, 2003

GlobeAlive -- The World Live Web -- In the words of its creator, Allen Searls,
"If you want static information, if you want documents, if you want data, the web is your man. It can get it for you. Wonderful. But now wait a second! What if you don't want a website? Hmm? What if you don't want static data, or even real-time data, or even interactive data! What if what you want is an actual breathing person? And I don't mean for dating. I mean for all the reasons that people are superior to documents in a world of ends. Yes, the web was designed for documents, but it is entirely capable of connecting people in the same way."
Recently discussed by Seb, Britt, Ming, Euan ("Google with meatware"), and Mark (All folks I read carefully in matters of weblife and webbiz.), GlobeAlive looks to be an interesting potential marketplace of ideas, conversations, and connections.

As a result, you can find me there. You should also be able to find me via a range of appropriate keywords, including "fpatrick" of "fpblog." If you do, and if I'm online, we can chat on subjects related to the stuff you read here, or leave me offline questions. I might not always be online, but I'll always respond to questions. This should be an interesting experiment...see you on the world live web...

(Of course, if you've got a question or interest in doing things that I write about, and you're not into "chatting" via a keyboard, but prefer the old fashioned way, I think you'll find a phone number somewhere on most of my web pages.)

posted by Frank - Permanent Link - |

Saturday, May 17, 2003

Thoughts on Benchmarking -- "If you can't imitate him, don't copy him." - Yogi Berra

And more on the topic, here and here.

posted by Frank - Permanent Link - |

Cause and Effect -- Regular readers of this weblog will know that I'm a fan of the "cause and efect" view of the world -- at least for finite, short- to mid-term analyses situations that encompass most management concerns. This link, while not an organizational management subject, is definitely a great example of cause and effect through an ad for Honda, a la 1987's The Way Things Go and Rube Goldberg.

posted by Frank - Permanent Link - |

Friday, May 16, 2003

Hugger-Mugger and Helter-Skelter -- Today's visit to Dictionary.com's Word of the Day page resulted in this gem...
Word of the Day for Friday May 16, 2003
hugger-mugger \HUH-guhr-muh-guhr\,
noun: 1. A disorderly jumble; muddle; confusion. 2. Secrecy; concealment.
adjective: 1. Confused; muddled; disorderly. 2. Secret.
adverb: 1. In a muddle or confusion. 2. Secretly.
The word itself made me smile and consider it as a possible "Friday Fun" subject, but then it hit me that in strategies or plans, the potential for a cause-and-effect loop between confusion and concealment is real. Then, with a hyphenated h-word in my head, I flashed on another -- Helter-Skelter, which implies to me not only a disorderly jumble and confusion, but also reactive running around to try to deal with it. Helter-Skelter also has its own cause-and effect loop. Here's a couple rough logical sketches...


Note the possible connection between the two, given several overlapping entities, but especially "incomplete analysis" that can turn a hugger-mugger into a helter-skelter and vice versa. For such loops, there are multiple ways out. Clarity of goals, effective plans, thoughtful analyses that uncover hidden assumptions, and Deming's directive to "drive out fear" can help avoid the death spirals, muggings, or finger blisterings associated with hugger-mugger, helter-skelter behaviors.

posted by Frank - Permanent Link - |

Thursday, May 15, 2003

Cutter - Agile Project Management -- Keith Ray noted that Cutter is offering a free download of what they claim is a $150 value. I'll bite. And probably write about it in the future. Again, have a good weekend. Really.

posted by Frank - Permanent Link - |

The Cognitive Style of PowerPoint -- by Edward Tufte. If you've ever seen any of his books on graphical design, you'll know, as I do, that this little pamphlet is probably well worth the $7 he's asking. (Tufte's site also has an interesting discussion board, which I referenced last September, here and here.)

Speaking of PowerPoint, here's a link that should cover me for tomorrow's "Friday Fun" posting. Have a good weekend.

posted by Frank - Permanent Link - |

Wednesday, May 14, 2003

Before the Plan, The Cheeseburger -- Dale Emery points to a PMI San Diego Newsletter (pdf) that contains a good one-page piece by Payson Hall on the value of a Cheeseburger lunch between a project manager and the sponsor/customer of a project. It features a list of 20 questions that can serve as the core of the pre-planning plan -- the initiation of the project and the relationship between th PM and the customer. Dale adds one word to the last question that, in my opinion, brings significantly more value to it. [Later - Actually, he points out that Hall uses that word in his presentations on the subject.] A quickie look at a presentation version on the same subject can be found in this Google cache page.

posted by Frank - Permanent Link - |

Tuesday, May 13, 2003

In Defense of Planning -- "I don't want to get off on a rant here, but..." my initial idea for this post was a response and critique of a committee-written (that should have been a warning) piece entitled Death by Planning, as a great example of strawman setup, knockdown, and re-setup. The authors, in an approach that to some degree, echoes some of the agile/extreme/etc arguements that I've read. Under their provocative title, they start by describing a pair of approaches to project plans that any effective, experienced project manager would describe as non-recommended, bad practice, and then go on to lay out what they claim is a "refactored" approach to planning that that same group of experienced project managers would recognize as established, reasonably good practice. (I would quibble with their questionable use of percent complete to assess task progress, but I like their explicit use of contingency -- I would use buffers for this -- to deal with the inevitable uncertainty in such efforts.) My original intention was to simply call them (and others) on the possibility that their piece might be read by others as a defense of the premise that planning is of questionable use. It may have been minimally used, or erroneously used, or not really used in environments like software or other creative or discovery-based efforts, but that is no reason to throw the baby out with the bathwater. It's not a question of pitting bad practice against good practice, but rather it should be a question of why good practice is not common practice.

That aside, the real danger of such such writing that implies the abandonment of rational management practice is that some people will read the opening statements and deduct that planning and control are useless. Even some blog-friends of mine -- Joe and Hal come dangerously close to skating the same thin ice in pieces that support the notion that "10 minutes of doing is worth 10 hours of planning/discussing." and "substituting some fast learning on our projects for some brilliant planning," I trust that they know how to read the ice, because Hal included the qualifying word "some" in the latter statement and that Joe included a full citation that followed the 10 minute/10 hour statement with "Trying it in cardboard is better than trying to predict it in steel." I fear that too many people will miss the importance of Hal's "some" and fail to recognize that "trying it in cardboard" is merely an alternate means of predicting the steel version, and find themselves falling through the ice.

Planning can take many forms. Shewart included "P" in PDCA, Six Sigma starts with D for Design which is nothing but a model for the process. Goldratt emphasizes first understanding "What to Change" and "To What to Change To" before moving on to determining "How to Make the Change Happen," but still includes that last question as part of a manager's responsibilities. Promises -- project and otherwise -- require rational prediction in the form of models of expectations, if only to understand when and how deviation from the desired direction is encountered when that model bumps heads with reality. An effort that involves more than the simplest set of tasks is a system. It's a system of goals/objectives, deliverables/stories/outputs, resources performing work to that end, and most importantly, the interactions between the pieces of required work. The system is not in the details, but in the dynamics, not in the links but the linkages, not in the ink but in the white space, not in the components but in the interactions between its pieces. Management is an effort of prediction and re-prediction -- and effort to deliver against promises that is a matter of understanding a possible, plausible, and probable model of interactions so that we know when we're hit with the improbable, implausible, and -- yes -- the impossible.

In another recent piece Keith Ray points to that hoary old Standish "Chaos" Study and finds in it evidence that 85 percent of features in IT efforts aren't even used by the customer and points out that...
"If you knew which features the customers were really going to use, You could avoid wasting 85% of your budget, and you could ship 85% earlier than the average software project, getting revenue sooner. Sounds like a win-win for both customer and supplier."
Yes it does. But knowing which features to build and which not to build requires not less planning, but better planning -- rational planning with a focus on the necessary and the sufficient without getting hung up in the unnecessary. Such rational planning doesn't require customer/sponsor "involvement," but their "commitment" (a la the committed pig and the involved chicken in the old ham and eggs breakfast project) from the get-go -- their input, feedback, direction for the goals, objectives, and deliverables of the project, and back-and-forth conversations on possibilities, probabilities, uncertainties and uncomfortableness.

The first of those conversations, based on what Covey would refer to as "starting with the end in mind" is what we call a plan.

"...but that's just my opinion. I could be wrong."

(Nothing like half a bottle of Bonny Doon Vin Gris de Cigare to get the juices flowing...or to force me to go back to the piece six times to fix spelling errors and add missing clarity.)

posted by Frank - Permanent Link - |

Saturday, May 10, 2003

Matching People and Jobs -- From the McKinsey Quarterly, via CNet News.com, a discussion of tools to help management assign and develop personnel slips into the subject of project management...
"As for the IT firm, it could benefit from an emerging class of analytical tools that use complex algorithms and artificial-intelligence techniques to shorten project completion times. By sifting through a database of employee skill sets, the tools generate staffing solutions to meet current demand and to anticipate priorities for emerging projects. The deployment of these solutions at a technology-consulting firm has cut project completion times by 10 percent to 40 percent and overall resource requirements by 25 percent to 40 percent.

A leading provider of data storage used one such software tool to examine a competitive product-development bid that had previously been running significantly behind schedule. Among other things, the tool helped the company anticipate when management intervention would be required, thus all but eliminating the frequent and time-consuming scramble to get management to sign off on major decisions. Indeed, it speeded up the company's bidding process so much that the prototype was delivered on time, ahead of those from competitors, which were forced to drop out of the running for a $300 million contract."
This latter example sounds intriguingly familiar, like Seagate and their use of Critical Chain-based project management with the supporting Concerto software, as reported in rdmag.com...
"Until recently, most of the systems that supported RandD management processes had a distinctly mechanical approach. They captured and cataloged all the tasks, deadlines, budgets, priorities, and so on. Seagate, Scotts Valley, Calif., chose Concerto from Speed to Market because it was decidedly different. It uses proprietary algorithms and artificial intelligence to predict the few tasks or resources that require management attention. As a test, Seagate implemented Concerto on a product development project that was five months behind with five months to go. When the product was delivered on its original target date, lagging competitors dropped out and left Seagate with 100% share--about $300 million in additional revenue. Needless to say, Seagate immediately implemented Concerto throughout the firm."
The original CNet/Mckinsey article chalks up the success to the software, but we all know it's only software that supports superior processes that will deliver superior results. Those "few tasks or resources that require management attention..." should sound familiar to readers of this weblog as the constraints of the project.

posted by Frank - Permanent Link - |

Thursday, May 08, 2003

Ideas, Ideas, Ideas -- Well, maybe not ideas, but a considerably comprehensive taxonomy of over 100 processes designed to develop ideas, complied by consultancy Martin Leith, Ltd. These are broken down into an interesting set of categories, based on three "worldviews"
Worldview 1: The world is a machine...
Inventory making, Combining, Deconstructing, Building, Springboards, Ideas across frontiers, Constraint removal, Laddering, Anchoring and spatial marking, Working backwards
Worldview 2: The world is an ecosystem...
Conversational, Collaborative, Break the rules
Worldview 3: The world is a field of energy and consciousness...
Minimalist intervention, Experiential, Shamanic
The resulting list of processes and approaches is quite impressive, ranging from Roger von Oech's Creative Whacks (Machine/Springboard/Connection Making) to Triz (Machine/Springboard/Pattern Making) to Appreciative Inquiry (Ecosystem/Collaborative) to Zen Koans (Energy-Consiousness/Experiential).

If you're looking to get unstuck from your assumptions and perceptions, this list should be able to aim you at an applicable approach. (Tip o' the hat to Renee Hopkins' Ideaflow (newly added to my blogroll) for this link.)

posted by Frank - Permanent Link - |

Wednesday, May 07, 2003

Death March Redux - Critical Chain Influence -- Edward Yourdon is revising his book, Death March. I'm intrigued and encouraged by the description of Chapter 4...
Critical-Chain Estimating Techniques for Death-March Projects. Why it's so important: along with negotiations, effective estimating is one of the key make-or-break activities at the very beginning of a death-march project. In the rare cases where they're allowed to create their own estimate, as the starting point in the negotiations, project managers need more sophisticated and modern -- and they need to be wary of the secretive attempts of individual project team members to build "buffers" into their own individual task estimates. This chapter explains and discusses the critical-chain estimating developed by Eliyahu Goldratt over the past several years.
I only hope that Yourdon has been distracted by Goldratt's notoriety as originator of the basic CCPM approach and is referring not to Eli's arbitrary "cut in half" approach to estimating, but rather to the resource involving solicitation of 2-point range estimates for both durations and iterations that has been developed by actual CCPM practitioners.

posted by Frank - Permanent Link - |

Tuesday, May 06, 2003

Consultants and Practitioners -- Who Really Drives New Thinking? -- Yesterday, I spent the day at a Project Management Institute (PMI) symposium put on by my local New Jersey Chapter. All in all, it was a pleasant experience, providing an opportunity to network and get in front of potential clients, but as an educational exercise, it was (dare I say "predictably") frustrating.

The symposium consisted of what one probably would expect...a couple of keynotes, a luncheon presentation, five tracks of three presentations apiece, a gallery of "poster presentations," and a collection of paid placement vendors hawking their wares. The keynotes were particularly entertaining, but only touching on project management as a peripheral component of their messages. I walked out of the luncheon presentation when it was clear that it was nothing more than a blatant commercial for their "learning simulation" game. The vendors were doing the vendor thing, offering education or software to support the "generally accepted practices" and certification of PMI members.

That left the presentations to provide new information or learning. Going through the fifteen track offerings, it was tough to find three of interest, given titles like "PM Practices According to Meatloaf," "Turning Engineers Into PMs," and "Are We Having Fun Yet?" With the absence of any real new thinking evident in the proceedings (In which, by the way, I couldn't find any of the following words -- lean, agile, extreme, or critical chain.), I stuck with a Risk Management track, since it's my philosophy that Risk Management is the raison de'tre of Project Management. It consisted of a presentation by on getting executives involved in risk management, an interesting talk about "Project Interdependency Management" in the IT area of the Canadian Department of National Defense, and a case study on the use of risk management in an IT project. I think I chose pretty well, since later in the day, only one other presentation on contract negotiation was offered to my conversation-opening question..."What were the highlights for you today?" The only other one in the schedule that I might have considered was "Establishing a Complete PMO."

But even of the three that I attended, to reasonable satisfaction, only the idea of cross-project interdependency management would have been new to most attendees. So much of PMI's focus is in the management of individual projects that any discussion of multi-project, program, or portfolio management is a refreshing breath of reality. The other risk management presentation were straight from PMI's Guide to the PMBOK, emphasizing the ranking and weightings of probability and impact of risks, or the use of old tools like Monte Carlo simulations. Good messages for those who are not using such practices, but this was a PMI event, where I would hope attendees would be familiar with these basics. In my opinion, they missed the boat by stressing the "addition" of risk management practices rather than the "integration" of risk management into and with the other processes associated with project management. I'm not saying that they were a waste of time...far from it...just that there could have been messages to stretch the attendees' experience a bit more.

Fortunately, at least some of the "poster presentations" -- typically a collection of PowerPoint presentation slide printouts -- did do a bit of stretching. Once I got past the one that suggested a list of activities with associated due dates as a component of "project management basics," I found two in particular that came close to new ideas of general value to project managers. One, by Somnath Kundu of Fi-Tek, LLC, provided a very nice discussion of project reserve, distinguishing what he characterized as "Committed Activity Target" from a "Reserved Activity Target," cleverly discussing "the duty of the project manager to keep the CAT and the RAT apart, in order to make sure there is always some reserve available for the project." Perhaps the concept appealed to me as a parallel to the idea of project buffer in CCPM, but nonetheless, it was a realistic view of dealing with the need to promise rationally, and to protect those promises.

The other poster presentation that I liked was by David Vincenti of BD Consumer Healthcare, entitled "Burn the Gantt! - Tools and Techniques for Crisis and Rescue Projects." His message was about getting out of crises and catastrophes in projects, and to my eye, served as a stealth introduction of lean/agile/extreme concepts, focusing on short term commitments and dedicated team attention to getting out of a crisis. A chat with David regarding this characterization resulted in agreement, but also an emphasis that this was his idea of "good practice" for short term efforts, and that to deal with larger efforts, Gantt charts and up-front planning are still, and will remain, good practice. His presentation included a quote that I warned that I would steal from him.
"The shortest way to do many things is to do one thing at once." -- Samuel Smiles, Self-Help (1859)
It is interesting that the big, carefully juried, expense-paid, consultant-heavy track presentations seemed to be rehashes of the "generally accepted" good practices in project management that PMI is in the business of promoting (Actually PMI's "business" is the promotion of its self-defined brand of professionalism in the subject, but that's a whole 'nother rant.), and that the less formal poster presentations by in-the-trenches practitioners offered the best new insights of the day.

Not what one would typically expect...

...but promising for the future.

posted by Frank - Permanent Link - |

Friday, May 02, 2003

Thursday Night Conviviality -- A gathering of bloggers took place last night at Katz's Deli in NYC (Think Meg Ryan in When Harry Met Sally). A good time was had by all, including Doc and I. Although I must admit that 18 hours later, I'm still trying to digest the good eats.

posted by Frank - Permanent Link - |

Friday Fun -- An Economy for Escape -- In the 30's, during the depression, the movie musical was born and raised to an art form by the likes of Busby Berkeley. Escape from today's economy comes in a different form, delivered by Spidey, Wolverine, Daredevil, and the Hulk. Have fun this weekend.

posted by Frank - Permanent Link - |

Thursday, May 01, 2003

Buyer's Responsibility -- Britt's (and other's) discussions of buyer-seller relationships have brought me to develop a whole new approach to offering consulting services to small businesses...but that's a subject for later. This recent piece from Britt raises the issue of "the buyer's ethical responsibility to embrace the seller and help extend the seller's skills and reputation." It's totally in line with the TOC view of a supply chain as a system...the idea that no one in the chain really gets paid until the final consuming customer puts down their money. So every buyer-seller link in the chain has some level of mutual responsibility for each other.

Some more food for thought from a TOC Thinking Process communication basis... If markets are conversations, shouldn't the topic of those conversations be focused on dilemmas, their proposed solutions, "yes, but's..." associated with the proposals, and eventual "yes, and's..."

Just thinkin' out loud for now.

posted by Frank - Permanent Link - |

An Impertinent Question -- "How Little Can We Do?" -- Johanna Rothman poses a good question. It's all about limiting things to the necessary and sufficient.

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



Google
Web focusedperformance.com


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...

Current
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