Free, unsolicited product management advice for Verizon Wireless

As I mentioned yesterday, I am using EV-DO to connect to the internet here in Vegas for CTIA. It's more economical and reliable than the hotels' and convention center's WiFi hotspots. What I didn't say is that the way I contract for this service is convoluted and actually, on my analysis, loses money for Verizon. Details to follow.

It's got me feeling a bit guilty, so I would like to offer them some free advice. If they implement my ideas and wish to share perhaps 10% of their incremental profits on the change, I'd be happy to accept. [VZW, you can email me at inquiry (at) caddellinsightgroup (dot) com for my PayPal info.]

Here's the situation with EV-DO. I have a Blackberry, using a 10MB per month plan costing $24.95 per month on top of my voice subscription. This is fine for emailing and web browsing through the Blackberry, but not enough to support what I'm doing this week--blogging, video uploading, etc.

For that application, VZW requires I buy unlimited data access for $49.95 per month, and on top of that buy tethered modem service (that allows me to use the Bberry as a modem for my computer) for an additional $15 per month.

As a result, it would cost me $39.95 extra per month to subscribe to this EV-DO service. Except for the fact that I need it for perhaps 15 days per year. The rest of the time, cheap or free WiFi hotspots do the job. So I can't justify an ongoing subscription for this service.

But here's the thing: VZW allows me to sign up for the service, then, when I don't need it anymore, I call them back to cancel. The billing is ugly and almost incomprehensible, but at the end of the day I only get billed for the days I use EV-DO, at the rate of about $1.33 per day. A bargain for me.

But not for VZW. Here's a litany of costs they incur, each time I set up the service:

Calls to tech support: 2 @ $10 (one call to activate, one call to deactivate)
Letters informing me of a change in service: 2 @ $2.50
Incremental billing costs for changes, prorates, etc.: unknown

Total: at least $25

For this trip, I will use the service for four days. Meaning VZW will get incremental revenue of $5.33, but spend $25, for a marginal contribution margin of ($19.67). Ugh.

Here's my idea. VZW should offer a daily plan. [Virtually every other wireless ISP offers such a plan.] I would pay $5 per day for that plan. Have the signup be online rather than through tech support, meaning the incremental cost should be near zero. Have me sign up for exactly the number of days I need, and have deactivation be done automatically by the ordering system.







Related post: "Worst Practices in Product Management"

product management, mobile, wireless, customer service, packaging, pricing, technical support, Verizon Wireless

The Forgetting Organization

Many years ago, I took a series of courses adapted from Peter Senge's book "The Fifth Discipline." The hallmark of that book was a concept called "the learning organization," which posited that to be adaptable in an environment of constant change, companies had to nurture and support the learning impulses in all their employees.

While I really enjoyed the courses (and over the past decade have grown to appreciate them more), I grew frustrated by our company's inability to learn from our experiences. We made the same mistakes again and again.

With the gallows humor familiar to anyone who works for a very large, slowly-changing company, I started calling us "The Forgetting Organization."

Twelve years on, not much has changed. January's Harvard Business Review features "The Experience Trap" (link - $$) by Kishore Sengupta, Tarek K. Abdel-Hamid, and Luk N. Van Wassenhove. In simulations performed with software project managers, the authors discovered that even experienced project managers made similar mistakes--for example, bringing on staff too late in the project--again and again, in different projects. Rather than learning from what had gone wrong in Project 1, the PMs did much the same in Project 2, and 3, and so on.

