Tips for getting the most from your software vendor

If you're ready to start a new software project and don't have staff with the skills and availability to start it, you're probably considering hiring an external vendor to help make your vision become a reality. To help your project go smoothly, here are some things you should do before and during your project to help it become a success, whether you hire me or someone else.

Understand your priorities

Before you get started, take a hard look at where your overall priorities lie. Everyone wants their software created quickly, at a low cost, and with high quality. To make matters even more unclear, "quality" can take on different meanings to different people. Application speed, ease of use, application up-time, number of bugs, scalability (i.e. the ability for the application to grow with few growing pains), ease of adding features, security of the application, etc., can all contribute to the perception of "quality". Unfortunately, many of these are conflicting goals. Making an application execute very quickly takes longer to develop and is more expensive to build, just like adding a large number features can make your application harder to maintain. You should understand where you are willing to compromise and where you are not so you can communicate this to me (or your vendor if you're using someone else), then follow up to make sure these priorities are followed. Communication upfront along these lines can save a lot of headaches and discussion when the bill arrives. If you're not sure where your priorities are, I can help talk you through the options so we can set expectations.

Establish common goals

Along similar lines, it will help both of us if you start by establishing a common and thorough understanding of what you want out of your application. Don't worry too much about hammering out all of the details when you're first getting started - I (or any good vendor) will expect you to change your mind about some of the specific needs you report during the course of making the software and will plan accordingly. However, if you don't have a clear idea of what you want, I would have an extremely difficult time delivering on your expectations. If you don't have a clear set of expectations as to what your new software will do, consider running a separate discovery project. Such a project may sound like a waste of money at first, but having common goals will help everyone in the long run.

Set a single decision maker for the project

I've worked on many projects without a single decision maker, and the common theme was that these projects tended to drift and never get completed. The problem is caused by too many people trying to pull the project in too many directions. If you set a single decision maker, he/she can keep the project moving and properly prioritize work that needs to get done. I can do this for you if you want, but it is generally better for you if someone on your team serves in this role.

Don't try to accomplish everything at once

I know, you're excited about the possibilities that this new software can bring. Truthfully, I am too. But software projects often fail when we try to accomplish too much too quickly. One thing that will help us manage your project is to break your project into smaller, yet still useful, chunks. More often than not, once my clients start working with their application, their understanding of what they want out of their software changes. Suddenly, features that were must-haves at the beginning become not important, and features that hadn't previously been thought of become high priority. But if you try to develop too much at once, problems are identified late. The later a problem is found, the more expensive it is to fix. If you start small, you will see the results of your work sooner, allowing us to adapt to each other's styles. This will allow us to communicate more effectively.

Pay time and materials

Many companies want to pay a fixed price for custom software because they think it lowers their risk. Fixed price projects certainly lower your financial risk, but what about the risk of not receiving what you wanted? Fixed bid projects are tougher for both of us. On a fixed bid project, you understandably want to get the most for your money and try to put in as many features as possible. But in most cases this can cause you to lose focus on your core needs from the software. On fixed bid projects I must protect my interests, and therefore cannot be very open to change requests. If a project is billed on time and materials, however, we both can focus on whatever is best at the moment, including considering cost. In other words, the discussion turns from extracting the most value possible from the other company in a fixed-bid situation to a more cooperative effort to build the best software possible in a time and materials situation.

Keep communication lines open

Be sure to stay active in your project. You may be tempted to give me all the information you think I need and then let me finish the project, but that's usually a recipe for failure. I'm good, but I'm not that good. Review any documentation, samples, code, beta versions, etc., as thoroughly as possible. Sometimes things get lost in translation. Sometimes one of us comes up with a better idea. Either way, the more you're involved the better the end product will be.

It all comes down to communication

Most of these suggestions come down to improving communication. Understanding your project and understanding your priorities help you give clearer directions to your vendor as to what you want from your project. Breaking down your project into smaller, but still useful, chunks helps us communicate what you need in a meaningful way. Billing your project on a time and materials basis helps us communicate about what the project needs, rather than about unnecessary information. Keeping communication clear, open, and frequent will help increase the odds of success.