3rd Party Vendor Solutions: Do they reach their potential?

  • [アーティクル]

Theory vs. Actual

Save time. Save money. Free up your full time employees to work on higher value initiatives. All reasons to pursue the Third Party Vendor (TPV) solutions. How well do they hold up under scrutiny? On paper, sure, you can make a great case for TPV solutions. However, in practice we all know there are obstacles to realizing the overall savings and cost benefit.

Controllable Factors – Hardly Rocket Science

These obstacles, many of which are controllable factors, usually start out as irritants, progress into real nuisances, to finally become repeat post mortem items and detailed “challenges faced” topics on our annual reviews. My conclusion, no surprise here, is that recognizing, preparing for, and dealing with the controllable factors up front will always result in the end product more closely resembling the theory envisioned at the contract signing then if these factors are brushed aside in the rush to get the dev cycle going. Here my list of controllable factors that can decide the fate of a TPV project.

Administrative:

What are the basic needs of the vendor team at the start of the project and how do you plan to meet them.

  • What credential sets and permissions will be needed for the vendors?
  • On site physical work space: does the vendor team have a place to set up shop when they are on-site?
  • In house email alias and building access
  • Vendor access to all project related materials- from the very start of the contract

Process Changing:

You can now pick and chose where the vendor teams will be physically located. In one of our projects we had the vendor dev team located here in town but the vendor test team was located in China.

  • How will vendor location (on site, in town but off site, out of town, or off shore) change the plan?
  • Time zone differences must be considered. You don’t want a test team in China losing an entire work shift waiting until someone comes on line in locally to help resolve an issue. Or visa versa.
  • Who is responsible to span the work shifts when time zone differences are a factor?
  • What is the engagement plan between the vendor team and the in-house project team?
  • Who does the travel between sites? How many times? Who pays?

OPS Centric:

Your operations, dev, and test teams know the rules to deploy. Does the TPV know them? For example, by what means does the application need to maintain state on a clustered environment? Discovering known conditions at deployment is bad form.

  • Platform – what does the platform they are coding for look like?
  • Security policies
  • Performance
  • Capacity
  • How do the TPV dev and test platforms differ from the Prod platform?
  • Specific architectural constraints

Basic Rules:

  • No assumptions. No interpretations. No open ends. Everything needs to be spec’d out
  • Nothing at the start of a project can be casual. Everything at this point must be formal.
  • Checkpoints along the project timeline – involve your dev and test teams for a sanity check
  • Release criteria
  • Deliverables required of the TPV

But That is so Obvious….

Obvious? Totally. Routine? Hardly. Simply stated we need to take our organizational knowledge and make it common knowledge for the TPVs. Something to consider; once you have complete and detailed documentation in place you won’t need to recreate it for each new contract you sign. Reuse, reuse, reuse. The initial cost of complete documentation pays for itself within your next project cycle when it can be re-used or slightly modified to meet the needs of the new project. Do it once and do it right and you will be able to spend much more time on strategic offerings -did someone say promotion? You must factor in the tasks, deliverables, and standards from the very beginning to reach the full potential of TPVs.