Outsourced IT services are on the rise. You know that because, just like me, you probably get a minimum of 10 emails a day offering developers for $399 a week. If you’re hiring, you’re getting at least the same amount of resumes daily from people who claim they’re software developers and can do anything.

In IT services, I’ve been on the both sides of the equation. Back in my day at Nokia we hired agencies to implement parts of the Ovi ecosystem: backends, web applications and Symbian apps. Later when I founded my own agency, I used the lessons learned from my interaction with agencies to deliver up to customers’ expectations.

Still it’s extremely hard to know in advance if the team is really good or it’s just their sales and marketing, and generally what the right price for software development actually is on the market where rates vary between peanuts and diamonds.

In this article I tried to come up with a list of items that need to be taken into account when considering a software development team or agency to make it easier to choose the right people for a project.

1. Is the service managed?

In the developing countries there is a perception that IT means lots of money. That’s why recently lots of random people flooded job markets in India, China, as well as in Ukraine and Romania. As an owner of an agency I’m getting dozens of applications weekly for vacancies that we don’t even post, like junior QA. Why? Because it’s IT and QA is supposed to be an easy job in public opinion here in Ukraine.

But it’s not only applicants who try to enter the IT business no matter what, despite not having even a bit of an interest for bits and bytes. It’s also business people who understood it’s “easy” to build an IT company to cater to Western markets. As a result, we have lots of companies whose business is basically giving a developer a desk, a chair, a computer and an Internet connection, saying “this guy on Skype is your boss now, do what he says”. What I usually wonder is what value they bring.

This kind of outstaffing means no responsibility for the company for planning, scopes and quality. You will need to micromanage outstaffed developers individually, explain them the requirements and also test the outcome of their work. With a vaguely defined scope the outcome is unpredictable and the code will need to be redone over and over again until it matches your expectations. You’re fine though if you possess tech team lead, quality assurance, business analysis and project management skills at once.

Managed service, on the contrary, takes lots of pain away from the customer who only needs a working product on time and at a certain level of quality. If the team is organized, responsible and doesn’t simply lease remote developers, but combines multiple roles, it’s enough for you to feed them high-level requirements on paper and they will do the rest, including discovery of the required functionality with you, putting your thoughts down in a specification, planning the work and delivering it. Even with tech savvy business people, hiring a managed team makes a lot of sense, as it frees up their time to concentrate on the business instead of software development daily operation.

2. What's their process?

From what kind of questions are asked while discussing the scope it’s relatively easy to make up an opinion of the team’s experience and focus. The structured and organized approach means you’re in good hands. Sporadic and chaotic communication, not knowing what to do next is a bad sign.

Make sure you understand what they would do next, what lifecycle of a product or a separate functionality is, how easily progress is tracked and status updates are communicated back to you. The development process cannot consist of daily phone calls only. There are tools like issue trackers and source code repositories, which are a must.

3. Can they write a spec?

When you write down a scope that seems to be clear, there is a lot in the back of your head, which may not get on paper, because it’s perceived implicit. When an underspecified spec gets directly to the developer, who is too shy or too far away (or both) to ask questions, the result can be very surprising. Leave alone programmers’ vision of user experience, “designed by professional developers” is UI you’re likely to see in hell. Hence the importance of specification, which is vetted to be clear before development start.

If you don’t have a spec, make sure you have one written. With a clear spec, you can have multiple teams bid on your project and compare their offers without the need to explain the project form 0 to each one of them (and be understood each time differently).

4. Do they have UI/UX skills?

User-oriented thinking is very important for the success of the product. Unless your target audience is bearded nerds wearing sweaters, the product needs to be user-friendly to attract more people to use it. Speaking of the bearded crowd, they still prefer Apple gadgets for exactly the same reason: user-friendliness.

A team, which over the course of the project can advise on best practices on the UI/UX and/or can create the whole UI flow before development start, comes really handy.

