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.

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 ?