Hello 888,
I think definitely yes, software maintenance is a big consideration
for outsourcing software development.
Even trusting someone that works within the company, but not for a
long time, can be an issue -- that person might not yet know the
style, the future is unreliable, and so on. Outsourcing is just the
same, because someone will sooner or later take over the code -- this
almost always happen, and that someone might be someone from within
the company.
While one should not over-evaluate the risk, one has to be very aware.
A big consideration is the level of trust on the performance of the
developer or developers one wants to outsource the project to. I would
say readability of code, and code style, are great factors that would
benefit -- or, in reverse, potentially hinder -- future development;
that is, if the company ever decides to take over the project now.
I have several personal experiences with this situation. The crucial
point from management is to save time, or to bring in special
expertise. However, the time-saving factor, while it often (not
always) seems to work out for a temporary period, would almost always
be negatively balanced by future investments that have to be made.
Like, a simple change in the software would bring up two choices:
- Outsource the project again, with a lot of management overhead, or,
- Let the in-house programmers tackle it, with a lot of technical
overhead.
The fact is that now management decisions would partly have to
consider wether or not it's more cost-effective to outsource, even
when special skills are now in-house, because of the time-delay caused
by "getting into" someone's elses software source code.
Let me give you a practical example:
Every company has certain agreed rules on how to lay-out a project.
Even when two, three or four programmers closely work together in a
company environment as a team, this is hard enough to keep up.
Now imagine the added risk of bringing this to someone from the
outside. Of course one can write specifications, likely already has
(e.g. precisely defined syntax formatting, compiler tools, libraries,
standards & conventions), but even then the concept and design of the
other party's creation will differ.
Now, if that sounds too negatively, I would add that one just have to
be _aware_ of the risks; not ignoring the inherent danger in
outsourcing software development results in greater ability to balance
the positive and negative influences of such process.
For further reference, I would like to point you to this publication:
The risks of outsourcing IT - Sloan Management Review; Cambridge;
Spring 1996; Earl, Michael J;
http://itom.fau.edu/sgalup/outsourcing_risks.htm
Abstract:
"Although large corporations continue to outsource IT services, the
issues of whether and how to outsource generate strong emotions on the
part of managers. Many practitioners and academics now argue for
selective or smart sourcing. Analysis shows 11 risks of outsourcing
that should be considered: 1. possibility of weak management, 2.
inexperienced staff, 3. business uncertainty, 4. outdated technology
skills, 5. endemic uncertainty, 6. hidden costs, 7. lack of
organizational learning, 8. loss of innovative capacity, 9. dangers of
eternal triangle, 10. technological indivisibility, and 11. fuzzy
focus. As corporate knowledge about IT outsourcing continues to
advance, the strategy of selective or smart sourcing may become the
norm."
I hope this helps!
Search terms:
"software maintenance and outsourcing"
"software maintenance" outsourcing risks
Earl M. J., "The Risks of Outsourcing IT" |
,
0 Comments
)