Welcome back to the final exciting chapter in our three-part series on Work Intake. Throughout the past two blogs, we’ve used dialogue with our requestor to help form a more thorough understanding of the true “ask” from us. In Part 1, we used an anchor chart to gather preliminary details from the original brief description. In Part 2, we reviewed the workflow details along with considerations for parameters and outcomes.

Before diving into today’s section, let’s quickly review what we’ve gathered thus far from the three different use cases, as we’ll be referencing them in the next section.

New infrastructure at a remote branch location

• Who: Remote branch users
• What: Site build-out of a firewall, switch, and wireless access point
• 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
• New or Existing: New
• Frequency: One-time
• Steps: 51 to 99
• People: 4 to 10 People
• Approvals: Yes, 3 to 5
• Dependencies: Yes, 3 to 5
• Locations & Environments: Internal production
• Methods & Access: SSH-CLI with a User account
• Change Management: Higher risk change: impacts production with new routing changes
• Business Value: New location provides opportunities to reach new customers for better growth and market share.
• Acceptance Criteria: When onsite staff are able to use the new equipment to access the main Data Centers.

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
• New or Existing: Existing
• Frequency: One-time
• Steps: 4 to 10
• People: 4 to 10 People
• Approvals: Yes, 3 to 5
• Dependencies: Yes, 1 to 2
• Locations & Environments: Internal production
• Methods & Access: SSH-CLI with a User account
• Change Management: Involves a couple of teams which would require a regular weekend change request
• Business Value: Security & audit compliance, able to close out the 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

• 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 with requests
• How: Automation to deploy the access port configuration
• New or Existing: Existing
• Frequency: Weekly
• Steps: 4 to 10
• People: 1 to 3 People
• Approvals: Yes, 1 to 2
• Dependencies: Yes, 1 to 2 Dependencies on the required server-side information prior to starting
• Locations & Environments: Internal production
• Methods & Access: SSH-CLI with a User account
• Change Management: Standard change as it is repeatable work effort
• 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
  

We will begin our discussion on the topic of assumptions related to complexity and effort (aka duration). For assumption values we’ll use estimations as opposed to more concrete answers that were used earlier in the series. As with estimations, we need to remember that these are projections which can skew too low or even go too high. Even if these values don’t hit the mark, they are still useful and a valuable part of the process. It’s also important to note that over time these estimations will steadily improve, thereby making future estimations more realistic, meaningful, and most of all, impactful to your team.

Complexity

Complexity can been represented from multiple angles ranging from the number of systems or integrations, upstream or downstream dependencies, to engaging multiple teams or even environments (dev versus prod). Here is where we will start to analyze and interpret the data we’ve worked hard to obtain via the last two blogs. Items for consideration from said data gathering could include Steps, People, Approvals, Dependencies, and Locations & Environments, though Methods & Access as well as Change Management could potentially play a role as well.

There are a few different options at our disposal for the complexity scoring. One example is using a range of “Low-Medium-High” with Low rating involving only a single system or integration as well as limited amounts of other criteria. A Medium rating could contain mixed amounts of middle-of-the-road values, while reserving High for when workflow involves multiple systems, lots of moving pieces (integrations or services), people, dependencies, etc.

Another rating option is the Fibonacci scale commonly used with Agile Story Points. The Fibonacci scale is a sequence consisting of adding the two preceding numbers together starting with 0 and 1. An example of the sequence would be 0, 1, 2, 3, 5, 8, 13, 21, with lower numerical values associated with less complexity and higher values with larger, more complex items.

Choose an option that works best for you and your environment. However, we do want to be consistent in the type of scoring, so down the road we can refer back to previous examples.

New infrastructure at a remote branch location

• Complexity: High
  • Within this deployment, there will be a significant number of steps to be performed along with multiple people and processes, as well as dependencies. There is also a greater potential for risk as the production environment would be affected with the introduction of new routing changes taking place.

Migrating from SNMPv2 to v3

• Complexity: Medium
  • The previous request for new infrastructure as well as this request for SNMP migration have a single deployment frequency, however, the SNMP migration has noticeable reductions in other areas. Interpreting the data we gathered, there is a significant reduction in the overall number of steps to be performed and small reductions in the number of dependencies and type of work being performed on the change request (meaning it’s less risky). Taking these requirements into consideration, this request would be marked as “Medium”.

Create automation for the provisioning of Data Center access ports

• Complexity: Low
  • As we start to review the last use case, we see the case as a smaller number of steps, people, approvals, and dependencies. It’s also worth noting that change management allows for a standard approval window for implementing the changes.

Work Effort/Duration

In terms of work effort or duration, we will focus the estimation around the amount of work our team will be on point to represent or work. Sometimes large-scale projects can include multiple teams and timelines that could have longer overall project timelines. However, we want to focus solely on the delivery from our team.

For the work effort, we’ll use a different type of estimation from complexity to offer a more unique value. We’ll categorize this work effort using a common yet familiar methodology by using a T-shirt size.

New infrastructure at a remote branch location

• Work Effort: Large
  • A new build-out may have a series of planning and estimation prior to approvals as part of a procurement process. Along with lead times for receiving new equipment there is a potential for timeline dependencies outside of our teams’ control, such as a new construction project. For these reasons, as well as the large number of staging and preparation steps, we will estimate this as a Large effort.

