Selleo Labs spółka z o.o.

Grzegorz supports smart technically-minded people as a business consultant and COO.

Grzegorz Rduch

## **What’s your approach?**

Outsourcing entrepreneurs and firms vary greatly in the way they manage the sourcing process. Some progress through it speedily and are fairly spontaneous in their approach. Others take their time and use a systematic process to specify their needs, identify potential service providers, filter through the candidates and eventually select the vendor to deliver on their projects. Some are more likely to rely on their gut feelings and intuition, while others seem to stay emotionally detached and use their brain rather than their heart in the process. **Those with a more mature sourcing process are more likely to identify and select the right service provider. Many outsourcing failures have their roots in a badly managed sourcing process.** If you agree with the opinion, what are some of the practices and process steps you might apply to increase the likelihood of finding the right service provider? What follows is a brief account of what the more demanding outsourcers do while prospecting for vendors. Hopefully, the text will offer some food for thought for those who are about to outsource and are in the process of looking for provider(s). Note that you do not need advanced software tools to implement the process below. A simple excel spreadsheet will often do. If you prefer a tool, you might google for one and find some such aids as the[ Website Vendor Selection Tool](https://www.demandmetric.com/content/website-vendor-selection-tool) or[ SupplierSelect](https://www.supplierselect.com/), to name just two examples.

### **1)** **Compile a list of criteria your vendor should meet**

Before you start looking for a vendor, think through your project and establish what is to be done. Divide the scope so that it is clear what is to be delivered by the vendor vs. what is to be delivered in-house. **Having defined the scope of work for the service provider, you can now compile a list of criteria your vendor should meet.** The selection criteria one uses should directly relate to the characteristics of your project as well as to the tasks, duties and responsibilities to be undertaken by the vendor. Some such criteria will be very **specific**; however, do not waste time reinventing the wheel. Instead, search for and utilize the lists compiled by others. Just modify them to fit the specifics of your project.

- specify WHO is to meet the specific criteria you choose\*\* – is it the vendor’s **company** as a whole, the **team** which would deliver the service or a specific **individual** at the firm, e.g. the vendor’s Project Manager / Team Lead?

Financial stability, for instance, is naturally connected with the company. As regards accumulated experience, however, you would be able to make a better decision knowing what the specific team / individuals have delivered so far. An overall company portfolio may not paint a complete picture of what the specific team offered to you have contributed to the vendor’s track record. As a rule of thumb – by default – assume you recruit a specific team / specific individuals and rate them rather than the firm. Only when a criterion clearly relates to the organization should you assess the vendor rather than the team. Accordingly, while gathering information in later stages, be specific and ask for information on the team and the individuals to be involved when appropriate. For the sake of convenience, **the criteria are sometimes grouped into broader** **categories**, e.g. technology, business, communication, etc. The more criteria you are going to use, the bigger the benefit you gain from the practice.

**Output**: a set of (categorized) vendor assessment criteria

### **2) Weight the criteria selected**

Projects differ in character. Some are, for example, small and may easily be delivered by a freelancer rather than a team. On top of that, those who outsource differ in their specific requirements, e.g. a bootstrapping entrepreneur views price differently than an existing SME with a consistent revenue stream and a budget set aside for the project. Accordingly, **some criteria matter more than others. It is time to capture that fact in your selection tool**:

- weight the criteria you selected in the previous stage. If you divide the criteria into categories, you may weight the whole groups before you move on to modify the weights for specific criteria within each category.
  In other words, you may choose to weight both the groups and the individual criteria within each group. Some of the criteria, i.e., the critical \*\*ones, should be marked as such. For example:
- expertise / experience in your technology stack (programming languages, frameworks, etc.)
- determine the top three technical skills that are the most important to you and therefore that the developers should possess.
- check whether the projects the company has worked on overlaps with your project type and size
- make sure that your team will consist of both senior and junior developers
- take into consideration is the time difference between you and the outsourcing company

A candidate vendor who fails to meet a critical criterion should be automatically eliminated, however high they score on the other criteria.

**Output**: a set of weighted vendor selection criteria

**3)** **Compile a vendor list**

