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, October 31, 2003

Estimates Are Not Commitments -- Earlier this month, in Promises, Predictions, and Planning, I touched on my ongoing theme of the oxymoronic "accurate estimate," and the importance to differentiate between what might happen if one gets lucky with an effort and what could happen if one doesn't. It's necessary to take both into account when making promises and plans. Dale Emery underlines the point...
"The essence of an estimate is expectation. When you give an estimate, you express your expectations about what will happen. Built into each estimate is an element of uncertainty. If you weren't uncertain, you would use a word other than 'estimate.'

"The essence of a commitment is promise. A commitment is a pledge or promise. When you make a commitment, you declare your intention to create some result, and you invite someone (usually another person, but sometimes yourself) to rely on your intention."
Dale goes on to advise clarity of one's request when there might be some confusion between the two. Too often, estimates are treated like commitments, "managed" to assure their accuracy, and in the long term develop a severe case of bloat as the estimator/deliverer endeavors to protect those commitments. What is lost in this situation is the opportunity to think in terms of what one might accomplish (rather than what one commits too) and perhaps manage the situation to actually do so.

You can run a lot faster if you don't feel compelled to cover your ass.

posted by Frank - Permanent Link - |

Nice to See Some Things Going Right -- From the Washinton Post: Military Uses Hussein Hoard For Swift Aid; Red Tape Cut, Cash Flows to Iraqi Contracts...A very nice example of close to the customer, decentralized decision-making and agile action for rapid effect, doing apparently quite well in a bad situation. Hopefully, the intention to continue it with budgeted funds (and maybe the bureaucracy that usually follows them) won't get in the way.

posted by Frank - Permanent Link - |

Thursday, October 30, 2003

A Portfolio of Project Portfolio Management Links -- While I'm incubating on the important portfolio and prioritization entry for my Enterprise PM series (which has already touched on Project Planning and Promising and Strategy), I thought I'd share the way too many links I've collected over the past few months.

- Enterprise Project Management and the Theory of Conscious Alignment
- Portfolio Management - How to Do It Right
- Right People - Right Projects - Right Time
- Powerful Portfolios
- Lessons From the Field - What State and Local Governments Can Teach Feds About Project Management
These were all triggered by the first in the list, from David Fletcher of the State of Utah. It makes a lot of sense that in these days of state budget crises in the US, the need to carefully pick and choose the contents of a portfolio is at the top of his mind. The "Right People" link is to a page that offers an excellent video (in realmedia format) on linking strategy, culture, and project portfolio. The interesting bit is the inclusion of rankings for cultural alignment as well as the usual strategic.
- Chosing Projects: Selfish Goals
- Picking and Choosing
Jack Vinson's "Selfish Goals" posting points to one on "Picking and Choosing" projects in the context of product development in general and drug discovery specifically. I particularly like the almost contradictory advice to "avoid 'sure things' at all costs" and to "avoid projects that have multiple 'and then we get lucky' steps."
- The Three Legs Of Portfolio Management
A short piece emphasizing "fit, utility, and balance."
- Portfolio Power
- Working the Numbers
- Project Portfolio Management Starter Kit
A few pieces from Gantthead, including a rudimentary Excel template (free registration required). The "Working the Numbers" piece touches on metrics used to assess portfolios.
- Getting Your Project Priorities Right
- Which Projects are Worth Your Time?
- Project Portfolio Management
A handful of IT/Technology portfolio pieces. But keep in mind that the real portfolio that needs to be managed in an organization goes far beyond just the tech stuff.
- The Project Portfolio is the Truest Measure of Organizational Intent
- Aligned For Change
- Connecting the Dots: Aligning Projects with Objectives in Unpredictable Times
A summary, and article, and a book about/from a pair of authors that gets into the all-important issue of strategic alignment of project portfolios.
- Project Portfolio Management
A high level presentation on the topic from Max Wideman.
- Portfolio Knowledge
- Bringing Discipline to IT with Project Portfolio Management
- Why Corporate Leaders Should Make Project Portfolio Management a Priority
A trio of links from folks trying to sell you PPM tools, but still worth a look.
- It Ain't the Tools
No false modesty here.
- Strategic Navigation: A Systems Approach to Business Strategy
- Advanced Project Portfolio Management and the PMO: Multiplying ROI at Warp Speed
A couple books I've mentioned way too much in this weblog, but for good reason.
There's even more, but this is probably enough to keep you busy. Watch this space for my take. Coming soon, unless someone out there hires me for an intensive engagement to implement the kinds of things I talk about here. If what you read here makes sense, go ahead and introduce me to your boss. I dare you. After all, without billings, it's just a hobby.

posted by Frank - Permanent Link - |

From Data to Power -- Via a summary by Jack Vinson, this piece draws a hierarchy of Data, Information, Knowledge, Intelligence, Wisdom, and Power, which I generally buy into, although while some forms of power can result from the progression, the acquisition and wielding of power does not necessarily require wisdom if based in physical might or in flawed paradigms. Of course I suppose that intelligence and wisdom in some area, such as rhetoric and human behavior, could overwhelm the lack in other areas.

