Excerpted from: Looking for Mr. Goodvendor, by Laura Leff, PMP

Applying Project Management Best Practices to IT Vendor Selection

By Laura Leff, PMP

Innovative Project and Vendor Management, Inc.

I once envied my husband’s skills in his career as a chef.  “It’s an art you can apply outside your work.  I’m a Project Manager.  What am I going to do, come home and manage projects?”  Soon afterwards, I came to appreciate that the skills I had learned as a Project Manager were much like the skills I had learned with my Mathematics degree:  it’s a mental dance.  Knowing the basics of the steps, they can be applied to a wide variety of situations.

Project Management, reduced to its simplest ethic, is the skill of knowing how to take an idea and make it into a working reality.  Having spent many of my PM years implementing vendors’ widgets, Project Management and Vendor Management have always gone hand-in-hand for me.  Yet it seems when many people turn to vendor selection, it’s often done in a manner that lacks the process and discipline that would be applied to the implementation.

Frequently, people decide that they need a widget and simply run at the first vendor that comes to mind.  Other times, a vendor does what I call “The Music Man Tactic” (check the plot synopsis on IMDB.com if you’re not familiar with the connection);  the vendor rides into town, tells people what their problem is and how their particular widget is the only one that can solve it, and everyone runs from the conference room waving their arms about how we need to buy this widget NOW to avoid the apocalypse.  Still other times, people do a little research to find a few vendors that might provide the widget they need.  These vendors are then called in for multi-hour presentation sessions on their individual widgets, which lead to a lot of questions, discussion, and chin rubbing but almost no  documented, apples-to-apples comparison of each vendor’s capabilities.

Similarly, know your company’s requirements from a security perspective.  What kind of information will be stored in the system?  Will it need any kind of special encryption or hacking protection?  Will the vendor need to access it remotely for maintenance?  If a system is going to be in your infrastructure, you should have someone with Information Security knowledge evaluate it critically before purchasing.

In Scope Planning, you should be documenting the requirements of the widget.  This includes everything discussed so far:  the customer needs, specific customer requirements, infrastructure requirements, integration requirements, and security requirements.  The more specific you can make these requirements, the better feedback from vendors you’ll get about their real capabilities and something you can compare on an apples-to-apples basis.  I’ve reviewed a number of Request for Proposals (RFPs) where someone wrote a requirement of “Has an easy-to-use user interface”.  Every single vendor in the world will tell you that their user interface is easy to use.  State specific requirements, such as “Must be able to change administrator privileges in three steps or fewer.”  Then circulate the requirements to the team and get confirmation from everyone that you’re on the same page for Scope Verification.

So in gathering this information, you’ve probably piqued the interest of some of your coworkers.  This can be used for your Project Human Resource Management and team definition, as well as Project Communications Management.  Vendor selection is one of the most effective times for bridging the aforementioned silos, and insuring that the right people are giving the input and thumbs-up to the ultimate vendor selection.  While there are many corporate cultures that subtly encourage people to “hide” their projects so that others don’t “get in the way” of accomplishing goals, not involving the right people becomes a “pay now or pay later” scenario.  If a vendor solution is done without all the key information considered, your quick selection may get seriously bogged down in argument and finger-pointing when it comes to implementation.

Since this often happens before a project is formally initiated, most of the players aren’t thinking of creating a project structure for their vendor selection.  However, taking some practices from the Project Management Book of Knowledge (PMBOK) can greatly increase the efficiency and effectiveness of a vendor selection, as well as the chances of selecting a widget that will ultimately work well within the company and serve the

customers’ needs.

It’s astounding how many vendor selections start without a solid definition of project scope.  The product description is the first key input to Project Scope Management.  In the case of vendor selection, you first need to get clarity on exactly what the customer need is.  In the case of the Music Man, it may be an invented need that sounded good in the conference room, but really isn’t the top priority of the company once everyone has a chance to catch their breath and get perspective.  Many people will want to provide a “magic bullet” based on their understanding of the need, and rush to say, “The customer need is for a workflow management tool,” or “The customer need is for a Web portal.”  What the customer needs is seldom based on the technology—for example, the customer needs a single, consistent place to be able to make requests of a given group and follow up on status.  That may be doable with a workflow management tool, a Web portal, or some other widget, so don’t limit your options too quickly.

