Risks Resulting from Dependencies on External Sources


This category of risks is quite large; it covers any requirements your project has for outside resources that the team cannot control directly. This could include other contractors, vendors, and so on. Here are some questions to ask to identify risks in this area:

  • Does your project use certain products or technologies that are unavailable from other sources? If so, investigate the stability of the vendors supplying that product. What if that product were discontinued? What if the vendor stopped supporting it?

  • Will another contractor on the project be making a delivery containing functionality your project requires? If so, who is tracking that contractor's progress toward meeting that deliverable?

  • Will you be interfacing or integrating your product with a legacy system? If so, who controls this legacy system, and who maintains it? Can you obtain early access to it?

An Example of Managing Dependency on a Vendor

On a project at a contractor facility a few years ago, my team identified a solution offered by a vendor that seemed to be exactly what we needed to solve our problem. Two significant risks were associated with the use of this product. First, it was a niche product for which no competing solution was available. If it turned out to be unsuitable for our purposes, it would result in a serious setback for the project. Second, the product was available in only a beta release.

To mitigate the risk, we chose to implement a small portion of the project requirements that exercised the interfaces to this product's functionality. This would tell us whether the project would fit our needs.

As often happens, the result was a mix of good news and bad news. The good news was that the product was indeed a perfect fit for our needs. The bad news was that the software was riddled with bugs. Several key aspects of its functionality did not work well. The bugs could sometimes be worked around, but this impacted our team's productivity as developers spent much time developing these workarounds.

We started to work through the standard support channels with the vendor to pursue solutions to the bugs we found. After a time, it was clear that although the product was a good fit for our needs, we were continuing to lose too much time chasing bug solutions, despite the fact that the vendor's support line was helpful.

We called the product manager at the vendor, who promised to look into the problems we were experiencing. He returned our call the next day. He agreed that our problems were indeed valid issues, but he added that our use of the product was stressing it in ways they had not anticipated.

Ultimately, we worked out a solution that ended up as a win-win solution for both the vendor and our project. Because the product was a beta release, the vendor needed useful feedback and bug reports that would help it improve the product. The vendor stated that our bug reports were indeed valid issues that we had uncovered, and its developers found our bug reports easy to understand, which helped them correct the problems. In exchange for continuing to provide frequent reports on specific documented problems (usually several times a week), the vendor gave us a direct line to the lead developer responsible for maintaining the product. This allowed us to bypass the normal support channels, reducing the time spent on the phone.

This solution was not perfect, because it still required a significant investment of our time to properly identify and distill the problems into reproducible bug reports. But in return for these efforts, we received software patches to correct the reported problems, sometimes within hours of the vendor's receiving our report. We also stayed in touch with the product manager and formed an excellent business relationship with the vendor. This kept us informed of the vendor's plans for the product. It increased our confidence that the product would be viable in the marketplace, thus reducing the risk that it would "disappear" and no longer be available. The project completed its development on time as a result.

Consider the following lessons learned from this example:

  • For any product required on a project, if you have no prior experience with the product, verify its viability and suitability for your project before depending on it to complete your project.

  • Be willing to invest some time to help your vendor, and search for a win-win solution.

Risks from Other Contractors

It's common for large projects (especially government projects) to have several contractors. If this is the situation on your project, take the time to understand any dependencies you have on the other contractors meeting their delivery schedule. Even if you have no dependencies, if one contractor runs into trouble, it's possible that the outsourcing organization may have to divert funding and resources to the vendor experiencing the problems. Therefore, periodic monitoring of other contractors is prudent.

On the same Department of Commerce project discussed earlier, the two main contractors both reported to the same contact at the Department of Commerce. I led one of the contractors. My project required the successful delivery of the other contractor's work. Our project was required to interface directly with the other contractor's code. This meant that the other contractor was supposed to develop an application programming interface (API) to their code. Although I monitored their success, I did not dig into the details enough. They were running behind schedule but were still on target to deliver in time for our project. I did not know at the time that the other contractor's project manager had negotiated a reduction in scope to reduce the delays. It turned out that the "reduction in scope" happened to be the elimination of the API my organization required to get its work done. The contact at the Department of Commerce did not realize that the API was required. In addition, the nature of an API is such that detailed knowledge of the underlying code is needed to develop it. This meant it would take too long for my team to get up to speed on the other contractor's code and develop a viable API in time.

In the end, we received extra money from the customer, and we borrowed two developers from the other contractor to get the API completed in time. But it was a close call. I learned the hard way to strive to identify all such dependencies and to make all the stakeholders involved aware of these dependencies.




Project Management with the IBM Rational Unified Process(c) Lessons from the Trenches
Project Management with the IBM Rational Unified Process: Lessons From The Trenches
ISBN: 0321336399
EAN: 2147483647
Year: 2007
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net