Lock, Stack and Bytes

It is official. Sony is virtually withdrawing from the PDA market with the decision to stop selling its Clie range of products in the U.S. and European markets. Sony’s move may well be the beginning of the end for the PDA as a product in general. One of the main reasons for lackluster PDA sales - once a hot gizmo among the upwardly mobile population - is the strong competition from “the communication business’s 800-pound gorilla: the cell phone.”

So, will PDAs be relegated to the dustbin of great products that failed? Or will it reincarnate in a different avatar? The debate is on. The product gurus are definitely trying to answer some of the obvious questions: Did Sony (and the others) didn’t foresee the threats from the substitute(s)? Were there simply too many features (do I hear some one say “the iPod lesson”)? Did the price reflect a fair value proposition from the customer’s viewpoint? How do PDAs differentiate from today’s feature-rich cell phones and “converged” mobile phones?

All said and done, it will be a while before the customers give their final verdict on the value of PDA as a product. Sony will more than survive even if the PDA market collapses. Thanks to their wide range of product portfolio and business units. But what about companies whose market presence is solely based on PDAs and related components and services - a company like PalmSource Inc., whose software powers the PDAs and which counts Sony as its second biggest licensee? They would definitely need to do some serious rethinking about their product portfolio. A single product strategy is always dangerous in hi-tech industry - especially considering the fact that technology is itself in a stage of flux.

So what are the lessons to be learnt? The one lesson that I will take home is that product managers within a company should always plan for failure. Always. Even in the best of times - when company’s products are raking in great returns, no competition in sight, substitutes are weak, the party for company’s “Killer Product of the Decade” is underway, etc, etc. - it pays to be a paranoid product manager. In fact, employers should pay product managers to be paranoid! In my book, a good product manager is one who is constantly aware that the next product to kill his/her company’s flagship product may come the very next day. Or while (s)he is sleeping in the night.

- Rajesh

In my opinion and experience, there is a very compelling reason (or reasons) behind all the horror stories about the high percentage of IT projects that fail. Johanna Rothman’s posting - How Much Rework Does Your Project Perform? - provides one of the answer. I am definitely not surprised by her assessment about the proportion of time that is just spent on rework in a typical project. My term for this “phenomenon” is “(Re)work in progress”. And by every account it is a very common occurrence in most IT projects. Companies can adopt numerous, fundamental approaches to overcome this problem. But this has to be complemented with a more lasting solution to the problem.

rework accounts for somewhere between 75% and 80% of a “normal” project’s time…

In my opinion, the main problem lies in focusing too much on the end product and too less on the process that takes us to that end product. Yes, I am talking something on the lines of CMM (Capability Maturity Model) for software development that describes the principles and practices underlying software process maturity. Of course, companies whose core competencies are not software products and services would not (and should not) invest the time and money to achieve CMM levels for their small IT or IS departments. However, in this age of global competition, efficient business/operational processes hold the key to a business organization’s ability to survive and thrive. In the absence of well-defined processes for managing in-house projects (IT or others), companies are unwittingly bleeding themselves of precious resources.

Every time a project is undertaken, there is widespread reinventing-the-wheel. It’s high time that managers and decision-makers ask themselves: What happened to the company’s software assets used in the last project? Can’t we use them again? Where is the documentation for the projects done till date? Where is the knowledge base? Where are the APIs? Where are the reusable components? Well-thought out project/product management processes can go a long way in addressing some (if not all) of the questions raised above.

- Rajesh