Historical information is also a primary input to Project Scope Management.  It seems that many (if not most) medium and large-sized companies are getting increasingly siloed, and communication between key groups often doesn’t happen until someone has a train already rolling down the track—often right at another group’s cow herd.  I’ve heard of many widgets that were purchased and then given to IT to “just make it work”.  When the widget only runs in a Mac environment and your infrastructure is all UNIX, this can be frustrating at best.  Knowing your company’s legacy infrastructure and environment (with what other software would the new widget need to interact?) is critical to insuring that the widget you’re selecting is one that will integrate smoothly into your environment.

Similarly, know your company’s requirements from a security perspective.  What kind of information will be stored in the system?  Will it need any kind of special encryption or hacking protection?  Will the vendor need to access it remotely for maintenance?  If a system is going to be in your infrastructure, you should have someone with Information Security knowledge evaluate it critically before purchasing.

Once the people involved in the vendor selection/project team are defined, it is recommended to develop a schedule (if you haven’t already done so in the requirements phase) for Project Time Management.  How long do you want to give vendors to respond, and how long does the team need to review responses?  Will you have time for a vendor “bake off” (i.e., bringing in two or more vendor products to implement in a test lab and consider side by side)?  How much time do you have for contract negotiations? Negotiations are one of the most neglected parts of the vendor selection process, and often lead to loss of leverage and money due to lack of time.  How much time should be allowed for Legal review of the contracts?  How is the knowledge of the selection team going to be communicated to the team that implements the solution?  All these tasks and responsible players should be documented and managed to insure that your selection stays on track.

For Project Cost Management, this is another place that having the right people involved and knowing your environment is critical to realistic estimating of a vendor’s solution.  If you realize that you’re going to need a new interface/API to a legacy system, then you need to insure that the development time and cost of the vendor or your internal people is factored into the implementation cost.  I’ve seen quarter-million dollar projects turn quickly into multi-million dollar projects when people start to realize just how many systems the new widget touches, or how much processing power needs to be built out to support it.

Project Quality Management is an often-neglected part of the vendor selection process.  Some people like to load software onto their computer and plunk around with it for a while.  With the need for a documented, apples-to-apples comparison, it is strongly recommended that you start with a test plan that is to be applied to all finalist widgets.  This insures a consistent and complete analysis of the tools, as well as something you can refer back to later if the widget surprises you by not doing something as you expect.  Additionally, look for existing standardized tests that your company may have, such as Security penetration testing, which may apply to your desired widget.

Project Risk Management is just as important in vendor selection as it is in mitigating the ongoing risk during implementation.  What role is this widget going to play in your company, and how will it affect the enterprise if it goes down?  How many years do you anticipate using this widget?  If you’re dependent on the vendor for support, upgrades, customizations, etc. in the future, how stable is the company to insure that they will be there for as many years as you’ll use their widget?  What is the chance of your vendor getting bought by another company, or even going out of business?  Who are the competitors, and who is demonstrating the product roadmap that most closely approximates your anticipated future needs of the product?  If you’re a mid or large-sized company, are you choosing a vendor that is properly sized to meet your needs, or are you putting your money on a vendor who is going to end up something like this:

Vendor selection benefits greatly from the PMBOK practices of up-front planning, clear definition, evaluation of quality, and management of risk.  You’ll know exactly why you picked the given vendor and what the tradeoffs were with the competition, be more assured of a smooth implementation and that the vendor will be there to support you for the long haul.  It certainly beats the Music Man, and your team will still be able to toot your own horn for the success.

--Laura Leff, author of Looking for Mr. Goodvendor