Now that you, hopefully, know quite well what/who you are looking for, **create a list of outsourcing vendors who are likely to meet the set of criteria you have chosen**. Cast your net widely, but sift through the findings and ignore the vendors who clearly fail to meet the key selection criteria. **Where to find the vendors?**

- your network may know companies to recommend,
- organic google search seems to be the preferred tactic,
- use some technology-specific catalogues and listings.

Having completed the search, you should have a solid list of candidates for further scrutiny.

**Output**: a list of potential service providers

**4) Gather and verify the information about the vendors listed**

With the criteria and potential vendors listed, it is now time to **gather and verify information on the vendors**. So, do some digging and learn more about the candidates selected so far. You can start off by asking the service providers to deliver the information needed as well as to rate themselves, i.e., their company / team against the criteria you find important. Convert the (key) criteria into a list of specific \*\*questions \*\*and e-mail them to all the candidates for answers (a list of criteria-based questions can be found at the end of this article). On the whole, the longer the list of questions you send, the lower the response rate, so make sure you do not cross the point beyond which you receive too few responses.

Additionally, you may augment your initial search by using the **information available online**, e.g. you can check what the vendor say about themselves in their marketing collateral, what the social media contents connected with the vendor are like, etc. In further steps you will attempt to **verify such information; you will actually expect the vendors themselves to substantiate the claims they make – and rightly so! The burden of proof lies upon them**. You will also want to verify if others, namely the vendor’s clients, have the same story to tell – use **references**. Again, some of the key questions – by no means all of them – may be selected for reference sources to provide feedback on.

- check team members references and carefully analyze resumes
- don’t hesitate to go deeper than a Linkedin profile, check other platforms
- the resumes should include projects the developer worked on with technology stack and what contributions he had to the project
- don’t be afraid to ask if the team has worked together in the past and whether or not they are located in the same office
- ask about the open source contributions of developers, review their publications, presentations and past workshops.

**Output**: a list of potential service providers with information from the initial search

\*\*5) \*\*Use the weighted criteria matrix to assess the vendors and shorten the vendor list

It is time now to review the information gathered and use your initial findings to **assess the service providers’ suitability to deliver the service** on you project. Assess individual vendors, as well as the teams they are ready to dedicate – against the pre-selected criteria, compare their weighted scores and decide which vendors to progress with. Ultimately, you should end up with a shorter list of the most promising candidates meant for more detailed scrutiny.

**Output**: a shortened list of potential service providers

\*\*6) \*\*Gather more information and re-evaluate the remaining candidates to arrive at a shortlist

Your initial search and assessment have hopefully shortened the list. With a more easily manageable list of candidates, move on to **interviews** to gather more information and/or verify what you have found out so far. For instance, suppose the service provider claim their language skills are excellent – they now have an opportunity to prove it live. You are not just buying an abstract service from a company or, at least, you will be much better off if you go beyond such a perspective. \*\*You are recruiting a specific individual or a team of specific individuals to serve on your project – your crew. Thus interview THE individual(s) as well as THE reference sources related to the specific team and their track record.

- hold an interview with every developer in the team to check their soft-skills, especially the ability to communicate well (especially if speaking a foreign language will be necessary to communicate during the collaboration), as well as hard skills. This way, no ‘weaker’ developer can hide behind his more talkative, better-skilled colleagues
- be prepared to review their code samples, or even better, conduct pair-programming sessions with each of them
- you can also give them a test project of restricted scope and time

\*\* The vendor’s company \_en masse \_may have impressive experience in your area, a rich portfolio of projects implemented and clients ready to recommend. The question is what has been your team’s contribution to it. It is also a good time to ask such a team for **code samples and application/system walk-throughs**.
Don’t forget to check whether the projects the company has worked on overlaps with your project type and size. Also, consider the vendor’s size, if there are enough people to take over. Remember that bigger doesn’t necessarily mean better. If you decide on a large company you may experience frequent staff swapping, so be prepared for that. While talking to the vendor, make sure that your team will consist of both senior and junior developers.
An additional, more practical factor, you should take into consideration is the time difference between you and the outsourcing company. A couple of your working hours should overlap to avoid early morning or late night meetings, so if you don’t have a preference from which country your partner should come from, time zones may make it a bit easier for you to narrow down your search.

