· Waheed Zarif · program-management · 4 min read
What to Consider in a Pre-deployment Field Inspection Survey
A field inspection that misses something isn't a failure. A program with no way to capture what the next crew finds in the field — that's the failure.
Late one fall I traveled with a colleague to survey and characterize a large sample of field sites in order to create a package of environmental upgrades for military housing. The upgrade package included products across filtration, humidity control, and lighting technologies. The goal was to specify a package compatible with 80+ field typologies so that it could be deployed across thousands of sites without surveying each one of them.
We documented site conditions and identified the product package. During the survey, we met many customers and everyone we met asked the same two questions: what is this program, and what does it mean for me. We had an official answer, which is something to the effect of “research-based solutions for healthier living environments”. While this is accurate, I learned that the useful answer has to be more specific to the customer’s needs and wants. The customers want to know what they get, what it does, what are the benefits, and what they are responsible for. The person that is carrying out the field survey is the only representative of the program that the customer will ever meet. If that person can’t explain the benefits and upkeep in plain language, customer satisfaction, adoption, and perception problems start on day one. Being able to effectively articulate the program is not a soft skill bolted onto the field survey.
The package specification that we generated has since gone into roughly 1,500+ homes. Somewhere in that rollout, an install crew found an electrical configuration issue that made the installation of one of our standard products impossible. During the field survey, we assumed a standard electrical configuration at each site, which turned out to be wrong. Another team sourced a compatible product, but the logistical headache taught me an important lesson.
No field inspection catches everything. The question that actually matters is what happens when someone makes a field discovery. In a large scale program, the answer is a structural framework to capture field knowledge. Installation and service crew turn over quickly. Every person that leaves takes site knowledge out the door, and the next crew rediscovers the problem.
I have been putting that structure in place in the form of a comprehensive knowledge base which serves different user profiles in the language that they understand. For example, a program manager talking to a customer may need a program overview, while crew members want to know how to solve an edge case or how to install, service, and troubleshoot products. There is also a third audience to account for: the internal teams that review each publication. Legal cares about claims, R&D wants to check cited data, and Marketing checks the client-facing collateral against their standards. A good share of these publications are read by people outside the company, and these checks and balances are critical. Therefore, writing one paragraph that satisfies a program manager, a crew-member, a lawyer, and scientist, and a brand team is a specific skill that I didn’t have before this.
Regarding the survey itself, at a review session, I suggested adding another field for electrical configuration and updating the inspection SOP. Now that I reflect on it, I don’t think that’s quite right. For context, a significant number of data that we captured during our field inspection never fed a decision. At the time, I would’ve said cut every field that doesn’t change a package specification. But now I believe a pre-deployment inspection/survey has two two jobs: a) it has to specify the current solution set across every typology, b) to find the next problem worth solving because it is the only time you will ever have a trained in the field, which makes it the cheapest chance to discover new opportunities. Now, I am against ruthless minimalism. I think it is so important to know which of these two jobs each survey field is doing and be honest when a survey data does neither.
None of this changes regardless of whether it is a military housing deployment, a substation, forward site, or a plant floor. The same cadence applies: characterize a sample, and specify a product/service package from it that can be deployed at scale. Surely, you will miss something that the field crew or technicians will find, and your crew will turn over faster than documentations are updated. The deliverable of any pre-deployment site inspection is not the solution package, it is a program that keeps getting the deployment right every time; even after people who designed it have moved on. This means somebody has to own the path from what one crew learns at a deployment site to what everybody knows at the next one. This tends to be no-ones job, since it is not any single department. I’ve spent most of my career picking it up.
