Most development work will go overseas, with two or three exceptions:
1. small jobs in small organisations
2. top level BA and SA work.
The weakness of this approach is that overseas companies need good specs. Back to waterfall if we are not careful.
The alternative is 'agile development', where there has to be top to bottom integration. If this can be made efficient, then it can compete pricewise with offshore development.
To squeeze the prices right down, we need more than just agile development, but we also need 'agile analysis'. When the MD (CEO or sponsor) says they want a system to allow x to do y to z, we have us use case 'Do y' and a domain diagram containing x and z. No messing. Rapid UML from start to finish. This gives everyone a summary of what the detailed discussions are producing. It need not be detailed but it MUST be accurate.
In front of this are discussions, prototypes etc involving operators, Business managers, analysts, designers, programmers, testers, etc. all working together at short notice in what ever combination give the answer quickest. This saves detailed documentation and resolves issues only when they need to be resolved.
SO what can we save? If the work costs 100 units, we can assign
40% to onshore work,
40% to work that could go offshore,
10% to documentation and
10% to management.
--------
100%
========
Offshore can cut the offshor component by a factor of 4, but possibly adds 50% to the amount of documentation and the management:
40% to onshore work,
10% to work that could go offshore,
15% to documentation and
15% to management.
--------
80%
========
Look at the agile approach. The onshore work halves. The offshore work has to remain onshore so that operators, managers and business staff can get involved directly. However, it is more efficient because it happens when it is needed directly between the correct parties. This knock at least 25% off the development. Also the documentation is halved. Management will need to be very responsive (that will cost more, but not 50% more)
20% to onshore work,
30% to work that could go offshore,
5% to documentation and
13% to management.
--------
68%
========
These figures are crude and disputable, but the message is clear:
we can keep the work onshore
but we must go fully agile. See all agile sites, and think XA(eXtreme Analysis) as well as XP (eXtreme Programming)
Gil
1. small jobs in small organisations
2. top level BA and SA work.
The weakness of this approach is that overseas companies need good specs. Back to waterfall if we are not careful.
The alternative is 'agile development', where there has to be top to bottom integration. If this can be made efficient, then it can compete pricewise with offshore development.
To squeeze the prices right down, we need more than just agile development, but we also need 'agile analysis'. When the MD (CEO or sponsor) says they want a system to allow x to do y to z, we have us use case 'Do y' and a domain diagram containing x and z. No messing. Rapid UML from start to finish. This gives everyone a summary of what the detailed discussions are producing. It need not be detailed but it MUST be accurate.
In front of this are discussions, prototypes etc involving operators, Business managers, analysts, designers, programmers, testers, etc. all working together at short notice in what ever combination give the answer quickest. This saves detailed documentation and resolves issues only when they need to be resolved.
SO what can we save? If the work costs 100 units, we can assign
40% to onshore work,
40% to work that could go offshore,
10% to documentation and
10% to management.
--------
100%
========
Offshore can cut the offshor component by a factor of 4, but possibly adds 50% to the amount of documentation and the management:
40% to onshore work,
10% to work that could go offshore,
15% to documentation and
15% to management.
--------
80%
========
Look at the agile approach. The onshore work halves. The offshore work has to remain onshore so that operators, managers and business staff can get involved directly. However, it is more efficient because it happens when it is needed directly between the correct parties. This knock at least 25% off the development. Also the documentation is halved. Management will need to be very responsive (that will cost more, but not 50% more)
20% to onshore work,
30% to work that could go offshore,
5% to documentation and
13% to management.
--------
68%
========
These figures are crude and disputable, but the message is clear:
we can keep the work onshore
but we must go fully agile. See all agile sites, and think XA(eXtreme Analysis) as well as XP (eXtreme Programming)
Gil