This post is a version of a presentation that Kirsten Mann, our vice president of product experience, made at the Oracle Construction Technology Summit, held in early February in Melbourne, Australia. Given the popularity of that talk and the many requests for Kirsten’s materials, we decided to publish her story here.
OK, be honest: Have you ever used a piece of software, on your computer, on your phone, on your TV and thought, “What bunch of turkeys designed this? I could do better!”
You know you have.
Well, we in the software industry need to own that. We don’t always get things perfectly right. But of course, there’s a lot we do well. Considering the construction industry’s reputation as a late-comer to technology adoption, there are practices and processes that may offer value to our construction colleagues.
Much of the improvement we see in the software industry is prompted by a constant questioning of ourselves and our techniques.This introspection has resulted in dramatic improvements in software practices, especially over the past 10 years. These improvements revolve around a shift in how we think about people – both in how people work as well as how they use software to do that work.
We work hard to gather feedback and usage information to ensure our software does the most good for the most people. We talk to people working at every level – from subcontractors on site to senior leaders of the biggest companies in the world.
The software industry also codifies and shares best practices well. This includes professional meet-up groups discussing issues relating to their specific fields, tech conferences, and millions of words published on sites and spoken in podcasts outlining the latest approaches to building and managing software.
In our experience, this kind of introspection and sharing is not a typical characteristic of the construction and engineering industries. That’s something that needs to be overcome, because sharing and learning from one another will be critical to the continued evolution of the industry.
With that in mind, here are five common practices software developers use that help us focus on people – the people who build our products as well as the people who use them—that can positively impact the construction industry.
A successful product must serve a real need and solve a problem for someone. We carry out research with our customers and users in the field to understand what these problems are. This field observation is known as ethnographic research.
The key principle behind such research is understanding people’s problems – as well as observing how they solve them. This knowledge is critical to creating great software and experiences, because what people say they do is often completely different to what they actually do. We often tend to invent perfect processes in our heads that we rarely follow.
Once we have enough understanding of the problem our customers are trying to solve, we can design experiences that support those aims. You might think that ethnographic research in construction projects is solely for architects and designers during the planning and design phase. But bringing that level of understanding to a wider portion of your project community could have a profound impact.
Inspiring your project teams to think about the people they’re constructing the asset for might even be a potential differentiator for your business. There are people on your teams who understand how to make a building that not only improves efficiency, but also the experience of its users: the residents and workers who will spend large parts of their lives within its walls. These people can also bring ideas to the table and generate value.
There’s so much talk about data warehouses, data lakes, big data, data hacks, etc., it can feel overwhelming. It can also feel like either a resource or a burden – you’re apparently collecting terabytes of data (i.e., a lot!) and not making use of any of the information.
Data usage in the software industry helps us continuously improve our processes. For example, we analyze our application usage numbers to reveal exactly what people are doing with our products, including the various interactions and process flows they undertake to accomplish their tasks. Using this information alongside ethnographic research can paint an illuminating picture – combining the what (usage data patterns) with the why (observing people trying to solve problems).
We’re beginning to see smarter use of data across the industry. At the Oracle Construction and Engineering Innovation Lab, we’ve partnered with industry leaders like Bosch, Jovix, Reconstruct, and Triax who are doing some amazing things with data. Their projects and products are enabling productivity on job sites through real-time reporting and predictive analysis.
Real-time data collection and analysis must become the norm for construction teams to get up-to-date information on the jobsite and avoid poor decisions and delays caused by out-of-date project information. Instant visibility results in greater transparency across teams and improved productivity and project outcomes.
An experience map is a tool that helps you understand the experience a customer has with your product or service. It tracks a person’s journey as they attempt to achieve a goal. It shows the interactions customers have during the end-to-end experience with your product and highlights how they feel as they go. Yep, I said it: we’re dealing with EMOTIONS here.
I realize talking about emotions might be alienating for some, but when it comes to thinking about why and how people interact, understanding users’ emotions is critical. You can’t design great experiences without that understanding.
To create an experience map, you need to use the two techniques above: ethnographic research—which is conducted to understand people’s needs—and from usage data that reflects actual behaviour. These techniques ensure that maps accurately represent real experiences.
Compiling an experience map takes a fair bit of time and effort – not to mention a healthy dose of honesty. Tracking how a person interacts with your business requires speaking to people in pretty much every part of your organization. It can be challenging getting people to think beyond how they’re meant to do something and talking about how they actually do something. However, an experience map will help you understand how people use your product or service and quickly identify where improvements can be made.
Even in software development – an industry which is supposed to embrace a philosophy of openness to new ideas and different ways of thinking – we too can be constrained by group-think and indoctrinated views.
A “hackathon” is a creative, collaborative event where groups of 2-5 people within a business team up to solve a problem in a new and unexpected way. It’s a way of encouraging blue-sky thinking and lifting people out of the constraints of the everyday. New ideas can be explored without having to take risky bets.
A hackathon should be viewed as a step on a journey to solve a problem, or a training ground to open people up to exploring different ways of thinking. In fact, the construction industry has been using this practice for several years. For example, the global Architecture, Engineering and Construction (AEC) Hackathon has run events globally since 2013.
But hackathons can be run at smaller scale – like in your own office! Why not think about holding a hackathon – it might help you source innovations and push employees to explore creative alternatives in areas which otherwise might remain stagnant.
A retro, or retrospective, can be thought of as a “lessons-learned meeting.” These are almost ubiquitous in the software industry. Every couple of weeks, following—or as part of—the conclusion of an iteration or “sprint,” an agile software team takes an hour or so to assess how the iteration went. Its prime focus is on identifying improvement opportunities, but this conversation also recognizes successes and helps surface issues that may have a negative impact on the team down the track.
During the retro, the team reflects on what happened in the iteration, specifically:
• What worked and what the team wants to keep doing
• What didn’t work and what the team wants to change
• Ideas for improvement
• Actions the team is committing to for the next cycle
A retro is different from a “work in progress” meeting, or a project post-mortem. It’s not talking about the project specifically. Rather, it focuses on how the team is working together on the project. And because it deals with a relatively small, recent period of work, the information you get is fresh and topical. You may be able to implement improvements that contribute to continuous enhancements - not only on the current project, but also on future projects.
We intuitively know that implementing large improvement initiatives can be challenging. Retros allow for incremental improvements to be applied. And the fact that these improvements are driven by the team improves the chance of the change being adopted.
If you’ve been thinking about how to get your teams on construction or engineering projects to work more effectively together, a regular retro may be your answer.
Experimenting with and adopting techniques like these requires leaders to be open to creating environments and nurturing cultures where people are valued - both within your organisation as well as with the people for whom you’re building things. Bringing people to the forefront of what you’re creating can be a major change and help you improve the way you work with the whole project community. These techniques can result in building things better, faster, and more cost-effectively.
Explore innovation in action at the Oracle Construction and Engineering Innovation Lab, a simulated worksite with integrated technologies.