posted by Frank - Permanent Link - |

Tuesday, October 28, 2003

Linkage Lagniappe -- My roughly monthly disgorging of random links I've gathered and want to share before they get stale, but for which I don't have time to devote full postings...

Three Signs of a Dysfunctional Company by Joanna L. Krotz...
1. You've got leaders who fake it.
Lesson: The discrepancy between what leaders say they want and what they really want often causes company dysfunction. You can't ask employees to do anything you're not willing to do yourself.

2. You've got bosses who like to point fingers.
Lesson: The remedy is to put your trust in the people you hire and give every employee sincere responsibility. Hands-on, my-way-or-the-highway entrepreneurs won't find this easy. But that's how the business gets better.

3. You've got a CEO who doesn't set priorities.
Lesson: Company leaders must set the mission and the agenda. A hands-off policy can only go so far.
Wikipedia on Critical Chain
A user modifiable online encyclopedia.
Innovation and Small Worlds: Bridging vs Merging
"In order to create innovativion, we don't need to merge or erase the gaps between groups of people and their ideas — we need to bridge them in a way that preserves the ambiguity that created the gaps in the first place."
The Project Carcasses that Litter the ICT-Dev Landscape
Yet another litany of why/how projects go bad, but from a different venue this time -- international development.
Modeling Project Management
From Max Wideman, a fascinating review of graphical "models" of project management from the late eighties to the "new century." An interesting read, despite the disappointing final "mind map" model that is nothing but a linear outline with items and arrows, providing no real appreciation for the holistic interactions between components.
Learning Communities and Learning Networks
"Most of us belong to more than one learning community. These multiple communities form a personal learning network . If a learning community equates somewhat with a course, then our learning network is equivalent to a degree program. Each community is a node on the network."
Control: A Metaphor
Project Schizophrenia
Seven Maladies of the Project
Skills Obsolescence
Four good pieces from Laurent Bossavit
Technical Debt
Pay me now or pay me later.
Supply Chain's Growing Pains
SCM -- cross-silo process management.
That should be enough to keep you busy for a while.

posted by Frank - Permanent Link - |

Enterprise/Multi Project Management and How to Make it Happen -- I'm putting the finishing touches on a 1/2/3-day seminar/workshop/course that starts with Enterprise PM and the PMO (Day 1), digs into details of Pipeline and Multi-Project Management (Day 2), and finishes up with how to implement these PM concepts in high-uncertainty environments like software, R&D, or product development (Day 3). Offered as a full 3-day course ($1,200), combinations of days 1 and 2 or 2 and 3 ($900), or stand-alone versions of day 1 or day 2 ($500) I'm shooting for an early December roll-out. If anyone is interested, let me know so I can decide whether to do it near those who are interested or just do it within shuttle distance of Newark Airport.

posted by Frank - Permanent Link - |

Friday, October 24, 2003

Weekend Wanderings - Henry Petroski - With the passing of Lewis Thomas and Stephen Jay Gould, I've had to find a new favorite author for non-fiction non-managerial subjects. Given my tech/engineering bent, civil engineering professor Henry Petroski seems to be quickly rising to the top of my list of possible replacements. While his subjects come uncomfortably useful to my work thinking (as did Gould, surprisingly, from time to time), they are delivered in a too entertaining way to feel like work. The books of his that I've read include...
To Engineer Is Human: The Role of Failure in Successful Design

