Helping Pipeliners Love Technology
Though every technology innovation is inherently unique, there are patterns in the innovation process. After many lessons learned in taking on the work of technology innovation for several years, we’ve distilled a 10-step process of getting from concept to meaningful product. I’ll reference work with Mobile Inspection FormsTM to give practical examples.
1. Find an Unmet Need
The closer you are to a problem, the closer you are to its solution. The world is full of unmet and hidden needs with people tolerating pain, unaware of a better way. Solutions do not come easily, and often symptoms obfuscate the core problem. After handling hundreds of thousands of inspection reports, PCS sensed an unmet need to streamline the process of inspection reporting as regulatory requirements were putting pressure on existing processes and raising the stakes. In speaking firsthand to numerous inspectors and experiencing the limits of existing processes ourselves, we validated the need. We were then able to study the core pain points in existing tools and processes.
2. Study the Effects of a Solution
Often when you solve one problem, you create several more. Did you only solve a symptom? Was there a deeper need that makes the solution unwelcome? Needs are not isolated. They are deeply connected with other problems that are being solved with an immense amount of compensation. As soon as change begins to occur and old systems are uprooted, it pays to have validated every assumption possible and understand the effects of the solution. Great innovators such as Sakichi Toyoda provide a useful framework for root cause analysis: ask “why” 5 times, and the answer to the 5th “why” usually narrows in on the root cause. The first four answers give insight to the context and symptoms related to the problem. The inspection reporting process had a lot of points for optimization, but we had to be certain of why existing steps in the process existed and what changing them would do. For Mobile Inspection FormsTM, we had to validate whether we actually decreased the time spent by inspectors completing reports and whether those reports were more accurate because we eliminated common errors like improperly formatted station numbers, incorrectly naming the report, saving over a previous report, etc. These things would indicate to us if the effects of technology were beneficial. A streamlined process meant huge time savings which inspectors loved, but also automated a lot of what office managers typically did. We learned assumptions and effects we had not considered the hard way several times before getting it right.
3. Gather Requirements from Stakeholders
A well-defined problem in context drives initial technical requirements. Now comes the hard work of unearthing hidden expectations users have for technology. What do they expect when they use a technology? What about it could make their life easier? Harder? What worries them about technology? Here we talked to some veteran inspectors and figured out what they liked and did not like about the current Excel solutions. Basic interaction with UI/UX prototypes really helps users articulate what they expect and builds buy-in so they can anticipate what is coming. This will save time later.
4. Design & Plan with all Stakeholders
Many technologies start here with a vague concept of a problem and a hubris about a solution: a recipe for low impact. Estimate what’s required to really solve a well-defined problem with technical experts, business advocates, and people proximate to the problem in the room. It took us several full iterations before we added schedules, budgets, and a seasoned inspector and business advocate to the table to help validate we were on the right course at every step. Building the right high-functioning team is very important. Brutal honesty and conservative estimates are critical here. If the problem is not real or you don’t have the minimum resources needed to solve it, save everyone the time and go look for another problem that you are better positioned to solve.
5. Build and Deliver Often Using Clear Requirements
Here the engineers do their magic. Clear requirements and expectations paired with a challenge to solve a real problem provides the environment for real innovation to flourish to fruition. Technology is built one functional piece at a time with a lot of risk and failure between each step, so having exact parameters facilitates clear communication and language around the inherent risks of innovation. During our development of Mobile Inspection FormsTM, the initial development deliverables and reviews were too far apart which sent the development team off on their own building with minimal communication far too much. Clearer roles and over-communication solved this issue eventually for us. Break development into smaller functional units with clear requirements and communicate often. When a feature will take a lot of effort to implement and is not mission critical it is best to build it in smaller pieces and get feedback than to spend a lot of time building it and then re-building it.
6. Feedback, Feedback, Feedback
Steve Jobs taught us that people don’t know what they want until you show them. This also goes for what they don’t want. You need to make space for people to say what they don’t like about what you show them and observe where they get confused or frustrated. As significant parts of Mobile Inspection FormsTM were built out, we had completely unbiased people with field experience test the solution and give feedback from a field perspective. No matter how much time is spent trying to understand the problem at the start and gather all of the requirements of the ideal technology solution the reality is that you will inevitably receive more detailed and rich information after someone tries what you built. Shorter feedback cycles help get earlier access to this rich information. This fact is certainly true for pipeline inspectors, and we made sure that all feedback is considered and factors in to requirements for the next round of development.
7. Iterate
Iteration is fundamental to innovation. Sorry if the title made you really think there are 10 linear steps to building an innovative technology: that’s just not true. Every step builds on the previous one, and if you move on too early to the next one, you’ll tumble back to whatever step missed the due diligence mark. Sometimes it’s all the way back to Step 1 and you only learned what not to do. If you executed the first 4 steps well, though, it is healthy to repeat Steps 5 and 6 as many times as you can afford and as fast as you can. If in doubt, iterate! Undo the missteps, bring better definition around the contextual needs you didn’t know existed before you started. Test everything. We adopted an Agile product development approach called Scrum to structure these iterations. This communication and structure provided great visibility across the team’s resources and allowed everyone to assist on tasks that took longer than estimated. It is important to focus on what is most important to users first so that the most important elements are in place if you run in to time or budget constraints. You can iterate indefinitely, but the feedback from the people using your technology will indicate when it is ready.
8. Tell Them Why They’ll Love It
You’ve created something exceptional, and people need to know why it is exceptional and that it exists to solve a need that you understand deeply. Innovative technology opens a whole new world of possibility, so tell people about that world! Show them what has been made and let them try it out. If they consistently get excited too, and articulate the value of the solution to you without prompting, congratulations. If not, then you are back at steps 1, 2, or 3. Don’t lose heart, though: this happens all the time. We did full pilot implementations of our solution three times before getting the thumbs up from inspectors and project managers. Now that we have something that really works we are telling the world about Mobile Inspection FormsTM and how it revolutionizes that manner in which pipeliners collect information regarding the quality and progress of midstream construction.
9. Launch in Partnership with Key Stakeholders
The key stakeholders actually using and depending on your technology will give you the most valuable information that can then be built into future versions of the technology. A technology launch should proactively engage these key stakeholders throughout the deployment process, and we found it best to incorporate certain key stakeholders directly onto the deployment team. Thinking of a technology launch as truly a partnership between the technology consultant and key stakeholders is vital to overall success. When deploying Mobile Inspection FormsTM, we develop a specific strategy for each project ranging from online training through field technicians capable of simultaneously serving as a pipeline inspector and providing on-site Tier 1 support each day. We listen to the needs of the inspectors and project managers and adapt each deployment to help them succeed. Sometimes that means customizing the processes around their requests or accelerating application updates in order to roll out features they require.
10. Support with Empathy
Nothing is flawless. There are holes in every technology, and users are very good at exposing them. After all the effort to build an amazing product, one might get discouraged that what you think is a small problem appears massive and emotional to someone that cannot do their job because it exists. Empathy is key in support. You must relate to the individual, then work to fully understand their problem, take responsibility for any gaps in the product, and have a process that makes sure every issue is assessed and resolved as quickly as possible. Over time we learned that with pipeline inspectors it was most effective to have people that could empathize with their situation in the field, so we sent our own inspectors to the field to work alongside them. PCS’s Support Team is comprised of professionals who know what a jeep is, what MTR stands for and the difference between a tie-in and mainline weld as well as why it matters. We work hard to empathize with inspectors, understand their problems and perspective and think how we can best solve it for them quickly given the time-sensitive nature of field work. If you really listen, they might tip you off on another problem that could drive your next innovative technology.
The work of building an innovative technology is never complete. You must constantly iterate, improve, and listen closely to your key stakeholders. Innovation is hard work, but it’s the path to real impact.
