The occasional work overloads are not uncommon, especially not to software development teams. If you’ve ever found your team stuck in such piles of work, subcontracting can be a good solution. Businesses have forever used subcontracting to take care of parts (often important) of their larger projects.
While the benefits of subcontracting are undeniable, the process of choosing the right subcontractors is not so straightforward. In this guide, I’ll walk you through a process that guarantees great hires and helps maximize your productivity.
It’s very risky to have only one subcontractor because it means that you’re totally dependent on them. If you have just a single subcontractor on your team, you could run into several problems:
While it’s difficult to foresee such situations, the risks are real. If you don't prepare for it, your projects could suffer in case these risks will materialize. But this problem has a solution: and it’s to keep a backup, i.e., to work with multiple subcontractors. Having several subcontractors onboard minimizes the impact of such situations.
Now that the risks and a potential solution are clear, let's look at a way to choose a new subcontractor as risk-free as possible. With so many incompetent software development companies out there, you have to take hiring seriously.
Remember: a bad hire could sabotage your project.
The answer to making the right hiring decisions lies in developing a balanced evaluation system.
I strongly believe that decisions must be based on facts, though I have found that making factual decisions is surprisingly hard. This natural inclination to base decisions upon how we feel about certain things makes it even more necessary that we develop a system that helps reduce the effect that human factors have on our hiring decisions.
Another important concern that an objective evaluation system handles is: it takes less time for our employees to evaluate subcontractors as most questions can be answered in a yes or a no. This avoids the need of pointless meetings where people argue about evaluation criteria that aren't measurable or are too subjective.
It’s crucial that our employees participate in the evaluation process, but with an objective evaluation system, it’s easier to involve them without disturbing the balance of their existing projects.
Here's a breakdown of the basic steps that you should take to hire the right subcontractor for your job. Now this process applies to businesses across all domains, but depending upon your specific industry, you could fine tune it to get even better results for you.
While evaluating a new subcontractor, it’s best to either use a small project or a noncritical part of a big project.
The project should be small in terms of the work volume, but should not be too small. The idea is that it should be just enough to enable you to evaluate the quality of the new subcontractor.
Your aim is to perform an objective evaluation. The best way to do this is to decide the evaluation criteria before a project starts. When you set your expectations at the very onset of a project, you are free of any bias. You’re only deciding what you want out of the project, and you’re not looking at the capabilities of the subcontractor or his / her team.
Good evaluation criteria are measurable: so pick criteria that will result in objective answers. Ideally, at the end of the project the subcontractor should either pass or fail. This way, you won't end up settling for a service provider who doesn't meet your expectations.
To give you a head start, here are some examples of a few good evaluation criteria:
Some examples of bad evaluation criteria are:
If you look at the second set of examples, you’ll see that they are all based upon personal standards. They are not quantifiable and won't result in objective answers – that’s why they need to be avoided.
After specifying the evaluation criteria, the next step is to prioritize them. The idea here is to divide the evaluation criteria into two groups:
One more thing: It’s not a good idea to share the evaluation criteria with the evaluated subcontractors. Think of the evaluation system as a strategy that you’d like to keep to yourself.
Not all projects are created equal. Some projects will be only relevant for a short period of time, some are not important at the moment, but might be important later on, and some are crucial to your company’s success.
Each project dictates a different approach based on its goals. It might be a perfectly good approach to write the code as fast as possible if the lifespan of the delivered software component is very short. On the other hand, if we have long term plans for the project, a subcontractor must take a totally different approach.
Because we want to see if the subcontractor under consideration will select the right approach for a project, we must communicate the project's goals very clearly. Otherwise, we won’t be able to evaluate if the subcontractor is capable of choosing the right tradeoffs.
When the project is over, it’s time to compare the subcontractor’s performance against the pre-defined evaluation criteria. Hopefully, if the evaluation criteria were defined correctly, you’ll be sure of making the right decision in the end.
You should communicate their 'score’ to your subcontractors, and whether or not they made the final cut. If you will continue to work with them, they should know where they fall short. If they failed, it’s still your responsibility to communicate your decision and its reasoning and explain how you believe they could improve their processes and quality of work.
My personal experience is that helping others (even if it's just by sharing honest feedback) earns friends and relationships while building goodwill. With this approach, you can make the rejections still seem like a win to the subcontractors — a win that allows them the chance to plug some shortcomings in their services.
I doubt it.
I think that it’s impossible to totally eliminate the human factor from the equation, but if we try to base our decisions on facts instead of fluffy feelings, we will be less likely to take the wrong call because facts don’t lie. And when the stakes are high, avoiding the wrong decision is very very important.
About the author: Petri Kainulainen is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book. He also shares is thoughts regularly on his blog.