blog

Photo of subway station by Matus Karahuta on Unsplash

How to Choose a Custom Software Developer, Part 2: Knowing What You Need

by | Aug 27, 2014 | Insights | 0 comments

In the first part of this series, we discussed four different types of custom software developers you might engage. Once you’ve selected the right type of developer for your needs, it’s time to understand your needs in more detail.

Technology and industry

When considering a potential vendor’s experience, clients sometimes have a tendency to think chiefly in terms of industry: if you’re a transportation company, you might seek out firms with experience working on transportation-related projects. This can be a mistake.

Familiarity with your business context can be a useful quality, but it’s easy to overemphasize at the expense of other important qualities. Going back to the transportation example, a large-scale web app for a shipping company isn’t the same as a backseat entertainment application for a taxi company. If you’re looking to build that shipping software, it’s going to be paramount that you find a vendor with experience building large-scale business-oriented web applications, even if that vendor lacks specific experience from working in the transportation industry.

If you need a heart transplant, you’re going to look for a surgeon with expertise in that exact procedure — you’re not going to worry so much whether they’ve worked on people with the same body type as you. The same applies here: industry familiarity is great, but the skillset matters just as much and possible more. Ask prospective vendors for references relevant to what you’re building and not only for references from your industry.

Of course, that can lead to one more complication. What if you don’t know exactly what to ask about? Or what if your initial ideas change?

A more effective RFP process

For a software development project, the request-for-proposal process is absolutely essential. If a developer misunderstands the requirements or scope of a project, costs can balloon and the entire effort can dead-end, leading to massive losses of time, money, and opportunity.

The process begins with requirements gathering. Clients should place a strong and continuous emphasis on the requirements gathering process. Begin by talking in high-level detail with a prospective vendor about the problem you wish to solve. This involves understanding why you believe you have a problem and why it is important to you to solve that problem. By understanding the problem – and the often more critical problems behind the problem – you can then engage in discussions about what possible solutions would satisfy your needs.

It is important to recognize that while discussing requirements, the focus must remain on the requirements and not the solution. Thinking prematurely about a solution or technology can result in missing critical requirements.

The fact is, during this process, clients will learn something new in every call with every prospective vendor — whether it’s about the type of software they will need to build, the nature of the problem they’re trying to solve, or opportunities to make the process more cost-effective. A single conversation with a vendor may well fundamentally alter what it is that you’re looking to do. With this in mind, it is important to continually revise your RFP throughout the process so that your prospective vendors can speak to the most up-to-date understanding of your needs.

Speaking with and ultimately choosing a vendor is really the first stage of your software development process. Capturing and sharing as much relevant data as you can is crucial to building the best software for your needs on schedule and on budget. If you can start the process right and find a partner matched to your needs, you’ll be on track to develop the tools that may streamline, grow, or transform your business.

graphic banner

+ more

Accurate Timing

Accurate Timing

In many tasks we need to do something at given intervals of time. The most obvious ways may not give you the best results. Time? Meh. The most basic tasks that don't have what you might call CPU-scale time requirements can be handled with the usual language and...

read more