Design Paradigms: Case Histories of Error and Judgment in Engineering
...See the theme in those two titles? (S**t not only happens. Sometimes it helps, sometimes it doesn't.)
Invention by Design: How Engineers Get from Thought to Thing
...Where do designs come from, anyway?
The Book on the Bookshelf

The Pencil: A History of Design and Circumstance
...The assumed natural design of everyday things.

His latest, Small Things Considered: Why There Is No Perfect Design, looks like a prime candidate for next on my bookshelf. According to Publisher's Weekly's review at, "...his latest effort, a wide-ranging exploration of the history and design of the everyday technologies like supermarket aisles and telephone keypads that are practically invisible in their ubiquity. Petroski emphasizes that these "small things" aren't in fact the results of a smooth and simple design process, but are rather the products of a constellation of oft-conflicting constraints, frequently with unintended consequences (consider the recently redesigned, fat-handled toothbrushes that, while more ergonomic, have rendered millions of traditional toothbrush holders useless)." His themes surrounding engineering and design make one all the more appreciative of the serendipitous successes and "good enough" failures we run into every day.

posted by Frank - Permanent Link - |

Friday Fun - A Logical Card Trick -- From Dave Weinberger:
"You are in a pitch dark room. You are handed a deck that has ten cards turned face up shuffled into it. Your job is to sort the deck into two piles, each of which contains the same number of up-turned cards. The solution involves no night-vision goggles or the ability to read through one's fingers. It's just so damn clever that you're going to go D'oh when you..."
...go to this Joho the Blog entry for the solution.

posted by Frank - Permanent Link - |

Thursday, October 23, 2003

Quote of the Day - Not Invented Here --
"If you want to see the future coming, 90 percent of what you need to learn, you'll learn outside of your industry. There is nothing that you can learn from inside your industry that will help you get ready for the future. Literally nothing, because you already know it."
-- Gary Hamel, author of Leading the Revolution
(via The CEO Refresher via the Creative Generalist)

posted by Frank - Permanent Link - |

Stage Gates and Critical Chain -- In a recent Sciforma Q&A column by Harvey Levine, the following question and answer about stage-gates, critical chain-based project management, and milestones appeared...
"I work for an Electronic High Tech firm and currently we utilize a Stage-Gate process for our NPD and have been researching the benefits/limitations of the ToC. In your paper you mention both and I would like to know if these can co-exist? From my research to date, it appears to me that the Stage-Gate methodology of NPD process management can co-exist with a ToC based task scheduling model? Can you advise?
...I assume that by "TOC" you mean that you are using critical chain methods. The early concepts for CCPM, as expressed by Goldratt, discouraged using milestones. Yet, milestones are at the very foundation of Stage-Gate. So, in theory, we could believe that TOC and S-G are incompatible. However, in reality, I think that this is not true. In practice, many CCPM implementers have ignored the original taboos that were proposed by TOC proselytizers and have incorporated most of the traditional CPM-type capabilities. While I cannot spell out the specific means of using CCPM with S-G, I can't see why these two processes cannot co-exist.
I'm in general agreement with Harvey's comments in the Sciforma Q&A column (although I'd be curious to hear from him more about the "CPM-type capabilities" he mentioned being incorporated by CCPMers -- I've dropped him an email query on the comment; if he responds, I'll pass it along), and offer a couple clarifications on the core topic from the CCPM perspective...

Early talk about milestones in the CCPM community should have drawn a finer distinction between "milestones" and "milestone schedules." Like the concept of "efficiency," the idea of milestones has had unnecessary abuse heaped on it by too many of my TOC brethren, especially those who, satisfied with the success provided by TOC solutions, fail to look beyond to the core concepts and definitions of preceding bodies of knowledge.

Milestones, aka, specific events of special importance -- such as stage gates -- are facts of life in a project, totally consistent with CCPM, and pose no problem whatsoever in the use of CCPM. The idea of pinning those milestones to target dates via a "milestone schedule," however (or of considering target dates for any task for that matter), leads to a setup for the impact of Parkinson's Law. Date-driven Milestone Schedules should be avoided if speed of delivery of the overall effort is important. What we want is a relay race, not a train schedule punctuated by stage gates attached to the calendar.

If there is some rare real reason to identify a target date with an intermediate milestone (usually some promise external to the flow of the project not associated with the completion of the project), that date would/could/should be buffered in the same manner as the final project promise date, with a "project buffer." Otherwise, stage-gates should float in time, uninhibited by any bogus "good enough, on-track" time targets, so that they can take advantage of early completions and avoid driving questionable quality. After all, the work is going to take as long as it takes. If the project environment assures efficient and effective behaviors in performing project tasks, unhampered by false priorities of task/milestone due dates, then the stage gates will be arrived at in a timely manner.

Effective projects are not about the schedule and plan. They're about the behavior and the work, and control mechanisms that don't get in the way of speed or quality and how, when faced with reality, performance matches or deviates from (or needs to detour around) the expectations that are the schedule and plan.


posted by Frank - Permanent Link - |

Wednesday, October 22, 2003

The Point of a Plan -- A passing thought on the value of a plan (strategic or project)...

It is not that a plan will tell you what you should do to accomplish your goal, but more often that you should be doing something other than what you thought you should do before prior to the reality of its execution. Its value is in the ability to analyze deviations from expectations and act accordingly, whether that action is to aimed at getting back "on plan" or taking a whole 'nother direction. Without a plan, it's not that you don't know where you're going, but that you don't know where you're going wrong.

A plan is built not to be blindly followed, but to be confirmed, adjusted, or abandoned.

posted by Frank - Permanent Link - |

What Do You (I) Do? -- In the last posting here, I asked if you could describe your organization's strategy, and how your project and your role (and, by implication, you) support it. Maybe first things should come first. Maybe a bottom up understanding needs to go along with that that comes from top down.

A while back, I settled on a description of Focused Performance that takes up the bulk of my home page. It started out as a simple elevator statement, but has grown a bit bloated with "marketing-speak" over time. I'll have to dig out the original from my archives to see if it still holds as a description of what Dave Pollard refers to as "what I do" in my Focused Performance persona, or even as a personal description of what I do.

In addition the the links above, which I've come across in the last few months, another recent encounter with a TOC-savvy friend has helped to trigger this introspection. We were discussing his year plus of being back in a corporate position after a foray into consulting. He told me that he finds himself brought into meetings at his company in which he has only loose connections to the subject at hand. It seems that his company has a recognized category of employee skill/contribution in which he finds himself. His boss told him this category contains people who provide "diversity of thought." I really resonated with that, even if it's just a nice way of saying one is a misfit that brings a different perspective to the table, or inserts important impertinent inquiries into the conversation.

Diversity of thought. Yeah...I like it. It's what I mean when I describe myself as someone who brings "fresh eyes, extra hands, and an open mind" to the tables to which I'm invited.

posted by Frank - Permanent Link - |

Sunday, October 19, 2003

What's in Your Strategy? -- Yesterday, I was honored to present two topics at the PMI Keystone Chapter's Professional Development Day. The first was an excerpt from my 1- or 2-day CCPM training offerings, which I called "Project Math Myths," a cautionary tale about believing that the estimates in your project schedules add up to anything that suggests a reasonable promise for your project that's really just an excuse to get 30 people to play with dice. Hal touches on a similar message in his posting today which he titled "Warning: This is NOT an accurate representation of how the project will unfold. Yeah, and it's against the law to remove the label carrying that warning. Or at least it should be.

That first presentation I made was done in traditional "work the plan" Powerpoint style, slamming my message into the brains of my audience through carefully crafted slides building my message. For my second talk, I shifted to a hyperlinked process flow chart that readers here should be familiar with. Having been hanging out with the "agile" crowd entirely too much, I let my audience/customers guide which of the boxes and arrows of the picture they saw as priorities to hear about and discuss first. This strategy was meant to mitigate my usual habit of using up all the time alloted (and often more) for my presentation. At least they'd hear the "features" of my presentation they considered "priorities." To tell you the truth, it was more fun for me as well. (hmmm... How about replacing Powerpoint with an html browser for presentations...hmmmm...)

In that second, agile, hyperlinked talk - "Enterprise Project Management - The Links and Loops from Strategy to Project Management, and Back" - after first addressing the audience's priority topic of portfolio management, they asked for my "insights" on strategy as it relates to the strategy through project management processes. My prepared thoughts included a take similar to a recent piece on the topic, but also included a question for the audience..."Who here can explain to me the strategy of your organization and the role of your project in it?"

Out of about 30 people, how many do you think raised their hands?
A) More than 20 of 30
B) Between 10 and 20 of 30
C) More than 1, but less than 10
D) 1 lonely person in the back of the room
If you answered D, congratulations. Scary, isn't it? But before you sprain your shoulder patting yourself on your back, ask yourself the same question.