With the new information at hand, re-assess the remaining vendors and further shorten the list or select the best candidate to deliver the service (if you do not intend to use the steps below).

**Output**: a list of 2-3 shortlisted vendors / the vendor selected

**7) Visit the shortlisted service providers**

When the project is mission-critical, it is highly advisable to consider **an on-site visit** to gather and verify even more information on the shortlisted candidates / the vendor selected. It is obviously much easier when you intend to collaborate with an onshore or nearshore service provider, and it is much more convenient when the shortlisted candidates are located in the same geographical region / country. With the additional information gathered during the visit you can re-evaluate the remaining candidates and select the most promising vendor. You may still want to keep in touch with the other shortlisted providers though. If – for whatever reason – you fail to complete negotiations with the top candidate, you will have the others to go back to.

**Output**: the vendor selected

**8) Use a pilot project**

Selleo’s prospects / clients vary greatly with reference to the practice. Those from Germany, for example, have applied the practice invariably. Clients from other geographic locations have been less consistent. Whenever possible, I strongly recommend the practice as it provides you with an invaluable opportunity to **test the vendor’s ability to deliver on their promises**. The development team can now prove many of the claims they made in the previous stages of the sales process. A pilot project also helps to “smooth things out” / “get things up and running” (e.g. communication, collaboration practices, etc.) before the actual work on the project starts rather than during the process. Should the team fail to meet the expectations created earlier, you have a list of other shortlisted candidates to return to.

**Output**:  the vendor selected

If at any stage you are dissatisfied with the results, i.e., you feel none of the identified candidates seems able to deliver successfully on your project, do not hesitate to go back and broaden your search at **point 3**. If you become satisfied with mediocre findings you may have to accept mediocre service delivery.

## **Conclusion**

As you can see there is quite a lot of things to be done. You can manage the process yourself or use a sourcing agent / broker to support you in the process.  Whichever way you choose, the process requires resources:  time and/or money – it comes at a very tangible cost. **What are the benefits then? You significantly reduce the risks involved in outsourcing your software development project. You increase the likelihood of selecting and building a relationship with the vendor who is actually able to deliver good service on your project.** All in all, the cost may well be considered an investment which pays off later on when you build your application. Many outsourcing entrepreneurs / firms would be better off if they had decided to account for the upfront investment.

