Is Your Real Time Too Real?

How to Walk the Path of Business Outcomes

--

by Mike Sturm

My Journey Into Software Started With One Call

Five years ago, I received a phone call from a good friend of mine. At that time, he was in charge of real time data solutions for the major oilfield services company where we both worked. He wanted me to work for him as product champion for our company’s main real time data delivery system.

Up to that point, my career had been entirely composed of roles in operations and sales. Other than being an end user, I knew little about how software was developed. My friend explained that the primary role of the product champion was to ensure that the software being developed solved defined business problems.

As someone who had significant experience with our real time system, as an end user, and who also had a fairly broad understanding of the oilfield business; he told me that he thought I would be an excellent fit for the role. After taking a few days to think about it, I took the job, convinced I was going to fix the system.

Users Are Right, But Not Necessarily Completely

Fast forward to today, I’ve now been the business owner for several products and my time in the software world has been one of the most challenging experiences I’ve had in my 25 year career. In that time, I like to think I’ve learned to bridge the gap between business use cases and development user stories.

One of the primary things I’ve learned is that business end users tend to be completely focused on the what of software and less on the why.

This is great for the development team, as clearly defined ‘do this’ user stories make for straight forward implementation. I spent my first year as product champion capturing these types of use cases from the business and translating them into detailed user stories. I noticed that more often than not, the new must have features being released were not having the expected business impact. As I tried to determine why we were not achieving the business value, I realized several things.

  1. When asked how the software could be better, business end users tend to ask for a better version of their current process. They rarely ask for a different overall workflow; rather, they focus on removing specific friction points in the current software solution.
  2. The end users viewed the software as a standalone step in the larger workflow. They would propose innovative changes to the software, but define the benefits in metrics specifically related to the software product (half the latency, twice the data points, etc.) instead of how it improved the full workflow.

Learning To Dig For the Real Value

These two points were driven home in a very direct way after one specific engagement to enhance the real time process for one of the business units. The business stakeholder had proposed a significant change to their workflow in order to enable an expert user to monitor the process and respond to events as quickly as three seconds after they happened.

The stakeholder’s team provided challenging technical requirements around transmission latency, data volumes, and the user interface, insisting that the workflow required the absolute minimum latency. I personally spent a significant amount of time with the team and brought in technical resources from the development team for feasibility and effort estimation, totaling approximately four man-months of time evaluating their proposed workflow and requirements.

During the discussions, we had been completely focused on reducing the time for the expert in the office to get the data and identify a change as the primary business goal. As we started to finalize the scope and cost estimate for the new workflow, I asked what I thought was a simple question: How will the expert’s feedback get sent back to the guys at the facility? The answer involved phone calls and other manual processes which could take anywhere from one to ten minutes.

After a few more questions, it became obvious that the changes in the software would actually have little to no impact on the actual full workflow cycle time.

Even if we reduced the monitoring process latency to zero, the effective time to close the loop back to the person actually executing the process would be unchanged. I realized that, from the very beginning, I had been asking the right people the wrong questions. By allowing the business users to set the scope and focus of the initial discussions, we had not started from the most fundamental question: Why are we undertaking this work?

I could not clearly articulate a measurable business impact to be realized from achieving the technical improvements.

How To Be a Leader and Not an Implementer

This experience changed my basic philosophy on how I interacted with the business and communicated the objectives back to the development teams. I learned to focus initial discussions on the “why” of a project and not on the “how’ and to raise the conversation from specific technical changes to what made those changes worth doing.

Along the way, I’ve learned that defining the actual business value of a desired outcome is much more difficult than it looks. Many people can easily tell you what doing a good job looks like, but find it harder to quantify how doing a better job leads to better outcomes.

I’ve also learned that even when the business value is well understood, delivering that value requires a joint effort between the business and the software team. End user requirements evolve with the product, so getting feedback and testing for value on a regular basis with the business is critical to achieving superior outcomes.

At Hashmap, we focus on generating real business outcomes. We understand that data, even the same data, is different for every industry and that having clearly defined business objectives are critical to delivering the expected value. From ingest to analysis, curation, utilization, and consumption — we can help you on this journey.

Feel free to share on other channels and be sure and keep up with all new content from Hashmap at https://medium.com/hashmapinc.

Mike Sturm is Director of Industrial Practice at Hashmap providing business guidance and operational expertise across industries with a group of innovative technologists and domain experts accelerating high value business outcomes for our customers. You can connect with Mike on LinkedIn and hear him periodically on the IoT on Tap podcast series.

--

--