Thursday, December 10, 2009
Wednesday, October 28, 2009
Is this the end of project inertia?
I have watched an organisation struggle to implement a large project. Dates were missed, clients disappointed and staff demoralised. The immediate reaction was to bring in the big consulting firms with their "proven methodologies" and ability to deliver. Yet still dates were missed. The general methodology was around delivering the Ben Hur release because that was the only way their processes including testing could work. Sound familiar? I am sure many of us could relate this scenario to various projects we have worked upon.
Recently I read the following article which shows a trend towards getting a new breed of project manager that is more in touch with the business and more focused on getting things moving rather than allowing inertia to rule.
http://www.cio.com.au/article/323172/key_capabilities_next-generation_project_managers?eid=-153
Recently I read the following article which shows a trend towards getting a new breed of project manager that is more in touch with the business and more focused on getting things moving rather than allowing inertia to rule.
http://www.cio.com.au/article/323172/key_capabilities_next-generation_project_managers?eid=-153
Monday, May 25, 2009
The Dreaded Patch Upgrade
So that time has finally arrived. That version of software that you have been running so happily for the last five months since upgrading has a bug in it which has just shown up. It’s critical for year end processing (30 June) and it’s now the end of May.
The vendor, ever responsive in these situations, jumps to it and a week or two later announces they have a patch for you. Just as you are sighing with relief and thanking God for saving your career, you hear the off the cuff remark: but of course you will need to take all the other patches since your last upgrade!
Five months worth of patches averaging 10-20 a week to be implemented in live with less than a month to go. It normally takes you about a month to organise the business for an acceptance test and then another month to execute it, fix any new issues and get agreement to go live. Suddenly updating your LinkedIn profile seems incredibly important.
Out of desperation you call up your counterpart at a competitor seeking help to pressure the vendor into releasing a custom patch to match your old programs. His answer: not an issue. He has taken the patch yesterday, tested last night, identified two regression issues which should be fixed by Monday, retest Tuesday, live on Wednesday. Is this just reckless abandon or does he have a secret? The answer is Automated Regression Resting.
It seems so simple. The main reason a patch upgrade causes fear is the amount of time it takes to test them before going live and nobody wants to just put things in live. This elapsed time is smashed when using automated regression tests. The impact is apparent when you look at an example whereby a major international funds management group managed to cut the execution of their test scripts down from 6 weeks to 3 hours by introducing these tools.
What I can’t understand is why so few organisations put the effort into setting these things up. Over 20 years consulting to many different firms around the globe I have only seen it used in about 2-3 companies. Yet every company I have ever discussed it with recognises the value add but there is always a reason not to do it:
- “We don’t see ourselves upgrading in the near future!”
- “The maintenance challenges are too extensive!”
- “We don’t have the budget this year!”
In the example given above the firm had already documented its tests. It then took one person 3 months to automate them. Payback was achieved within the first 3 months.
So what is needed to become the hero of your business and be in a position whereby the mere mention of the wrd upgrade does not have you cringing under your desk?
First you must have some test scripts. Hopefully the last time you did a manual upgrade you documented with your business the tests that were necessary to satisfy them that the system was stable. These should be your base as the business has previously agreed they were acceptable. If you don’t have this then you need to set a team aside to document what tests are required.
Next you need to setup a database that is typical of your business. Real data is important rather than test data as it has a much better chance of identifying the unexpected changes that will really affect your business. This database is critical to the success of your testing so make sure you take some time to get good coverage.
Now automate the scripts using whichever tool you have chosen. This could be as simple as keystroke and mouse capture or a more complex scripting mechanism.
You can now create your baseline. Execute the tests across your database and store them away. It does not matter if the results are correct or not. The key for regression testing is to identify change. Change maybe wrong or it could be for the better. Once you have identified change then you work out which is correct and which wrong. Then you can update your base results set.
Your final piece to consider is maintenance. There is an ongoing cost to having an automated regression suite. As many changes that come through are deliberate you have to go through each of them and alter your scripts to cater for them. This can be a non trivial event but will still normally be offset by the gains from automation. To give you an indication of size, one vendor of asset management software took the one man month worth of effort to update between versions. Their test scripts at the time took 8 hours to run.
To be successful at automation consider the following:
- Use a professional test consultant to define your scripts. Experience at this point will make maintenance much easier.
- Check what automated checking tools your testing software has.
- Check what features your testing tool has to minimise maintenance. For example if one login screen is used for all tests can it be maintained in one place and not all test scripts.
In summary automated regression testing pays for itself in a very short time. On top of this though is the fact that it is one of the few ways to protect your business from the dangers of urgent patch upgrades. As such it would be hard to understand why those companies that don’t have it are not being negligent towards their business’ interests.
I would be interested to hear other people’s experiences with automated testing to see what benefits they have achieved and what pitfalls they have run into.
Friday, January 23, 2009
Why offshore - can't we find the people?
I had a response from a past colleague who raised a very good point which is we need to consider the availability of the relevant skills in both numbers and ability. Graduates are not interested in COBOL and if you need 40 J2EE developers for 6 months its quite a challenge trying to find them. Hence the appeal of the scale of these large offshore companies.
I must admit my thoughts were primarily around those companies that were moving whole operations offshore on a permanent basis. In such a situation there is normally a large training process to handover the knowledge which could be done just as easily (if not more so) somewhere closer to home.
This lack of availability does worry me. Does Australia not have the foresight to produce the right candidates from its education system? Do our graduates think they are too good for the old tools?
Maybe it is a bit of the chicken and egg syndrome. Until someone has the capital base to setup an operation with some of these skills readily available there will not be a local option and hence the work moves offshore. I wonder what is happening to all those people being put out of work!
I must admit my thoughts were primarily around those companies that were moving whole operations offshore on a permanent basis. In such a situation there is normally a large training process to handover the knowledge which could be done just as easily (if not more so) somewhere closer to home.
This lack of availability does worry me. Does Australia not have the foresight to produce the right candidates from its education system? Do our graduates think they are too good for the old tools?
Maybe it is a bit of the chicken and egg syndrome. Until someone has the capital base to setup an operation with some of these skills readily available there will not be a local option and hence the work moves offshore. I wonder what is happening to all those people being put out of work!
Saturday, January 10, 2009
Why Offshore?
Despite a continuing trend to move both information technology and business processing offshore I am yet to hear anyone touting it as a major success (except for the outsource companies themselves)! What are the reasons behind this?
I first got involved in offshoring in 1997 and have been involved in various incarnations since. This has stretched from first sampling the service by bringing a few skilled people onshore to top up head count, to moving complete data processing teams offshore. I have had varying levels of success from complete failures where we have had to rewrite all the code that was produced to successful teams functioning during our night to process data.
There are many resources out on the web that can help you to avoid the pitfalls that I and others went through so I don't intend to focus on them here (if you are interested then leave a comment and I will give you my two cents worth on how to make it successful) instead I would like to discuss some of the downsides to offshoring. This may sound a bit negative but if you wade through it to the end I have some more positive thoughts about alternatives.
Cost
It is indisputable that the cost per day of doing work in India, Thailand or China is dramatically less than the USA, UK, Europe or Australia. There are countless examples whereby it can be shown to be cheaper by a magnitude of 10. However what is more questionable is the cost per unit of work. How much functionality do you get for a day's worth of coding in Australia versus that in India?
I know that some software companies will first quote for the work using their local resources and will then apply a multiplier of 2-3 times to get the budget for doing the work in their offshore centre. So what you say! Assuming a cost of $1000 per day in USA versus $100 per day offshore, even if it does take 3 times as long, you are still dramatically better off. This is true but the gap narrows and some of the other trade offs that you have to make might erode that benefit further. For critical time to market initiatives this does start to make much more of an impact.
Ancillary costs also start to add up. For example it is generally agreed that to make this process work you need to send quality people from your local operation to the offshore location to transfer the knowledge and then manage the process. This initially sounds like a quick trip but in fact takes substantially longer than you would expect. I know of instances of people that were sent to the offshore location and are still there 4 years later. With the lucrative ex-pat packages that are used to compensate these people it is not a complete surprise. Once again adding to the costs.
Then there are the regular managerial trips across to review the operation. Given the distances involved these will normally take at least a week of a senior person's time, without counting the cost of "Delhi Belly" that will make it impossible for them to actually do any work!
These ancillary costs are easily consumed if you are moving very large numbers (hundreds or thousands) of staff offshore but in the funds management or independent software vendor world this is not so easily achieved so they do have a tendency to be noticed on the bottom line.
Quality of Service
Anyone that believes moving your operation away from your clients to a country that does not have the same first language or cultural background, does not effect the level of service you can provide, has their head buried in the sand. You need only look at the number of UK financial and utility firms that tried moving their call centres to India around 2000 only to move them back a few years later. See articles such as:
http://www.independent.co.uk/news/business/news/call-centre-switches-jobs-back-from-india-to-britain-574174.html
In another example there is a major US bank that has offshored its internal help desk. You need talk with very few of their staff to understand the very high level of frustration with using this service or the number of work arounds they have in place to try and get things done.
Remember when measuring the cost of a support service to your clients or your internal staff, the actual cost of providing the service is normally a lot less than the impact it has on the customer. For example lets assume I am a senior manager in Australia costing $200 per hour, my local support person costs $100 per hour and the offshore support person costs $10 per hour.
Scenario a) Under the local model the support person comes to my desk and takes an hour to fix the issue. This costs $100 for support.
Scenario b) With the offshore model using remote diagnostics the person takes twice as long to fix the problem. (From actual experince I think I am being very generous here!). This costs $20 for support.
It is quite clear from an IT perspective the offshore model is dramatically cheaper, but lets compare the real business cost. In scenario a) I lost an hour of my time or $200. In scenario b) I lost 2 hours or $400. It is not too hard to see which method is truly cheaper for the business.
None of this takes into account the relationship cost of exposing your customers to a degree of frustration.
All of these issues lead me to one of my strongest beliefs: NEVER push your clients (either internal or external) away from you by sending them elsewhere to get service. Know your clients well and keep them close to you and loyal!
Political Instability
There have been a number of disturbing events in both Thailand and India of late that raise the question do you want to put your business at risk or worse the lives of your staff for the sake of a few dollars.
Thailand has had 10 coups in the last 40 years and then more recently had sufficient civil unrest to close the airports for eight days in 2008.
The terrorist attacks in Mumbai, which took 2 days to suppress, have exposed some of the security risks within these countries.
Regulatory Protection
Satyam. Need I say anymore. One of the key criteria when selecting an outsourcing provider is financial stability. How can you trust the local regulatory regime when this style of fraud has been perpetrated for so many years?
If you are contemplating moving your development or research functions offshore then you should also investigate the issue of intellectual property protection. Some of these countries have a questionable background in protecting ownership rights as can be attested to by the Swiss Watchmakers and the American Film Industry both of whom are selling a tangible product. How well do you think you can protect your intangible intellectual property in that style of regime.
Staff Turnover
It is difficult to get exact numbers for staff turnover in the offshoring industry but there is a perception that it is high. This should be investigated when considering moving anything offshore.
You should also be aware that it is a very competitive environment to attract staff into. At one point I was trying to find 2 test analysts offshore. These positions took a number of months to fill. Once we had found the right candidates and they had accepted the positions the offshore manager advised us to keep interviewing. I asked why and was told they might not show up. I ignored this advice much to my detriment. Netiher candidate reported for work!
Methodology
The majority of development styles being used for offshoring are centred around traditional waterfall or plan-driven methodologies. These emphasise the up front analysis and design processes before passing the specifications offshore to be built. The opposing camp is around a new style of development generally referred to as agile. Agile methodologies emphasise face to face communication between all parties invloved. This style can be contradictory to the whole concept of having your developers 10,000 miles away.
Martin Fowler compares these two methodologies very well in his article "The New Methodology" at http://martinfowler.com/articles/newMethodology.html
Within this article a comparison is made to the construction industry that uses similar plan-driven methodologies whereby the engineers write a design which is then passed to the builders to complete. The concept is that design is difficult to predict and so requires expensive creative people whereas the build can be passed to less expensive people. This matches to many software companies' views of offshoring. We will do the design locally and ship the grunt work offshore. However there is a viewpoint suggested by Jack Reeves that the writing of source code is the true design and that the build is simply the compile. If you follow this line of thinking then with offshoring you are pushing the most intellectual part of the process away from where the action really is.
The Alternatives
I promised at the beginning that I would move towards suggesting some alternative to the current trends so hopefully I am good to my word. But first a bit of background of the funds management industry in Australia.
Going back 20 years there was a fairly even spread of organisations between Melbourne and Sydney and then a second tier within the other capital cities of Australia. Since then there has been a continuing trend of mergers, acquisitions and back office outsourcing which has moved most of the players to Sydney with a small contingent in Melbourne and an almost negligible amount in the other capital cities.
This has forced most of the workforce into Sydney which is by far the most expensive place to live in Australia and 15th most expensive in the world. In comparison Mumbai is 48th, Bangkok 105th and Bangalore 118th.
Given this it is no surprise that firms are looking to move their operations out of Sydney to a cheaper location and these days that all means Asia. But does it have to? Brisbane is cheaper than Mumbai at 57th and Adelaide also competes at 73rd.
Imagine what your staff would say when you announced that you are moving their jobs to a cheaper location and they have the option of moving to either Mumbai or the Gold Coast. I think I know which queue I would be in.
This same analogy can be used in most countries around the world. For example many UK Banks have chosen centres outside of London for their call centre operations. The US has middle America or Canada.
By choosing to move some of your operations to a cheaper location within your own country you negate many of the issues mentioned above. Some of the advantages are:
I first got involved in offshoring in 1997 and have been involved in various incarnations since. This has stretched from first sampling the service by bringing a few skilled people onshore to top up head count, to moving complete data processing teams offshore. I have had varying levels of success from complete failures where we have had to rewrite all the code that was produced to successful teams functioning during our night to process data.
There are many resources out on the web that can help you to avoid the pitfalls that I and others went through so I don't intend to focus on them here (if you are interested then leave a comment and I will give you my two cents worth on how to make it successful) instead I would like to discuss some of the downsides to offshoring. This may sound a bit negative but if you wade through it to the end I have some more positive thoughts about alternatives.
Cost
It is indisputable that the cost per day of doing work in India, Thailand or China is dramatically less than the USA, UK, Europe or Australia. There are countless examples whereby it can be shown to be cheaper by a magnitude of 10. However what is more questionable is the cost per unit of work. How much functionality do you get for a day's worth of coding in Australia versus that in India?
I know that some software companies will first quote for the work using their local resources and will then apply a multiplier of 2-3 times to get the budget for doing the work in their offshore centre. So what you say! Assuming a cost of $1000 per day in USA versus $100 per day offshore, even if it does take 3 times as long, you are still dramatically better off. This is true but the gap narrows and some of the other trade offs that you have to make might erode that benefit further. For critical time to market initiatives this does start to make much more of an impact.
Ancillary costs also start to add up. For example it is generally agreed that to make this process work you need to send quality people from your local operation to the offshore location to transfer the knowledge and then manage the process. This initially sounds like a quick trip but in fact takes substantially longer than you would expect. I know of instances of people that were sent to the offshore location and are still there 4 years later. With the lucrative ex-pat packages that are used to compensate these people it is not a complete surprise. Once again adding to the costs.
Then there are the regular managerial trips across to review the operation. Given the distances involved these will normally take at least a week of a senior person's time, without counting the cost of "Delhi Belly" that will make it impossible for them to actually do any work!
These ancillary costs are easily consumed if you are moving very large numbers (hundreds or thousands) of staff offshore but in the funds management or independent software vendor world this is not so easily achieved so they do have a tendency to be noticed on the bottom line.
Quality of Service
Anyone that believes moving your operation away from your clients to a country that does not have the same first language or cultural background, does not effect the level of service you can provide, has their head buried in the sand. You need only look at the number of UK financial and utility firms that tried moving their call centres to India around 2000 only to move them back a few years later. See articles such as:
http://www.independent.co.uk/news/business/news/call-centre-switches-jobs-back-from-india-to-britain-574174.html
In another example there is a major US bank that has offshored its internal help desk. You need talk with very few of their staff to understand the very high level of frustration with using this service or the number of work arounds they have in place to try and get things done.
Remember when measuring the cost of a support service to your clients or your internal staff, the actual cost of providing the service is normally a lot less than the impact it has on the customer. For example lets assume I am a senior manager in Australia costing $200 per hour, my local support person costs $100 per hour and the offshore support person costs $10 per hour.
Scenario a) Under the local model the support person comes to my desk and takes an hour to fix the issue. This costs $100 for support.
Scenario b) With the offshore model using remote diagnostics the person takes twice as long to fix the problem. (From actual experince I think I am being very generous here!). This costs $20 for support.
It is quite clear from an IT perspective the offshore model is dramatically cheaper, but lets compare the real business cost. In scenario a) I lost an hour of my time or $200. In scenario b) I lost 2 hours or $400. It is not too hard to see which method is truly cheaper for the business.
None of this takes into account the relationship cost of exposing your customers to a degree of frustration.
All of these issues lead me to one of my strongest beliefs: NEVER push your clients (either internal or external) away from you by sending them elsewhere to get service. Know your clients well and keep them close to you and loyal!
Political Instability
There have been a number of disturbing events in both Thailand and India of late that raise the question do you want to put your business at risk or worse the lives of your staff for the sake of a few dollars.
Thailand has had 10 coups in the last 40 years and then more recently had sufficient civil unrest to close the airports for eight days in 2008.
The terrorist attacks in Mumbai, which took 2 days to suppress, have exposed some of the security risks within these countries.
Regulatory Protection
Satyam. Need I say anymore. One of the key criteria when selecting an outsourcing provider is financial stability. How can you trust the local regulatory regime when this style of fraud has been perpetrated for so many years?
If you are contemplating moving your development or research functions offshore then you should also investigate the issue of intellectual property protection. Some of these countries have a questionable background in protecting ownership rights as can be attested to by the Swiss Watchmakers and the American Film Industry both of whom are selling a tangible product. How well do you think you can protect your intangible intellectual property in that style of regime.
Staff Turnover
It is difficult to get exact numbers for staff turnover in the offshoring industry but there is a perception that it is high. This should be investigated when considering moving anything offshore.
You should also be aware that it is a very competitive environment to attract staff into. At one point I was trying to find 2 test analysts offshore. These positions took a number of months to fill. Once we had found the right candidates and they had accepted the positions the offshore manager advised us to keep interviewing. I asked why and was told they might not show up. I ignored this advice much to my detriment. Netiher candidate reported for work!
Methodology
The majority of development styles being used for offshoring are centred around traditional waterfall or plan-driven methodologies. These emphasise the up front analysis and design processes before passing the specifications offshore to be built. The opposing camp is around a new style of development generally referred to as agile. Agile methodologies emphasise face to face communication between all parties invloved. This style can be contradictory to the whole concept of having your developers 10,000 miles away.
Martin Fowler compares these two methodologies very well in his article "The New Methodology" at http://martinfowler.com/articles/newMethodology.html
Within this article a comparison is made to the construction industry that uses similar plan-driven methodologies whereby the engineers write a design which is then passed to the builders to complete. The concept is that design is difficult to predict and so requires expensive creative people whereas the build can be passed to less expensive people. This matches to many software companies' views of offshoring. We will do the design locally and ship the grunt work offshore. However there is a viewpoint suggested by Jack Reeves that the writing of source code is the true design and that the build is simply the compile. If you follow this line of thinking then with offshoring you are pushing the most intellectual part of the process away from where the action really is.
The Alternatives
I promised at the beginning that I would move towards suggesting some alternative to the current trends so hopefully I am good to my word. But first a bit of background of the funds management industry in Australia.
Going back 20 years there was a fairly even spread of organisations between Melbourne and Sydney and then a second tier within the other capital cities of Australia. Since then there has been a continuing trend of mergers, acquisitions and back office outsourcing which has moved most of the players to Sydney with a small contingent in Melbourne and an almost negligible amount in the other capital cities.
This has forced most of the workforce into Sydney which is by far the most expensive place to live in Australia and 15th most expensive in the world. In comparison Mumbai is 48th, Bangkok 105th and Bangalore 118th.
Given this it is no surprise that firms are looking to move their operations out of Sydney to a cheaper location and these days that all means Asia. But does it have to? Brisbane is cheaper than Mumbai at 57th and Adelaide also competes at 73rd.
Imagine what your staff would say when you announced that you are moving their jobs to a cheaper location and they have the option of moving to either Mumbai or the Gold Coast. I think I know which queue I would be in.
This same analogy can be used in most countries around the world. For example many UK Banks have chosen centres outside of London for their call centre operations. The US has middle America or Canada.
By choosing to move some of your operations to a cheaper location within your own country you negate many of the issues mentioned above. Some of the advantages are:
- Communication is easier since there are no language or cultural issues
- Ancillary costs are less since flying to Brisbane from Sydney is cheaper, quicker and less likely to result in sickness
- Time zones are basically the same
- You have a known political situation and an active regulatory regime
The issue of cost per day still stands though. These regions are cheaper than the major financial centres but still not as cheap as Asia. This is where I believe the government can step in to help stimulate the economy. In the current financial crisis many organsiations will be looking for ways to reduce costs and moving things offshore will be in the front line. Governments are all talking about stimulus packages to help the economy grow at this time. If they were to provide tax incentives to encourage firms to move the work to other regions within Australia, jobs would be saved, infrastructure invested in and a new competitive environment created.
I would point you to the incredible success that Dublin had with the International Financial Services Centre. This was a zone defined by the government as a low tax zone that encouraged European organisations to setup their operations in Ireland. It dramatically boosted the Irish economy and has seen unprecedented growth. For example funds under management grew by 77% in 2 years from 1998.
Conclusion
To conclude I think the trend to offshoring into the cheapest of locations in Asia will continue, particularly for large firms. However I would hope that with smaller firms, where many of the issues I have raised will show themselves, serious consideration will be given to their local options without being lured by the promises of amazing returns.
I am very interested in other views on this topic so please feel free to comment.
Subscribe to:
Posts (Atom)
