All too often we engineers end up blindly actioning tasks without questioning the true requirements driving the request.  Even if you are ‘efficient’ at deployment, doing the wrong task well is not ‘effectiveness’.
Picture the scene when a project manager walks into your workspace.  “Hey junior-engineer-I’ve-never-seen-before, I need to you to install a 3750E-48TS in the Phoenix branch office. It’s a straighforward task, so I expect it complete by Friday.”

This sounds straightforward, but the experienced engineer will tell you that such tasks are rarely straightforward. When something seems too good to be true, it usually is.

The solution to an unstated requirement

As always, we need to get very specific about the terms we use.  In the above example, you’ve been given a ‘task request’, not a ‘requirement’.  It is your job as an engineer to translate high-level customer requirements into detailed designs, bills-of-materials, change plans etc.  Hardware selection doesn’t happen until after you assess the requirements, examine the current network and standards and propose a design.
When the request is very specific, you can fall into the ‘authority trap’. You deliver what they asked for, but it’s not what they wanted. Then the conversation sounds like this,  “But…. you seemed so confident and specific. I thought you knew what you were asking for!” You can blame the customer all you like, but you’re the doofus here. This often happens if you are a new guy and the customer has been through a similar process before. It’s hard to question an assertive personality. The project manager in this example is trying to reduce time to deliver (and your ability to ask for design time), by providing a pre-packaged pre-simplified solution.
A solution is great, but what was the requirement again?

Assume Nothing and push for requirements

I don’t care what solution was designed by another engineer last year, you shouldn’t blindly borrow his or her solution. It is extremely rare for any two projects to look alike, and even then the passage of time changes things. You need to gather true network requirements for every single solution you deliver. Period. Your job is to find out what is required and more importantly, why it is required. I would ask to the requestor the following question.
What are trying to achieve? – This may seem fluffy, but it is quite useful. Especially if you follow up with the 5-Whys. You would be amazed how many new solutions come to light when you start with this ‘ultimate question’.
In this example you could find out that:

• That the PM needs GigE and GigE / PoE ports for new kiosks and phones in the branch office. This was the same requirement they had last year.
• That a switch was needed last time because there was no free GigE ports in that branch IDF stack last year.  PoE ports were also required last year, but were delivered using pre-existing capacity.
• That currently there are plenty of GigE ports and no PoE ports free.
• That the C3750E-48TS was the right choice last time but is a terrible solution to the current requirement. (and has subsequently gone end-of-sale!).

Sherpa Summary

• Don’t blindly accept task requests without context
• You’ll need a keen eye to spot task these. These are ‘pre-engineered solutions’ which are dressed-up as ‘requirements’.
• When this happens you need use the ‘ultimate question’ to peel back the pseudo-engineering, seek the true requirements and engineer the best solution.
• Be effective by choosing the right tasks, them complete them efficiently.