Contextual Inquiries: The Foundation for Digital Transformation
Innovation, much like any journey, needs context. Understanding the problem space, people, technology, and processes is the foundation for successful digital transformation.
The Problem with the Problem Space
Initially, software development worked entirely as a waterfall. Projects, broken into linear sequential phases, each dependent on the one before. This required a lot of time upfront, investigating, and documenting the problem space.
The life cycle, from build, through test, to deployment, would take several months or even years. In the meantime, the work context or problem domain had shifted. So, despite a sizable upfront investment, when implementation took place, there were no guarantees that it would answer the needs of the business.
Waterfall Approach
Waterfall Approach started in 1970 by Dr. Winston Royce with the “Waterfall Model”, and it is the traditional approach to software development. Some version is still being used in many enterprises today.
Waterfall Lifecycle Pros
Easy to understand, use and clearly fixed
Production definition is stable, understood and static
Best for short and simple projects
Finished product is close to expectations
Waterfall Lifecycle Cons
No working software is delivered until the end of lifecycle (introduces high risk with deployment team)
Poor model for long and ongoing projects
Difficult to measure progress within stages
Cannot accommodate changing requirements. A big change mid-stream can kill the project.
Integration is done as a ”big-bang” and if requirements, design or dev is wrong, the whole project may need to start over
This is why the industry evolved towards Agile development. Yet while its use is widespread and underpinned by robust principles, it is regularly misinterpreted and erroneously applied. Often Agile is seen as a quick build and deployment, and nothing more. Once it’s deployed, stakeholders watch, from a safe distance, to see what sticks, or is functionally viable. Somehow, skipping contextual inquiries, engineering based on assumptions about the problem space, and not defining any sort of strategy or roadmap became the norm.
Common Agile Approach
Agile Approach started in 2001 with “The Agile Manifesto”. It is the contemporary standard for software development, especially for B2C applications.
Agile Lifecycle Pros
A very realistic approach and representative of the nature of software development
Promotes teamwork and cross-training
Suitable for changing and adjusting requirements
Delivers early, partial working solutions by emphasizing output over documentation
Agile Lifecycle Cons
“Planning” can become requirements definition based on assumptions about end user by non-end users. True planning may be skipped and teams may adopt a “figure it out as you go” mentality
Hard to manage complex dependencies from undefined scope
Requires Agile Leader to manage production
Minimal documentation produced
Hard to transfer knowledge to new team members, and vision of what is being delivered may change
Many enterprise budgets are not structured to fund agile projects
This approach ignores the fundamental need to investigate and understand the problem space – the context. It’s a high-risk approach. Indeed, with failure rates up to 90%, it is possible to waste an entire line of capital on a product version that is entirely wrong.
Over-exploring the problem space is a problem, and not exploring it is also a problem. Agile should mean agility, not lack of planning. The diagram below strikes the right balance between contextual inquiries (CI), user centered design, and rapid agile delivery.
Agile Approach Revised
Below shows a revised approach to agile development, illustrating how a brief contextual inquiry should be used to set strategy, and a flexible roadmap for all production. Subsequent builds can further investigate the problem space in a targeted fashion to validate assumptions, and de-risk investments.
The revised agile approach aims to install safeguards to de-risk uncertainty. The approach is compatible with business case development, contextual inquiries, design thinking, and the project planning needed for enterprise applications.
How Agile Should be Used
Should start with contextual inquires that provides input into setting IT strategy within a functional area.
Business strategy should be determined to set direction and goals. A roadmap should be built that implements and matures appropriate technologies to achieve the desired goals. Product iterations should incrementally move the business and organization closer to realizing those goals.
Tactical planning should occur to determine specifics about the iteration, not the product vision and direction.
Usability testing should follow design cycles to ensure interfaces are user friendly in the work context.
What Are Contextual Inquiries?
The solution is not a new one; after all, contextual inquiries have been around since the 1950s. They originated from psychology principles that emerged in the military during World War II. Contextual inquiry, born of engineering and user-centered design, focuses on understanding how the work gets done and the problem space. Through a mixture of observation and interviews with subject experts in their working environment, it is possible to understand what has become habitual and overlooked, and use that as the basis for designing effective experiences for any given work context. The challenge is finding balance -- not doing too much, or too little. This takes skill.
After all, it is crucial to build a picture of how work is performed today before figuring out how it can be improved tomorrow. Understanding interactions with other processes, technology, people, and the environment itself, dictates all design and transformation roadmaps. Teams need to know the work context today, to see how new technology can be slotted in tomorrow. The interface, for example, should be attractive and easy to use, the color palette be appropriate for the environment, and the navigational structure should logically mirror the flow of work. Technology should be selected to support and enhance existing work tasks, not create new ones.
Why Use Contextual Inquiries?
Contextual inquiries are the primary means by which user and customer-centricity are infused into products and services. They provide, in turn, the foundation for successful digital transformation. Performed successfully, they result in building the ideal future state user journey, accurate and complete workflow mapping, and a thorough understanding of the work context so that change can be planned, the right technologies can be identified, and organizational step-wise performance increases can be achieved. The digram below gives an example of how understanding the user journey today, enables teams to see the right technology investments for tomorrow.
How Do Contextual Inquiries Impact the Bottom Line?
In the early 2000s, HP’s customer center received an elevated volume of calls about laptops with broken hinges. Yet, engineers who had already performed countless physical stress tests using machines to open and close the laptops were confident the hinges would not fail--if used the way they had assumed.
When they sent in the user experience team to investigate, they found that many people left their laptops open on their desks all day. When they moved to a new location, they would pick them up by grabbing the corner of the screen and then carry it to wherever they were going. This was causing stress on the hinge at an unanticipated angle, causing them to break prematurely. Knowing this in advance would have saved money on stress tests and hinge design iterations.
Contextual inquiries capture such human behavior that affects the bottom line of organizations. It allows teams to see the real problems worth solving. After all, if you don’t understand the environment, the problem space, and the technology used, you are throwing away capital investment.
At a refinery, our client tasked us with optimizing the process of trucks arriving, weighing, and then unloading. Surprisingly a paper trail followed the whole process. The opportunity to digitize, improve the tracking, and remove paperwork existed and was obvious. We were, however, building on the work of a pre-existing team, and they had already launched one application for an element of the journey without a CI. With the CI, we were able to see what was left, and needs not yet met.
A crucial issue had been overlooked.
No one mentioned that when a truck showed up and spent more than the estimated time at the refinery, there was a significant additional cost. While the stakeholder stated that demurrage, as it is known, rarely happened. We observed, however, a stream of calls, emails, and invoices about additional delay costs throughout the day while conducting a CI.
Having witnessed the problem first-hand, we did some analysis and found that a fleet of refineries were spending a staggering $3 million a year on demurrage. Talking to the truck drivers, we found out why. Oil refineries are enormous; in Texas, they are like small cities with minimal signage, and it all looks the same. The truck drivers would arrive on time, but would get lost navigating in and out of the refinery.
By providing the truck drivers with better way-finding information, we could save the company $3 million a year.
Contextual Inquiries Can Transform Your Business
CI provides value by understanding what no one has noticed or recognized. It provides essential input to personas, understanding users' mindsets, and driving adoption beyond the technology.
But it needs the right team, in the right place, and providing the right amount. The team must be highly skilled and spend time on location. And they should be prepared to look wherever the work leads, to uncover the problems worth solving.
We spotted the demurrage problem because we paid attention to the calls and emails coming in. You become aware of what people are actually doing, rather than developing an abstract view of what people think they do.
Contextual inquiries are the fundamental, foundational way to transform your business; they require senior stakeholder buy-in and professional expertise to be executed.