If you haven't run into this situation, you're lucky. Managing vendor disagreements can be a very interesting situation. On the one hand, you're forced to almost blindly trust what your vendor is telling you—and yet, if team members are disagreeing with the vendor, whom should you believe?
The first element of managing vendor disagreements is the discovery component. Sit down with the team members who are in disagreement and try to get at the heart of what they' re saying—what their disagreement is all about. You should also sit down with the vendor and try to understand its side of the disagreement as well. Misunderstanding on the part of team members It could be that the source of the disagreement is merely a misunderstanding. Perhaps your team members have always worked with one product; this new product behaves differently, but they' re expecting the same outcome as with the old.
Misunderstanding on the part of vendors Alternatively, perhaps the vendor has misunderstood what your actual intent is for the product it' s going to supply. The vendor, after understanding the nature of the misunderstanding, might respond, "Oh, well, Widget A won' t do that, but Widget B will." Sure, you should 've gone through this discovery process at design time, but this kind of thing has a way of slipping through the cracks. Paradigm shift It could be that the vendor' s product is just fine for what you ' re trying to do, but there' s a paradigm shift that team members have to go through in order to effectively use the new product, and they simply have not yet made that leap. Recall the mainframe project in the Real-World Scenario earlier in this chapter? In that instance, we had several mainframe programmers who were used to thinking in top-down programming format and had a hard time grappling with object-oriented (OO) technologies (where you put an object on a screen, then write the underlying code for that object). A paradigm shift was required. Unfortunately, especially in OO, that shift is a hard one to make, especially if you ' re coming from the old school of programming. The ego factor Sadly, IT is an industry that' s fraught with large egos. It could very well be that one of your team members has forgotten more about the product than the vendor will ever know, and he' s prepared to tell the vendor so. Managing this kind of thing may require that you use "tough love" tactics where you tell the team member to do things the way the vendor says they need to be done. Alternatively (and most often), you may have to replace this talented team member, because he will derail the project, by doing things his own way, more than he will help to get his tasks done. In the final analysis, it is, after all, all about tasks and their timely and successful completion that makes a project successful.
The 800-pound-gorilla vendor Some vendors have a "my way or the highway" attitude when it comes to their product. Some products, especially enterprise-class software, are so cumbersome that companies are forced to wrap their way of doing business around the product, rather than the product wrapping itself around the way the company does business. Additionally, some companies think nothing of calling you up, telling you that the latest revision is out, that your revision will become unsupported in a few months, and asking how soon you can be converted—all at a substantial cost to you. I think that project managers would benefit from heavily weighing this 800-pound-gorilla phenomenon to see if this is somewhere they think the project should go. In other words, if you marry into a software or hardware product that' s a phenomenon all unto itself, then you' re stuck with that phenomenon. When you' re on board the Queen Elizabeth II, you go where the captain wants you to go (unless you buy the boat).
This is a place to weigh the disadvantages of integrated systems against the advantages. Suppose that you' re using an enterprise-class relational database management system (RDBMS), one that comes with its own software development environment (SDE) or perhaps even with some canned apps that may loosely fit some of the stated deliverables of your project. Should you invest your company ' s development environment completely in this one large offering, or should you investigate to see whether other SPEs and tool sets may do a better job—if for no other reason than simply to avoid having all of your eggs in a single vendor' s basket? Normally, with integrated systems, you' re worried about two different platforms (whether hardware or software) talking to one another. But don' t forget to ask, "Should I sell my soul to this company?"
Platform wars This phenomenon is especially prevalent in the network operating system (NOS), SPE, and RPBMS camps. One guy likes Unix; another won' t do anything that' s not Microsoft-oriented. One gal loves Oracle; another thinks that Sybase hung the moon. Pevelopers are really funny about stuff like this—one talented developer will insist on using the Java language and a particular Java SPE, while another says that the best code comes from C++ and has the SPE to prove it.
As a PM, it ' s up to you to create a standards-based environment that utilizes the best-of-breed technologies for the given task at hand —often regardless of one individual ' s personal preferences. This is a really difficult call to make. You can reduce the difficulty by going to websites that specialize in IT research, sites that can give you sage (and especially agnostic— meaning vendor-independent) advice about choosing a product. Gartner Inc. (www. gartner.com) and IPC Corp. (www.idc.com) are two such companies involved in this kind of research. You can do a lot of your research for free without having to purchase a subscription to their extended services, but for heavy detail and Q&A, you' l l need a subscription membership.
Tip Check first. Your company may have a subscription to one of the research groups, and you can set up conference calls with SMEs in the subject you ' re interested in researching.
research groups, and you can set up conference calls with SMEs in the subject you ' re interested in researching.
The "Planning Took Too Long and Now the Technology's Different" Phenomenon
The "Planning Took Too Long and Now the Technology's Different" Phenomenon
The IT world is a very fast-paced environment—. one, in fact, that often outpaces the rigors of good project management. Suppose that you ' re responsible for a fairly large client/server project. Because the project is large, you opt to go through the formality and rigor of PMI' s recommended phases.
Your project has taken so long that, back at concept formulation and early design time, thick clients were hot. A thick client represents an actual executable that a technician must install on each end-user' s computer in order to participate in the client/server process (clients developed, in times past, with PowerBuilder, Visual Basic, or another quality SPE). Now, thin clients—ones that connect using an ordinary browser and rely on server- side processing or, at the very maximum, a minor download of some software to the end-user computer through a first-time connection to the app' s website—are hot, hot, hot.
Additionally, at concept formulation time, 100Base-T connections were usual, but now Gigabit Ethernet (1000Base-T) is expected.
As well, where you once only had to worry about passing Structured Query Language (SQL) statements back and forth between client and server, you must now think about rendering things in Extensible Markup Language (XML) so that browsers can intelligently work with your system' s back-end databases (still passing SQL statements, still returning rows, but now translating into XML on the fly). The possibility of utilizing an application server to help you with the process is a very distinct one.
One of the very important talents a project manager brings to the table is "design elegance:" being able to design a project in such a way that it moves quickly through the preliminary phases, the deliverables and requirements are largely independent of the technology du jour, and the technology is decided upon at or near project implementation time—thus keeping the project at least somewhat near prevailing technological normality. The rapid changes such as those just described demand that an IT PM stay abreast of technology, or at least be able to come quickly up to speed. Otherwise, the PM is at the beck and call of vendors and team members and may wind up dealing with a vendor disagreement—or worse, a platform or app war.
Was this article helpful?