Sengupta et. al. attribute this forgetting to several factors: (1) the disjoint and time-lagged relationship between cause and effect, (2) conflict between initial plan and long-term goal when conditions change and (3) the fallibility of initial estimates (and people's tendency to hang onto those far past their useful lives).

In other words, software projects, like so much of the high-value work in business today, operates in the complex domain. The authors prescribe a set of practices to help companies suffering from "the experience trap," but a simple recognition of the environment that people are working in, and training and reinforcing awareness of that fact, could help workers learn more.

Or, in other words, to forget less.

(Note: I also mentioned the above story in a previous post.)


complexity, learning, organizational behavior, project management, Harvard Business Review

Top 5 Best Business Books of 2007

(If you'd rather see the 2008 list, you can find it here.)

It's December, and "best of" lists are appearing everywhere. Here, too. So, if you are still searching for great gifts for the business-book reader in your family, you can't go wrong with any of these titles:

5. "Reinventing Project Management," Aaron Shenhar and Dov Dvir. A look at project management that goes way deeper, and is far more useful, than "on time, on budget, to requirements." Here's what I wrote about "RPM" earlier this year: 1, 2.





4. "Smart World," Richard Ogle. Innovative breakthroughs are not created by solitary thinkers toiling in the lab, but by people or groups interacting with their networks and environments. Prior posts on "Smart World": 1, 2.






3. "X-Teams," Deborah Ancona and Henrik Bresman. How great teams orient themselves externally and encourage dissent. Here's what I wrote about it back in May and June: 1, 2, 3, 4.






2. "Negotiation Genius," Deepak Malhotra and Max Bazerman. The best one-volume negotiation book you can buy at any price. Read a fuller review here.






1. "The Future of Management," Gary Hamel. (It's in stock at Amazon.) How to build a change-adaptable business in the 21st century. I did five posts on this book last year: start here.






negotiation, innovation, creativity, project management, organizational behavior, reading list

Boeing learns hard lessons about partner management

(UPDATE: 11 Dec 07 - Boeing confirms it's on schedule for first 787 flight in 1Q2008)

I wrote a couple of weeks ago that the trend toward collaborative product development would create a premium for partner-management skills rather than pure technical skills for innovators. Nowhere is this in bolder relief than in the Boeing 787 project, some of the travails of which are profiled in a front-page Wall Street Journal article today (link - $$).

What surprised me the most were the issues resulting from inadequate supplier management; specifically this:

"In addition to oversight, you need insight into what's actually going on in those factories," says Scott Carson, the president of Boeing's Commercial Airplanes unit. "Had we had adequate insight, we could have helped our suppliers understand the challenges."

And this:

But many [Boeing partners], instead of using their own engineers to do the design work, farmed out this key task to even-smaller companies. Some of those ended up overloading themselves with work from multiple 787 suppliers, Boeing says.

The company says it never intended for its suppliers to outsource key tasks such as engineering, but that the situation seemed manageable at the time. "We tended to say, 'They know how to run their businesses,'" says a Boeing executive familiar with the company's thinking.

As Boeing knows now, selecting a strategic partner and entrusting it with designing, building and delivering a critical subsystem is far different from sourcing a standard part from a supplier. The prime contractor has the right and obligation to critique, probe and view its partner's activities from the inside (you need Doubting Thomases).

In the short term, these delays hurt Boeing. There is PR impact. And financial hits, in the form of penalty payments and cash-flow delays. But it is important to remember that the 787 product will have a 30-year life cycle. By that count, a 6-month or even 1-year delay in deliveries will have a negligible long-term effect.

It's also good that Boeing is not trying to mask its mistakes and instead to discuss and learn from them. Not everyone agrees: the Journal article states, "Lessons that Boeing is learning the hard way could end up helping rival Airbus." This will be true to some extent--but the highly complex lessons Boeing is learning will be hard to glean from the outside. If Airbus gets too confident in its follower role, it will overlook its own inevitable mistakes and let Boeing get out even farther ahead.

(Photo: the 787 Dreamliner. Courtesy of Boeing)

alliances, partnerships, innovation, aviation, mistakes, project management, product development, Wall Street Journal

How significant is Boeing's 787 delay?

The Wall Street Journal reported today (link - $$) that Boeing has pushed back the launch of their 787 Dreamliner aircraft by six months, due to delays from partners supplying key subcomponents. Boeing's stock fell nearly 3% on the news.
But what's the long-term impact? Using the framework set out in "Reinventing Project Management," by Aaron Shenhar and Dov Dvir, we can evaluate the project and get an idea of the long-term cost of a schedule slip. (Here is a prior post on this book.)

"RPM" looks at projects over four dimensions: novelty, technology, complexity, and pace.

Novelty: on Shenhar and Dvir's scale of extension, platform, breakthrough, the Dreamliner project is a new platform.

Technology: on their scale of low-tech, medium-tech, high-tech and super-high-tech, Dreamliner is high-tech--using technologies proven in military applications in commercial aircraft for the first time.

Complexity: scale is assembly, system, array. Dreamliner is an array project (most new product developments are system projects, but given Dreamliner's unusual complexity--e.g., subcontractors work on their pieces across the world, then subassemblies are shipped for final assembly to the US inside 747 transport planes, I'd rate it an array project).

Pace: on scale of regular, fast/competitive, time-critical, blitz, the Dreamliner project is fast/competitive--typical of new product introductions.

The "RPM" map, then, would look like this.


Projects of array complexity in particular are subject to delays. As mentioned in the WSJ article, Boeing's extensive use of subcontractors lessens the control it has to respond to issues in the supply chain. (See this prior post for discussion about how outsourcing, regardless of its benefits, lessens direct control.)

But the Dreamliner will be a platform that contributes to Boeing's income for thirty years or more, if the 737 and 747 are any predictors. So on the face of it, a six-month delay is not significant.

What would be significant is if the project management approach that Boeing used differed from the needs of the project. As far as I can determine, Boeing knows what it's doing. The biggest risk would be to rush the plane out prematurely, in which case any operational problems would raise questions about the suitability of the entire platform. Paradoxically, announcing a delay should raise confidence in the project, as it demonstrates that Boeing won't put the plane in the air until it works.

So, a six-month delay is... embarrassing? yes. Costly? yes, in the short run. Long-run significant? No.

project management aviation alliances reading list Wall Street Journal

Why do so many projects fail?

If you've worked on more than a handful of projects in your business career, you are familiar with failure. Lots of projects simply don't work right: some are abandoned before they're complete, others don't meet expectations, others finish but are so agonizing that they burn out teams and managers both.

A new book, "Reinventing Project Management," by Aaron J. Shenhar and Dov Dvir, dissects the topic in great detail. It's a refreshing look at project management, not least because they focus less on the discipline of work breakdown structures and task dependencies and more on what different projects try to achieve and how methodologies and management approach must adapt to the needs of the project.

In summary, there are two reasons why projects fail:

1) the wrong objectives are assessed
2) the management style of the project doesn't match the needs

To point (1) the authors point out the tyranny of the "iron triangle"--(meeting requirements, on time, on budget). The dimensions of the iron triangle are immediately assessable--are we late? have we checked off all the requirements?--but they don't reflect key business value that is only measurable over time. Was our new project a success in the marketplace? Have we developed a technology platform that can support our business for the next decade? It's very possible that a late, over-budget project can be a success in the long term. So the iron triangle needs to be put in perspective.

To point (2) the authors measure projects on four dimensions: novelty, technology, complexity and pace. How any project fits on these four dimensions affects how it should be managed. The wrong management style frequently leads to failure. They cite several examples, including:

1. NASA's moon-landing project, a success despite radical technological breakthroughs required (super high on the technology scale) and constrained timeframe (fast on the pace scale--"before the decade is out"). The managers of that project proceeded deliberately, built lots of prototypes, and carefully worked out the kinks they found. (As a counter-example, the authors point to the shuttle program, which despite similar technical complexity was rushed through on a compressed budget.)
2. The Denver airport project, which was managed like a straightforward construction project, despite specifying a state-of-the-art baggage handling system which had not been deployed on a similar scale before (super high on the technology scale).
3. The Segway. A brilliant and novel technological device (rated as breakthrough on the novelty scale), its failing was the closed nature of its development. Because no prototypes were tested in the marketplace, and little if any market research was done, the Segway was launched into a marketplace that simply didn't need it, or didn't need it at the price.
   

To succeed, say the authors, you must assess a project based on the four dimensions, and create budgets, schedules, objectives, success criteria, etc., specifically for that project. Doing that gives a worthy project a fighting chance to succeed.

project management innnovation technology marketing product management reading list

Sports Analogy Week, Day 4: Finishing

A basketball player is said to be a "finisher" if he/she reliably scores two points or gets fouled when going to the basket.

To define this term by counter-example, let me present Charles Smith. From Bridgeport, Connecticut, he played college basketball at Pittsburgh and was chosen third in the 1988 NBA Draft. Smith was tall and a good rebounder. But he was an awful finisher. When he played for my team, the Knicks, there were countless times when Smith found himself under the basket with the ball in his hands, and it seemed as if someone would block his shot 75% of the time. His Wikipedia entry states:

As a member of the Knicks, Smith is infamous for missing four consecutive shots directly under the basket as he attempted to tie Game 5 of the 1993 Eastern Conference Finals against the Chicago Bulls. After taking a 2-0 lead in the series, the Knicks lost Games 3 and 4 in Chicago. With a chance to take a 3-2 series lead, Smith's attempts were hampered by Michael Jordan, Horace Grant, and Scottie Pippen in the final seconds, becoming one of the most notorious moments in Knicks history.

Charles Smith just couldn't finish. By contrast, Tony Parker of the San Antonio Spurs is a tiny guy by NBA standards, yet he finds a way to get the ball into the basket from in close despite the tall trees around him. Tony Parker is a finisher.

Finishing is just as important in business as on the basketball court. Many, many people are good at the start of a project, when everything is just words on the white board and nothing is at stake. Much harder is the end of a project, when people are tired, customers cranky, flaws apparent, and yet, somehow, certain people find the fortitude to see the project through to the end.

So, ask yourself. At work, are you Tony Parker? Or are you Charles Smith?

(Photo: Tony Parker finishing, by Half Crazy Girl via flickr creative commons)

sports basketball project management organizational behavior leadership