Managing Vendor Problems & Failures in Software Projects

Article by Lee Clemmer (7,746 pts ) , published Jun 5, 2009

Software projects depend heavily on vendors. If vendor-provided platforms, programs, libraries, APIs or features have problems, then so does your project. If a vendor fails to deliver on promises or performance, your project might fail. How can you keep this from happening?

Software Projects Depend on Vendors

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 not be 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.

Not Performing as Expected?

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.

Subcontracting Problems

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 could 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.

391908765 bd88c3f2f4.jpb, Nixon McInnes, Flikr, 2007

Keeping Problems from Becoming Total Failures

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.