Software development is seldom easy, and outsourced custom software development introduces another layer of complexity. Which doesn’t mean it can’t be simplified, but it requires serious planning.

Chunking the project, or breaking it into discrete sections, is one approach that ensures you cover all the important points. Read on to find out how to use a choose, create, deploy methodology.

Choose Your Developer

Choosing a developer is a lot like choosing a partner, and arguably just as critical. Unlike the rest of the development project, you have complete control here. It’s only your company involved. Use your power wisely and you’ll reap the rewards.

This checklist will help you identify and choose the best developer:

1. Develop A Requirements Document

Be inclusive here. Get input from everyone from end users to IT support staff to executives with sign-off responsibility involved.

Your requirements document should spell out in detail what you want the finished product to do:

• how development collaboration looks
• milestones
• performance penalties
• and how you define and measure success

Hint: spell out how much of the development should be performed onsite and write this into the document.

2. Build Your Internal Development Team

Make appropriate, talented, decision-making members accessible to your development team.

Appoint key team members—a strong, knowledgeable lead person, IT support members, and a beta test manager at a minimum.

3. Do Your Research to Find Development Candidates

Talk to other companies who’ve developed projects like the one you’re going to undertake. The internet can provide countless aids, including forums, associations, and many other groups that allow you to build up a list of developers.

Get your list down to a manageable size, no more than five companies, ideally, and begin contacting them.

4. Share Your Requirements Document, from 1, above.

If it’s too lengthy, you may want to only present a subset of it to your candidate shortlist. Study their response (and how quickly they responded). Are they just after the quick sale or are they taking the time to get to understand your needs better?

Pare your list to three candidates whom you then invite in for more detailed conversations.

Use your requirements document from point 1, as a starting point when you meet with prospects. Treat the meeting as a high-level candidate interview: interactive, back-and-forth exchanges, with questions from both sides (good questions can tell you more than answers.)

5. Choose a Company and Create a Design/Performance Document.

It will contain parts of your requirements document but go much deeper. It’s a blueprint for the development job, created jointly between your team and the developer, much like a project playbook. Expect negotiation here.

A good developer will likely propose different features than you anticipated—ones which will often be superior to yours, achieve your outcome, and result in a superior solution.

This document must contain information about mutual obligations and rules for delivery, regular and development milestone meetings and delivery schedule, testing and quality control specifications, as well as penalties for non-delivery of product or meeting deadlines. Specify milestone documentation requirements.

These not only let you know the progress of the project but serve as evidentiary yardsticks in progress against plan. You also need to be comfortable with the procedure/document your developer provides at the end of the project.

Assume you’ll have other developers looking at this code somewhere down the road—be sure the original developers leave a good record of their work.

You can expect the developer’s legal department to have input here (yours too probably). While legal can seem like a stumbling block, it’s important that they keep each party’s best interests in mind and have their input, just in case problems emerge later on that could require a legal solution.

Creating Your Product

If you’ve covered the ground we mentioned above, chosen a good developer, and created a solid design/performance document, you’ve done 80% of the work.

Nevertheless, consider the following points as you get into this crucial part of the cycle:

1. If you agree some development will take place onsite, provide the developers with a great work environment. Don’t relegate them to a second-rate place to work. Environment plays a big part in creation.
2. Make sure the people you committed to the project are fully available to your partner. REMEMBER, your developer is YOUR PARTNER, not a hired resource. Treat them as such, and your life (and finished product) will be much stronger.
3. Diligently hold to agreed meetings. These should have been outlined in your design/performance document. If your developer cancels even once, raise it as an issue. You don’t want to let a bad habit develop. Hold your own team to equal standards.
4. Don’t scrimp on testing. Depending on your developer’s methodology, testing could be more frequent during development, or more on the backend. Whatever the case, thorough testing of some kind during development is critical. Do whatever is necessary to provide adequate testing resources on your end. Time and resources spent here will make post-rollout support all that much easier.

Deploy to the Field

Here’s where the rubber meets the road. No matter how much you’ve prepared, how many alphas and betas you’ve tested, going live is the target you’ve had in your sights since the beginning.

Make sure your developer hasn’t left the building. Their job isn’t complete until their code works smoothly and satisfactorily in the field. You will never have to have this conversation with a good developer, but stories abound of developers who deliver their code after internal testing and march out the door, on to the next job.

You should have covered rollout, the developer’s responsibilities to stay involved until it’s successful, and what constitutes completion of the project, in the design/performance document.

And don’t forget to create a plan to inform and alert your clients (if it’s an application that affect customers) of the new software.

If you handle the announcement of the new software as an advantage to customers, they’re much more likely to put up with the inevitable initial annoyances caused by new software rollouts.

Success—if Done Correctly. Otherwise….

After such a successful and pain-free project, I hate to end with horror stories, but I must. Unless you follow a system like the one above, filled with accountability, superior testing, and frequent communication, your final chapter could be much less rosy.

You could even end up on this list of Real Life Examples of Software Development Failures.