Companies don't do projects - people do projects. It is essential to keep this in mind when selecting a supplier. Even though a particular company has done exceptional projects in the past, the future success has ultimately to do with the competence of individuals taking part in the project. Companies can create the culture, process and also have the support in place for greatly enhancing the possibility to do successful projects but still the actual results depend on the individuals actually involved.

I have experience in both being a customer and service provider for software services from over 15 years. In this post I will do my best to summarize some of the things I've learned about how to choose a service provider. I'm however not trying to write a comprehensive guide on choosing a software service provider in general but one that applies especially to Drupal services. Some parts of the post are generic but most of it are very much related to Drupal and the current Drupal market.

Specialities of Open Source

Open source has made it easier to evaluate providers and developers. Previously the providers could have said they have done projects X, Y and Z and at the same time inform that the characteristics and details of the projects are classified. Within the open source community, participation with the product itself is public. This is especially true with projects like Drupal where everything rotates around the central Drupal.org site. It is easy to go and see what a developer has been working on, evaluate the code and see how long history a developer has.

Some companies will still claim that their developers are really experienced even when Drupal.org profiles of their developers are almost empty. Customer projects are after all often under non-disclosure agreement and details on what individual developers have done in them are not public. If a developer has not participated in the open source community or has not produced anything visible within it, it is completely reasonable to question their competence. In order to know an open source product you must take part in the community. There is no other way to influence or even know where a product is going, get support and get issues fixed. There are also a number of business benefits for a customer if their development team contributes back to the community. It takes a while to explain why contributing back to the community is a great idea for a customer and it will be a topic of another blog post.

When evaluating the competence of a particular team member, more traditional ways like evaluating developer CVs and client references should always be accompanied with having a look at their Drupal.org profiles. These profiles show immediately the amount of participation a particular developer has had in the community, the duration of their involvement and the depth of their knowledge.

Business competence

In addition to evaluating technical and Drupal competence, it is essential to evaluate the competence of the team in regards to the business vertical of the project. Previous experience in projects within the similar business vertical is important, as this helps the team to understand customer requirements and build new ideas on top of them. Not everybody on the project team has to be expert and teams with mixed experience may often even produce better results than teams that have plenty of experience in a single business vertical.

Cultural fit and communication competence

Another important aspect is cultural compatibility of developers. A good developer should be able to relate to users of a site. For example if you are building an e-commerce site you should be able to relate to how customers will use the site. Thinking like this is difficult if a developer is from a very different culture than the users of the site and it means a developer will just do exactly what he is being told to do without adding any value to the project. Developers that just blindly implement without thinking are not very valuable and they put a huge pressure on documenting every little detail on the customer. Even the most comprehensive documentation can't cover every interaction so the result of the documentation driven process is almost always worse than a more agile one.

Because of the stereotypes within a technical field, also the social competence of the team members should be considered when selecting the team. Developers are often too focused on the technical details leaving other factors secondary. If the communication between developers and the rest of the organization does not go smoothly, the outcome is either suboptimal or at least there is a lot of extra work required from everybody in the project. It also makes work frustrating for everyone involved if communication is an obstacle in daily work. For these reasons, fluent communication skills are really a must-have for any developer.

Providers of different size

Competent providers are found in every size from freelancers to mega corporations with tens of thousands of employees. Mostly same things apply to providers of all sizes, but there are some special characteristics.

In terms of commitment and price, it is often best to use freelancers with no fixed expenses and thus more flexible pricing for small projects. This also makes sure that a particular person is hired for the job and that they are committed to the project. Vacations or other days off at a wrong time are usually not generally an issue with a freelancer - they only get paid when they are working after all. Unfortunately, good freelancers are often hard to find. Another down side is that using only freelancers doesn't scale well for bigger projects and in many cases customers want to have an organization that can be held responsible on project results. In large projects, maintenance can also be an issue since it's not realistic to ask for 24/7 support from freelancers, not even when some of them are more than willing to sell it.

Micro companies with less than ten employees are mostly in the same category as freelancers. Same strengths and weaknesses apply, but naturally they can take on bigger projects than individual freelancers.

Small and medium companies are often technically the most capable ones when it comes to using open source technology. This is certainly true with Drupal. Most companies of this size have between ten and a hundred employees. With more resources, these companies can often take on a project of almost any size on their own. On many markets these companies seem to face a fierce price competition from smaller players with limited fixed costs. This hypercompetition might end up pushing daily rates down even to an unsustainable levels. Small and medium companies usually have limited financial resources and if they become unprofitable they will quickly have to let people go. Letting people go can wreck a company on highly competitive job market with competent people leaving the company. For this reason it is certainly a risk to work with small or medium company that is not clearly profitable. Other than the financial risk most of the best companies currently on the Drupal market are of a small and medium size.

Large IT companies have also been moving to Drupal lately. They are good at selling to large public and private projects with their sales teams and vast experience in large projects. The biggest difference when working with large IT is that teams become even more important. A large IT company might include references from other side of the world and initial team members who change positions in the middle of a project. It is even more important to evaluate the team, not the company with large IT. Currently many large IT companies also lack experience in Drupal and tend to outsource the work to smaller companies. This might change in the future, but at least currently not many large IT companies have considerable knowledge in working with Drupal.

The size of the provider is not by no means a determining factor in provider selection. At least not as long as the different characteristics of the different size classes are considered.