\*\*Post Scriptum 1 \*\*I would like to express my gratitude to Daniel Young from [Dragon Sourcing](https://www.dragonsourcing.com/) for all the insights and useful tips he offered.

\*\*Post Scriptum 2 \*\*I wrote the article and compiled the lists of criteria / questions below  with the outsourcing entrepreneur / firm in mind. Still, I guess, the contents are equally important for service providers, development teams or even freelancers. What are your answers to the questions? I mean, the answers you provide in the daily practice of service delivery.

Outsourcing entrepreneurs and firms vary greatly in the way they manage the sourcing process. Some progress through it speedily and are fairly spontaneous in their approach.

How To Choose The Best Software Development Company

\[TOC\]  
  
Let’s assume you are outsourcing your software development and wondering if things could go any faster. Development teams quite obviously vary in their inherent ability to deliver fast. On the whole, you determine the potential when you select a specific vendor / team to deliver the service. Having made the decision, you, in principle, have a very limited influence on how fast your software might potentially be developed. However, it can be observed that the very same team delivers at various speeds depending on the client they serve. The differences can often be traced back to how the outsourcing entrepreneur / company structures the collaboration process. Some outsourcers organize and manage the process well and thus empower their teams to reach their top speed. Others are much less effective in this respect. Which practices hold the development team back from achieving their top speed? How can you optimize the outsourced development process for speed? I have asked some developers for their insights and would like to share the findings in this blog post.

## Incomplete and/or ambiguous tech specs

Requirements / technical specifications delivered by outsourcers vary greatly in terms of how easy they are to execute on. We have been developing applications based on both high-level requirements and fairly detailed tech specs, i.e., complete sets of wireframes / mock-ups and user stories / use cases, which were converted into acceptance test scenarios and approved of by the Product Owner before milestone implementation. **With complete and unambiguous tech specs at hand, the development team implements much faster.**

An added advantage of providing your team with executable tech specs is that there is less need to provide them with ongoing feedback during development, which allows you to devote more time to customer-focused activities at the front-end of the product development process.

**Provide your development team with executable specs!**

## Tech spec development on the critical path

Executable tech specs do take time to develop. Sometimes they are developed only after the team have finished the implementation of a specific milestone. In such a case, developers often cannot move on immediately to implement the next milestone and are forced to fill in the gap working on a different project – an unnecessary distraction and a loss of momentum. There is a much better alternative though; tech specs can be developed concurrently with development and thus be removed from the project critical path. The development team can progress speedily from milestone to milestone.

**Get the tech specs ready for the team to progress smoothly from milestone to milestone. Eliminate gaps between iterations!**

## Multiple requirements changes during milestone implementation

Requests for change submitted during milestone implementation may slow things down. The more requests submitted and the more fundamental the changes requested, the slower the progress. Tech specs may need to be reviewed and updated, and so do the schedules and budgets (on fixed-price engagements). Rework may add onto the workload.

Mid-course corrections are unavoidable, especially on innovative projects. Still it is possible to reduce the impact by selecting the backlog items which are least likely to change as well as by reducing the iteration cycle time. With less scope on the plate, you are less likely to disrupt the implementation work to be done.

**When requirements are volatile, work on items least likely to change and shorten the milestone cycle time!**

## Lack of / insufficient / delayed feedback

**The less precise the tech specs provided, the greater the need for ongoing feedback.** When the requirements / tech specs are not complete / unambiguous, teams often get stuck in their development efforts. In such cases, their performance vitally depends on clarifications provided by the Product Owner. Clients differ in their response times – some take days, others merely hours to answer their developers’ questions and remove roadblocks which pop up on the way. Some teams take risks and develop without the feedback needed; in practice, they very often have to rework the solution when the feedback finally arrives, which again consumes time and money (on Time and Material engagements).

Knowing that your specs may be vague and you may not be available to fill in the gaps for the developers on an ongoing basis, strive for a team with expertise in your domain and application / project type. Find a team who understand your business, the problem you are trying to solve as well as the product you want to build, so that they are well positioned to fill in the gaps themselves.

**Be available to provide the team with sufficient, timely feedback. Respond fast!**

## Too much feedback

At the other extreme, there are the Product Owners who get involved despite the fact that the team have sufficiently informative tech specs against which to deliver. It does not concern cases where a scope change is needed during milestone implementation. It concerns situations where the Product Owner attempts to interact with their developers even though they do not need any feedback to progress efficiently. Specify what you need and let the team do their job.

I guess the main reason for it is that back-office activities are much less challenging than the front-end work to be done with target customers / users. If Product Owners get sufficiently involved at the front-end of the process, they hardly ever have time to waste with their development teams at the back-end.

**Do not get in the way when the team is progressing smoothly. Your time is likely best spent working with your customers and/or users!** 

## Delayed acceptance. Team overextended on too many projects

Some Product Owners take a long time to check and provide feedback on the deliverables submitted by their teams. If the Product Owner unduly delays acceptance and, additionally, asks the team to progress with the work on the subsequent milestone, the team that agrees to do so, may soon be left stranded with a few unfinished milestones, which negatively impacts the service provider’s cash flow – see more on the point below. **When stuck in this way, i.e., without feedback or acceptance, teams are tempted to wait and fill in the slots with additional engagements to maintain utilization at a reasonable level. A perfect recipe for slowing things down.** If – at a point further down the road – all of their clients being served eventually decide to speed things up, they are in for an unpleasant surprise – the team may have very little room to move faster.

A note for developers. Do not yield to the temptation until after

* you have informed your client of the problem you face,
* you have presented the measures you might be forced to apply to alleviate it,
* you have clearly explained why you need to do so,
* you have given the client time to adjust, and still …
* you have been ignored by the client despite doing all of the above.

**Keep the above in mind, yet never accept deliverables which do not fulfill the agreed upon acceptance criteria**. If deliverables are flawed or incomplete, demand that the team remove any deficiencies before you accept and pay for the work done. Deliver the straightforward message as soon as possible.

**Do not delay the acceptance of deliverables which satisfy acceptance criteria. Provide fast feedback on corrections needed. Keep the team busy on your project!**

## Unduly delayed payment

From the client’s perspective, the iteration cycle technically finishes when the agreed upon deliverables have been submitted. From the vendor’s perspective, the cycle is over when the associated payments have been executed and the team have been remunerated for the work delivered. The client may have accepted deliverables and still delay the payment for them. The practice can have a very disruptive impact on the vendor’s cash flow as **typical software development houses / design agencies – like any service providers without passive recurrent revenue streams – vitally depend on the steady cash flow streams coming from the clients they serve. In the most dismal scenario, the vendor may lose valuable resources by not being able to meet their financial commitments towards their employees.** Such payment default(s) may seriously cripple the team to deliver the service, let alone deliver it fast.

Some vendors may have been stung by unfair clients who did not pay for good service in the past. Being painfully aware of the payment default risk (which increases in proportion to the amount of work delivered and not paid for), they may feel reluctant to enter a new relationship with high velocity and ramp-up fast. You can help them hedge the risk. You do not need to use upfront payment to remove the doubts besetting their minds – start off with a small job or a short iteration, let them implement it fast and clear their doubts with a prompt payment.

**Pay fast for work well done!**

## Middlemen

Service providers sometimes develop applications for other software development houses operating in the client’s market rather than directly for the client who commissions a software development job. When it is so, the information flow is extended over **3-5 entities**, i.e., the offshore / nearshore service provider, the local service provider, the client and even the client’s customer and/or user. Quite expectedly, **the longer the chain, the more time it takes to develop the solution**. Just think of the number of acceptance activities to be performed and the number of people to be involved before the deliverables eventually reach the end of the development cycle.

If speed is vital, you should eliminate middlemen from the process and **be as close to the development team as possible**. You should even consider if outsourcing is the right strategy to pursue. If you optimize the project implementation strategy for speed, you may actually be better off collaborating face-to-face with physically collocated local resources. They may seem more expensive on the surface, however, if you consider the cost of delay, they may not be as costly as they appear at first sight. Alternatively, outsource but collocate with the key team members – either at your premises or theirs – for the fuzzy front-end of the process, bring things up to speed and only then – when things are running smoothly – dislocate to reap the cost benefits of outsourced development without sacrificing the speed you need.

**Eliminate middlemen!**

## Conclusion

If you want to optimize the outsourced development process for speed, it may well be a good idea to focus on the main obstacles which slow development down; ensure smooth progress by proactively removing the stumbling blocks which get in the way. Let’s reiterate the main points with **a checklist**:

* provide your development team with executable specs
* get the specs ready for the team to progress smoothly from iteration to iteration; eliminate gaps between milestones
* keep the team busy on your project
* when requirements are volatile, work on items least likely to change and shorten the iteration cycle time
* be available to provide your developers with sufficient and timely feedback
* do not get in the way when the team progresses smoothly with implementation
* when milestone deliverables are submitted for acceptance, provide fast feedback on corrections / modifications needed
* do not delay the acceptance of deliverables which satisfy the acceptance criteria
* pay promptly for work well done
* avoid middlemen

All in all, if you are truly after speed, release the brake and you may find out the accelerator will take care of itself.

**PS**

The article is based on the accounts and feedback gathered from my [co-workers in Selleo](https://selleo.com/software-development-team) as well as from developers I’ve met at technology-focused events I attended over the last few years. I would like to express my gratitude for all the insights these folks provided me with.

Let’s assume you are outsourcing your software development and wondering if things could go any faster. Development teams quite obviously vary in their inherent ability to deliver fast. On the whole, you determine the potential when you select a specific vendor / team to deliver the service.

CTOs

Founders

Read Our Blog.
Make better products with us.

Grzegorz Rduch

Blog posts that I worked on

How To Choose The Best Software Development Company

Tips On How To Optimize Outsourced Software Development For Speed

SaaS Founder Starter Academy

CTOs

Founders

Read Our Blog. Make better products with us.

Grzegorz Rduch

Blog posts that I worked on

How To Choose The Best Software Development Company

Tips On How To Optimize Outsourced Software Development For Speed

SaaS Founder Starter Academy

Read Our Blog.
Make better products with us.