How can you ensure quality in offshore software development?Hoe waarborgt u kwaliteit in offshore softwareontwikkeling? How can you ensure quality in offshore software development?Wie können Sie die Qualität in Offshore Softwareentwicklung sicherstellen?
Frequently, I hear people mention that ‘the quality’ of the software that is produced offshore is bad. Or people say ‘Indians produce bad quality’. Or they say ‘outsourcing doesn’t work, because the quality is too low’. Such conclusions sound like generalizations and it always produces one question for me: how did you organize?
In most cases, people speak about India and not about other countries. I believe the reason for this is the dominant position of India in the offshoring world. Most work is moved to India, so the chances are big that experiences are from working with Indian people. It is unfortunate that experiences are sometimes negative, but unavoidable. Offshoring is a complex form of organization, people have to manage across borders and cultures and many companies having no prior experience.
Vaak hoor ik mensen zeggen dat de ‘kwaliteit’ van software die offshore geproduceerd wordt slecht is. Of mensen zeggen dat ‘Indiërs slechte kwaliteit produceren’. Of ze zeggen dat ‘outsourcing niet werkt omdat de kwaliteit niet hoog genoeg is’. Zulke conclusies lijken te generaliseren en er komt altijd één vraag bij mij op: hoe was de organisatie?
of
Frequently, I hear people mention that ‘the quality’ of the software that is produced offshore is bad. Or people say ‘Indians produce bad quality’. Or they say ‘outsourcing doesn’t work, because the quality is too low’. Such conclusions sound like generalizations and it always produces one question for me: how did you organize?
In most cases, people speak about India and not about other countries. I believe the reason for this is the dominant position of India in the offshoring world. Most work is moved to India, so the chances are big that experiences are from working with Indian people. It is unfortunate that experiences are sometimes negative, but unavoidable. Offshoring is a complex form of organization, people have to manage across borders and cultures and many companies having no prior experience.
Oft höre ich Leute sagen, dass “die Qualität” der Software, die Offshore produziert wird, schlecht ist. Oder Leute sagen „Inder produzieren eine schlechte Qualität“. Oder sie sagen „Outsourcing funktioniert nicht, weil die Qualität zu gering ist“. Solche Schlussfolgerungen hören sich wie Verallgemeinerungen an und es stellt sich mir immer eine Frage: wie hat man organisiert?
In den meisten Fällen reden Leute über Indien und nicht über andere Länder. Ich glaube, dass der Grund dafür die dominante Position Indiens in der Welt des Offshorings ist. Die meiste Arbeit wird nach Indien ausgelagert, daher ist die Wahrscheinlichkeit groß, dass die Erfahrung auf der Arbeit mit indischen Leuten basiert. Es ist unglücklich, dass Erfahrungen manchmal schlecht, aber nicht vermeidbar sind. Offshoring ist eine komplexe Form der Organisation, Leute müssen sich über Grenzen und Kulturen hinaus managen und viele Unternehmen keinerlei vorherige Erfahrung.
Es ist die Frage„
It is within the question ‘how do you organize’ that we can find both the problem and the solution. In many cases, companies start with offshoring a project or a business process. The leading idea is to take a project that can be clearly described in a requirements document. A supplier on the other side of the world is searched and the project is subcontracted to that supplier. What happens on the supplier side is a black box. The project is sent into the black box, some idea is formed about what ideally should come out of the black box and when it should come out. And then we wait till the black box pops out the project. In many cases, the thing coming out is not what we had in mind.
Companies focused on the short term (we wanted to get this project done because we couldn’t do it ourselves or we didn’t have the people) will easily conclude ‘offshoring doesn’t work’. There was the expectation that this one project would produce positive results and there is no stamina to invest time to make offshoring work. Companies focused on the longer term (they envision a strategic advantage by engaging offshore resources to produce value on the long term) might be willing to question themselves ‘what went wrong and what can we change to make it work better the next time?’. I believe that many of the conclusions described above are caused by companies focused on the short term.
Quality (in a service context) is the result of two ingredients: people and process. The problem in the traditional form of ‘outsourcing’ is the black box: the outsourcer has no insight nor influence on which people are involved in a project and how those people work. Obviously, when you engage a quality service provider, you just want to get the result and you don’t want to mingle in the black box. The reality is that many offshore service providers cannot produce the expected quality on its own and a close interaction with the outsourcer is needed. Close cooperation, communication should lead to opening up the black box to produce the expected outcome.
The key to producing high quality is getting the two ingredients right. Firstly, you want to engage the right people in your project or business process. Instead of relying on the people hiring skills of the service provider, it is advisable to have an influence on the hiring decision. The steps taken in hiring employees in the outsourcer’s company can be applied equally to the hiring of offshore staff. Second, the major question to be asked before the actual work starts is ‘how will we work?’. The black box approach relies on the (lack of) processes of the offshore service provider. The outsourcer has its own processes, but the project goes into the black box. The problem is that the provider can never produce the results alone using only his own way of working. Close communication and agreement is required on requirements gathering, how to deal with unclarities, how to stay aligned, progress and many more factors. The processes in the black box and on the outsourcer side should be opened up. Before the real work starts, developing a common process gives both ‘sides’ insight into who does what in each stage of the cooperation.
People + Process = Quality. Get the right people in the right position, clearly document how the work is done and what is expected and the result will be the quality you expected.
About Hugo Messer
Hugo Messer is a Dutch entrepreneur, distributed agile team specialist, and author. He is the founder and owner of Bridge Global, a software services provider, and ekipa.co., an agile coaching agency. He has been building and managing teams around the world for the past several years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. Whether it’s offshoring or nearshoring, he knows what it takes to make global cooperation work.
View all posts by Hugo Messer →
you need to know the team, have some of them, at least the project leaders over with you for a few weeks. make sure they are familiar with exactly what you are doing and what you want them to do. once they are back and you start the project you need frequent meetings to make sure everyone is on the same page. you don’t want to get into the situation where they ask a question one day, you answer it the next, they ask a followup the third day, etc. have a plan for addressing things like this, early morning or late evening meetings will likely be required. if you have the tech lead on the offshore side spend a fair amount of time with you then this person can be instrumental in pushing the process along and not getting into the ‘question-a-day’ rut. you also need to make sure that you are providing detailed instructions of what you want. too many places take for granted that their environment is either very intuitive or well documented when in fact it is anything but. i’ve worked with a couple of offshore teams from India and there is nothing wrong with their ability. like any group of people anywhere the skill level will vary from person to person but overall the people i’ve worked with are quite capable and some were outstanding. the truth is that if things aren’t going as you planned its likely because you really don’t have much of a plan
“I believe the reason for this is the dominant position of India in the offshoring world”
I disagree. Its also about culture. The movie 3 Idiots illustrates that well (Bollywood).
You have a nice video.
I think the major requirement is that the outsource company have western management on premises.
I moved from Detroit USA to Philippines in 2009 and from here the perspective is very different.
It is very easy for me to control quality because I am here everyday supervising and training the western way.
The biggest mistake I made is underestimating the differences between Asia (including India) and the west. They are very different cultures, at many levels.
Hello,
Steps I would think key to start off-shoring based on what I’ve seen are:
-Identify activity/feature type which is for you already standard (meaning that all steps and the knowledge needed are clearly identified)
-Document the activity (in detail) and work through real life examples with the offshore team (for example through webex sessions or in person if possible)
-Give the offshore team time and opportunity to read the information, reformulate so they can ensure they have understood -even better if the person(s) can be come over for a few weeks (this also allows to ensure integration with local processes and organization)
-Clarify how the transfer of the activity/development (progressive or one by one) will be done between the two teams (trigger information, timelines, expected response/reporting)
-Dry run in real life conditions to align on key steps
-Regular update calls especially in the beginning of the transfer phase
Off-shoring (in particular) to Asia is a like managing a virtual team with the addition of a stronger cultural aspect to be managed and it is vital to ensure that a common understanding of an issue or activity is ensured and communication is easy for everyone.
The mistake that I’ve seen most often is failure to architect the design in a way that enables the outsource team to own their work. If the performance requirements are documented and the interfaces clearly defined, then the team can work semi-independently, or at least without daily oversight. The key is to “design for outsourcing” and hold the offshore team accountable for their results.
The fundamental problem with separating the software development from the business that it would support is the length of the feedback cycle. With Waterfall development the feedback cycle was so long anyway that moving the software development remotely made almost no difference at all to the software development process, and the quality was always poor; even if all the tests pass, the chances were that what was delivered was only remotely related to what the customer needed. So it is the remoteness that matters; it makes it very hard to get short feedback loops. Being offshore or Indian makes very little difference. As I say, with Waterfall it made little difference, but modern approaches use very short feedback loops to get rapid feedback in fitness for purpose, etc. to bring the quality up to unprecedented levels, and also to cut down on the vast weight of documentation that has built up traditionally, to manage the handover of information between phases. While offshore work *can* get some of these efficiency savings by being ‘agile’ within the team, the rapid feedback from the customer is very hard to achieve, so quality can very rarely be as high as can be achieved when working in close relationship with the customer.
I have had both good and bad outsourcing experiences. Actually, my worse experience did NOT come from India but South America. The success or failure of an outsourced project depends more on how well you prepare for the project BEFORE outsourcing. It is very difficult for the outsourced company to completely understand your business and goals as it is, so if you don’t provide excellent specs, and maintain good communication, the project will be doomed. The best outsourced projects I have seen is where you have a good architect and project manager state side, that communicates early and often with the out sourced team. An agile, iterative process is also best, where you get pieces of the project back often, so that you are able to adapt and correct problems early on, before the point of no return.
We have had good and bad experiences. I think the bad experiences where mainly bad due to our short comings.
Understanding how to manage off shoring has two major challenges. One being remote work. This in itself lends to a different management and communication agenda. The second challenge being culture.
If your approaching off shore to simply save costs, you are not only missing one of the greatest benefits of tapping into global resources, but you’re also likely to be disappointed in quality.
A few tips:
-Your prep time must be double that of which would occur if the person sat next door to you every day.
-All aspects of the work to be performed must be regurgitated back to you in their own words for clarity of understanding.
-Small milestones must be established, and reviewed timely.
There are many more best practices to be adhered to when utilizing outsourcing offshore, but if done right, you will have a great experience and the quality will be what you expect.
It’s all in the process.
What is the definition of “good quality”.
What is “good quality” for someone could probably be a total junk to another person.
If every step of the details are defined, proper milestones are proposed, and the quality assurance process is implemented then there should be no problems.
The fundamentals of project management and supplier agreement management still apply irrespective of work location.
As the customer you are accountable for providing the supplier with clear, detailed product requirements.
You are equally accountable for product quality by ensuring that requirements are testable/demonstrable and that the supplier has quality plans in place that meet your test expectations and you approve of them.
In effect you define the project success criteria.
Then put in place sufficient quality control gates that ensure deliverables pass your quality criteria and that the supplier provides evidence of testing performed and test results arising with high pass rates.
The project plan, schedule and methodolgies incorporate the above and ensure that quality is a continual project culture trait.
Finally, ensure that contractually the supplier is paid on the basis of delivering a top quality product only (your success criteria) and not on the basis of effort expended.
A poor performing supplier absorbs the schedule overrun due to poor quality and repairs arising.
It’s about getting the commitments, roles and responsibilities right.
Hope that helps?
Alan
In most respects, you do what you would do if you weren’t offshoring, except you can’t shortcut the steps the way you might if you were all co-located. For example, metrics play an extremely important role during testing phases because it’s harder to discuss progress, test results, and implications of defects. Similarly, communication is very important (as always) and must be very clear and more frequent than in the co-located case. Finally, it’s helpful to have someone from the “onshore” team located with the offshore team to facilitate communication and collaboration. That resource should be very familiar with the product/project and plays a key role in knowledge transfer and relationship management.
Speaking of which, one of the things that can be challenging about offshoring is establishing or repairing social relationships. Social interactions are key to software development, and offshoring often disrupts existing relationships (or forces new ones), and these relationships become highly centralized; i.e., dependent on interfaces between a small number of people. Effective collaboration, on the other hand, uses a more cohesive model – more peer interations and less dependency on individuals to pass on the message. Having someone offshore from the onshore team can help build relationships, even if this is initially a high centrality model. Another thing that helps is to have offshore team members spend some time onshore not only to learn the project but more importantly to build relationships with the onshore team.
I believe one of the biggest things that one must do to provide the greatest opportunity for a successful offshore project is to consider the offshore team to be en extension of your own team.
How many times have we complained when our business users throw their requirements “over the wall” and say “tell us when you are done”. You need to be sure you do not treating your offshore partners in a similar manner.
I strongly recommend that you either embed on of your team members into the offshore team or more likely, embed a member of the offshore team into your team. This strategy provides a communications conduit and provides continuity of the teams. You then have a greater ability to manage quality to a level similar to an on-shore team.
It may be slightly more expensive this way, but well worth it.
I think that before going to an outsourcing, you have to take into consideration different aspects as follows:
-Service Provider: The company that will provide the services should have experience and credentials working in this type of services. It has to show applicable methodology and it should be validated “live” having a visit to their facilities before contracting the service.
-Location: Choosing the location doesn’t mean just selecting a specific country (like India) but to understand different issues: experience, culture, language, timeshift, taxes impact, country stability, human resources availability, an so on.
-Scope: The scope of activities may vary and be associated to that the roles and responsibility of the work developed in each location. If we cut the scope throughout the SDLC then Functional Design may remain locally (where the business knowledge is) and the rest of the process off-shored/outsourced.
-Service Control: There must be a clear definition of Service Level Agreements in order to ensure that the work is correctly done. It must be associated to penalties so the outsourcer makes his best effort. There must also be a well designed governance model to define adecquate change control and escalation process.
-Transition: Before going to the outsourcing service, there must be a very good transition in terms of process definition and knowledge transfer to avoid any service level reduction or disruption risk. Forms (functional design, technical design, etc.) for each part relationship must be defined in order to avoid any misunderstunding in the SDLC process. “Inputs” and “outputs” of each phase of the SDLC process must be clearly established.
Of course there is more points and a deeper analysis in each one, but at least that’s the starting point from my perspective.
The question of how you ensure quality in offshore software development was answered – in the general sense – by the following statement: “Quality (in a service context) is the result of two ingredients: people and process.”. In other words, control quality by controlling the people you have working for you and controlling the process that guides the people.
This next statement is an excellent example of what happens if you do not have control: “The project is sent into the black box, some idea is formed about what ideally should come out of the black box and when it should come out. And then we wait till the black box pops out the project.”. If you have control over your people and your process, you should have a white box – everything is totally visible as though operating in a transparent box. If you do not have control, nothing is visible, as though it were all operating in a black box.
Obviously, due to distance and the fact that you are contracting work to an alien organization, you would seemingly have little control over the people and the process. To gain some control, do the following:
1. Contract work to an organization that can do the work. Do not contract to the lowest bidder. Take the time to select the best organization. You take the time to try to hire the best candidate when hiring to fill an open position. Do the same when hiring an outsourcing organization.
2. Insist on the “best” people the provider has to lead your project. Review their qualifications (ask for and read their resumes). Ask the provider to have the project leader(s) trained if you believe it will help.
3. Impose your process – “flow down the process” — to the outsourcing provider. Insist on regular progress and status reporting, with appropriate quality metrics. Insist on regular quality audits. Take time to visit the provider on a regular basis to talk to the project team members and conduct your own audits.
One North American organization I worked with, which had been contracted to provide safety-critical software applications to different European and Asian transit providers, did what I suggested above.
The customer selected the best provider available, based upon our ability to do the high quality work. As the Quality Assurance leader, my resume was made visible to the customer; they insisted that I receive some extra training and I did.
The customer insisted on a strict project quality and reporting strategy that included detailed monthly progress and status reports that were both written and video-conferenced. The written reports included quality metrics and the results of regular quality audits which were subsequently reviewed and discussed during the video conference.
The customer also visited on a regular basis, to discuss issues with project and senior managers, and project team members; and to conduct audits of their own. Their audit results were compared with the results of the audits my team conducted and any discrepancies carefully analysed and discussed. Our operations were not a black box to the customer and they benefited by being aware of all issues.
The problem isn’t with Offshoring, it’s with Outsourcing. Most software development organizations do not have the maturity in gathering and documenting requirements to contract development to an outside agency. If your company sends a development manager to, for instance, Belarus to hire a team of programmers to write software, that team will inherit the manager’s attitudes about requirements, change management, and quality, and will answer to this manager for their performance. If, on the other hand, you contract with another company in Belarus to develop the software for you, every single little change in any aspect of the program becomes a contract negotiation.
The problem isn’t with hiring people from “somewhere else,” it’s with hiring people from “some other company,” and the extra layers of management and overhead that adds.
In my opinion following few steps involved in ensuring quality –
1. Quality standards – Clearly identifying giving appropriate metaphors to indicate what do you mean by quality. Does your off-shore team see what you see when you say quality? It could be user interface, usability and so on. Mare statement such as ‘user friendly interface’ does not ring a bell on other side and it is too broad to agree upon. Best way is to guide the offshore team to various other products/application which become kind of bench-mark for quality. Very clear definition of quality expectation is very essential even before your off-shore team provides estimates to project. Also how frequently you want review.Customer review add to over-head to the vendor.
2. Quality Reviewer – ‘What you observe improves’. Who reviews the quality and gives final ok? Is it left the vendor team or is it part of your team? If you can afford, keep reviewer of quality from your team who knows what is required. Never leave it to the vendor team unless you have worked with them earlier and you know that they understand these things better.
3. Ensuring Quality – This is the responsibility of vendor/off-shore team. However please make sure if they have right mechanism to ensure quality. Do they have automated unit testing practice? Are they in a position to do continuous integration and provide software for review on frequent basis? What are the test management mechanisms and facilities they have (such as test planning, execution, bug-reporting etc)? Is all this transparent to you?
Ensuring quality is the responsibility of Off-shore team. If you are dealing with new vendor, it is safe to keep verification with you. And this verification must happen frequently with proper feedback and follow-up.
Contract and SLAs will never ensure quality. They only breed fear.
Amongst the significant basis in choosing an Offshore service supplier is good quality standards. That is really important in figuring out if the enterprise follows global requirements and other development process standards.
The opportunity of actions may change and be associated to that the tasks and liability of the perform designed in each place.