Joe's Jottings
Jottings Number 71, by Joe Podolsky:
From: JOE_PODOLSKY@HP-PaloAlto-om4.om.hp.com
Date: Thu, 3 Apr 97 17:23:52 -0800
Subject: Hurray for Real Time Management!
Bo Davis, a friend and colleague in HP's information technology community, has long complained about our chronic inability to manage projects and to learn collectively from our often-repeated mistakes. He feels very strongly about correcting this, and he is focusing his time now on promoting the use of an internally developed Lotus Notes application called the Project Manager Assistant that makes it easy to do a good job of managing and documenting a project. Bo's efforts are slowly paying off, but he feels like he's pushing a rope most of the time. But Bo enjoys fighting windmills; he seems happiest when he's on valiant, idealistic quests. So I was a bit surprised when Bo exploded into my cubicle a few weeks ago telling me that he now understands why his task is really impossible. He just finished reading _The Stuff Americans are Made of_, by Josh Hammond, and James Morrison (which, by the way, has a nice introduction by HP CEO Lew Platt). Hammond and Morrison say that we Americans have some cultural characteristics that differentiate us strongly from people in other countries. That statement is no great surprise, but Hammond's and Morrison's points are a bit embarrassing. Here is Bo's paraphrase of their list of American traits: 1. Insistence on choice 2. Pursuit of impossible dreams 3. Obsession with big (the book calls this chapter, "Big, Bigger, Bust") 4. Impatience 5. Acceptance of mistakes (the chapter title is "Fire, Ready, Blame - Trying to Do Things Right the Second Time) 6. Urge to improvise 7. Fascination with what's new Bo says that traits 1, 4, 5, 6, and 7 make a repeatable process culturally almost impossible. Do you agree? Let me make this discussion more specific to HP. I meet often with external customers. Occasionally, they ask about how we manage projects, assuming that we must be really good at it. The conversations go something like this: Customer: "How do you identify your projects so that you can collect all costs and benefits and calculate an accurate return on investment?" Joe: "Uh...well, we give them names, like Snakes or Redwood or Tahoe. Our accounting systems can track location codes, so if the project happens to coincide with one or more location codes, we get project costs. But mostly, the project manager just tracks costs on a spreadsheet. And, even then, we don't usually closely relate implementation and support costs to a project. Those costs often get mixed in with legacy systems support, so getting ROIs for a specific project is really a work of art." The discussion continues like this for a few more minutes, and the customers get that, "This bee can't fly," look in their eye. But, of course, the HP bee does fly, I'm happy to say, and I've come to understand that part of the reason we fly so well may be _because_ we're lousy at project management. Instead, we manage everything as on-going business. The targets may have been originally set considering projects, but actual costs are managed in real time. IT spending is a business decision made by the business managers. We expense things as we go and match those expenses to revenues every month. If business is good, we tend to get a little sloppy and spend a little more on whatever; e.g., people, convention trips, off-site meetings. If times get tough, we tighten our fiscal belts. Managers make priority decisions on what to spend based on the current situation. They are not locked into project plans that were made in an entirely different business environment. That flexibility is important even if there aren't any significant shifts in spending climate. We actually do a pretty good job of planning projects. Most IT projects go through some form of "launch" based on the Ernst & Young Navigator (TM) methodology. But, as we all well know, specifications and plans change, a lot. And those changes inevitably have effects on spending. In tightly controlled environments, each significant modification generates an "engineering change order," and the formal plan is appropriately modified. All that accounting, when done properly, creates a lot of overhead. We skip all that by adapting our work to the current needs of the projects' customers on an on-going basis. When the project is done, it usually has the capabilities that the customers want at that time, which may be really different from what the customers said they wanted when the project started. Hurray for real time management! This same idea seems to work as well for teams. Some of you may remember Jottings #32 that discussed Michael Schrage's book _No More Teams!_. Schrage suggests flexible collaboration rather than having designated teams. Along the same lines, I just heard author/consultant Richard Whiteley at a Customer Work Innovation Network conference. One of his key strategies for "customer-centered growth" is to move "from teamitis to universal collaboration." Whiteley says that there are seven pillars of universal collaboration: 1. Overarching purpose (e.g., vision, mission) 2. People involvement 3. Internal customer process 4. Development of collaboration skills 5. Positive team environments (that allow the formation of _ad hoc_ teams) 6. Organizational structure (that allows work to be done informally) 7. Infrastructure (that allows people to work across the organizational white spaces) Again, in HP, we tend to focus more on individuals than on their teams. For example, we have experimented with but never institutionalized team compensation. We encourage the formation of teams as needed, but even designated project teams tend to be short-lived and break down as situations (rapidly) change. To paraphrase Eisenhower's famous quote on plans, teams are nothing, but teamwork is everything. This gives us great flexibility, but at a significant price. Teams don't stay together long enough to learn and get better as an intact group. We have to go through a "forming" process each time we start a new project. We may repeat mistakes, but we also don't carry forward previously good ideas that don't apply to this exact situation. Again, hurray for real time management! Is all this HP "stuff" true because we're a company that started in America? I'm not sure. I see these project and team traits in all parts of the HP globe. I think it may have more to do with our "value discipline." In Treacy/Weirsema terms (see Jottings #21), HP might again be demonstrating its primary focus on "product leadership" rather than on "operational excellence," our tendency to do the right thing even at a cost of some efficiency. What do you think? Should Bo continue his joust with project management windmills or find some other less daunting task? What examples do you have of projects and teams that have succeeded, here at HP or elsewhere? Regards, Joe