Gary Hamel of 'Core competence of the corporation' fame says "The Facebook Generation….. At a minimum, they’ll expect the social environment of work to reflect the social context of the Web". He goes on to layout web 2.0 practices that are most at odds with current management practices for large companies.

 I am listing these down below with my thoughts in italics on how it will affect Indian outsourcers:

1. All ideas compete on an equal footing.
Idea sharing itself is currently contained within well defined teams. Any sharing beyond these established boundaries happens as a result of management intervention or through rigid, formalized mechanisms like a KM portal. Fast forward 2020: Employees will expect organizations to encourage them to be part of virtual teams, freely contributing outside defined boundaries. Problems will be posted for anyone to attack and solve. Solutions generated in project X would be instantly accessible to someone in project Y leading to greater productivity. Web 2.0 technology would allow it!
2. Contribution counts for more than credentials.
Pay would get linked not just to designation as it currently is, but to your ability to contribute to the organization outside of your project. People on the bench would be expected to contribute to projects as part of virtual teams. Why can't it happen today ? Because the technology does not allow it. Technical problems that do not require the client or project context can easily be attacked by anyone in the organization. Future IDE's would allow this to happen. Metrics would be tracked around these and compensation linkages established.
3. Hierarchies are natural, not prescribed.
More power would flow to the developer on account on her increased ability to contribute. The power a given project manager has over her developer would decrease as multiple peer projects managers would have an 'indirect' relationship with the developer by virtue of virtual teams. The same would apply at all levels.
4. Leaders serve rather than preside.
I would modify this clause as "Managers would falter. Leaders would flourish". Getting things done through positional authority would take a back seat and skill would become central. Web 2.0 enabled virtual teams would make everyone stand naked. Measuring contribution would be easier and leaders would be forced to contribute as individuals and not just as 'bosses'.
5. Tasks are chosen, not assigned.
Virtual teams attacking problems would naturally allow individuals to choose tasks. People would gravitate towards tasks they are more skilled at doing. Individual work packets would get disaggregated into project contextual tasks and generic tasks. Generic tasks would get attacked by virtual teams who would choose the tasks they wish to do. I also envision a kind of 'competitive bidding' among employees for tasks.
6. Groups are self-defining and -organizing.
You won't always know who your project mates are. Skill and dynamic matching of those skills to tasks would define which group you belong to, who you work with and what you do.
7. Resources get attracted, not allocated.
Smarter projects run by better managers would command the best resources. People would have the freedom to choose.
8. Power comes from sharing information, not hoarding it.
Keeping knowledge to oneself and applying it to one's own task in one's own project would still be good. But applying that in a virtual team to a dozen projects would get greater visibility and recognition.
9. Opinions compound and decisions are peer-reviewed.
Web 2.0 allows you to be anonymous. This would allow real time review in virtual teams and poor decisions would get a public roasting.

Is any of this any good for us ? Well, there is good and bad in everything. :-)

How do you think Web 2.0 would affect the work force ?

Shefaly blogs about the importance of keeping promises to customers. Drawing largely from the consumer product world, she paints an argument for timely delivery and the serious costs of messing up. In the highly transactional world of consumer goods with large volumes of relatively lower priced goods getting sold to the masses this is very true. You absolutely have to tie in your suppliers, manufacturing, marketing and sales to a tee.

Move to software.

Nick Carr talks of commoditization in the hardware and software product markets: "It's typical when industries mature and buyers start focusing on prices rather than features…. They're competing on cost rather than innovation and features."

What about the world of software services? Firstly, we deal with 'clients' and not 'customers'. Dawud nails the difference. With clients, the 'when' of delivery is important, but the 'how' of delivery is even more important.

When was the last time you had a large, complex program delivered perfectly on time? Let's face it. Slip ups happen. Unlike a P&G shampoo, each project is 'manufactured' to order and there is too much magic in the process for things to be perfect. What saves the day is relationships and the trust that comes with it.

So, how do you build trust while you deliver?

Honesty: Many delivery issues have two sides to it. Both the vendor and the client could have done things different. One way to open up clients to do their bit is by being honest about one's own mistakes. When clients see that they you are your own devil's advocate, they will stop feeling compelled to attack and will instead be open to meet you half way.
Honesty is also in being open about what is good your clients. Say you are trying to sell a rewrite of a large legacy mainframe application. There are two options in front of you.
Option a). Keep the backend as it is and rewrite the UI alone in a new technology. Price: $5M
Option b). Rewrite the whole thing lock stock and barrel.  Price: $12M.
Based on your analysis you are sure that Option b would be too high a risk to take and would likely lead to failure. Option a, though far from ideal would more than meet the needs and has a high chance of success. Which one would you recommend? If you put down the pros and cons in all honesty and recommend option a, this would lead to a high trust partnership and if you land up with downstream issues in delivery, you will have the client on your side. Joe Ippolito has some good tips on honesty in sales.

Communication: Communicate both the good and the not so good at the right time using the right tools. Often, bad news is bottled up and hidden away from the customer until it is too late. The reasons? Hope and fear. On one hand, people hope that somehow the problem would vanish and on the other hand they fear that bringing things out into the open would spoil relationships or make them look incompetent. Often, bad news is brought up through emails. Big mistake. Face to face communication of bad news allows appropriate communication of the context and ensures you have better control on the situation. Communicating bad news early and in a face to face discussion builds trust and shows the client that you really want to solve problems.