A bit sobering, isn't it?

It's probably not your fault, but instead the fault of a poorly communicated (or perhaps a poorly crafted, non-communicable) strategy. The next time you run into someone you think should know more about your company's strategy, earnestly pose that question. And keep asking it until you find someone who doesn't squirm uncomfortably and answers it to your satisfaction.

posted by Frank - Permanent Link - |

Friday, October 17, 2003

Friday Fun - Hell Frozen Over -- Steve Jobs using a Dell machine to demonstrate iTunes for Windows... (via Universal Rule)
[Disclosure: A Mac user since its beginning, I own a bit of AAPL]

posted by Frank - Permanent Link - |

Tuesday, October 14, 2003

The Top 10 Ways Software Projects are Different -- By James Bullock (at Pm Forum, this excellent article starts off with a refreshing admission...
"A couple years ago I helped a PMI trained project manager, a mechanical engineer, who ran plant floor install projects for years - recover a floundering mission-critical software project. Now that it's shipped and routinely in the Media Metrix top fifty, she manages most of the software development projects in that shop. She primarily needed a little insight into how software projects are different from other projects. That plus some software vocabulary and an occasional sanity check on a task, technique or work product was all it took to help her succeed. Software projects are a little different, but not all that much."
Summarizing Bullock's ten differences does not do the article justice, but I will anyhow. Just be sure to go read the full piece.
1 - The artifacts in software projects often aren't as visible or well-understood as in other projects...
[Kind of like any project of discovery - FP]
2 - The end state of a software project is often a lot more speculative than with other projects...
[Ditto - FP]
3 - There is an incredible variability in what we call "software" and projects called "software development." Designing a Formula-1 racer is different from designing next year's Camry which is different from designing GM's new fuel-cell multi-vehicle platform. They all have to do with designing cars yet we treat them like vastly different activities. Somehow we try to treat making software as the same when the products are as different as Camrys, racers, and platforms...

4 - The production chain from feature to code to executing stuff varies wildly in throughput, availability, reliability and even variability itself. Software production varies from one application technology to another, from one platform to another, and even between deployments of the same production chain...
[All the more reason to understand the potential of that variable variation - FP]
5 - Producing code varies wildly in the character of the work. Code production can be mostly any one of: discovery, investigation, design and creation, generation of code, integration, or something else...

6 - Software production involves a lot more than producing software. Production processes on the front-end (before features) and back-end (after something that executes) are more variable than code production, and often dominate the project schedule, risk and variability. Non-production activities can also dominate the project, like organizational change, team formation and technology adoption...
[Amen. - FP]
7 - There aren't any software-only projects...
[Amen again. - FP]
8 - Software development capability is usually a limited, shared resource...
[And amen one more time. Most IT projects are in multi-project, multi-responsibility environments. - FP]
9 -The tools and methods in software projects are tunable. So, if rebuilding the software every five minutes helps code production, adjust your environment to do that...I like to iterate processes and methods with each project increment - "How can we do the next one better, faster, cheaper?" then track process or method changes explicitly on the project plan...
[I love it when a plan comes together. I love it more when it changes due to learning. - FP]
10- A software project manager is employed for a reason. Projects this challenging need leaders and managers, not just administrators. You are there to manage the project and support the people who will have to deal with changing targets, multiple demands, variable production, accidental (or deliberate) changes to their world, multitasking, new methods and so on. There is a tremendous temptation for project (and line) management to retreat into administration:The methodology said . . . Those bad and evil customers, developers, vendors, agitated ghosts said. . . The PMO requires . . .It's too hard, complicated, confusing, obscure . . . It's your job to make it happen. If you can't figure that out (maybe by finding a trusted adviser) then your job description is inoperative...
Jim also includes a few bonus points "about agile." Go read the whole piece.

posted by Frank - Permanent Link - |

Sunday, October 12, 2003

Enterprise PM - It Starts with Strategic Interdependence -- Last week, I wrote a piece extolling the criticality of interdependence in making promises, predictions, and plans. In it, I mentioned the need for projects to be driven to support the strategic needs of the organization and to keep those needs in mind, overcoming the strength of apparent functional boundaries when defining the project. It reminded me that those blocking boundaries don't just happen in a vacuum. They are the result of fragmented strategies that cause conflict and competition exactly where cohesion and collaboration are needed most, in the execution of the strategic plan of the enterprise. So, let's get into strategic interdependence and the strategic plan as the driver of the work done within an enterprise project management process...

An effective strategic roadmap serves several purposes. It identifies the things that are currently blocking desired levels of attainment of "goal stuff" and tactical objectives designed to get there. Once short- or mid-term problems or blockages are dealt with, the strategic roadmap also lays out a clear vision that builds upon the future freed up capabilities and defines the path to strategic objectives.

Too often, strategic plans, when they exist, are merely the collection of local, functional initiatives, developed locally and functionally as a response to a direction set by the top of the house. A high level direction is set, an affordable total budget is determined, and the various pieces of the organization try to divvy up that budget in an fund what they think makes sense to follow the strategic direction, with minimal, if any, regard to the relationship of other parts of the organization to the goals.

(From you know who)

These hierarchically driven, silo-centric plans may seem to make sense when looking at the larger functional objectives in relationship to the direction, or when looking at the components within the functional efforts to achieve their local objectives.

They seem to make sense if one buys into the idea that the whole is the sum of its individual parts. But in any complex system, be it an organization or a project, the whole is more about the relationships between the parts than the parts themselves. In the common strategy/budget process described above, the resulting lack of connection across functions, the lack of relationship between local endeavors, and the lack of coordination and synergy all result in wasted efforts at best and conflicting efforts at worst.

An effective strategic planning process is developed not in the isolation of individual functional fiefdoms, but in an effort that involves the leadership of every function. It simply "starts with the end in mind," admits to the problems and obstacles that are in the way of that "end," and develops an understanding of the core root cause problems that perpetuate them as well as the direction of their solution. From there, based on those core, aligning directions, the process identifies intermediate tactical objectives and opportunities that are clearly understood as stepping stones to the larger strategic objectives, and links them to one another via logical connections open to scrutiny and refinement by the rest of the organization.

A Real-life Sample Strategic Roadmap
(Shrunk to illegibility to honor confidentiality of Focused Performance client that used it to grow throughput/revenue over 50% in 15 months and to set them up to support innovative market offers.)

As the driving aspect of true enterprise project management, such a strategy then drives a portfolio of projects and programs to achieve those tactical objectives in a consistently aligned manner. In the same way that a project is collection of interdependent efforts, an organization's strategy is its "meta-project" aimed at delivering its future goals.

A clear strategy, in addition to providing the major project and programs that make up the enterprise project portfolio, also goes a long way to clarifying their relative priorities. Projects and programs aimed at dealing with current constraints to organizational throughput and deeper core problems rank high in priority; the former to drive sustainable immediate gains, and the latter to lay the foundation for subsequent efforts associated with those core problems. To the extent that the strategy identifies time-sensitive opportunities, they too, get a priority nod. The strategic road map often serves to trim a lot of waste that comes in the form of unnecessary local efforts, freeing resources up to address what is truly important. And finally, the easily seen time relationships associated with the cause and effect logic of a good strategic roadmap provide further input into the prioritization process. (After all, causes come before effects, that combined with additional causes added later in the form of projects or programs, lead to further effects and objectives on up the strategic road. There's no point in jumping on project D immediately if, to get its full benefit, you need to complete A, B, and C first.)

In addition to what objectives are going to be targeted and what efforts are going to be used to reach them, the strategic plan also needs to provide a certain level of direction for how those efforts will be delivered. One of the obstacles that faces any strategy is the inevitable fact that there is a finite set of resources available to deliver it. One of the responsibilities is to identify both the key current constraining resource as well as the ideal "strategic constraint" that the organization chooses as the basis for its competitiveness. You can't accomplish more than your current bottlenecks will allow, so there's no point in pipelining more than can be done. And if the current constraint doesn't make sense from a strategic or competitive perspective, a piece of the strategy needs to include means to move the constraint to where you want it. Clarity on resource constraints also impacts prioritization, since you don't want to waste critical resources on low value projects or programs that take a lot of their attention.

Enterprise PM-related Outputs and "Customers" of the Strategic Planning Process

A project plan does not stop at a hierarchical work breakdown structure detailing pieces of the effort. An effective plan goes on to develop dependency networks interlinking the components and defining resources needed to effectively manage the effort and deliver the whole. Too often, strategies stop with the equivalent of a WBS and fail to fill in the arrows across the functions that define the real dependencies and clarify what is both necessary and sufficient to succeed as a complete enterprise. Such a road map, often depicted as a vertical logic tree leading to the strategic objectives, if turned on its side, would look like your basic project dependency network. To a large extent, strategic planning and execution is little more than project management, writ large. And the tools that go along with effective enterprise project management are the means of making it happen, as well as the primary source of strategic risk (and opportunity) management by feeding back the promises and performance of the pipeline of projects against the strategic expectations.

posted by Frank - Permanent Link - |

PMOs - Here's a quick quip that just occurred to me...

The most valuable (and least taken on) role of a PMO is that of Project Manager for the meta-project that is its organization's strategy.

posted by Frank - Permanent Link - |

Friday, October 10, 2003

Some Programming Principles: Projects, by Watts Humphrey -- From s.norrie, some cogent snippets from the subject article by Humphrey...
"...the fundamental purpose or objective of most software to develop or enhance a product to meet a business need....This means that the schedule, cost, and quality of the work is of paramount importance..."
Coincidentally, it fits reasonably well with my post here yesterday.

posted by Frank - Permanent Link - |

Friday Fun - A PM Theme Song? -- A possible theme song for project managers...
"Facts are simple and facts are straight
 Facts are lazy and facts are late
 Facts all come with points of view
 Facts don't do what I want them to"

    -- Talking Heads, Crosseyed and Painless
(And speaking of tunes, Apple's got something nice coming soon for Windows users...the iTunes store.)

posted by Frank - Permanent Link - |

Project Conflicts -- From a year ago yesterday. Worth a revisit. (If nothing else, I'm consistent.)

posted by Frank - Permanent Link - |

Thursday, October 09, 2003

Promises, Predictions, and Planning -- Projects are about promises. Project management is an effort to make, manage, and keep promises about scope, quality, schedule and cost of efforts deemed worth pursuing. While Deming said, "Management is prediction," pinpoint prediction cannot be expected and to strive for it is a futile waste of time. However, reasonably reliable expectations of when a user or an organization will have a specifically defined product, process, system, feature, or fix to support its efforts must be expected and provided by those tasked to deliver them.

Like many partial efforts that are too often described as projects, "software projects" rarely, if ever, stand alone. At best, they are most often components of larger initiatives, delivering either products to be sold or changes in business processes aimed at more effective operations and better profits. As such, the real promises associated with them are those that are tied to the bottom line impact of the effort. (Too often there is too strong an organizational border between things like R&D or IT and other components of the larger projects, but that's a strategic discussion for another time.) The component projects exist to serve the larger effort, which exists to serve the strategies and goals of the parent organization, which need to make and keep promises to satisfy key stakeholders.

In recent examples of high-profile failures of major companies to keep their promises (and of the Sarbanes-Oxley response), it is incumbent on management to demand reasonable and reliable promises regarding the efforts under their charge. Otherwise, they won’t be able to make or keep appropriate promises to the customers and shareholders who foot the bill. It's not good enough to leave critical aspects of project promises too open-ended or too open to compromise. While details along the way are, of course, subject to modification and tweaking along the way, the larger efforts' significant objectives, deliverables, and success criteria need to be kept at the top of the mind of those involved, and the promises associated with them must be kept unless and until rational decisions otherwise are made.

How the objectives are delivered may be subject to considerable learning along the way, but the basics of what will be delivered, in terms of functionality related to bottom-line impact, needs to be a relatively constant pole star for the project. If delivered functionality deviates too much from desired functionality, then the project's success is called into question. One way of avoiding this is to manage the big-picture effort, not just the component part, as the project. A new product development effort is not just and R&D/Engineering design effort, but a manufacturing, distribution, marketing, and sales effort as well. Implementation of a business system is not just a software project, but a process design, training, customer preparation, and roll-out effort as well. By doing this, the day-to-day interactions between suppliers and customers (both internal and external to the project) are formally included in the planning that goes on not only at the start of the effort, but also in the replanning that goes on daily during the execution of well-managed, high-performance projects.

Such projects need the close interaction of all these internal customers throughout the project. To accomplish this, project planning needs to move away from the oft-recommended hierarchical WBS viewpoint of the project to the interdependent view of a dependency network as soon as possible. The project level emphasis on the components of the components that are encouraged by detailed WBS views takes too much time for too little benefit, and tends to isolate the projects internal customers and suppliers. More important for an efficient planning process -- and an efficient, effective plan -- is to get out of the details of components and into the higher level details of the interdependencies between the project's component efforts and resource groups. The time wasted on detailing what goes on within a component effort or within one set of resources or another is time that is more productively spent on understanding what needs to pass between them.

If there is any chance of reasonably predicting the outcome of a complex effort, the identification of major dependencies is far more important than the futile attempt to identify unidentifiable details of work in particular components. To this end, for planning, the linear list and hierarchical outline-dominated Gantt Chart view (too often presented by project management software as the default view) should be avoided. It should be replaced by a dependency-centric network view of the understanding of the project that combines the boxes (the work) and arrows (outputs/handoffs/inputs/deliverables of that work) of the effort. Or even better, it can be replaced by a view dominated by post-its or cards. In either case, it is put together by those who will do the work or by their trusted representatives, typically facilitated by a project manager.

Once the objectives, the major chunks of work required, and their interdependencies are understood, the time and cost aspects of prediction and promise can be addressed. But to address them effectively and efficiently, sufficient respect for uncertainty and unknowns must be paid. The idea of "accurate estimates," over which too much time, effort, and angst is too often spent in project planning, needs to be set aside. It must be replaced with a brief conversation about how long (in time or iterations) something might take and how short it could take if good luck and good work practices come together. The former needs to respect the fact that Murphy's Law has not yet been repealed and that there are non-trivial unknowns at the time of planning. The latter highlights what management practices and additional predecessor pieces of the project would benefit delivery speed. The difference between the two is the time value of doing what is necessary to make the shorter time more likely.

From a planning efficiency perspective, this two-point range estimate heads off a lot of unnecessary negotiation, CYA, and other political activity that is associated with "accurate estimates" or "estimates as commitments," and does little but strain the necessary teamwork and trust between the people involved. It does so by respecting the concerns of those who will do the work, and and by providing necessary understanding of the prediction to those for whom speed of delivery translates to more benefit.

And from an effectiveness perspective, it provides the basis for rational predictions and promises; expected not-to-exceed promises bounded by the upper limits of a range of reasonable prediction that is managed, refined and narrowed as the project effort learns more about itself.

posted by Frank - Permanent Link - |

Tuesday, October 07, 2003

Tales of Measurement -- From Dave Weinberger...
"Measurement is important. Even more important: knowing what not to measure and not confusing the measurement with the thing measured."
This should be painfully obvious to regular readers, but Dave also goes on to include some hilariously horrifying examples. Check them out, then come back here and leave a comment with examples of your own.

Any examples you wish to share either by email or by commenting at this weblog will be collected, categorized, and turned into a book that will make me millions, since people pay a lot more attention to things that don't work than to things that do. Just ask Scott Adams.

(Just kidding about the book...although...hmmmm...)

posted by Frank - Permanent Link - |

Sunday, October 05, 2003

Medium... Well Done -- Today's post is a brief respite from the usual message of this page in order to point you to stuff about it's medium -- the weblog. There was a conference in Boston this weekend that I wish I could have attended in person, but that was well reported on the web, including official and unofficial webcasts which allowed me to "attend" from the discomfort of my too familiar office. The focus of BloggerCon was the medium of weblogs, where they're at (in politics, journalism, business, community-building, collaborative activity, ...) and where they're going. Attended by some of the "stars" of the medium (they would cringe at that designation, as well as those of us interested in communication about the things about which we care, many of them offered their own commentary and reportage on the event. If you are at all interested in this blogging thing, check out the following links.
Dave Weinberger reported that "Chris Lydon wonders whether blogging reflects social reality which consists of individuals with complex ideas and resistant to labels.".
That's a category that I would be proud to be included in.
Doc Searls has a good summary of highlights for both days, through which I found Heath Row's amazing live notes of the conference for both Saturday and Sunday.
That's a wealth of reportage on the subject that puts to shame what I recently tried to do with my PMI Congress postings. Someone claims that Heath is a twelve-fingered typist.
My never-met, physically-just-up-the-road neighbor here in NJ, Jeff Jarvis, talks about meeting someone he considers famous...the modest Dan Bricklin, who "got to talk about the future of these tools and all they need to do. He wants to be able to place and edit photos and edit text fluidly. It will take millions of dollars in development, he says. But it could be done in open-source..."
Regarding Dan's fame, you do know the significance of something called VisiCalc, don't you?
By the way, Bricklin posted some photos from the event.
(Scroll down a bit if you check out these pics. At least Apple has the lions' share of the market for the blogarati...look at all those PowerBooks!!! -- I would have fit right in.)
Esther Dyson even chimes in...
"The first magic of blogging, of course, is that everyone can self-publish. Everyone has a voice. The tools makes that possible. But the next magic, much harder to achieve, is that everyone wants to be listened to... In the blogosphere, there's no shortage of airtime, but there's still a shortage of attention. That is, there's an attention divide: the candidates who get too much and give too little... and the rest, who even en masse don't have enough to give to satisfy all the world's publishers, marketers and would-be stars, and who crave just a little for themselves."
Who? Me? Crave attention? Maybe a little, inasmuch as attention is one way of attracting business, but I hope that the people who come to this weblog -- along with its non-business counterpart, or subscribe to my RSS/XML feeds, come to see me as a trusted advisor, pointing the way not only through my own developing thoughts, but more importantly, to the thoughts of others worth listening to more than myself.

Blogs are links.

Blogs are comments.

Blogs are communication of ideas and collaboration for their development.

I'm just throwing my 2 cents into the pot for the taking by anyone who wants to take it and run with it.

...or to hire me to help them run with it.    

posted by Frank - Permanent Link - |

Saturday, October 04, 2003

Throughput and America's Dentists -- David Anderson, author of the highly recommended book, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, and recent convert to blogging, suggests that...
"Sometimes it is easier to understand the concepts of the Theory of Constraints with a practical real world example."
...and he proceeds to do so here. Check it out.

posted by Frank - Permanent Link - |

Friday, October 03, 2003

Friday Fun: Wishlist -- In case I'm on anybody's holiday shopping list, almost anything here would be OK, although the green laser pointer is a little more practical than the Airzooka that the child within me finds too cool.

posted by Frank - Permanent Link - |

The Psychology of Change Management -- From The McKinsey Quarterly...
Employees will alter their mind-sets only if they see the point of the change and agree with it—at least enough to give it a try. The surrounding structures (reward and recognition systems, for example) must be in tune with the new behavior. Employees must have the skills to do what it requires. Finally, they must see people they respect modeling it actively. Each of these conditions is realized independently; together they add up to a way of changing the behavior of people in organizations by changing attitudes about what can and should happen at work.
Unsurprisingly, these four conditions map very nicely to a model that we in the Theory of Constraints community refer to as the Six Layers of Resistance to buy-in...

Layer One - Lack of agreement on the problem.
Layer Two - Lack of agreement on a direction for a solution.
Layer Three - Lack of agreement that the solution addresses the full problem.
Layer Four - Concerns regarding side effects of the solution.
Layer Five - Concerns regarding obstacles to implementation of the solution.
Layer Six - Unspoken fears.

Defining and implementing a solution requires not just the technical aspects of the problem, but also the ability to bring stakeholders and necessary participants through the Six Layers. In the McKinsey article, the first condition of seeing the point of the change and agreeing with it sufficiently to give it a shot is clearly the broadest, requiring getting through the first four layers. Without agreement on a problem, there's no point talking about a change. Even if everyone recognizes the problem, it may be so ingrained that it's seen as the nature of doing what we do, with no real way of dealing with it. A direction is one thing, but if people are going to be brought to agree with it, a whole lot of dotted i's and crossed t's are needed. Finally, if one sees the proposed solution as a possible trigger of something worse, there will be foot dragging.

The second condition of the article -- surrounding structures "in tune" with the new policies, processes, and desired behaviors -- reflects some of the aforementioned I's and t's. New policies, metrics, and rewards are necessary to assure that the desired behaviors are achieved or to reinforce beneficial results of other tactics. Condition three -- employee skills -- or rather, the lack of necessary skills is one of the obstacles of layer five.

Finally, one of the toughest layers of resistance, if it appears, is number six -- unspoken fear, often fear of "going it alone." Especially for changes that involve considerable culture change -- major changes in behavior -- being the first out of the trenches and out into no-man's-land can be a daunting experience. While the first five layers can be largely dealt with through clarity of thought and communication, the best means of moving people out of their fear is through leadership. And leadership is about, as the McKinsey article suggests, modeling and supporting the desired behaviors.

(A tip o' the hat to Jack Vinson for the link.)

posted by Frank - Permanent Link - |

On Conversation --
"Ideal conversation must be an exchange of thought, and not, as many of those who worry most about their shortcomings believe, an eloquent exhibition of wit or oratory."
    -- Emily Post

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