Some management issues are eternal and come up over and over again, with no real answer.  The underlying issues change over time and from one situation to another. But they are important questions, so they never go away. For example, I was recently asked, “When should you create a product / service internally and when should you buy a commercial product or hire outside experts?” Hmmm… the old build or buy question. For a smaller company, this isn’t that difficult a question because they only have a limited number of service departments. Smaller firms regularly need to bring in expertise because they cannot afford to sustain certain fundamental services. A large firm can (and usually does) have at least some capabilities in every service area.

World spanning firms have significant legal departments, a large IT organizations, facilities managers and architects, very complex HR services, etc. Aside from the question of internal capabilities, there are also other legitimate reasons to default to internal development such as: client confidentiality and protection of proprietary processes. In many cases it appears that internal development is cost effective, but internal service often do not include all costs or may not even know what their costs are (ex. Not every department  is directly charged for the space they use). There are also other untested assumptions. An outside vendor may deliver a product late (but may be penalized), or may go over budget (but may not be paid for all overages). Internally, penalties for these areas would not make sense. With so many untested assumptions and unwritten criteria for new projects, internal vs. external comparisons will never be totally fair and balanced. Until all of these assumptions are explained, documented, and quantified, it’s difficult to even define what fair and balanced means.

What’s the solution? The simplest solution may lie in a process you’re already using… the Request for Proposal (RFP). If you’re not familiar with this it is a document to gather information from several potential vendors or service providers. The RFP clearly lays out project details (eliminate any confusion over what you’re asking for), requests specific details (ex.: one-time cost for travel, ongoing cost for management, licensing fees, etc.), is reviewed internally by multiple departments, and provides an unbiased (as much as possible) score for each candidate. Your firm may already issue RFP’s. Usually, due to their high number of projects, IT departments have the most RFP experience, but RFP’s are moving into every group and all types of firms. But RFP’s have two problems. They tend to require a lot of resources and all of the untested assumptions we spoke about create a faulty filter for the build vs. buy decision. You can fix this by performing an assessment of capabilities.      

Essentially, this is still an RFP but instead of asking questions about a specific project, it asks more general questions to understand a candidate’s ability to perform different types of work. Applied internally, this tells you when a given department is the best option for a “build” solution. It also gives you a chance to get agreement on some of the unwritten rules. For example, if an application for confidential work should be performed internally… what is confidential, and who defines it (legal, IT, compliance, corporate security, etc.)? With more of the unwritten rules spelled out, build vs. buy becomes a lot more logical and easy to determine. Here’s a summary (and a bit of an expansion) on how to do this:

1. Identify groups with many build vs. buy decisions.
2. Determine the area of competency you are ranking.  
   1. Ex.: Web development vs. database management
   2. Ex.: Managing existing space vs. procuring new space
   3. Ex.: Internal e-discovery vs. outsourcing e-discovery
   4. Review the criteria for the “RFP” with each group
   5. Develop a “capabilities” RFP
      1. Include outside groups for comparison
      2. Ask a few quantifiable questions, to rank cost/time/etc.
      3. Review and score the responses
      4. Rank the capabilities of groups to deal with each area of competence
      5. Review and finalize the results with each group
      6. Apply to the next build / buy decision

See… not too difficult. What was that? You think this might work for other firms but that you might have some resistance in your organization? How can you get buy in to this process? That’s a really excellent question! And I have what I hope is a really excellent answer. In tomorrow’s post…. Because that’s my Niccolls worth for today!