A recurring issue for IT and business management is whether it’s best to build an in-house team or outsource the development of software applications. Some of the biggest factors when contemplating application outsourcing are cost, security and loss of control.
Business agility remains a top priority, but this puts added pressure on teams to move fast, and can sometimes lead to rushed projects and a lack of attention to detail. When in-house teams are under tight deadline restrictions, corners can get cut. In fact, most in the developer community agree that outsourcing is the best way to go for timely and on-budget development projects.
During last week’s webinar on IT Transformation featuring Marc Cecere, vice president and principal analyst for Forrester Research, many questions presented by participants went unanswered due to time constraints. Because these questions are likely being asked by many in the IT arena, we asked Marc’s webinar co-host, Pete Pizzutillo of CAST to provide answers to the three most frequently asked questions.
I was watching the gymnastics competition at the Olympics on Sunday night and on more than one occasion heard commentators applaud competitors for their agility. As I watched these gymnasts move swiftly and with exacting precision across the beam, floor, vault and bars, I could not help but marvel at their abilities and at how appropriate a descriptor “agile” was for them.
I have been an East-Coaster all my life. I’ve lived, worked and even attended college in states that all lie East of the Mississippi. However, throughout my 18 years working in the technology business, my clients have been spread out around the U.S. and abroad. I’ve found myself doing phone calls before the sun rises and well after it has set. That’s just the way it is in this business.
While it is admittedly easier to write about companies that are located in another state, I the remote worker hardly begins and ends with us writers. More often than not I’m working with companies that have developers, architects, managers, directors and even executives spread out over multiple locations. One Canadian-based division of a company I represented showed a real sense of panache and even went so far as to build a robot with an embedded web cam to allow one of its developers to move to another province while still maintaining a “physical” presence in the office.
But the truth of the matter is that communication between people not within a single office is still problematic. You just cannot possibly be as free and open via email or even over the phone when it comes to scheduling meetings and sharing ideas.
As Johanna Rothman points out in her Managing Product Development blog:
“Let’s assume you have what I see in my consulting practice: an architecture group in one location, or an architect in one location and architects around the world; developers and “their” testers in multiple time zones; product owners separated from their developers and testers. The program is called agile because the program is working in iterations. And, because it’s a program, the software pre-existed the existence of the agile transition in the organization, so you have legacy technical debt up the wazoo (the technical term). What do you do?”
It’s Personal…and It Isn’t Being the good consultant and managerial-type she is, Rothman offers a number of ways to mitigate issues between dislocated teams of developers. Her ideas are solid and very much in tune with promoting a good work environment for developers. These ideas encompass many good practices. She suggests establishing teams so that developers can’t be borrowed between offices and ensuring that each team has a specific task or feature on which they always work. She says to establish specific goals for each team and espouses the need to take extra time to map out what needs to be tested in each iteration so that teams in different time zones are not inconvenienced by conference calls outside their zone’s normal work hours.
All of these have great potential to make teams work together better…I’m not sure they solve the problem of the structural quality of the software being developed, though. The problem there is similar to something I learned in my eighth grade Chemistry class. There I learned that every vessel you use to measure something has a certain amount of inaccuracy to it. Therefore, when you use multiple vessels to measure something, you increase the level of inaccuracy for that measurement.
Similarly, when you split up a project, each team yields a certain level of control to its counterparts in other offices and geographic differences – whether teams are split between areas of the U.S. or other countries – play into what goes into the software and how code is written. Those are issues that cannot be resolved easily when you bring the various portions of a project together. However, if an organization implements an across-the-board requirement that all teams perform some form of structural analysis throughout the process, it can potential technical debt as well as provide a measure of visibility into the quality of the application software being developed.
Personally, combining Rothman’s ideas with structural analysis sounds like a good idea…technically speaking.
There’s a very old mantra around project quality that says, “If you want something done right, do it yourself.”
I disagree. We recently remodeled the bathroom in our master bedroom. Rather than taking my own sledgehammer to the walls, tub and toilet and then hanging my own sheet rock, my wife and I hired a local contractor who came in, did the demolition and reconstruction, and in the end we wound up with a room with which we’re very happy.
I can tell you without reservation that had I done it myself the project would have turned out disastrous because I confess to a certain measure of incompetence when it comes to carpentry…and plumbing…and electrical systems…and just about every other discipline that goes into rebuilding a bathroom.
I guess you could say we had “great expectations” and knew that to achieve them we needed to find someone else to do the job.
I suspect that this lack of capability in terms of doing something yourself does not always extend to companies when they choose to outsource software builds, but there is some measure of it. The decision to outsource usually comes down to one of two reasons – a company doesn’t have the time to do it or feels an outside group can do it better.
This decision to outsource is being made by an increasingly large segment of the business community. As was recently noted on The Outsourcing Blog, “the public and private sectors alike are becoming increasingly reliant on third-party suppliers to effectively operate.” What is a bit off-putting, however, is the claim made in that post that, “that some 64% of third-parties fail to meet stakeholder expectations and contractual commitments, according to recent research we have undertaken.”
The fact of the matter is, regardless of where a company chooses to outsource, there is a certain relinquishment of control. It is simply neither possible, nor desirable to hold tightly to the reins of all aspects of an outsourced project. When the outsourced project has an offshored element, the potential increase in benefits is met with an equivalent set of risks. Cultural differences and distance alone significantly contribute to increasing both the risks and management costs.
Much of this can be attributed to the fact that organizations have not previously had the means to assess application software quality in real-time when its development has been outsourced. QA plan compliance checks, while useful in some capacities, are normally performed via random manual code reviews and inspections by QA staff. For a typical one million-line-of-code J2EE distributed application, there is significant risk that key issues will go overlooked. Furthermore, standard functional and technical acceptance testing is simply insufficient at detecting severe coding defects that may have impact on the reliability and maintainability of an application. Finally, in the current geopolitical context, programming vulnerabilities, or even hazardous code in a mission-critical application, could easily produce disasters in production – data corruption or losses, system downtime at crucial moments – all of which negatively affect the business operations.
Unfortunately, most IT organizations have chosen to leave the technical compliance issues aside, due to either limited resources are scarce or a lack of the required skills. Instead, they all too frequently assume that tersely worded SLAs will be enough to protect them over time. In reality, while today’s SLAs routinely include financial penalty clauses, fines and legal battles, they are not all that effective in preventing system failures.
Get it Right
In order to be successful, companies need to acquire and deploy software solutions that help manage these global partnerships by providing greater insight into the build process through real-time access to objective data. Employing a platform of automated analysis and measurement to assess the application as it is being built, for instance, affords transparency into the outsourced work, grants discipline into how information is handled and yields metrics to evaluate results.
With that kind of real-time access and information into how a company’s software is being built or customized, it won’t matter if the outsourcer is across the hall, across the street or across the ocean. You will always know just where your software is and if the outsourcer is building it efficiently and up to your high application software quality standards. Not having that kind of insight could lead to software issues that would scare the Dickens out of you!
In 1807, French playwright Charles-Guillaume Étienne penned the famous line, “On n’est jamais si bien servi que par soi-même.”
For those who do not speak French, you may recognize this now idiomatic phrase as the oft uttered, “If you want something done right, do it yourself.”
Étienne’s words are a proclamation of self-reliance commensurate with the attitude of the French Revolutionary period during which he earned his acclaim; however, they are quite obviously not a hard and fast rule among businesses today. In today’s world, many companies that want “something done right” – including the development of software – look overseas for other companies to do it right for them.
Historically, outsourcing projects have been viewed as a difficult and even tenuous proposition. Variances in how work is conducted and language differences (like the one eluded to above) are seen as things that need to be overcome in order to make outsourcing work…and often the reason for making it work is simply that it costs less to do it overseas.
There are those who question whether it truly does cost less having it done overseas if these problems must be overcome or at least worked around. Others, however, perform their due diligence, not only before deciding to outsource, but also during and after the project has been done.
Ask the Questions
The decision of whether or not to outsource comes down to one question, “Can another company do it more efficiently than your own?” Curt Finch, CEO of payroll automation company Journyx, offers some advice on the Executive Street blog about how to make the decision of whether or not to outsource software development. He makes it sound very simple:
Answer four questions:
1. How much?
2. How long?
3. How risky?
4. How strategic?
The questions of “how much” and “how long” are rather straight-forward and objective – either the potential outsourcer can do it cheaper and quicker or they can’t. Even “how risky” under Finch’s definition – that being how solid the company is and how it is viewed by previous customers – comes down to figures (Finch points to stock price) and real, albeit anecdotal data.
Unlike the first three questions, however, “How strategic?” is a far more subjective question to answer. By Finch’s admission, this question raises more questions:
“What will your IT shop learn from building this application in-house? Is this knowledge coherent with your company’s core business strategy? Will the education your team gains from this exercise lead to improved capability for your company’s business, or is it detracting from more appropriate knowledge?”
He admits these are hard questions to answer…or are they?
Get the Answers
Most people believe that outsourcing is akin to off-loading and if that is the plan of the company shopping the project for outsourcing then the chances are pretty good the project will turn out pretty bad. Taking a hands-off approach to managing an offshore outsourcing project – by relying on SLAs, for example – and expecting a high-quality output is not only unrealistic, it’s also unfair. Rather, close management — or, even better, increased visibility into the project using application software structural analysis — is critical to achieve the desired result. To achieve the necessary visibility into the project and in so doing also achieve the strategic value sought in outsourcing the project, a company should consider implementing a platform of automated analysis and measurement to perform strategic structural analysis at each stage of the build.
The next-best thing to hands-on management, structural analysis provides the visibility critical to catching code imperfections in preproduction phase, before the application is deployed and causes costly and inconvenient outages or compromises security. With this hands-on approach to outsourcing, companies can realistically expect performance equal to what they can produce in-house.
That kind of visibility makes the most difficult of the outsourcing questions much easier to answer because the development of software is neither out of sight, nor out of mind, but rather it is simply software done right!
This blog has long professed the need for businesses to analyze, measure and assess their IT application portfolios to identify those issues with application software that cause a whole spate of headaches, from application failure, to business risk to increased technical debt.
To this end, Large enterprises have been able to apply an automated solution to perform this assessment has meant installing a comprehensive platform that analyzes and measures existing applications and can also scrutinize application software during the build or customization processes to catch issues as they happen. However, smaller businesses and individual developers generally do not have access to these large platforms and even some larger enterprises have not yet availed themselves of the technology available to them. As a result, those who have yet to adopt automated analysis and measurement platforms find themselves having to do the best they can with manual assessment of their application software, which is grossly inefficient.
Today, however, CAST released a solution for those who do not have access to comprehensive application analysis platforms with the launch of Rapid Portfolio Analysis (RPA).
RPA is a cloud-based SaaS offering that proactively identifies poorly performing applications. It provides an affordable, on-demand alternative to expensive enterprise application portfolio management or project portfolio management solutions, while automatically providing feedback on software health. The information provided by RPA arms executives with the information to determine which applications need further investigation or closer ongoing monitoring for structural issues. With companies spending as much as 70% of their IT budgets on maintenance and support costs, RPA can provide a quick overview of the things that could be ailing a company’s IT portfolio. By identifying those problem areas and then fixing them, CIOs could save their companies significantly by reducing or even eliminating business risk (i.e., security breaches or outages and downtime due to application failure) and excess technical debt, which the CAST Report on Application Software Health (CRASH) identified back in December as reaching an average of over $3.6 million.
At a time where world economics dictate that companies do all they can on trimmed budgets, being able to identify problem areas quickly and relatively inexpensively would certainly allow CIOs to focus more of their budgets on innovation rather than remediation.
So when it comes to identifying problems in IT applications, it seems like “clouding” the issue might actually clear it up.