Migrating from SNMPv2 to v3

• Work Effort: Medium
  • The SNMP migration would require a couple teams working together as part of the overall effort. Our team would support creating and testing the new network configurations in lab. When ready for the migration, our team would deploy the new configuration, engage the monitoring team for their updates, and work with the security team for their validation sign-off.

Create automation for the provisioning of Data Center access ports

• Work Effort: Small
  • As we saw in the previous example, the automation for provisioning ports has a lower level of complexity. With narrower scope, the development and testing work for this new automated workflow could be performed in a smaller window of time as our team has created similar workflows in the past. Therefore, this work could performed in 3 to 6 months.

Putting It All Together

We’ve now completed the gathering of requirements as well as estimations, so we can establish where our next commitments or sprints will be directed. We did not include escalations as part of these efforts, as we wanted to maintain a steady state in the evaluations.

From the analysis of the three examples above for potential placement within our backlog of work, we would be working towards offerings with a higher return in value while spending a lower amount of effort.

As we look for potential placement within our backlog of work, we want to lean towards offerings with a higher return in value while having to spend a lower amount of effort. From the analysis of the three examples above, our backlog would be the following:

• Create automation for the provisioning of Data Center access ports
• Migrating from SNMPv2 to v3
• New infrastructure at a remote branch location

The creation of automation for provisioning is a request that is smaller in nature yet having a fixed parameter, allowing for a quicker delivery (lower effort) as well as reducing repeatable recurring manual workload and future use cases (high rate of return).

The SNMP migration would be second, as there is a defined amount of volume in the number of devices impacted. As this is a one-time remediation, there is a lower rate of return associated with the request; however, value of the new SNMPv3 would be applied to future devices via golden configuration updates.

The new infrastructure at a remote branch provides our business staff a higher value, though the longer lead times and procurement timelines lead to a much larger amount of effort. This last use case presents a future opportunity whereby the larger project could be broken down into smaller standardized sub-components. These smaller components could potentially lead to smaller efforts with larger rates of return.

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

Work. The never-ending laundry list of ‘To-Do’ items that greets us every day when we log on to our computer. Tasks seem to multiply in request queues faster than a soaking wet gremlin, yet they seem to eclipse the small delivery of items being completed.

We all have requests sitting in our work queues aging from days to weeks or months from their submission date. So how do we begin to make sense on which items can or should be done now? Is it better to tackle the quick wins by going after the low-hanging fruit? Or is it better to go after the larger corporate wins that may be more time-consuming but have the potential for a great impact? More importantly, how would we address unplanned activities (aka fire drills) or ever find the time to get to those bothersome back burner activities? These are some of the questions we will uncover as part of this blog series on work intake.

What Is Work Intake?

Work intake is a way of gathering requirement details to begin organizing, classifying, and prioritizing work efforts to truly understand what a customer is requesting. Over time, employing work intake strategies will help your customers formulate what they’re really asking for in a more consistent manner that will provide valuable downstream details to the engineers doing the requested work.

By employing work intake, we are gathering details, estimations, and business requirements to provide an effective strategy for making positive decisions and outcomes for the organization. Be careful, though, as an abundance of data or asking too many questions does not always translate to more effective results. Causal inference of the data becomes more valuable when it improves our understanding or outcomes. Therefore, using the right questions will help lead us to better decisions.

Where to Begin?

In order to see the complete picture from a request, we need to lay out all of the pieces of the puzzle. While no two requests are the same in nature, the types of questions to be asked of the customer should be in the same consistent and methodical process.

Throughout the series, we’ll use three separate and unique request examples to provide context around each work intake topic. These request examples, which are common requests across network services organizations, are:

• Upgrading new infrastructure at a remote branch location
• Migrating from SNMPv2 to SNMPv3
• Automated provisioning of Data Center access ports

Starting Point

Critical details from the requester are typically fresh in a user’s mind as they are submitting a request. Employing a classroom technique called anchor charts with the 5 W’s + H of Who, What, When, Where, Why, How will help requesters visualize their request as well as lead to key insights which will be explored more in our next blog.

Taking the original use cases listed earlier, and applying the 5 W’s + H, would begin to provide necessary content to understand the requester’s ask. Here are some examples:

Upgrading new infrastructure at a remote branch location

• Who: Remote branch users
• What: Site refresh replacing legacy firewall, switch, and AP
• When: October 31st
• Where: Burbank remote location
• Why: Legacy equipment is EoL (end of life) and is no longer supported
• How: Replacement to include updates in SoT (Source of Truth) and monitoring

Migrating from SNMPv2 to v3

• Who: Monitoring Team
• What: Remediate 100+ network devices
• When: Risk closure by Nov. 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

Automate provisioning of Data Center access ports

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

Does the 5 W’s + H anchor chart listed above provide valuable information to these use cases? Yes, it most certainly does. However, there are still meaningful questions and analysis that need to be understood in order to produce tangible artifacts for the engineering teams to process these requests. We’ll continue to delve deeper into this work intake analysis in future blogs, so stay tuned.