st 
[vc_row][vc_column][vc_column_text]By Wojciech Ciesielski, Software Development Manager/ Software Mind – Outsourcing software development services is an ongoing trend for years now and although it is still a popular approach in many industries it is far from having perfect track record of meeting executives’ expectations. What seemed like a easy win when comparing operational costs on paper proved to be far more complicated when attempted in real life. For example General Motors dissatisfaction with outsourcing its IT caused the company to reverse the process. In 2012 GM has announced plans to move 3,000 of IT jobs previously outsourced to Hewlett-Packard back in-house. By the mid-2015 automaker’s plans included having 12,000 strong IT staff by 2017, almost ten-fold increase compared to 1,400 IT workers in 2012.
This article attempts to describe often overlooked aspects of outsourcing software development that greatly influence the overall effect such initiatives have on business outcomes.
Software Outsourcing Often Fails To Meet Expectations
Qualified software developers are an expensive workforce. Comparing IT wages in countries like Germany, UK or USA to going rates provided by near- or offshore vendors it seems as the only rational choice is to switch over to their services. On paper this decision gives immediate 20-70% cost savings. But does it really?
For some reasons a lot of outsourcing arrangements deeply disappoint failing to meet business expectations. Pace at which new software is delivered is lower than expected. Support and maintenance costs skyrocket. Introducing even fairly simple changes takes weeks or even months. Reliability of IT solutions is far from satisfactory causing an onslaught of outages hurting the bottom line and/or reputation among external partners and clients.
A lot of those failures starts with an overly simplistic approach to ROI calculations, reducing the cost of software to almost exclusively cost of labor. Differences in quality of skills might affect the bottom line to a far greater extent than differences in hourly rates.
Savings on Skills Generates Significant Hidden Costs
If outsourcing initiative planned ROI is calculated focusing mainly on comparing hourly rates of contracted staff against in-house personnel or those offered by other vendors then very significant hidden costs are not accounted for. In this article we will focus on two often overlooked factors greatly influencing the bottom line of any software development initiative: efficiency of software delivery process and financial impact on lacking quality caused by underqualified development teams.
Software delivery process efficiency
One of the critically important aspects that define organization’s ability to generate high ROI on investment in software development is efficiency of the development process itself.
There is a clear global trend in the industry to move away from a traditional waterfall development processes to leaner approaches. Agile, adaptive and empirical methodologies like SCRUM are now a go-to solution in all companies aspiring to industry leadership.
Doing it right gives organizations significant advantages:
- Short time-to-market for delivering business value to end users
- Better ability to adapt to changing business conditions
- Significantly better control over project cost and scope
Short time-to-market for delivering business value to end users, whenever internal or external (customers, partners).
Projects done in traditional waterfall process tend to last months, sometimes even years. Any investment in the development efforts is locked and frozen until the software reaches its users. Main principle of the agile methodologies is to deliver workable software releases incrementally adding business value with each release. That means that after each release (usually at least once a month or two, with the best teams shortening it down to two weeks or more) benefits provided by the software start to pay back costs of creating it.
Better ability to adapt to changing business conditions.
If a project is done in a traditional model then the process of introducing a change is a complicated and cumbersome one. It requires altering design documents, project schedules, negotiated scope and project timeline. Which is made way more complicated as the requirement specifications, design documents and project schedules created in the project’s inception phase are covering the entire project.
In a lean process specification/design/plan phases are done in shorter cycles focusing on features ordered by their ability to generate business value. This naturally reduces the scope of any changes that might be requested by the business stakeholders. It means much lower procedural barrier to introducing changes which otherwise is penalized by the change management costs.
Significantly better control over project costs and scope.
One of costly misconceptions common among non-technical managers is that a waterfall project gives better control over project delivery timeline, budget and general ROI. This stems from the faulty assumption that it is possible to accurately specify, design and schedule a complex, multidisciplinary, multi-actor, communication-heavy process of delivering complicated software. Vast plethora of failed waterfall projects that were either cancelled or vastly exceeded planned budgets proves how both dangerous and widespread this assumption is.
Discussion on how lean and agile processes can give product sponsors far greater control over their IT spending is definitely out of the scope of this article. One of the best introductions to this topic is a highly recommendable book “Software in 30 Days”, by SCRUM creators Ken Schwaber and Jeff Sutherland. This great management-centric introduction to SCRUM describes its principles, benefits and approaches to introduce it into an organization. Chapter on how lean empirical process increases planning precision has been an eye opener for many used to traditional thinking about IT project planning and budgeting.
Capitalising on Agile Development Process in Outsourcing Context
Let’s put the above in the context of an IT outsourcing relationship between the organization ordering software (outsourcer) and an outsourcing vendor providing the development team (outsourcee). In order to reap the rewards of an agile process there are certain factors that are crucial to success. Let’s discuss main of those – communication and quality.
Avoid communication barriers
One of the key aspects of agile project delivery is effective communication. For this process to be efficient it needs to be very communication-heavy. Key to success is regular, frequent and tight cooperation between business stakeholders or their representatives (the role usually referred to as a Product Owner in SCRUM terminology) and the development team.
Working remotely by itself inherently makes communication less efficient, regardless of tools employed to limit the impact of geographical distance. This is why when choosing an outsourcing vendor it is crucial to require and verify strong language skills, at least among outsourcee’s top staff.
Another often overlooked critical factor that might doom the project from the start is ignoring the impact of the time difference between outsourcers business personnel and the development team. It is virtually impossible to successfully implement agile process if there is no significant overlap between office hours those two groups are comfortable to work in.
The team needs to be able to agree on a schedule providing at least 2 to 3 hours of daily overlap without pushing neither side to very inconvenient hours. If the outsourcer puts their business users in a position requiring regular meetings at 5am or 10pm there will be a understandable pushback against this arrangement, tainting the process with resentment from the start. If the same is forced on the development team then for the same reasons vendor will have problems retaining its top talent. And in the long run it will affect the customer.
Assure the development team has highly capable and empowered technical leadership
Success of the agile process depends on a collection of engineering practices that make swift development possible. Quality control needs to be highly automated so the cost of regression tests of each deliverable do not accrue with each release. Development, testing and deploying an application needs to be fully automated and repeatable (practices known as continuous integration and delivery).
Your technical team must have necessary knowledge of those processes and tools supporting them in order to implement those elements of the delivery pipeline.
The way cooperation between outsourcer and the development team is organized must empower the technical team to get what they need in terms of the process and infrastructure. This is especially important if the company ordering the project does not have strong IT shop with those practices already embedded in their work culture and environment.
Code Quality and Why Big Balls of Mud Cost Millions
“Big ball of mud” is an excellent term coined by Brian Foote and Joseph Yoder to describe what software systems inevitably turn into when not enough attention is paid to the quality – both on the code and overall architecture level:
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.
The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP ‘97/EuroPLoP ‘97) Monticello, Illinois, September 1997
Engineering quality of a software system is an elusive factor to quantitatively measure but it plays tremendous role in shaping overall TCO of systems that support core business processes. Constant conflict between quality and critical resources (effort/time/money needed to deliver business value) always exist in software development and needs to be dealt with.
There are situations in which an immature architecture of a software can actually be an advantage.
This often is the case when the system operates in a domain that is not yet fully understood or when radical changes in the direction of project growth are expected. When this is the case strong premature emphasis on architecture can actually be more dangerous than none at all. It might turn design decisions and architectural constraints into a force hampering evolution and experimentation.
This phenomena is related to the topic of the previous section on agile delivery process as one of main contributing factors to such prevalence of dramatic failures of software projects developed in the traditional waterfall model comes from the expectation to design majority of the architecture in the very early phase of the project life.
Good and robust software architecture is an expensive goal to achieve, especially when the business domain being explored is new or requirements are quickly changing.
Overinvesting in the design/architecture might delay product’s market entry to the point when the whole business case for the system’s existence stops being relevant, competition gets ahead. Opportunities are lost or even entire organization gets out of business.
On the other hand if you think good architecture is expensive, try bad one.
When quality is permanently written off the list of team’s priorities big ball of mud starts to come into being. As requirements are added or changed the system gradually erodes. Complexity is not being hidden behind smart abstractions. Components become interconnected in places that should be separated by clean boundaries and interfaces but are not. Code that was written at some point in time as a throw-away prototype gets fossilized deeply within the system and more code grows around it, making it difficult to replace.
Imagine a spacious apartment, carefully designed to be at the same time aesthetically pleasing and functional. Then requirements change as the owner wants to use part of the main living room to create guest bathroom. Doing this job well require redoing piping, opening walls and floors to provide water to the new bathroom in a way that is safe and does not compromise functionality of the rest of the apartment.
Getting it right is more expensive than just putting a water pipes through the middle of the living room and sewage pipe out through the nearest window. But for pretty obvious reasons the latter it is not the course of action usually chosen.
The same happens when changes are introduced to the software without paying attention to maintaining quality (engineering quality not being synonymous to bug-free fulfillment of specified business requirements).
The difference is that contrary to construction industry effects of this process are not directly visible to end users hence its scope and gravity is often not appreciated. This decay of the software is virtually impossible to be directly measured with any quantitative metrics, even less with non-technical ones. Technical debt, software equivalent to duct tape, bailing wire and pipes running through the middle of a living room build up in the system. It makes introducing each next change gradually more difficult and risky as it becomes difficult to change anything without breaking a dozen of features duct-taped to whatever developer is trying to change.
For any non-trivial critical system that is likely to be often changed and adapted throughout couple years the cost of this erosion may by far exceed the cost of initial development.
It will cause the release cycle to grow exponentially with time as making changes takes longer, causes more regression bugs, requiring longer test cycles and more changes to the code. System’s performance will start to suffer despite throwing at it more powerful (and expensive) hardware. In extreme (but unfortunately not that rare) cases development is grinding to a halt as the cost of introducing even simple changes become prohibitive enough to render any change economically inviable. Any software engineer worth their salt will run screaming when presented with such spaghetti code jungle which incurs penalties related to high turnover rates.
Rewrite of majority or even the whole system might become the only option to move forward. The cost of such scenario for a moderately complex system may easily reach millions of Euro when accounting for cost of creating the original system and the cost of the rewrite itself. For a large system this number easily skyrockets up to tens and sometimes even hundreds of millions.
The only way to avoid it is to have a technical team capable of walking the line between avoiding preemptive over-engineering and managing the level of chaos in the code they are crafting.
Two main skills critical to doing it successfully are technical prowess in software engineering coupled with an ability to understand business priorities.
This is found in top software engineers who naturally strive to have their systems perfect as a bonsai garden, have the skill necessary to build such well constructed software and at the same time are capable of keeping their perfectionism in check by understanding when good-enough is enough in a given business context.
Constantly working on non-visible aspects of the system – architecture, design, automated test tools, performance testing, monitoring and optimizations – wisely focusing on the most critical or outdated parts. And being vocal to their business partners when they notice that the quality is falling behind too far due to business pressures, allowing the business to make educated decisions how to navigate around risk inherent to making those compromises.
Summary
If the software being built is non-trivial and likely to live as a crucial element to the business then the hourly rate paid for development work becomes far less relevant in shaping total cost of ownership than it is often perceived by decision makers.
If contracted skills are below certain technical level then the long-term impact of resulting decreased quality and accumulating technical debt is often by far exceeding the total cost of building the system. This cost multiplier by itself sometimes reaches an order of magnitude or even more in worst cases. When it adds up to the cost of business opportunities lost due to inefficient development processes then the total penalty for choosing not sufficiently qualified provider greatly outweigh 50% or even 70% savings on a per-hour rate paid for contracted developers.
And we have not accounted yet for losing business edge that may be possible only if outsourcing teams is able to offer truly innovative technology solutions. This by itself can make or break the business, making it even more critical to target top talent when the technology is core to the competitive advantage.
There is a consensus within the IT industry that the core productivity of best programmers is an order of magnitude higher than that of mediocre ones . Coupled with factors described in this article top talent can generate value that never commensurates with the cost difference between the top and mediocre providers.
This is especially true when a company ordering software does not have top-of-the-line in-house technical organization. When building advanced technology solutions critical to the business’ competitive edge, choosing vendors capable of providing the cutting edge staff often is one of the best bargains that can be made.[/vc_column_text][vc_row_inner][vc_column_inner width=”1/3″][vc_single_image image=”3356″ img_size=”full” add_caption=”yes”][/vc_column_inner][vc_column_inner width=”2/3″][vc_column_text]The author: Wojciech Ciesielski – Software Architect and Development Manager at Software Mind SA with more than a decade spent creating software for start-ups, telecomms and financial clients across the World. Technology enthusiast and evangelist currently providing architectural oversight to several projects Software Mind is realizing for a NYSE listed company in USA. His focused on helping clients strategize, design and implement IT systems and entire architectures critical to business operations. Contact: > LinkedIn[/vc_column_text][/vc_column_inner][/vc_row_inner][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]This article was published in the Outsourcing Journal Special Editions “The ITO Edition” (Q2/2016), which is available for free download via the Outsourcing Verband Website: https://www.outsourcing-verband.org/outsourcing-journal-special-editions/
[/vc_column_text][vc_empty_space][/vc_column][/vc_row]