Thoughts from the trench - by Prakash Muralidharan

September 19, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Should you move first or fix first?

Filed under: Outsourcing, Strategy — Prakash Muralidharan @ 10:02 pm

Dinesh Goel of TPI says "Corporations deciding on a sourcing strategy need to answer the “chicken or the egg” question: what comes first - the fix or the move?" "Fix" here means improve efficiency and effectiveness. "Move" refers to outsourcing. He goes on to propose the following framework for making the decison:
   TPI framework

It would be interesting to place the fix first /move first dilemma in the context of the larger sourcing problem. What to outsource and what to retain in house is a more fundamental problem. You obviously want your own people to work on the more strategic stuff. But what if your strategic stuff is all messed up and you don't have the skills needed to fix it. You might then opt for a Move (bring in a vendor)-Fix (let him change the model and also empower your people)-Move back(take your baby back and manage it with the newly empowered people) model. In this case you would go in for a transformational partner rather than just someone who can just drive efficiencies. I think of it something like sending your kid to a great boarding school.

To cut a long story short, the whole move-fix/fix-move puzzle needs to be viewed in the larger context of what is strategic to your business, whether your people have the skills needed and what type of a partner to engage to transform the areas that need 'fixing'. Once you have this nailed, you can go on to decide whether to fix first or whether to move first.


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Should you move first or fix first?

del.icio.us:Should you move first or fix first?  digg:Should you move first or fix first?  fark:Should you move first or fix first?
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/09/19/should-you-move-first-or-fix-first/trackback/

July 13, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

The nature of demand for software services.

Filed under: Software Services, Strategy, Client Management, Account Management, Pitching — Prakash Muralidharan @ 3:49 pm

A salesman's job is to shape needs and generate demand. With the economy in recession, many clients are cutting budgets. Prabhu says there is evidence that budgets are getting halved in several industries. Demand seems to be either stagnant or is taking a nosedive.
     Talking of demand, there have been very different times too. Most people of my generation (read oldies!) have seen the Y2K boom followed by the rollercoaster dot com era - dog food selling websites getting valued at billions and then getting dumped at values lower than even their tiny dog food inventories would command. The dot com era also saw the demand for skills like 'digital strategy'. You could download a few articles on B2B and B2C and take a month rehashing them into a nice looking ppt titled 'Monetizing Eyeballs', replete with clouds and arrows and bill at $250/hr while you are at it. Oh! Did I mention fat perdiems ?
      Most attempts to understand demand are done from a vendor's perspective. Starting with staff aug and ending with consulting. Co-sourcing and managed services bring up the middle. 
Makes perfect sense. The only problem I have is that this is a very inward way of looking at demand, it's demand from a vendor perspective. The client simply does not think on these lines. From a client's perspective, there are two broad classes of demand a). Steady state demand (SSD)-The keep-the-lights-on part that is responsible for keeping the business running and b). Transformational demand (TD) that seeks to change the business. Steady state demand, while being unglamorous, provides much the needed revenue stability that comes with an annuity business. It allows you to meet your numbers, build operational relationships and acts as a backbone during tough times. Transformational demand has peaks and troughs, is sometimes based on the whim and fancy of client execs. Tapping into transformational demand needs a different style of engagement, centered on thought leadership and the business domain. It demands that you take a point of view when you talk to customers instead of just asking them "I have great people with me. How can I help ? ". What makes transformational demand most critical is that today's TD is tommorrow's SSD. Here are some key differences between the two streams of demand and some thoughts on how to engage.

 Steady state demandTransformational demand
Demand VisibilityTypically of an annuity nature and has long term visibility. Visibility is often tied to related transformational initiatives.Visibility depends on the level of client engagement. Lower levels of engagement limited to operational staff renders poor visibility while a strategic engagement approach leads to much higher visibility.
Demand VolatilityLow to medium volatility compared to transformational demand. Downturn in budgets could see positive or negative spikes depending on the client's propensity to right size his own IT organization.Highly volatile as demand is often discretionary. Economic cycles drive budgets and spending. Clients often prefer to have a greater proportion of internal staff do the work.
Strategic importanceAdds revenue predictability and acts as a backbone during lean times. Helps build strong operational relationships.Best way and often the only way to dislodge a deeply entrenched SSD competitor. TD manifests as future SSD.
How to Pitch ?Commit productivity improvements year on year and lock up demand in the form of multi year annuity contracts.Do not focus on cost or productivity as a value. Instead, demonstrate thought leadership through a 360 degree approach encompassing domain, people, processes and technology. Key message :"You are at point A now, but need to be at point B and here is how we can take you there".
What the client looks for in a partner ?Flexibility and demonstrated value that goes beyond cost arbitrage.Thought leadership and business value.
Keys to shaping demandEarly entry into the sales cycle. Strong operational relationships and the ability to link cost savings through offshoring in SSD to investments in TD.Strong strategic relationships and the ability to lead the thought process.

