Peter Mojica, Long-Term Archival Preservation Records Management Legal Discovery Compliance
Skip to content

What are the most important decision factors when selecting a provider for your next software development project?

Rating: +0

Positive Negative


Let's say I'm a CTO/CIO in a company and I've been asked to develop a custom web-based solution for a business process of the company. As always, we think we have a pretty good grip on the requirements and desired functionality for the process tool - we just need a little bit of guidance. I'd like to do the development in-house but I don't have the right people and talent to pull this off. I need to hire a team from a technology provider to do the job.

After scouting the providers and explaining my problem to them, a few of them start to feel like the right kind of partners to do the development with. The problem is, I don't yet have a definite answer who's the best fit for our organisation, vision and goals.

What should be the most important decision factors when selecting a provider for software development project?

How do you decide who are the obvious experts to take care of the project and provide the solution?

* This was selected as Best Answer

Lauri,

If you've already decided to outsource the development vs. build internally, and I guess you've also decided to outsource to a local firm that maintains an in-house development staff vs. going off-shore. It also sounds like the project that you are under-taking is pretty custom and doesn't fit into an existing COTS offering. Given all of those parameters my biggest factor would literally be style and personality of the primary team leaders that I and my team need to collaborate with on a daily or semi-regular basis to get requirements and testing done back and forth.

Let's face it, at the end of the day, your going to be hiring staff extensions vs. an offshore development team. And this is not to unusual, especially if the project being undertaken is pretty custom, having the resources near and dear is probably preferable for a good outcome, but given that scenario you want to make sure that personalities mesh will with your organization. Especially, if you've already selected the tool sets (ie. J2EE, Jboss, etc.) then the development and architecture is really more commodity and the skill will be in the "getting it done" and "delivery", many firms and people can get things "underway", but it’s always moving things off the white-board and into a spec, and into code, code that works, than can be used and supported and evolved, etc. on a timely basis is the key. So, if all of your pre-requisites in terms of checking references, checking prior "production" work product, etc. has been done, then look to work with the team whose style and personality jive best with yours. Trust that the "work" will get done, the pre-requisites did pass and the architecture is based on well known standards and best practices for delivering a J2EE environment, for example.

You may want to consider carving out a “slice” of your overall development project pie, as a test case, maybe have them write a needed sub-system or engine within the overall framework, something that's not throw-away in the event that they fail the "get along with my team" pilot. See how they work-out on a short, maybe 6-8 week deliverable, before contracting for the entire project scope.

On these types of custom projects, factor in some scope creep, and normal sundry project delays and overruns, your going to be visiting with this external team for sometime, so criteria number one should be will they mesh.

In terms of deciding who the best would be, my advice would be to find someone who has the closest match to your vertical who has done something similar before within their portfolio of prior projects – this way you get the benefit of some of their prior clients mistakes, improved processes, bright ideas, etc. If you venture to a real solid team, with no domain or vertical expertise, no matter how good they are, they will be learning quite a bit on your nickel which they’ll take to their next client.

Good Luck,
Peter
January 2008