As a cost means a different thing to different people (in a given context), therefore, it is obvious that profitability would also be sensitive to these variations. For example, we have “Gross Margin”, “Operating Margin”, and “Contribution Margin” to assess the profitability from different perspective; one cannot be a substitute for another, as the constitution of each is different, and each has been devised to assess a performance from a specific perspective.
Is that all about a project when it comes to profitability assessment; may be not.
One may usually start from ROI (IRR, NPV, and Payback Period (including McFarlan’s analysis,)) to assess from returns perspective; however, it may not be true for s/w projects that we carryout for customers because this step would have already been done by customer. Nonetheless, it is the starting point for a project, though this accountability may not lie at our end, or we may not carry out the analysis exactly under those heads.
Having said that, a project (unless it runs to some millions of dollars, or is of strategic importance) may not require these overall measures, instead we would be interested in data in terms of “Earn Vs. Burn” (Earned Value). This is profitability from “delivery” aspect. It has been in practice for more than a decade, and has matured over a period of time. Though, there are many variations and measures for this, a quick look upon CPI, SPI, and TCPI should provide enough pointers; getting into details, where these measures point trouble (may be potential one) is the subsequent step.
You can further develop it by introducing savings and environmental dimension to it. That is, by looking at it from COQ, IP reuse, and Quality Projections perspective on one hand, and from FOREX hedging, span (spread across financial years), resource pyramid change, promotions / increments, and business continuity perspective, for long duration (multi-year) perspective. What is means, is not only you should be vigilant on profitability measures, but on factors which can impact (positively / negatively) the profitability of a project.
Can this approach be further developed, the answer is yes. We can further consider the “opportunity” cost, and measure the profitability through Economic Value Added (EVA). It may sound extreme, and may be, it is for small projects; however, would be beneficial for large long running projects. What it means is that you are going beyond financial profitability and looking at true (economic) profitability. The reason being, a company can have a positive MVA; however, could still be operating at negative EVA. But it should definitely be at next level (maturity level), and would make more sense at an “aggregate” level.
Last but not the least, you may also see profitability in terms of “incentives”, i.e. all incentive based projects have the potential to contribute towards revenue, and take away from that pie. Whether it is applicable in a given case depends on the model adopted; however, incentive based projects are a reality, especially in a service organization.
In essence, you need to figure this out (project profitability) from “Fitment / Contribution”, “Financial”, “Delivery”, “Quality / Engineering / Productivity”, “Environmental”, and “Economic” factors. That is, each role and level has an opportunity to contribute to project’s profitability, and we should consider ALL, when it comes to project’s profitability.
As I mentioned in the beginning, you need not do all, or conduct this all the time, for all factors, and / or by all the people; instead, it is the context, which should drive your choice of tool / measurement.
Saturday, November 14, 2009
Monday, May 11, 2009
SaaS, S/W+Service - Is this the end of licensed s/w?
It is a fundamental understanding and fact that no solution fits all requirements and hence markets. A market is defined on the basis of segment it serves, and no two segments are same; as otherwise, there had not been any segmentation in first place.
Having said that, let me develop it a little further.
SaaS (Software as a Service) was started with much fanfare, and still is the buzz word at some (if not, many) places. It might have been started as an alternative to "Licensed" software; however, it is also a fact that it has to have revenue generating mechanism to survive. Therefore, the revenue mechanism could be "pay-per-use", "bulk-slot" or something else. What it essentially means is that instead of paying for the usage of s/w upfront, you pay as you use; essentially, staggering the cost over a period of time, instead of incurring at a point in time.
Has this been able to make a significant dent in "License" software world? Is it really a cost effective an answer to "Licensed" software? Or, is it really an alternative to "Licensed" software?
Before, answering any of these questions, let's have a brief look at "Software + Service". What it means is that you are combining the goodness of both and getting that delivered over locally, and over the cloud. However, the questions applicable in case of "SaaS" are also applicable in this case. However, is it really the silver bullet?
The answer to all of these questions, actually lie in backdrop, which I have used in the beginning of this blog. That is, it depends on the market (segment) that you are servicing.
The reason being, whether it is standalone s/w, SaaS, or S/W + Service, one needs to understand the needs (read requirements) from following perspective,
1. Customizations Vs. Standardization - Business specific implementation
2. Security - Data security, and security to business secrets / competitive advantages
3. Business Continuity - Backup, and Disaster Recovery
4. Scalability - On demand usage
5. CAPEX and OPEX Vs. Budgets
6. Statutory regulations (Data Centres, Data Sharing etc.)
7. Network connectivity and latency
What it essentially means is that depending on constraints a customer would need to trade-off in order to fulfil his / her requirements. These constraints, along with choice of trade-off would decide the segment a customer belongs to.
Now, after assessing all this, can we say that one is better over the other? Not really, as each has its limitations; however, is a right fit for given market segment. For example, a SaaS may not provide me a flexibility of “customization”; however, if my requirement is standard and is also provided by the vendor, why would I not be interested in that? For example, a simple mail service provided by Google to enterprise may not have the flexibility of customizations; however, it does meet the needs of small enterprises, who need basic mail facilities. Therefore, it is the right solution for this market; the contrary may holds true for large enterprises, and hence, the custom implementation.
A software plus service may be providing a platform to have the customizations along with goodness of SaaS; however, can everyone afford it? Even if for argument’s sake, if we accept the affordability, can it also negate / neutralizes other factors, as listed above, i.e. Security, Network Connectivity, Statutory and Regulatory requirements?
Obviously, it cannot. Therefore, the impact of these available options on product companies would be a function of presence in a given market segment. They would need to optimize the offering as per given market segment.
It means that if for a product company the segment now lies in “Software + Service”, it would need to make an investment in that, and realign its resources, and operations in line with this segment. The same holds true for SaaS, and standalone S/W.
At best the emergence of alternatives (as discussed above) would need realignment of focus, resources and operations, depending upon the exposure of that organization to given segment. However, it is also true that, companies relying on bloated "(Product) Gross Margins" would need to align their business direction from "S/W Product", to "S/W Service"; hence, requiring a change in pricing model, charging model, service model, and may be a change in workforce mix and skills.
In nutshell, whether you like it or not, the erstwhile, s/w product companies need to mend their ways the way they had been doing the business. They solely can't rely on fat "product margins"; instead, they need to adept, adopt, and excel in new game via realignment of business to suit the environment. The reason being, today's behemoth is no guarantee for future existence.
Having said that, let me develop it a little further.
SaaS (Software as a Service) was started with much fanfare, and still is the buzz word at some (if not, many) places. It might have been started as an alternative to "Licensed" software; however, it is also a fact that it has to have revenue generating mechanism to survive. Therefore, the revenue mechanism could be "pay-per-use", "bulk-slot" or something else. What it essentially means is that instead of paying for the usage of s/w upfront, you pay as you use; essentially, staggering the cost over a period of time, instead of incurring at a point in time.
Has this been able to make a significant dent in "License" software world? Is it really a cost effective an answer to "Licensed" software? Or, is it really an alternative to "Licensed" software?
Before, answering any of these questions, let's have a brief look at "Software + Service". What it means is that you are combining the goodness of both and getting that delivered over locally, and over the cloud. However, the questions applicable in case of "SaaS" are also applicable in this case. However, is it really the silver bullet?
The answer to all of these questions, actually lie in backdrop, which I have used in the beginning of this blog. That is, it depends on the market (segment) that you are servicing.
The reason being, whether it is standalone s/w, SaaS, or S/W + Service, one needs to understand the needs (read requirements) from following perspective,
1. Customizations Vs. Standardization - Business specific implementation
2. Security - Data security, and security to business secrets / competitive advantages
3. Business Continuity - Backup, and Disaster Recovery
4. Scalability - On demand usage
5. CAPEX and OPEX Vs. Budgets
6. Statutory regulations (Data Centres, Data Sharing etc.)
7. Network connectivity and latency
What it essentially means is that depending on constraints a customer would need to trade-off in order to fulfil his / her requirements. These constraints, along with choice of trade-off would decide the segment a customer belongs to.
Now, after assessing all this, can we say that one is better over the other? Not really, as each has its limitations; however, is a right fit for given market segment. For example, a SaaS may not provide me a flexibility of “customization”; however, if my requirement is standard and is also provided by the vendor, why would I not be interested in that? For example, a simple mail service provided by Google to enterprise may not have the flexibility of customizations; however, it does meet the needs of small enterprises, who need basic mail facilities. Therefore, it is the right solution for this market; the contrary may holds true for large enterprises, and hence, the custom implementation.
A software plus service may be providing a platform to have the customizations along with goodness of SaaS; however, can everyone afford it? Even if for argument’s sake, if we accept the affordability, can it also negate / neutralizes other factors, as listed above, i.e. Security, Network Connectivity, Statutory and Regulatory requirements?
Obviously, it cannot. Therefore, the impact of these available options on product companies would be a function of presence in a given market segment. They would need to optimize the offering as per given market segment.
It means that if for a product company the segment now lies in “Software + Service”, it would need to make an investment in that, and realign its resources, and operations in line with this segment. The same holds true for SaaS, and standalone S/W.
At best the emergence of alternatives (as discussed above) would need realignment of focus, resources and operations, depending upon the exposure of that organization to given segment. However, it is also true that, companies relying on bloated "(Product) Gross Margins" would need to align their business direction from "S/W Product", to "S/W Service"; hence, requiring a change in pricing model, charging model, service model, and may be a change in workforce mix and skills.
In nutshell, whether you like it or not, the erstwhile, s/w product companies need to mend their ways the way they had been doing the business. They solely can't rely on fat "product margins"; instead, they need to adept, adopt, and excel in new game via realignment of business to suit the environment. The reason being, today's behemoth is no guarantee for future existence.
Subscribe to:
Posts (Atom)
