Introduction to Work Intake – Part 2

In this second post in our Work Intake series, we’ll continue to expand on the use cases previously used in Part 1 of the Introduction to Work Intake. Before we begin, let’s quickly recap from Part 1 what work intake is and why it is important. Utilizing an anchor chart of 5 W’s + H, we began to gather preliminary requirement information from three different use cases.

New infrastructure at a remote branch location

• Who: Remote branch users
• What: Site build out of a firewall, switch, and AP
• When: October 31st
• Where: Burbank remote location
• Why: Company is expanding to meet customer demand.
• How: Physical build out of new location to include placement in SoT (Source of Truth) and monitoring

Migrating from SNMPv2 to v3

• Who: Monitoring Team
• What: Remediate the 100+ network devices
• When: Risk closure by November 1st per Security Team
• Where: All locations (35 sites)
• Why: New security standard due to an internal audit
• How: Device configurations moved to the new standard

Create automation for the provisioning of Data Center access ports

• Who: Network Implementation Team
• What: Provide deployment of ports for new server build-outs
• When: Servers to arrive October 1st
• Where: Brownfield DC
• Why: Implementation team is overwhelmed
• How: Automation to deploy the access port configuration

Existing Workflows

After the preliminary information has been gathered, our next step is to determine pre-existing versus ‘net new’ work effort, as it helps further the understanding of the use case. We’ll employ the term “net new” to represent a function or piece of work that hasn’t previously been performed and isn’t being done today. This is regardless of a manual, semi-automated, or even fully automated effort.

To quantify the procedural efforts of this pre-existing work, we’ll use the following functionalities as a means to quantify the significance of the work effort. These functions include:

Frequency

• How often is this work or function performed?
• Values: One-time, Hourly, Many times a day, Daily, Weekly, Quarterly

Steps

• How many different processes or steps does it take to complete the work?
• Values: 1 to 10 steps, 11 to 20, 21 to 50, 51 to 99, Greater than 99 steps

People

• How many different people or teams are needed to complete the work?
• Values: 1 to 3 people, 4 to 10, 11 to 20, 21 to 50, Greater than 50 people

Approvals

• Are any approvals, either prior or during, needed in order to complete the work?
• Values: No, Yes (1 to 2), Yes (3 to 5), Yes (6 or more)

Dependencies

• Are any dependencies, either prior or during, needed in order to complete the work?
• Values: No, Yes (1 to 2), Yes (3 to 5), Yes (6 or more)

Using this function from above, let’s begin to apply it to our existing three use cases to obtain further insight to them.

New infrastructure at a remote branch location

• New or Existing: New
• Frequency: One-time
  • The build out would be a one-time event
• Steps: 51 to 99
  • There would be numerous steps during within the planning, purchasing, receiving, testing, installation, and finally the actual cut-over to the production environment.
• People: 4 to 10 People
  • 2x Network Engineers, 1x Cabling Technician
• Approvals: Yes, 3 to 5
  • As the request involves new equipment, there would be different approvals from finance for the bill of materials, purchasing for the ordering of equipment, as well as change ticket approvals.
• Dependencies: Yes, 3 to 5
  • New equipment would require certain logical dependencies with creating a bill of materials prior to ordering. Additional dependencies might include lead times from the vendor or supplier for shipping or even receiving at the main office for pre-staging prior to shipping to the remote location.

Migrating from SNMPv2 to v3

• New or Existing: Existing
• Frequency: One-time
  • The remediation would be one-time migration
• Steps: 4 to 10
  • Processes may differ across companies however this will be classified with 10 steps. These include receiving the request, gathering server side details, review of the environment, creating a script, then change management process of writing, submitting, and approval of change. Then implementation & validation of the change, validation to requestor, closing request.
• People: 4 to 10 People
  • 3x Network Engineers, 2x Monitoring Engineers, Security, Change Mgmt.
• Approvals: Yes, 3 to 5
  • Multiple approvals from Network, Monitoring, and Security teams.
