Skip to main content

The Human Element in Technical Projects: Stay Sharp Episode 37

By June 25, 2024No Comments

In Episode 37 of Razorleaf’s Stay Sharp podcast, The People Factor in Technology Projects, co-hosts Jen Ferello and Jonathan Scott discuss why people are the most critical, overlooked, and unpredictable part of any technology implementation. They dig into why projects really aren’t just technology problems, the many mistakes organizations make about involving people or dealing with them in a project, and why you should absolutely start every project with the people who use the end result in mind.

It’s Always “The People Are the Problem”

Jen and Jonathan have touched on the challenges of working with people in many different Stay Sharp podcasts. Whether you’re dealing with PLM, PDM, MES, or any other kind of project, you’ll usually find both hosts returning to the idea that “the people are the problem.” Jen starts by posing the fundamental question: Why is that? “Why is that such a big deal? What about people?” Jonathan responds by pointing out that part of the reason is that even though the age-old framework for managing change is “people, process, technology” or PPT, people are often simply not considered. He says, “It’s always going to come back around to, but are people going to use it? will we adopt it? You frame it as a technical problem, but then at the end of the day you realize that it’s not really a technical problem if nobody does anything with it.”

Jen suggests another part of the resistance to involving people is because they’re unpredictable. Engineers—and she notes she is one, herself—“would all like to … reduce the number of variables to make it easier to solve the problem. That’s what we do. The people are hard to understand, to predict, to explain, to control, all of those things.” Jonathan agrees, noting that while there’s merit to starting a project by eliminating some of the variables, making some assumptions, and simplifying, “Where it gets hard is remembering to include the people back in the project.”

The People Mistakes We Make

Jonathan concedes that project teams don’t consider people until the end of a project because at base, project is pretty linear: assemble a technical team, solve the problem, roll it out. But one of the planning errors we make is forgetting that people don’t change quickly. He notes that of all the projects he’s seen in his career, those that made people the focus only at the end of the project have succeeded less than half the time. Maybe even much less. Those projects weren’t always a failure overall, because many retrenched and succeeded in subsequent attempts, but they certainly failed with that approach. Or as Jen puts it, “They succeeded more slowly.”

Jonathan points out that people have one of three attitudes in regard to a technology project: positive, negative, or neutral. Mostly, they’re going to be on board and engaged or resistant. The challenge is minimizing the resistance. “Your chances of getting somebody on board, excited, energetic, on the positive side of that are greatly increased by bringing the idea, the notion of change, to them, rather than waiting until they find out about it.” They need context, they need to understand the problem and the decision that was made that resulted in the solution.

What’s critical is giving people the opportunity to speak up, because even if their opinion doesn’t impact the outcome of the project, they feel like part of the solution. It also ensures ongoing communication. “At least you’re still having dialog,” Jonathan says, “because you’re aware of it, you asked for their input early. Even if you didn’t take it, there’s a conversation that can happen, which is better than the ‘I don’t know what they’re doing over there, but I’m going to talk behind their backs because I think it’s going to mess me up. And I feel negative and I’m getting cemented in my negative views about it.’”

Involving people at any and every stage of a project is also important because without their input, your project might be doing the wrong work. Jonathan shares an example of a project to create an automated tool that changed when someone actually sat down with the people who would use the tool. “I was off solving the wrong problem,” Jonathan says. “I thought we needed an enterprise workflow when all we needed was a CAD viewer.” Ultimately, you need to consider the people factor throughout a project because people are doing all of the parts of the solution.

Learn More About Dealing with People in Your Technology Projects

The full podcast episode offers more details including why training shouldn’t be the only way you engage with people on a project, what psychological safety has to do with technical projects, and how to gently guide leadership to the realization that they need to think about organizational change management (OCM).

Follow ‘Stay Sharp with Razorleaf’ on:

Close Menu