5. Do they have Business Analysis?

This is another non-developer role, which is yet extremely important for the success of an engagement with a software development team. Describing requirements briefly assuming everything else is obvious and implicit, customers may get really surprised about how many gaps there are to bridge. Consider an example of a requirement saying “the app must be handy” and how a developer would perceive it, compared to a detailed flow chart and layouts leaving no room for misinterpretation.

To make sure the scope is clear there are Business Analysts, who’ll make additional discovery with the customer to make sure that what gets to the developer has been scoped out properly.

6. Do they test?

As we all know, there is no software product in the world, which is 100% bug-free. Testing developers’ outcome yourself involves lots of back and forth and frustration.

It’s much faster when it’s tested and fixed where it’s developed, especially with remote engagements. Consider the time needed to come from one desk to another to clarify something versus doing a fix and then waiting for someone in another country to have a look. Working in different time zones makes it even slower.

7. Can they say No?

It’s a good reason to worry if the team always says they can deliver everything to any deadline. It’s in some cultures to never be able to say no to a superior or customer out of respect. But what’s the use for respect if your deadline isn’t met and the feature you promised to your customers is not ready? That’s why they need to be honest. If something is not realistic, you must be the first to know and options must be considered, such as altering expectations or reducing the scope if the deadline cannot be moved.

8. Can they think one step ahead?

Software development is not carving in marble. On the opposite, what’s done can and will be altered down the road. Some people though code like there is no tomorrow and everything they implement is final. This leads to patchy code, workarounds and improper structure. After some time working this way, the product becomes unmaintainable and has to be revamped entirely, which is more costly than sticking to the proper design from the beginning. That’s why it’s always important to keep in mind that everything is temporary and what kind of changes is expected in the code later.

9. Do they use freelancers?

While using external help on demand may be a good way to save a few bucks, in a time critical environment it’s just as unreliable as it’s cost-efficient. Everyone heard these typical freelancer excuses about losing an internet connection, hard disk crashes, 5 grandmothers dying in a course of a year and so on.

By hiring an agency you’re already using external help and count on their responsibility and responsiveness. One thing is hiring a company that is responsible for your product, which most likely would replace people who are, for example, sick, with other employees, and another thing is to manage a bunch of scattered freelancers.

While freelancers are great for smaller things, to do a big project you need a team preferably sitting in the same office or seeing each other regularly, testing, deploying and discussing details on spot.

10. What's their technology stack recommendation?

With a new product, beware when you hear a technology you’ve never heard of before and make an effort to google it. Some teams would intentionally offer an exotic tech stack to lock you in with them.

The less widespread the technology is the more difficult it would be for you to find another team that would have experience with it. In other words: Python, Ruby, Java, C# good, while Haskell, Lisp and Erlang are questionable.

Another tech stack issue is introducing new technologies into an existing project only because the new team has no skills in the existing stack, like adding a C# module into a Java product running on Linux. Combining the two environments will most likely complicate administration and integration.

11. How do they plan?

Just like every big meal has to be split into chewable portions, each software product has to be scoped out and then broken down into smaller development tasks in order to be successfully completed. No matter how agile you or your team wants to be, iterations can be small, but they have to be there. With development from scratch it’s milestones that need to be planned ahead to make sure everything is on track. There is nothing more frustrating than waiting for a product to be done in a year and seeing something very different from what you expected after such a long wait.

About the author

Since 2005, Konstantin has been the CEO of Redwerk, a software development agency. The 40-head strong organization offers development of software products of any complexity leveraging the best technologies available. Redwerk’s track record includes e-government projects in EU and USA, SaaS products for television, innovative mobile apps, and award-winning data mining tools. Konstantin holds MS in Applied Mathematics and is an author of numerous publications on software development and security.

Before starting Redwerk, he spent 10 years working as a software engineer and architect at several startup companies and giants like Nokia where he took part in development of the mobile navigation system and the Ovi services ecosystem.