What are your thoughts and experiences with various demand streams ?


     


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: The nature of demand for software services.

del.icio.us:The nature of demand for software services.  digg:The nature of demand for software services.  fark:The nature of demand for software services.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/07/13/the-nature-of-demand-for-software-services/trackback/

June 6, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Shaping needs versus shaping demand.

Filed under: Software Services, Strategy, Selling — Prakash Muralidharan @ 1:24 am

The term 'shaping demand' is very popular catch all phrase that stands for everything that you need to do to morph demand to align with supply. In blunt terms, if you can sell profitable projects with a high offshore ratio, end to end scope of execution and a favorable resource mix then you have managed to 'shape demand'.

The intent is good, but I feel the focus should be a little different. Projects where the demand is aligned to the supply have a better chance of succeeding, other things remaining the same. However, ultimately it is problems that give rise to needs and needs in turn create demand for services. 


Shaping demand and Shaping needs

You cannot 'shape demand' unless you help the customer in the demand creation process. The way to do this is by focusing on the problem and helping the customer distill it into needs. Doing this does two things: One> You really, really understand the customer. Not from a vendor viewpoint of service lines and offerings but from a viewpoint of the problem as the customer sees it -with visibility and leverage into all the intangibles that go into the customer's buying decision. The vendor essentially becomes a participant in the decision and is thus in a position to shape the form and structure of the decision and not just the outcome. You don't just win the prize, you get to decide the prize - add any bells and whistles needed, before you win it.

Two> Even if your are less capable that your competition in execution, the customer sees you as a cut above the rest of the vendors who are running around trying to 'sell' their services. You have as much skin in the game as the customer.
You have a far better chance of aligning demand to supply, by not trying to shape demand, but instead, taking a consultative approach to selling that focusses on problems and needs. The demand shaping will take care of itself!


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Shaping needs versus shaping demand.

del.icio.us:Shaping needs versus shaping demand.  digg:Shaping needs versus shaping demand.  fark:Shaping needs versus shaping demand.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/06/06/shaping-needs-versus-shaping-demand/trackback/

June 3, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Rupee appreciation and the industry response.

Filed under: Software Services, Outsourcing, Indian Business, Strategy — Prakash Muralidharan @ 12:07 am

The five year rupee dollar exchange rate clearly seems to trend towards a stronger rupee. Here's the picture from Yahoo.

Chart

