1 year ago Oleksandr Kravets
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.
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:
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:
Hint: spell out how much of the development should be performed onsite and write this into the document.
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.
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.
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.)
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.
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:
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.
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.