Listen, listen and listen: Listening to anyone provides that person psychological air and allows a climate of trust to build. Ask for ways in which your service can be improved and don't take "all is fine" for an answer. All is never fine. Probe to bring out small irritants. Nips these in the bud.

Choose battles wisely: Every client will have shortcomings. Overlook the small ones, complement the client and compensate for these lapses. Letting the small stuff pass builds trust and allows you to bring up the more important aspects where you need the client to change.

How you deliver does matter a lot.

Ramshankar laments about the lack of visibility when it comes to the services that IT departments support and expose to the business. "There are very few organizations where one gets a sense of what IT truly delivers to its customers at what cost, at what performance level, conditions and so on….What about “make your own Service menu” like “make your own pasta”! Is there flexibility within IT Services to accomplish this?" He goes on to suggest ITIL V3, a standard that recommends dynamic catalogs as a possible solution that can help end users and business see IT like a burger. Log in to an intranet portal or something and 'order' IT. Essentially hide away complexity and expose a very simple front end to business.

Renjith blogs about ITIL V3…"the Service Catalog concept have been enhanced and coupled with Demand Management, Portfolio Management and Request fulfillment."  

Interesting. Now, where's the burger?



IT plays multiple hats when it comes to business. I briefly touched upon the two broad types of IT demand in a previous post. Basically, there is the transformational 'change the business' part, and then you have the keep-the-lights-on 'run the business' aspect. 

Certain portions of 'run the business' are definitely like a burger. Desktop software installations come to mind. You have limited complexity, a fixed set of ingredients (read skills sets), a mature and repeatable execution model, resources are interchangable and not too many unknowns. When was the last time an IT engineer failed to install Office on your desktop ? Surely you can, given the right tools, adopt sophisticated demand forecasting with integrated resource fullfillment and maybe even aggregate demand across customers and have a portfolio level approach. The benefits are clear and easy to quantify.

'Change the business' is an entirely different game altogether and so will any aspect of 'run the business' that requires close integration with 'change the business'. This is more complex stuff that requires a more strategic approach both from business and from IT. 'Change the business' is more like a full course meal in a gourmet restaurant, replete with all the bells and whistles. 

Burgers are cool and have their place. So do gourmet dinners. The trick is to know what to serve to which customer.

Abhijit writes about estimation as being the weakest link in software development. He says:

"Most of the times the people who estimate and people who develop are different, their skillsets are different, and most importantly the business needs and constraints change at a higher frequency. "

Estimation is surely a weak link. Often, sales guys try to sell the project through an estimate. From a management perspective, if you can get the three edges (scope, time, cost) of the 'golden' triangle to meet then you have a successful development project. What do you think is the weakest link ?

I sometimes grudge the fact that I never made any money with stock options. But do I deserve any at all ? Let me find out. First, let me establish a logical basis for granting stock options to an employee. Stock is ultimately a share in the business and to get a share of the business, broadly speaking: a). One should have invested one's own money as capital (in which case the stock compensates for entrepreneurial risk taken)  or b).One should have been in a position to do something that would enhance shareholder value directly and importantly tangibly. I stress the words directly and tangibly here and c). The difference in shareholder value added between an outstanding performer and an average one should be significant enough to grant options to motivate the outstanding performer and d). The base salary should be low enough compared to the shareholder value added to justify share options.

Case a). Granting options to a project manager. Base salary: 80K
Sub case 1: Great manager manages the project well and delivers 10% ahead of schedule with associated 10% lesser cost at an increased operating margin of 30%. Believe me, this is not an easy act.
Annual Revenue from  project : $1M
Operating margin          : 30%
Earnings from project   : $300000
Share holder value added : $6M (assuming a p/e of 20).
Sub Case 2: Average manager delivers 10% behind schedule with associated 10% cost overhead at an reduced operating margin of 25%. 
Annual Revenue from  project : $1M (most clients ultimately pay up!)
Operating margin          : 25%
Earnings from project   : $250000
Share holder value added : $5M (assuming a p/e of 20).
There is an added cost due to loss of interest due to delayed payment which I shall ignore here.



Case b). Granting options to a sales manager.Base salary: 100K
Sub case 1: Great manager signs three large deals aggregating $50M at an increased bill rate that allow a projected operating margin of 30%
Annual Revenue generated : $50M
Operating margin          : 30%
Earnings from the manager  : $15M
Share holder value added : $300M (assuming a p/e of 20).
Sub Case 2: Average manager signs one deal for $5M at an decreased bill rate that allow a projected operating margin of 25%
Annual Revenue generated : $1M
Operating margin          : 25%
Earnings from the manager  : $250K
Share holder value added : $5M (assuming a p/e of 20).

Seems like the superstar sales guy deserves a few options. His contribution to share holder value is direct, tangible and is an incredible 3000 times his base compensation and he outperforms his "average" counterpart by a factor of 60.
The superstar project manager for all the long nights he has put in has only managed a contribution to share holder value that is 75 times his base pay and he outperforms his "average" counterpart only by a factor of 1.2. Moreover, his contribution is not as direct and as tangible as that of the sales guy. After all what is a project manager without a team ?

It is never easy to link individual contributions to shareholder value, and the logic in the arguments above are not watertight, but well it is clear that I am either moving into sales or going back and ranting to my boss. :-)