4 Mistakes you Should Avoid When Outsourcing Software Development
Choosing a software development vendor can be a daunting task. Without proper preparation and a solid grasp of the key steps, the choice can lead to a veritable nightmare. Today’s post is aimed at those who want to be in control of their project when outsourcing to an agency.
What can go wrong?
1. Lack of transparency in cost estimates
- When your vendor presents you with the cost estimate, only features are costed. Project management, team communications and QA are absent.
- The vendor is running a business that has to track hours/days worked by the developers. If there is a team working on the project, this team will need to communicate with each other and with you - the client... If this is not considered as a separate line item, these hours have been punted into hours for feature development.
- If your vendor says that they don’t bill for team communications or project management - that is another huge warning sign - bear in mind that they pay their developers for every hour spent at the office and this money does come from your project.
- If all the extra hours (PM, QA, BA, communications) are packed into feature estimates your provider will have a hard time following these and will likely lead to scope creep.
- Some agencies are ashamed to admit that their developers are human and have to talk to each other.
- Ask for transparency.
- You’ve chosen the vendor for your development
project,set budget and deadline and signed the contract. A week into the project you ask for an update and hear “all is going according to plan.”
- Your requests to collaborate with developers are denied because “they work better when left alone.”
- The project manager always knows best.
- These are professionals and your input as an amateur is not needed, necessary or welcome.
- The product you end up with will have nothing to do with your expectations.
- You are in for a painful process of getting the agency to build out according to your scope.
- Timelines and budgets are likely to be blown.
How it should be:
- The agency should work to understand your worldview - your business pains, your proposed solution. This is not a one-time deal - your worldview must be run against their tech expertise constantly to ensure that the product being built reflects the realities of your business. A key part of this process
aredemos at the close of each sprint where the features that have been developed are showcased to you. The agency should also set up a staging server to provide you access to the work in progress and to enable you to provide extensive feedback which in turn provides basisfor the evaluation of the project and the direction it is going
- Your vendor asks no questions, keeps communication to a minimum and sticks by their own worldview of your business;
- The vendor asks questions but you never see your answers implemented. It’s as if you are not being heard;
- The vendor overuses technical terms especially when
discussionbecomes heated or touchy. This is used as an instrument to confuse you and to highlight the vendor’s expertise;
- When things go wrong (deadlines missed, features delivered not as planned) communication becomes very sparse.
You will lose control over the project unless the communication problem with your development vendor is solved.
How it should be:
- Weekly calls are a MUST, not a nice-to-have;
- Weekly calls should be followed up by a summary from the vendor’s side. The summary should reflect the feedback that you had provided on the call;
- If deadlines are missed or
featuresnot delivered as planned, you should know ahead of time and why the delay is happening. Most projects will have project creep or scope creep. Highlighting these situations is a sure sign of a quality agency.
4. Quality Assurance
- You ask for a testing check-list but there isn’t one.
- There is no specific QA role in the team chat or project management software.
If your software development company does not include quality assurance and code review in its statement of work, deadlines can be significantly altered due to extended bug fixing. This will create difficulties for you, as you will be tasked with detecting the bugs.
How it should be:
At the very least functional testing of features, regression testing upon completion of the scope and load testing for performance should be conducted by your provider to ensure proper software delivery.
Here we’ve outlined the dos and don'ts of
We hope that your communication with vendors is always straightforward and productive. If you ever need a second opinion – ask us a question via the special form on our website.