We’ve seen a lot of different approaches to finding an outsourced dev team over the last fifteen years of that we’ve been in the business. There are the corporate types that send out 99 questions RFIs to a list of “qualified vendors” and then pick a short list for a round of more intensive questioning. There are casual businessmen who pick up their phone and call some people they know for recommendations and then call the recommendations out of the blue for a “chat.” There are the dyed-in-the-wool, “we’ll outsource our lunches to Asia if we can save a dime” types that send out a 40-page RFP, full of restrictive requirements, and instruct you to compete on this opportunity and win the multiyear contract, you must bid the best solution, with the best schedule and resources, at the lowest fixed price.
Where do I start to find an Outsourced Dev Team?
There are literally thousands of books on the subject from both sides of the table and a theoretical (really?) point of view. If you like to read, there are many, many opinions you can consume – but I can’t say honestly they will do more than give you more thoughts to ponder. As we say in marketing, “more choices can just lead to more confusion” and no choice. The same is true of too much information. Unless you have some point of reference that tells you who is writing the article, book, blog article, etc. – you are really just piling up opinions, not a path to a sound choice.
So, before we start on these points, let’s be clear. We’re a vendor of outsourced software development projects for both project-based (limited term) and dedicated team-based (indefinite term, specific team member) opportunities. We’ve been doing this work for over 12 years now from our offices in Mexico and the US for our primary market – North American businesses in the US, Mexico, and Canada. We’ve got a vested interest, but the points come from 3rd-party interviews of our past and current customers. These are the points that drove them to pick an outsourcing partner for their projects, large and small. So, take it as you will, these are the points that made their outsourcing relationship successful from their point of view.
What should you look for when selecting a partner for outsourcing your software development project? The first five points:
1. Knowledge of Necessary Technology
Notice the emphasis on necessary. Being able to pick the right technology for a project and having enough knowledge of a selected technology to take advantage of what it offers successfully, are two different issues, but both are important. If you have an existing investment in a technology, you need a vendor that respects that investment, and understands when, where and how to apply it properly. If you are approaching a completely new project that might require some thinking and experience you don’t have internally, you need a partner who understands the technical options available and can help you pick the best approach based on their knowledge and experience.
In software development, you don’t want a partner that will pick the “shiny new object” because it is hot, new and fun to play with or tout what they know – simply because they are hip-deep in spare developers who are adept at that particular approach. It isn’t necessarily bad to go with what you know or risky to use new approaches that offer strong advantages if your partner can take a balanced view and share the options with you.
The important issue here and throughout all these ten points is trust. You, as a buyer of service, need to be able to trust the choices your partner and development team will need to make in the process of developing your software. If you have to micro-manage every decision and second-guess at every fork in the road, you might as well find your own direct hires and manage the team yourself. The outcome might not be any more successful, but at least you will have the peace of mind of knowing you made the choices, right or wrong. If I sound like I’m advocating for not outsourcing your project, I have to answer that it might be the best answer if you don’t come into the idea of outsourcing with a strong need and desire to share the responsibility for success with a partner you trust. But along the same line, your partner just shouldn’t assume you can go along with every choice, just because they think it is best. They should know when to come to you, give you the information they have and walk you through the choices they are considering. Successful partnerships require shared responsibility and knowledge.
2. Relevant Experience
Knowledge and experience sound like they should go hand-in-hand and in truth they should, but all too often, they don’t. But, since we’ve established that knowledge of necessary technologies is critical, let’s be clear that relevant experience is an important distinction. Having deep experience with SQL databases may not prepare your team to find a solution to the challenges of dealing with a large inventory of specialized parts with variable pricing in an international market (as an example). The inventory problem is going to require the team to apply database technology and experience, but the business problem of properly controlling and managing the parts and their prices requires another level of experience and insight. The experience the team brings to the table can greatly speed the process of developing a solution, but it needs to be relevant to the situation and not take you down a rabbit hole.
But, you also have to be careful of what you ask for. Because of the specialization required to be successful in today’s global marketplace, it is unlikely you will find a services vendor (or several to select from) whose background is an exact match for every situation. However, you should be able to find a range of vendors who can bring to the table enough relevant experience along with a consultative approach to problems that will blend your expertise into a combined, collaborative team. Broad industry experience may actually be better than years of experience in developing the same solutions for the same vertical if it helps the team look at alternatives and think of better ways to approach a problem.
But in the end, it is again a process of trust. If the team says they have deep experience in X, Y, and Z and it turns out they really only know Y, that may be good enough for the purpose, but not if you don’t find out until the work is done that they don’t have good coverage for X and Z. Your team needs to be able to be open and honest, questioning what you need and how functionality should work in your context, rather than assuming it works like every other instance in the industry, without investigating. Relevant experience should tell them that this is the way it often works, but your mileage may be different.
3. Development Methodology to Match Your Culture
In today’s software development industry, it is popular to say “we’re agile” or “we are fully committed to DevOps” without really understanding what that should mean in the context of product development or organizational culture. If your organizational structure is largely a top-down, strong leader hierarchy, a fully-agile development methodology may sound good but just end up being oil in troubled waters. And since organizational culture takes considerable time and effort to change, simply bolting on an “agile” outsourced dev team isn’t likely to turn an ocean liner into a high speed, catamaran-style yacht.
If you are seeking an outsourcing vendor for a software development effort, it is important to first look at your team and understand how they really work currently (rather than how they might wish to work), before seeking a team that sounds like it hits all the current catch phrases common in the industry. Every vendor will tell you they can be fully compliant with every current methodology out there. But, the truth is every agile implementation is its own animal, just as every team that uses a deeply-structured, waterfall methodology has a different appetite for risk and ways to deal with it.
What you need in a vendor is someone who is willing to look at your culture and adapt their approach to fit appropriately, rather than enforce a new and different approach because “it is better and it is what we do.” Methodology zealots who promise to “train and transform” your team while they develop your software are probably well-meaning, but attempting too much to be successful at two different outcomes. And don’t allow yourself to be deceived, change isn’t easy on any side. If your vendor isn’t fully committed to understanding and adapting to your needs, there will come a time in the project when the teams will have to rationalize their methodology. It is better this is done upfront and face-to-face, during the initial phase of the project, rather than while the project is on the road to completion. Again, the implementation of your methodology is likely to be different than your vendor is used to and the longer you have been using it the more disruptive attempting to change will be. An experienced vendor will have been through many different situations and be more adaptable than your team. You should be able to tap into that experience and work with your partner to blend teams into a cohesive unit.
4. Project Management Excellence
Since the widespread adoption of agile methodology for software development, project management has been a somewhat challenged term in the software development industry. Unless it is a large project, most teams don’t automatically come with a traditional project manager and if they do, they are likely to be more of a client “interface” and less of a “manager” than you might expect. This is because in agile methodology, the team is expected to take responsibility for managing development tasks and their accomplishment in the timeline of the project. But, that should NOT mean there is no project management or person to take the lead position when necessary. It simply means that members of the team have a more important role in understanding the whole project, where the tasks they accept fit, and where other members of the team are at the moment. They can and should stand up and ask questions directly, take responsibility for their work and have a sense of ownership in the application and the outcomes of the project.
But, in line with matching the project methodology to your culture, this may be the “norm” today, but it shouldn’t stop a team from adapting to an approach that will fit your culture more closely. I would never discourage a team from being fully involved and collaborative, but there are times when a lead developer or technical architect is a better option to work through options in meetings with your IT group or subject matter experts (SMEs) on your product team. Excellent project management means understanding where things are, being ahead of problems with solutions, and being flexible enough to meet client needs within the project framework. Those are issues that teams can handle if they are trained and experienced in agile, just as well, or better, than a project manager role. They are on the ground, in the thick of development. If they can’t and don’t take control, communicate issues and progress toward goals, they are not truly agile or a committed member of the team.
In today’s environment, the key issue to watch out for is vendors who attempt to hide direct access to the development team behind layers of intermediaries who want to translate and manage expectations. This leads to a loss of fidelity and real, honest communication – the lifeblood of a project. This is a road to false expectations and sudden surprises – not something anyone wants. I can’t think of a project that hasn’t had challenges to the original expectations in one way or another. The key is to be proactive and avoid breakdowns that sap productivity and kill success. An outsourcing vendor that operates as a partner to their clients understands this dynamic and is able to be up front when problems surface.
5. Easy to Work With
It may sound like a modern outsourcing vendor would come in with a lot of ideas you’re not familiar with or expectations you’re not ready for. That should certainly not be the case. A good outsourced dev team is a product of a service-based culture that is by nature willing to do what is necessary to get the job done with a positive, forward-looking attitude. They should want your team involved as much as they can be and take the time to share who they are and know your team well. They should be willing and able to take some time to have the two teams meet and work directly together, in the same place – whether it is in their data center or on your premises. If you don’t find this kind of positive, let’s work together as one team attitude in a prospective vendor you’re probably headed in the wrong direction.
But that does mean – they will need to ask questions and take the time to understand your team members individually. And your team is expected to do the same in return. So, if a team member wants to discuss the last UI mockup for a function, they know who to talk to and they don’t feel they have to run through a bunch of hoops to get down to a discussion of what is possible and realistic. In modern projects, teams don’t specify every detail up front. They know too much is likely to change through discovery in the course of a project. They discuss what needs to be decided and done when it is logical to do it. If the relations between the client and development team are strained, these important conversations can be delayed or “kicked upstairs” where they languish, putting development progress at risk.
A positive, optimistic viewpoint can’t be maintained through every obstacle in a project, but if it is the culture of the team, rather than the exception, attitudes will tend to return to positive ground more quickly. A vendor and team that is a pleasure to work will overcome problems as quickly as possible and be honest about where they stand and the issues they face. It is a value that is hard to replace, once you find it.
We’ve got five more points to go through, but we’re going to hit those next week. We hope you are finding this take on what an outsourcing relationship should be helpful. It has been helpful to us to have the results of the interviews in front of us as we look at what we can do to continue improving the experiences of our customers as they work with us.
The second part of this article is waiting for you here.
Scio provides outsourced software development services for our nearshore clients in North America. We have partnered with client organizations large and small for mission-critical projects and IT services. If you would like to discuss how we could work with you on your next project, contact us. We would be happy to hear from you.