Whatever The Hell It Is I Do All Day

I often refer to my job as being “whatever the hell it is I do,” upon which I also often append “all day.”
I refer to my job in this fashion because 1. My job, while often hectic and challenging, is pretty boring. 2. The actual details of what I do are difficult to explain. 3. I try not to take my job (or myself) too seriously.
Well, prepare for 1, because I’m about to take a crack at 2.
(Nothing is going to change 3.)
First of all is my title:  Senior Analyst – Integration.
The obvious first question is, “Who gives a shit?”
However, the second obvious question is, “What does that mean?  What sort of integration are you analyzing?”
Well, the thing to consider is…I mean…well, it’s kind of like…hm.
If pressed, in a more serious setting, I generally respond with, “I’m essentially a Project Manager.”
That’s all well and good if you know what being a Project Manager entails, but there are, no doubt, plenty of people out there who don’t.
So.
I suppose that I should first explain a term and concept:  NOC, or Network Operations Center.
Longtime readers may recall that for several years I worked in a NOC – particularly those longtime readers who worked in that NOC with me.
In any case, here’s one definition of NOC:

Stands for "Network Operations Center." It is the central location where a company's servers and networking equipment are located. The NOC may reside either within a company's campus or at an external location. Smaller businesses and organizations often have an internal NOC, in which local technicians administer and monitor the servers. Larger companies may have a NOC setup at a location developed specifically to house server equipment.
[…]
While NOCs are used by all Web hosting companies and ISPs, they are also useful to companies whose services are not related to the Internet. Many companies use a NOC to manage internal communications, administer employee e-mail accounts, and backup data. Because maintaining an Internet connection is vital to most businesses today, most NOCs are monitored 24/7, with automatic alerts that notify technicians when servers or network connections are down.
(Source)

This definition is essentially correct, with the caveat that in some companies, such as the one I work for, the NOC isn’t necessarily where the actual equipment is located.  Actually, I’d say that’s the case with most companies, or, at the very least, it’s not where all of the equipment is located.
A NOC is, however, a centralized location for monitoring, troubleshooting, and repairing issues.
In any case, as a cable company, my company provides a wide range of products and services to individuals and businesses, such as Internet access, telephony, and video.  As a result, there are all manner of devices, data connections (fiber, coaxial cable, etc.), and software applications that can – and do – stop working at any time, for any number of reasons.
And that’s where the NOC comes in; they need to be aware of the breakdowns, and have to work to restore service as quickly as possible.
And that’s where I come in.
My department’s function, historically, has been to ensure that as new products and services which require monitoring and troubleshooting support efforts from the NOC are rolled out to customers, the NOC is ready and able to provide that support.
In terms of actual deliverables, this means providing support process flows, operations guides, training and training materials, ensuring that the NOC techs have access to all of the necessary tools for monitoring and troubleshooting, escalation contacts and procedures, verifying that all of the previously-listed items actually perform their intended functions, and, ultimately, getting the NOC management to say, “Yes, we are officially ready to support this product or service.”
And that would be the “integration” mentioned in my title, though to be honest, “integration” is a holdover from our group’s old name, “Integration Services.”  (We’re now called “Operational Support and Readiness,” and we’re part of a – slightly, for the time being – larger group called “Service Transition.”)
In terms of day-to-day activities, this entails reading through technical documents and network architecture diagrams that describe what the product or service is and how the associated equipment and applications it runs on actually work, identifying the potential failure points, attending lots and lots of meetings with the cross-functional project teams that are actually designing, documenting, and implementing the new product or service, and working from there to determine what the expectations are of the NOC, what the NOC will need to do in order to deliver on those expectation, and how the NOC will do it.
Understanding the specs and architecture documents requires being at least passingly familiar with the terminology and device functionality – you may not know exactly how a switch works, for example, but you do understand what it does – or at the very least an ability to identify the people who are familiar with it and can explain it to you, and you have to be able to translate all of that into terms that someone who may be only slightly more (or even considerably less) technically skilled than you are can understand.
So other than going to meetings and reading through technical documents, what do I actually do?  Well, as mentioned, I write operations guides, I develop training materials – sometimes I actually provide the classroom-style training – all of which I’ve distilled from the information gleaned in the tech docs and meetings, but also through a defined requirements process and checklist that spells out exactly what I need to have in order to provide the NOC what it needs.
That entails managing individuals and groups outside of the NOC and my department who have – in theory, at least – the information I need, which can mean wading through office politics, departmental rivalries, personality clashes,varying levels of expertise and knowledge.  And sometimes the information, for any of those reasons, and many, many more, might never become available to me, in which case I still have to ensure that the NOC can support the new product or service.  How do I, and the other members of my team do that?  Honestly, I don’t know, but somehow we manage.
Mostly I think it’s creativity, a high tolerance for frustration, and a stubborn refusal to just let things drop.
Of course, there are all sorts of other activities beyond what’s involved in preparing the NOC to support new products or services, such as documenting and refining our internal processes, archiving project materials, serving as a SME (Subject Matter Expert) on various processes and tools, administering our internal Web site…
Recently, after the reorg – or “Functional Realignment” – the scope and or scale of what my team does has expanded a bit to include other groups, which means we’re no longer as exclusively-focused on the NOC as we had once been.  Basically, while we have had three people added to the team, and some of our old responsibilities have transitioned to other groups, the net result is still that we’re doing much, much more work with very few resources.
So, yeah.
That, in a wordy nutshell, is whatever the hell it is I do all day.