I don’t like Microsoft Project. Allow explanation.
MS-Project is great when one starts planning for an initiative. Especially if it is a large and complex one. The software allows a lot of control on task planning, resource allocation, levelling etc. Moreover, your boss possibly wouldn’t sign off until he has actually seen a MS-Project. Boss agrees, champagne’s popped, Pizza sauce stains boss’s $125.95 Lilly-white shirt. Much happiness flows. Then things start turning bad.
After a few months into the project, boss asks how likely are we to ship the software on the 25th of December? Umm…see…of the ninety four tasks, eight are in red and there were a couple of unplanned activities that came by, Jeff ate a really bad Turkey on Thanksgiving and couldn’t check himself (leave alone his code) in for a good week…so. The trouble is, you still don’t have a number – like “Chief, we are shipping on 25th December with a 19% probability”. And that is why MS-Project is useless other than to clip-board carriers who come at status meetings.
You want a statistical estimate of shipping probability? Simple, just ask the Product Managers and Engineers to bet money on their dates. I am serious. Convert the money pools into odds and that is the best estimate you will ever get.
Gary Orenstein on GigaOm has an insightful piece on the enterprise effect of cloud computing. Cloud Computing holds out enormous promise of liberating divisions within an enterprise – especially small and medium enterprises – of the draconian clutches of its in-house IT department (if it is rich enough to afford one, that is). Vendors will have setup multi-tenanted cloud platforms and applications that divisions can sign up and use (and stop subscribing when they wish). Imagine the productivity impact this will most likely have on businesses.
I was thinking how this may impact enterprise level information aggregation and decision support systems. “Single version of truth”, “three-sixty-degree view”, “firm-wide, firm-wise” were just some buzz words that the DWH/BI practitioners have gone around with for quite a while now.
And they had a valid point (how much that translated into efficient and effective implementation is another matter though). So now in the new world where the workflow, processing and storing are all happening on the cloud, where does the Enterprise Intelligence box sit? Most likely that will move to the cloud as well. It will be a fascinating space to watch as it plays out. The application vendors on the cloud will – someday – want to forward integrate into BI/DWH/Analytics on the cloud but size could be restrictive. I would rather prognosticate that the BI/DWH/Analytics vendors with cloud infrastructure will integrate back stream into applications. What happens when only parts of the enterprise are using the cloud while the rest is using in-house applications hosted in local data centers – how does the mashup happen then? And where?
What do you think? How do you feel this game will be played out?
Human beings started domesticating wild plants and animals sometime around 8,000 B.C. That started the shift from a hunter-gatherer existence to domestication and settled farming. Hunting-gathering is an okay way of subsistence so long as there are more lucky days than ones when not much turns up. On the contrary a settled-farming society can expect (a) more predictability of food, (b) predictable – perhaps lesser – work schedules, (c) greater attention to family and raising children and (d) greater longevity.
This shift took millenniums to achieve, but most importantly the early humans realized that their end goal of species propagation cannot be sustained through an erratic hunt-gather way of life. While the start and end of this metamorphosis is well understood, for a moment think how it must have been towards the middle – or around the 25th percentile. Undoubtedly there were rival groups supporting either forms of existence. And they would have had their cogent reasoning. All said, hunting-gathering was proven and yielded results. The settled farming camp had it tougher, I am sure. They had to sell a concept, perhaps build a prototype of a farm and wait for a drought or famine to come about that would conclusively prove their argument.
I view the start-up, adrenalin pumping way of life versus the “large company” process driven existence as symptomatically similar to the example above. Just as a small tribe that has existential needs of only a handful can be profligate in their ways to not farm and only hunt and gather, a start-up company often exists in a similar bent of mind. A more process driven, settled existence is derided – mostly with the argument of slower turnaround (our early ancestors also had to deal with it, I am sure. “Today I can just go out and kill a boar and eat it. But in your way we’ll have to wait till it becomes big enough for it to be food”). It takes a phenomenal amount of evangelization before the change can be brought about. The problem becomes compounded when a start-up is bought out by a large company and the matter assumes tinges of cultural conflict.
Unfortunately, there is no silver bullet but the metamorphosis need not (a) take as much times as it did in human evolution (b) simply subsume into a bureaucratic maze that masquerades as settled existence. The hunter-gatherer culture depends on rock-star performers and the start-up equivalence is also somewhat similar. And once these individuals buy into the settled existence idea, it spreads like a virus. Like our ancestors, prototyping the concept may help and it is important that both forms of existence be allowed to continue just so the experiment has a control sample to refer back to.
Many equalize a settled existence with a sloth existence. The reality is far from it. A settled existence merely allocates human enterprise and intellect to initiatives that result in maximum return rather than spreading them thin over fragmented activities.
Finland ranks 60th in league table of mobile phone users. So when a bunch of Nokia engineers got together to figure out how to build the software the drove mobile phone usage they were obviously at a disadvantage. The fact that the sun hardly set for 73 consecutive days during summer also must have added to the insomniac woes. But I digress. The point is – when should intensity of customer proximity (in the physical sense, not the business behavior metaphor) matter for a product management team and what trade-offs can a business make when that intensity is low.
Let’s agree on one thing – being close to the customer is a sine-qua-non in product management (even if product management does not include product marketing). It is also true that innovation often happens closer to the source of talent and not necessarily near the point of consumption. What happens when the source and consumption have a few miles – perhaps a couple of oceans – in between.
Products that serve customer segments that are largely democratized in terms of practices and usages stand to make the most of leveraging the flat world. That is, higher democratization translates to higher indifference towards intensity of customer proximity. The game shifts to the talent source. Actually the game shifts to a combination of costs and talent source. A great example is possibly Banking applications. It is possible to segment banks and create a deep segment that has almost identical behavior – so it is immaterial if the product is built in Gdansk, Poland and deployed at a Bank in Johannesburg. So long as Gdansk can provide talent required to build the software – both Product Management and Development.
Now take the legal world. Legal practices tend to significantly differ across the world. Low market democratization makes it necessary that legal products products for say the American legal industry is built pretty close to the market – somewhere in America. The alternative is a bit messy. Keep business close to the consumption and development close to where development talent is abundant. Managing this divide, especially across continents, is a challenge.
Democratic markets offer great value to business to optimize production. Imaginative use of geographically dispersed talent base can lead to interesting business forays (like say the product development center at Gdansk matures to start understanding the requirements of local Polish Banks and morphs the main system to satiate the needs of the local market. A pretty low cost virgin market penetration strategy!).
If you have had experience in handling such situations either as a part of your business or as an outsourcing vendor, I would love to hear your thoughts.
In the coin collection from my travels across the world I found something truly priceless. Or worthless, depending of which side you examine the matter from. Here is what I had
Fifty Zimbabwean cents
A Zimbabwean fifty cent coin. Must be the most worthless piece of currency ever to exist on this planet.
A different perspective
My financial senses have become a little numb these days with so much money being thrown around in the economic crisis. Millions, Billions, Trillions are all uttered in the same breath like zeros – finally – do not matter. The intention is to shock-and-awe the world economy out of the coma. The backdrop couldn’t have been better for some Zim-maths.
At the official exchange rate, it would take you 300 trillion Zim Dollars to get one buck. That is 600 trillion of these fifty Zim cents. The 50 cent coins were about 2mm thick. You have guessed where I am getting with this, right? Yes, if you piled the fifty cent coins one atop the other, the stack will have reached a height of 745,645,431 miles. That is when you get one US Dollar.
- 745,645,431 miles is 1,561 round trips from the earth to the moon
- 745,645,431 miles is 29,943 times around the earth at the equator
- And a beam of light starting from the base of this stack will have to travel for an hour and six minutes before it illuminates the top-most fifty cent coin.
All this for one US Dollar.
At the beginning of the year I gave myself a target. Unlike the armchair-resolutions that I also indulge in, this one was shorter term and hence more exigent. The Q1 readership of this blog had to equal that for the whole of last year. Well, “year” is a misnomer since I started Confessions of a Digital Immigrant (seriously thinking of pruning it down to a manageable “CDI”) in June of 2008. Still, like anyone who has been handed down a sales target, I found the self imposed goal a touch onerous.
I did two things. One, I wrote more (in an effort to bring down the marginal cost of production!). Running a professional blog alongside running a group in a company standing in the middle of the economic meltdown makes serious demands of ones time. But I decided to hang on. Two, I opened up the windows to let fresh air come in. That is, I started the “Expert Zone” feature, inviting guest posts from people who have clearly left me behind in evolution.
Despite all this, I failed. I came 7.5% behind target. I had a good mind to blame it on the recession and or Tim Geithner but looking around I thought it is perhaps easier to push the jaw out and take the blow myself. There were brighter spots however. Average readership per day almost doubled as did the number of people who subscribed to RSS feeds of CDI.
Going ahead, expect more posts on the blog and on topics that cover a wider gamut of the industry – both on the business side as well as on operational aspects of product management. Interactivity of CDI is low, primarily due to restrictions of WordPress.com but I wish to improve on that too. My task would be easier if you leave a comment on what you would want to read more on CDI.
I will keep the thanking short because any amount of it will always be inadequate. For everyone who stopped by CDI to read the stuff – Thank You! For those of you who have CDI on your RSS readers – Thank You! (CDI not on your reader? Get it now. How?). For those who commented on the blog and challenged my thinking – Thank You! For those who linked back to CDI – Thank You! For those who contributed to “Expert Zone” – Thank You!
That’s it. Back to work.