Dealing With Vendors on Software Projects

Most software projects depend on a software vendor in one of a few very critical ways. Application roll-outs or upgrades rely on the new package functioning as advertised. Of course the app must not crash and the installs must be successful. This situation is the simplest and it's not what we will mainly focus on in this article. Instead, we will look at ways to improve process in software project management.

Much of the time software projects are development efforts. Application development depends on vendors providing working APIs, libraries, or middleware that satisfies project requirements. Application servers, feature-rich platforms, and high-performance interfaces to databases all must work properly for development to be successful. Even if the software is developed entirely in-house and is custom code, vendor interdependence can be present, although it is less critical.

So, what to do when problems arise? First, identify whether the vendor misrepresented the capabilities of the solution. Or, were they unaware of bugs that your project has uncovered? If problems like these arise, work closely with the vendor and impress upon them the importance of delivering a working solution.

If you discover that a vendor solution simply won't perform, verify that before abandoning the solution or switching vendors. Some vendors may have other options that they can provide, whether their own staff or new code. Using cutting edge or beta code brings its own problems, of course.

What if the problems aren't with vendor code, but instead with subcontracted coders? This can seem to be an intractable problem. Once a project is well under way, getting replacement programmers up-to-speed can be difficult. The same goes for augmenting development teams. Even well documented code can take a new developer time to understand. Hopefully you've picked resources that can deliver to begin with. Whenever you can, have an option for assistance or take-over of development lined up.

As projects progress, changing directions or switching tracks becomes more and more difficult. If you identify critical decision points ahead of time, and prepare sound contingency plans and options in advance, disasters can be averted. This sort of thorough planning takes more time and may seem unnecessary, but it can save your project.

Having a vendor management system can be a big help--if you don't have one, consider creating one. Knowing how far over budget you might go if a vendor can't deliver is far better than having no idea. Stakeholder confidence and desire to follow through to completion are much more likely if they know that the problems were possible and have been planned for.

Take the extra time and effort--it can make the difference between failure and success.

My experience in vendor management and project managagement demonstrates the critical importance of vendor selection, vendor managment, and risk mitigation in IT projects. In a recent project, we tried three different lead software developers (contractors) before we found one who was competent and could communicate effectively. The core software in this mission critical project was discontinued by the vendor (one of the largest hardware and software companies), and support has been ineffective and glacially slow.

My advice isn't anecdotal--look at the recent failings for cloud services providers, such as Amazon. Use wisely your power of choice.

Photo by Nixon McInnes, http://www.flickr.com/photos/nixonmcinnes/391908765/