Sunday, April 12, 2020

Buying Enterprise Network Services 2 - Understanding the Work at Hand


This blog is a continuation of my previous post Some Considerations for Buying Network Services. In this entry I am going to provide some thought material to help in understanding the characteristics of the different kinds of work an organization needs accomplished and some associated ideas on how to contract for the work.

Before we get started, one of the problems that I observe is that many organizations seem to deal with "absolutes".  They define a type of activity, for example "Networking", and then decide how to contract for the effort, for example "outsourcing".  Depending on the culture of the organization, this may lead to discussions that contain statements like "well, if  we outsource everything then we won't be able to tell the contractor anything and we get whatever they want to provide the service".  On the other extreme are statements like, "if we continue to use level-of-effort contracts with the government telling people what to do we won't get anywhere as no-one is actually responsible for making things better and we have no idea what all these people are actually doing".

Clearly, the extremes don't work.  So, what actually makes sense?  It can be pretty complicated, but one way to start is to understand what actually needs to get done.  From my experience there are three basic types of work:

  1. Services Outsourcing.  All IT organizations do this to an extent, but the question is really the need to understand the right level of what is a Service for an organization.  For networking, the lowest level is buying point-to-point telecommunication capacity and the highest level may be complex service types and levels delivered to the organization's locations with special services related to access to the Internet and Cloud services.  Importantly, Outsourcing contracts need to include specifications for the services to be delivered as well as the contract's interaction with an organization's other related activities.  Examples include, Enterprise IT Operations and Cyber Operations centers.
  2. Outcome-based Tasking.  This is the type of work that is designed to develop a capability based on a specification.  An example of this could be installation of a new local area network in a building to a set of performance and reliability specifications.
  3. Level of Effort Tasking.  This is the type of activity that maximizes flexibility.  An example is the rapid implementation of a new capability where there is very limited time,  only general requirements, and near real-time changes may be necessary to meet the actual mission need.

Some of the main characteristics of these different types of work of work are:

  • Specificity of the work.  This means that the definition of the services or work to be accomplished is much greater for Commodity Services Outsourcing than it is for Level of Effort activity.
  • Duration of the work.  Services Outsourcing are generally activities that span five to 10 years.  A Level of Effort activity might only last weeks.
  • Changes to the work.  Changes to Services Outsourcing generally requires the definition of a new service, negotiations with the contractor, and contract modifications.  All of this could take months.  Level of Effort activities can change on a near instantaneous basis.

A word on "absolutes" associated with Service Outsourcing.   Although, not as flexible as the other methods, it does not mean that a contractor can do whatever they want as long as they meet the contracted service levels.  Contract service levels is just one part of the what must be specified.  All the required parameters that affect the cost of the service must be included, as well as the verifications mechanisms required for proper oversight of the contract.

What does this all mean?  It means that the hard part of buying Network Services is to actually understand the services needed and all their related characteristics to address the diverse needs of the organization.  These are primary considerations in the types, requirements, and services levels that are part of the overall acquisition architecture, strategy, and roadmap.  More than a  technical issue,  it must also have what is in general more important, and many times neglected, a set of organizational structure and business decisions.

More on organizational and business elements in the next installment (hint: it is an architecture as well).

No comments: