The Hurdler
“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one we are willing to accept, one we are unwilling to postpone, and one we intend to win.”
--John F. Kennedy 5/25/1961
As technology becomes more complex across organizations, there is a greater need than ever for the role of Hurdlers within IT and Web Analytics. From the analyst that works across multiple database teams to make sure that newly implemented capabilities can capture and store the right data elements, to the project manger who builds a programmatic process for IT to design their applications to be quantifiable, Hurdlers are the ones that can get things done because they understand what the end result needs to be, and they challenge us to see through every step. They know that the faster our interconnected teams can figure out these steps, the faster we can execute the solution so we can know if our efforts have proven successful. Hurdlers take ownership and are not held back by org charts to get things done. And they communicate well.
Elements of an Effective Hurdler
• They quickly bottom out the issues in detail.
• They identify the requisite tasks and drive for results regardless of org structure.
• They communicate the value proposition across multiple levels, ensuring that what they’ve helped to change, sticks.
The Analyst as Hurdler
Diana is a Web Analyst who came from the IT development organization. Because of her background, she knows the back end system and how it collects data. One day, she received a request for some analysis on page traffic, but could not find any instance of the pages in our Web Analytics tool. Instead of reporting back to the customer that the pages simply could not be found, she let the customer know that we were looking into the request and would likely have to do some further work to get them what they needed. What she discovered was the application was writing an extremely long concatenated value into the query string, before being fed into the database. Further investigation uncovered that the field in the database was only one-fifth the size it needed to be. Worse yet, she discovered that the data was not even getting truncated, but it was getting dropped completely! A simple change to the database to increase the field size was required. Diana not only followed through on getting the cross-functional partner to task and fixing the database, but she also worked upstream to identify ways the application itself could be more efficient and not require so much data to be appended in the first place. Finally, her tenacity resulted in building a stronger relationship with the customer.
The Project Manager as Hurdler
Every week, there seems to be a new online application or capability that our team is asked to measure. These days, we are involved in the design and development process, so we usually know how to quantify these results. This wasn’t always the case. For us, we had to overcome a culture of “measurement adds too much scope, so reporting gets thrown out first”. It took the creation and adoption of a whole new project management concept called Design for Measurability to transcend this gap.
Brenda was a new Web Analyst that came to my team after many years in project management. We had already identified that a key issue for us was the lack of our ability to measure the capabilities that were being created—specifically, there was a lack of precisely instrumented page names and query string parameters—which hampered our ability to do analysis about specific online behaviors. Frustrated product owners could not tell if the new capability was working, and the analytics team could not get the attention of developers since the measurement requirements were now adding "scope". Brenda started with the issue (capability exists, but no data to know how we’re doing) and worked backwards – What kind of business questions were we trying to answer? What was limiting us from measuring? What types of people and technologies would need to be brought together to solve this? If asynchronous data was the issue, what business events would need to be created and captured in order to understand the desired behavior?
After she bottomed out the issues, she worked with the technology architects to pull together our internal standards for coding query string parameters, page names, AJAX, Flash, and other forms of data calls that result in an activity that we might want to measure for a business purpose. She then packaged this into a type of “umbrella” document and incorporated this as a mandatory step in the first phase for all project kickoffs. She then led a massive communication effort to sell the process, not taking for granted that the existence of the new process itself would be sufficient for adoption. Which brings me to my final point…
Communication – Visio alone won’t make a process stick
My team resides in what I refer to as a “process heavy” organization. And while many processes do serve their purpose and provide consistency and quality, there are enough examples otherwise that the word “process” is sometimes viewed as a bad word, perceived as something that adds a lot of overhead with little or no value added. So indeed, adding yet another process—even for the best of reasons—was a challenge. The Hurdler realizes they must do more than create a Visio diagram for a process to take hold, which means that any good Hurdler must also be a good communicator. In Diana’s case, it was listing out the tasks required from key individuals across a disparate technology organization, then holding them all to task and giving frequent, group-wide updates. For Brenda, this took the form of copious meetings across all levels – from one-on-ones with senior management, to project requirements auditors, to road shows with project management and development teams. In Brenda's case, she added a separate value proposition just for the development teams, pitching the process as a way they could know how much their new capability was contributing to the organization.
In short, Hurdlers are successful because they understand exactly what their hurdles are, and they adjust their approach, speed, and intensity accordingly to overcome each one. And just like the physical athlete, they do it in such a way that they still maintain their forward momentum after each successful completion.
Concepts in this series are based on the book, The Ten Faces of Innovation, by Tom Kelley, 2007.
Comments