Working With a Technical Partner

Regardless of which company you choose to be your software development partner, we want your project to be a success. In this, the first of two posts, we suggest some points to keep in mind when evaluating proposals. In Part 2, we will look at some factors to consider both before choosing a partner, as well as during the project.

Avoid Being Over-Prescriptive With Your Brief

Software developers are amongst the most highly paid professionals. They are (or should be) experts in building a solution from a set of requirements. So, make full use of the value that they are bringing to the table by leaving as many technical choices as possible to them. What differentiates an ultimately successful project from an unsuccessful one, is how well the solution addresses the problem or opportunity rather than whether it ticks each box from a list of requirements consisting of “put a text box here and a button there”.

The secret is to provide a description of the problem you want to solve or opportunity you want to address in your brief as opposed to a description of how you see the final system looking and working. This allows each developer you approach to demonstrate their experience and expertise in the solution they ultimately propose.

It is also important in your brief to give an idea of your budget. We often hear the argument that “if I tell you that then that is what you will make me pay, regardless of what it actually costs you to build it.” This is a flawed rationale. Each competent developer will know of many ways to deliver a solution that meets your requirements and the cheapest option is probably not going to be the best. By providing a budget, or a budgetary range, you allow each proposer to suggest a solution that is within your means, rather than getting 5 proposals that are far in excess of what you are looking to spend, thus wasting everybody’s time.

If you are creating a new product, also give some thought to what the smallest set of features might be that will allow you to test your idea. Defining this Minimum Viable Product (MVP), implementing it and then measuring its success or otherwise is the best way to minimise the risk of new product development.

Look for Attention to Detail in Potential Technical Partners

Failing to pay attention to detail is a fatal flaw in a software developer or development team. And there is much more to building an application than simply the user interface that you work with. Look for a technical partner who is also wanting to talk to you about non-functional features like:

• All the different kinds of testing and how much is appropriate for your project;

• Security;

• User experiences and collecting usage metrics;

• Ongoing cost of ownership;

• Required levels of system performance, e.g. how many users should be able to use the system at any one time, etc.

This is the knowledge you are really paying for when you engage with the better software development companies. Developers who don’t think about these things may appear cheaper, but the risk of your project failing or suffering from a budget blowout is much higher.

Compare Apples With Apples

We’ve already touched upon the plethora of possible solutions that could be implemented for your specific situation. This makes the job of comparing the proposals received very difficult. However, do not fall into the trap of just comparing the predicted price of each proposal without considering all the other factors. For example, you will likely receive at least 1 proposal where the developer has submitted an unrealistically low quote. What this often means is that they don’t consider any of the non-functional requirements of your solution, so security, performance, etc. is neglected. We have often been asked to get involved to rescue these kinds of systems. What we also find in these situations is that the code is written in such a way that makes it extremely difficult to add new features or change existing ones. This is a manifestation of something called “technical debt”, where decisions taken for the sake of saving time or money early in a system’s development, incur an increasing cost to work around or with over time.

We suggest making use of a simple decision matrix, listing the factors that are important to you and your project with a weighting for each. Then evaluate each possible partner against this set of criteria. An example of this may be:

An example decision matrix

Look for Clear and Open Communication from Potential Technical Partners

Software developers are not renowned for their communication and personal skills, but of all the reasons software projects fail, most can trace their cause back to an issue with communication. It is essential that you have the ability to have very open and honest conversations with your technical partner.

It is not your job to learn how to communicate using the latest technical jargon. It is, however, very much the job of your technical partner to understand what you want and to communicate effectively with you in layman’s terms. This should start from the moment you first make contact with them. Do they hear you out when you explain what you are looking for and ask questions to gain a better understanding? How do they react when you disagree with them?

When a written proposal is submitted to you, is it structured coherently? Is it written in plain English or do you feel like it is trying to bamboozle you? Does the proposal include details about how the technical partner is going to keep you up to date with progress, get feedback from you on work delivered, etc.

If potential technical partners do not convey the idea that they take communication seriously, you should consider this a major red flag, irrespective of the strength of the rest of their proposal.

Look for Flexible Terms

We often use the analogy of building a house when talking about software development. But that analogy isn’t completely accurate. A construction project will consist of a fairly short design phase (architect, engineer, interior designer, etc), followed by a long and predictable build phase (there is a plan, the plan is hard to change and it is fairly clear whether the plan is being followed) and finishing with a short testing and remediation phase.

Software development is quite different. It consists of a long design phase (gathering requirements, proposing a solution, writing code — yes, writing code is essentially turning the current understanding of the requirements into something that can be built by a computer) followed by a very short build phase (the compilation of the code into a program that can be run) and a fairly long testing and remediation phase (the intangible nature of software means that people often only understand what it is they want when they can actually start using the system). Software development is more of an exploratory process than more traditional forms of engineering.

That is why contracts that are typically used in construction are a poor fit for software development projects. You should be looking for terms that allow you to work closely with the technical partner to achieve a shared goal, whilst leaving you in control of the overall budget. A common way of achieving that is through the use of many short iterations, where the scope and cost of each iteration is fixed, but the number of iterations can vary depending on what you and the team learn as the project progresses. You don’t want to find yourself in a situation where you are spending more time arguing over the terms of the contract (“But it is obvious that when I said I wanted a wall it should be plastered and painted”) instead of working out how to make your app the best it can possibly be.

The best software development partners will not lock you into long term contracts. They will stand by the quality of their work and allow you to leave without penalty if they are not performing.

In Part 2, we will look at some factors to consider both before choosing a partner, as well as during the project.