• Dependencies: Yes, 1 to 2
  • Dependencies on the company baseline standards and model specific best practices for SNMP v3 settings.

Create automation for the provisioning of Data Center access ports

• New or Existing: Existing
• Frequency: Weekly
  • Requests for new access ports come in multiple times a week
• Steps: 4 to 10
  • Processes may differ across companies however this will be classified with 10 steps: receiving the request, gathering server side details, review of the environment, creating a script, then change management process of writing, submitting, and approval of change. Then implementation & validation of the change, validation to requestor, closing request.
• People: 1 to 3 People
  • Network Engineer, Server Engineer, Change Mgmt.
• Approvals: Yes, 1 to 2
  • Change ticket approval
• Dependencies: Yes, 1 to 2
  • Dependency on the required server-side information prior to starting

The large details that we have gathered thus far will provide critical structure and visibility into understanding the entirety of the request. At this point, we are starting to see our three different use cases begin to take shape.

Additional Parameters

Obtaining these seemingly minor details up front helps paint a better understanding of where this work is taking place, as well as how our engineers will need to interact with the requestor’s environment in order to fulfill the work. Sometimes these items are very well understood for daily work, also known as “Keep the Lights On”; however, other times when multiple teams or systems are being integrated, this level of detail truly stands out.

Locations & Environments

Which regions and/or environments would be a part of this effort?

Examples: Internal, DMZ, Internet

Which domain(s) would be utilized for this effort?

Examples: Production, UAT, Development

Methods & Access

What method(s) would be used to interact with your request?

Examples: SSH/CLI, RestAPI, SOAP, All of the above

What type of account would the engineer use for authentication and access?

Examples: Service account, User account, Local account

Service Management

Some organizations maintain change windows for certain operations. Identifying this up front can reduce obstacles and help establish timelines.

Examples: Standard Network changes are performed every Tuesday from 8pm-2am

Using the parameters from above, let’s proceed to apply them on our existing three use cases.

New infrastructure at a remote branch location

• Locations & Environments:
  • Internal production
• Methods & Access:
  • SSH/CLI with a User account
• Change Management:
  • Higher risk change window as this would introduce new variables to the production environment such as routing changes.

Migrating from SNMPv2 to v3

• Locations & Environments:
  • Internal production
• Methods & Access:
  • SSH/CLI with a User account
• Change Management:
  • Involves multiple teams, so it would require a regular change on a weekend.

Create automation for the provisioning of Data Center access ports

• Locations & Environments:
  • Internal production
• Methods & Access:
  • SSH/CLI with a User account
• Change Management:
  • Standard change window as it is a repeatable work effort

Outcomes

Lastly, outcomes provide us an opportunity to see why the requestor is coming to us. The value of the request will be seen in their eyes. Creating an acceptance criteria may create some dialog to establish a limit on the work effort, though setting these expectations up front can help both the requestor and the Engineering team to work towards the common goal.

Business Value

Business value can be subjective, as it may differ from company to company or even from team to team within an organization. The aim is to capture the positive outcome that the company would receive (using quantify for measurements such as time, and qualify for adjectives such as faster, better, etc.).

Acceptance Criteria

These are typically a list of requirements which would need to be satisfied in order for the requestor to sign off on the completed work. Having these agreed upon up front helps establish what the completed work may look like as well as reduce scope creep.

Using the parameters from above, let’s proceed to apply them on our existing three use cases.

New infrastructure at a remote branch location

• Business Value: A new location provides opportunities to reach new customers for better company growth and increase in market share.
• Acceptance Criteria: When onsite staff are able to access the main environment from the new equipment.

Migrating from SNMPv2 to v3

• Business Value: Security and audit compliance, as we’ll be able to close out this Risk item
• Acceptance Criteria: When the Security team is able to resolve the audit item.

Create automation for the provisioning of Data Center access ports

• Business Value: Cost save associated with reduction of person hours & reduced manual error
• Acceptance Criteria: When the engineer can feed a list of Brownfield ports to the automation