Introduction to Work Intake – Part 1

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.