Tenuous Linking

There is a rather obscure issue that I've seen arise in project planning meetings over the years.  It has to do with feasibility versus risk, but also risk versus payoff.  The word "tenuous" has several definitions, but in general it refers to something being "thin", "delicate" or "weak".  The word "linking" in this context pertains to physical or logical establishment of specific relationships between two distinct realms of information or services.  In other words: establishing a link between two database tables, or between an employee and a physical asset, such as a computer.  Putting these two words together then should render an obvious meaning.

Most projects in the IT world that demand a "planning meeting" involve complicated issues.  Logistics, resources, technical issues, budgets, and my favorite aspect of all: politics.  Sometimes these are born from CxO meetings and are dropped onto the heads of the IT minions like a brick on an ant colony.  Sometimes they're born from departmental or divisional meetings, where they want to achieve greater collaboration and reach.

Where this term "tenuous linking", which I completely made up all by myself, out of thin air, tenuously, comes into play here is with respect to how such projects are fleshed out.  The process usually starts with one party saying that they'd like to accomplish "X" but need to somehow link system "A" to system "B" in order to connect the dots.  Suits often use "connect the dots" as a means to convey hipness with the younger IT slaves, rather than big, confusing terms like "synergy" and "economies of scale" and so on.  Then the other party says something like "you can't access system 'B' because that's OURS, and WE control that, so YOU can't have any.  Nah nah nee nah nahhhh...", followed by an awkwardly long silence.

Once the political/rice-bown/mini-kingdom crap is ironed out, then it usually gets into the technical aspects.  Once into this phase issues are identified with how feasible specific types of links are, or will be, with respect to different data types, formats, access methods, authentication methods, and the king of all project dooming catastrophies: the upgrade.  That's right.  Off in the distance, over the mountains of project planning, hidden behind the clouds of quarterly projections, in the valleys of stupidity, there lives the "big upgrade" project.  The one that's never going to happen, or at best may not be initiated for another six to twelve months.  This is where the "risk versus payoff" part comes in.

Typical projects where you may find this to be relevant include links between things like employee management systems, asset inventory systems, procurement tracking systems, regulatory compliance systems, manufacturing process systems, CRM systems, BIM systems, and so on.  Each of these often overlaps significant portions of the other in terms of data, features and functionality.  While the interfaces may appear obvious, these other aspects I've described often interfere or obstruct the path towards joining them for a greater purpose.

How do you assess the practicality and feasibility of each tenuous link?

You break it down in to the smallest components that impact the risk, and each that impact the potential benefit.  Some of the most common road bumps (risks):

- The systems have completely different authentication and access schemes (too difficult or expensive to overcome)

- The systems have completely different data formats (too difficult or expensive to overcome)

- One of the systems will "soon" be replaced with a newer/different system (waste of time to attempt)

How do you trump these obstacles?  Easy: You carefully assess the value of the potential benefit of the desired outcome.  Then you insist the ney-sayers cough up specific numbers pertaining to the level of effort and costs incurred with overcoming the obstacles.  Then match the numbers up.  When the CxO is told that his cute little baby project won't fly because the numbers just don't jive, and he/she drops their Martini glass in a panic, you can point straight at the numbers, and then point directly at the folks who gave you the numbers.  While the CxO is busy beating the evil-doers with his/her favorite Gold-plated Driver, you can sit back and prepare for the bruised clowns to come back to the table with a more cooperative attitude.

Aside from the numbers aspect, there is always the issue of third item.  This requires a bit more savvy and patience.  You need to carefully assess the realistic time frame as opposed to the stated time frame.  A lot of times, party "B" will be to resist efforts to bridge the gaps until they get their new system.  This is most often used as ammunition to keep pressure on higher-ups to continue funding and supporting the plan to get to the "new" system.  The fear they see is that if they allow linking to the status quo, it will negate the need for upgrading or replacing the system, at the very least it could delay their plans.  This is bad.  But if you remain vigilant, you can work with party "B" to make everyone happy.  How?

Devise the plan such that you take into account the interface aspects of the status quo, as well as the expected interfaces to the new system.  Identify any gained advantages with the interfaces to the new system.  Make sure to state in your plan that phase 1 can be done now, but phase 2 (using the new system) will yield even more robust results.  This can help to allay fears and suspicions and possibly draw party "B" over to your side of the effort, which can only help push the momentum towards accomplishing the links sooner.

Tenuous links exist everywhere.  We rarely identify them.  We rarely document them beyond stating their existence, since the "tenuous" nature is often intangible or subjective.  NEVER take "it can't be done" for an answer until you've ferreted out every bit of technical assessment.  In most cases, the biggest obstacle to accomplishing a technological goal is the human aspect.