Over a four year period the appreciation is almost 20%. Mobius says Infosys has done a splendid job of containing the operating margin dip by leveraging scale, increasing billing rates and growing the high margin segments of the business faster. I would also add to that possibly (don't know for sure!), good hedging practices, growth in non US business and better execution practices especially on fixed price projects. Venkatesh suggests leveraging Agile and lean practices to improve processes thereby getting more bang for each person hour of effort. Achyut calls for human value appreciation by hiring people with more business acumen and combining multiple roles into a single person. Shivprasad has some job security tips for employees.

Clearly, the industry has responded in a broad based fashion with multiple market and delivery levers getting pulled. Here is what I think would be the strategic implications:

-Long term contracts with US clients would becoming less attractive and compa nies would start looking at ways to avoid long term bill rate lock in.

-With top managers getting incentivized on margins, internal resource arbitrage would start happening with non US clients being able to command more senior and experienced resources. A rupee spent in servicing non US clients would add more to the bottomline than a US client.-Sales folks would start getting incentivized not just on topline but also bottom line and revenue quality. Not fair eh ? Well, people who sell profitable projects are better than people who sell unprofitable ones. Now, before I open up a pandoras box, let me move on to the next point.  Smile

-Fiscal management would move down to the project level and margin management which is currently a delivery management responsibility would start becoming a project manager responsibility.

-There would be an added incentive to apply the offshoring model to business segments like consulting to squeeze out even better margins. Standalone consulting that cannot be offshored in itself and does not lead to downstream business would be questioned
.


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Rupee appreciation and the industry response.

del.icio.us:Rupee appreciation and the industry response.  digg:Rupee appreciation and the industry response.  fark:Rupee appreciation and the industry response.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/06/03/rupee-appreciation-and-the-industry-response/trackback/

May 29, 2008

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Revenue distribution in software services-No long tail

Filed under: Software Services, Indian Business, Book review, Strategy — Prakash Muralidharan @ 12:00 am
Chris Andersen pioneered the concept of the long tail and Wikipedia defines the same as:

The long tail is the colloquial name for a long-known feature of statistical distributions (Zipf, Power laws, Pareto distributions and/or general Lévy distributions). The feature is also known as heavy tails, power-law tails, or Pareto tails. Such distributions resemble the accompanying graph.

In these distributions a high-frequency or high-amplitude population is followed by a low-frequency or low-amplitude population which gradually "tails off." In many cases the infrequent or low-amplitude events—the long tail, represented here by the yellow portion of the graph—can cumulatively outnumber or outweigh the initial portion of the graph, such that in aggregate they comprise the majority.


I have been pondering about the possibility of an upstart services company with a new business model. As part of my analysis I have been looking into the financial statements and annual reports of companies and this is what I found from the annual report of one such company.

-The bulk of the clients are between $1 million and $ 5 million  but they contribute to less than 6% of the revenue.
-72% of the revenue comes from 28% of the clients and these are not small clients (> $10M).
-Truly large clients are not many.


Note: The data used for analysis has undergone some approximation.


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Revenue distribution in software services-No long tail

del.icio.us:Revenue distribution in software services-No long tail  digg:Revenue distribution in software services-No long tail  fark:Revenue distribution in software services-No long tail
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2008/05/29/revenue-distribution-in-software-services-no-long-tail/trackback/

October 14, 2007

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

What should a CIO do ?

Filed under: Strategy — Prakash Muralidharan @ 5:11 pm

Interesting question eh ? Nobody would have any issues in defining a CEO or CFO role. But C.I.O ? Allan Holmes calls for two types of CIO's, strategic and tactical. "Strategic CIO who would focus on creating value through technology, and a tactical CIO whose primary goal would be to run an efficient IT shop." Peter Weill of Sloan MIT says "The CIO’s expertise is in communicating to business colleagues the importance of IT—and more important, getting the governance right." Peter seems to point us to the CIO as a business partner, some one who can tell the business as to what is possible with technology.
             
Chaim Yudkowsky provides the following guidelines for a CIO role :
Manage and safeguard key data, communications, hardware and software.
Provide input and feedback in the overall business strategy and budgeting process, not only for IT. 
Help improve process efficiency and reduce cost using technology. 
Be an active part of an executive team with a mission of profitability and productivity.

Most CIOs come from a predominantly IT background and according to CIO Insight : 65% IT, 9% business, 26% hybrid. Jeff Wacker of EDS has an interesting view on what CIO's should not be : Chief Inertia Officer , Chief Impediment Officer, Chief Inefficiency Officer.


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: What should a CIO do ?

del.icio.us:What should a CIO do ?  digg:What should a CIO do ?  fark:What should a CIO do ?
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2007/10/14/what-should-a-cio-do/trackback/

July 30, 2007

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Revenue per employee : A shortsighted productivity metric

Filed under: Software Services, Pricing, Strategy, Account Management — Prakash Muralidharan @ 1:59 pm

I came across this piece in the Times praising US tech companies. The article uses revenue per employee (RPE) as a yard stick and claims "US IT professionals more productive". Basically we have Wipro,Infosys,TCS etc on one side and IBM,Dell, HP etc on the other. The arguments are backed up by numbers but the logic is flawed. I find it hard to believe RPE can be linked to a professional's productivity. The revenue a services company makes is broadly (ignoring systemic factors like currency risk, credit risk etc) dependent on the following :
- Bill rate (significantly higher for 'Western' players)
- Utilization rate (More or less the same)
- Offshore onsite mix (Much better for Indian players).

The higher RPE that US companies make is largely on account of the following:
- Significantly higher bill rate
- Broader portfolio that includes software products and consulting which traditionally have a greater RPE than pure services
- Higher onsite/offshore ratios leading to a higher top line for the same number of FTE's billed.

None of these factors have anything to do with employee productivity. In fact for certain types of engagements staffing more productive employees could reduce RPE! A better caption for the article could have been "US companies turning people capital into cash more productively".


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Revenue per employee : A shortsighted productivity metric

del.icio.us:Revenue per employee : A shortsighted productivity metric   digg:Revenue per employee : A shortsighted productivity metric   fark:Revenue per employee : A shortsighted productivity metric
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2007/07/30/revenue-per-employee-a-shortsighted-productivity-metric/trackback/

June 24, 2007

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

Web 2.0, SaaS and all that: A fillip for infrastructure outsourcing ?

Filed under: Outsourcing, Technology, Strategy — Prakash Muralidharan @ 8:25 am
Nick Carr writes says "The management of atoms is becoming as important as the management of bits.." in his insightful (as always) article. The last few decades has seen work move to wherever it can be done most efficiently at the best possible price. As enabling technologies have evolved and outsourcing models have matured, we have seen software outsourcing progress from maintenance all the way to product development. If the management of atoms becomes as important as the management of bits, we will likely see outsourcing models evolve further in the infrastructure space. We could have a Google data centre in China, managed by technicians in Vietnam with the software written in the US and maintained in India!

Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: Web 2.0, SaaS and all that: A fillip for infrastructure outsourcing ?

del.icio.us:Web 2.0, SaaS and all that: A fillip for infrastructure outsourcing ?  digg:Web 2.0, SaaS and all that: A fillip for infrastructure outsourcing ?  fark:Web 2.0, SaaS and all that: A fillip for infrastructure outsourcing ?
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2007/06/24/web-20-saas-and-all-that-a-fillip-for-infrastructure-outsourcing/trackback/

June 10, 2007

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

The over engineering trap

Filed under: Software Services, Products, Gotchas — Prakash Muralidharan @ 3:17 am
You see it everywhere. Right from Microsoft's billion dollar products to simple .NET applications. Features that nobody wants to use, but everybody is made to pay for.  The over-engineering malady stems from wrong assumptions, philosophies and attitudes.

More is always better: More is not always better. Packing in features that nobody wants increases the chances of bugs in the features that people really want, makes them pay more for these buggy features and slows down time to market. The marketing folks who are reading this would probably feel that without some over-engineering they cannot sell the product. Agreed! More could possibly be better for the company making the product, but almost always bad for the end customer. 

We need to plan for the future: Let's face it. Most of the time you cannot predict future requirements. Requirements change and that is the fact. The way around that is not to predict and wire in your 'bets' into your requirements but to make the right decisions in the design. However, watch out for the flexibility mania in design (see below).

Product marketing over zealousness: Rand Eckfeld's IEEE paper brings out the importance of using Agile principles in strategic planning. "Projects must be coupled with a complimentary approach to strategy to in order to achieve the overall business goals. If agile development is to continue growing in the business community, complimentary strategic planning capabilities must be developed that share the same agile philosophies. " Product marketing would do well to apply Agile principles during customer interactions to stabilize and prioritize requirements better. Often product marketing has only a strategic feel of what the customer wants and distills this feel into a 'creative' product requirements specification setting off over-engineering. Steve Garnet explores the idea of Agile in business more fully.

Flexibility mania: Joshua at Dr.Dobbs defines code level over-engineering as "When you make your code more flexible or sophisticated than it needs to be, you over-engineer it."  

 


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: The over engineering trap

del.icio.us:The over engineering trap  digg:The over engineering trap  fark:The over engineering trap
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2007/06/10/the-over-engineering-trap/trackback/

May 20, 2007

Nederlands/Dutch Français/French ???????/Russian Deutsch/German Italiano/Italian Português/Portuguese Español/Spanish ????????/Greek 日本語/Japanese 한국어/Korean 中文(简体)/Chinese Simplified 中文(简体)/Chinese Traditional

The top five grand challenges for offshore software services companies.

Filed under: Software Services, Outsourcing, Indian Business, Strategy — Prakash Muralidharan @ 7:01 am

 Grand challenges of offshore software services

Irving Berger's grand 21'st century challenges inspired me to think about the biggest challenges in offshore software services.

Paradigm shift from service provider to influencer : Being able to influence and drive IT budgetary decisions rather than just respond to RFP's. This would require not just a strong understanding of client businesses but a very high level of trust.

Genuine transnational multi shoring: Being able to leverage local strengths in geographically diverse locations and weaving that into a holistic and a compelling value proposition.


Large deals: Large and complex deals that go beyond the traditional software-BPO mix. Such deals would provide revenue visibility and would stretch current capabilities in execution, mindset and risk management. 

Cultural integration of global workforces: Being able to meet the other challenges above would require the increasingly diverse workforce to be culturally integrated. The culture in offshore firms with purely Indian ethos and values would need to evolve into a more inclusive and global culture.   

Making product outsourcing work: Product development outsourcing has caught on, but is a model in the midst of growth pains. These pains are very different from the ones experienced by the first generation of outsourcers a couple of decades ago. 

 


 

 


Linking and Sharing

If you found this page useful, consider linking to it.
Simply copy and paste the code below into your web site (Ctrl+C to copy)
It will look like this: The top five grand challenges for offshore software services companies.

del.icio.us:The top five grand challenges for offshore software services companies.   digg:The top five grand challenges for offshore software services companies.   fark:The top five grand challenges for offshore software services companies.
Trackback

Trackback URI for this entry:

http://www.prakashonsoftware.org/blog/index.php/2007/05/20/the-top-five-grand-challenges-for-offshore-software-services-companies/trackback/

Next Page »