Selecting a Software Development Vendor

If you’ve considered the costs and benefits of a custom software solution, your next step may be to begin evaluating a company to develop a solution for you. The right partner is critical to your success. Finding one is not as difficult as it might appear if you use the criteria listed below. The criteria are not listed in order of importance, as the project’s needs will dictate the relative importance of each criteria. In some rare cases, for example, knowledge of the technical environment may be the most important criteria (real time process control systems for example).

Please note we have not addressed price in this list. Price is always important, but it’s critical to keep these other criteria in proper perspective, particularly when you take into account the cost of a failed project.

Stability

Acquiring a custom software solution from a software house often means contracting with the company to maintain the solution in the future. Unless your internal IT resources are going to assume this task during a formal handoff, the vendor will be your first resource to fix issues, enhance the system, or modify its behavior as the business needs dictate. For more complex projects spanning several years, the stability of the vendor becomes important even before the handoff. You want to select a vendor with an established presence, a satisfied list of clients and the financial stability to survive downturns, recessions and ever increasing competition. In short, you want the vendor to have been around a while, giving you some assurance that they will remain in business for the expected life of your custom software solution.

This point is closely related to the vendor’s stability; in particular we draw your attention to the following points.

Track Record

1. Business Analysis Success 

Based on the reasons for failure we cited above, we suggest that you request references from the vendor’s clients and ask them the question directly: “Did the developer get the requirements right the first time?” Yes is the best answer, of course, but maybes or are not necessarily bad news. There are reasons on the clients’ side which contribute to not defining requirements correctly, too: Lack of executive involvement, lack of dedicating the time needed to study the documents and participate in the process, and so on.

2. Budget success 

How well has the vendor performed on previous projects with respect to timelines and budgets? This answer, too, is sometimes not so easy to evaluate. In some cases, especially when the client did not clearly understand their own objectives or requirements, the project begins, runs well on time on budget, and then hits a hiccup when the software is delivered and found to be disappointing. It must then be redesigned and rebuilt and thus the project goes over budget for reasons which have little to do with the vendor. Ultimately, it is the vendor leading the client through the development process. It is thus the vendor’s responsibility to ensure that the solution will solve the client’s requirements. What’s important here is the track record – the company’s performance over many projects.

3. Cultural Fit/Alignment 

The requirements gathering process should be illuminating to the client, leading to insights into an individual’s job function, and to improvements in business process design. This is exciting because it shows people how to do their jobs more efficiently, and offers the promise that when the software is delivered they will be more efficient and effective.

4. Their Process 

Based on the remarks above, we suggest that you formulate a set of questions for your potential software vendor:

1. You should ask for a full briefing on their software development methodology, and whether they follow any of the industry standards (ITIL, CPI, ISO, etc.). 

2. Ask them whether their methodology is based on a traditional approach, an agile approach, or a hybrid. 

3. Ask to see the working documents and systems they use during their process as well as the deliverables that are generated from their systems and processes. 

4. Ask the references if the vendor followed the process description.

5. Responsiveness 

This again is a question for the references. How quickly did the vendor respond to important issues? Depending on the project’s importance to your organization, this may be more or less critical.

6. Technical knowledge 

Judging technical competence, especially when performed by non‐ technical people, is challenging. But a track record speaks for itself. Questions to ask the vendor’s references include: 

1. Budget performance. While being on time and on budget doesn’t always mean the company has solid technical expertise, it usually implies that they were not delayed by technical issues too often. 
2. Does the supplied solution meet the performance criteria which were established as its objectives.