Why Projects Fail – Avoiding the Pitfalls with Jen Cohen

 

Why do projects fail? Often, projects fail because the company believes technology can solve all their problems. Jen Cohen, the Vice President of Core Engineering at Toyota Research Institute says that it’s always about the people who USE the technology. Jen talks with Elizabeth about how the most critical skill set for success is empathetic listening. You need to listen to people’s concerns and change accordingly. So if you want to know more about why projects fail and how you can avoid the pitfalls, this episode’s for you. Tune in!

—

Watch the episode here

Listen to the Podcast here

Why Projects Fail – Avoiding the Pitfalls with Jen Cohen

Change Management Lessons From An IT Executive

This is the show where we interview experts from around the world on subjects such as leadership, presentation skills, visibility and communication. My guest is Jennifer Cohen, known as Jen from the Toyota Research Institute. She is someone who makes technology work for business. Since the 1990s, she has helped companies like the Toyota Research Institute, Cisco and Birkenstock adopt solutions that drive meaningful business results as well as rebooting inefficient teams, establishing best practices, and streamlining processes. She has also helped several startups.

The thing I love about Jen is she cares as much about finding the right people as she does about technology, how to ease the fears of the users, to get people with new tools and systems. Although getting the technology and processes right is important, Jen believes that successfully making these changes comes down to one thing, the people.

Her motto is, “It’s always about the people and when we value each other and work together, we can accomplish amazing things.” She has spoken a lot about why do projects fail. It’s usually because people aren’t following the formula or they’re so excited about the technology, they forget about the people who are using the technology. Let’s go on to the interview with Jen Cohen.

—

Jen Cohen, welcome to the show.

Thank you for having me. I’m honored.

I’ve been waiting to have you here. I’m delighted to have you. Before we get started on why projects fail, let me ask you about your dream interview. If you could interview someone who is no longer around, who would it be? What would you ask them and who should be listening?

My dream interview is somebody who is around and that is Gene Kim, one of the authors of The Phoenix Project because he and his co-authors wrote a book as a novel about the things that weren’t working with IT and systems. It’s a phenomenal novel that puts into perspective the interconnectedness between our systems, people, the dangers of siloing and too much work in progress. I would interview him, although he is still living.

Who should be listening?

Formal training is crucial to success. Click To Tweet

A number of people should be listening. DevOps is not new at this point. People have heard it.

For our international readers and those who are not living in the tech world, what is DevOps?

When I started my career, programming would happen in one group. Deployment would happen in another group, supported the systems that the COVID run on would happen in another group. All of those groups weren’t exactly talking. There would be a lot of problems and we’ve all experienced some big service that’s gone down. Many times has that been because people weren’t talking and something wasn’t realized.

DevOps is a way of developing and deploying software in a way in which everyone’s involved in communicating and following a reasonable process. It’s not new anymore, but it can be spread to more than just systems. You can see this in many business processes where folks are siloed and not communicating and working together towards an end goal. Nominally working together, but not really working together. The DevOps was the beginning of us looking at it from that perspective and there are many more ways to look at that in many other areas.

We talk about all sorts of things, technical and non-technical, on this show. A lot of people who are non-IT people who are listening like me, I’m just ordinary user. I’ve heard you say that nobody wakes up in the morning saying, “I’m going to kill my project.” Why do so many projects fail?

I wish I could give you a one sentence answer to that, but I do have a formula for how not to have projects fail. There are a number of reasons and I’ll start with people seeing technology as shiny and being able to solve all their problems. I’ve been in technology my whole career. To the core, I love technology. I learned over time that it doesn’t solve all my problems. I know for instance, of a company that was in the footwear industry and the president of the company worked with some consultants and found this great, shiny new technology that was going to fix all of their problems.

This was their ERP, Enterprise Resource Planning system. Unfortunately, they didn’t hear the stakeholders saying, “This doesn’t manage orders by size.” Something that’s important for a shoe wear company, after they put it into production, they had to use Excel because they couldn’t order shoes. They didn’t know if they needed more size 6 or 12. That’s a critical thing when you’re a footwear company. In that case, the tech was shiny and they didn’t hear the people who had concerns.

We’ve all seen people get very excited about a shiny, new project and then they missed the key thing that you couldn’t order what size shoe you needed. Was this what you mean by getting romanced by technology or not getting romanced by technology?

 

It’s exactly what I mean. The tool looked like it could do all these amazing things. It could do amazing things, but those amazing things have to fit the business it’s going into. We’ve all had some technology that we’ve purchased, whether personally or professionally that we thought was going to solve a lot of problems and been let down. That’s where we get romanced by technology. The technology was cool, it just didn’t fit their needs. The other factor is that they weren’t hearing or considering who the stakeholders were. They had warnings but didn’t hear those warnings. Not being romanced by technology is the first part. There are other parts to why projects fail.

What should they have done instead?

First and foremost is defining stakeholders. We don’t do a great job in Corporate America of defining stakeholders.

For our international readers, who are the stakeholders?

Anybody who has got a stake in what’s happening, but the way it gets traditionally defined is as top people in departments who are involved in some way. Especially that project that I’m speaking of is that the stakeholders are everybody, including the daily users of the systems, IT people who support it and vendors who have to accept things from it.

The stakeholders are anybody who has been touched by the project. When we look at technology, we see the goals that we’re trying to achieve, but then we also see the big picture. Redefining stakeholders is anyone who is going to be touched by the project and hearing out their concerns and making sure they’re addressed is critical for projects to be successful.

You need a system that could do different things for different needs, which doesn’t fit on a brochure.

Looking into the systems is critical. One of the other things that are helpful when you do a project is to have a change agent and to use change management. One of the things that didn’t happen in that particular project was change management. Change management is a skillset. Now it’s being called change agility. I’m trying to keep up with the new-fangled words for it. It’s having somebody who can go in and listen to the concerns, figure out what their requirements are instead of skipping to the what, the cool, shiny tech. It’s the why and how.

No app can fix a broken team. Click To Tweet

Why do we need to replace this system? How are we going to do that in a way that meets all of our needs that lets us order shoes at the end of the day? Those are the kinds of things we need to ask ourselves those questions. We need to have empathetic change agents who are hearing the concerns on the line and the how and then we can settle on what cool technology can solve it for us.

Is a change agent someone who is already working in the company or do you have to hire someone to come in as a change agent?

It can be either, although it’s usually better if it comes from within the company. The key that I see is a lot of times, people who can get stuff done are put in the position of change agent without the change agent skills. To be honest, I’ve been in that role. I was in that role before I knew there was a skillset for it before I had the phenomenal GE change management course I was able to take. What I’ve seen too often as change agents who are folks who can get stuff done, come in and slam their fist and say, “You must change. You must do this new thing,” without hearing the concerns of the stakeholders on the why and how.

The key to a change agent isn’t where they come from, but rather the actual skillsets. The most important skillset is to listen to people’s concerns empathetically. We probably can’t answer or make everybody perfectly happy in a change. Change is hard, we know that. We can hear their concerns and make sure they’re covered. In the case of the footwear company, had IT and the daily users been heard, they wouldn’t have gone through such a disastrous software change that ended up in a buyout and four rounds of layoffs. It can have real-world consequences when we don’t hear those concerns.

Do you mean after they implemented the new technology, four rounds of layoffs and then they got bought out by somebody else?

Ninety-five percent of it was due to the fact that they couldn’t order or manage their supply chain because their system didn’t work to know what size shoes they needed.

There are so many examples of cool new things that don’t go right. How do we know we need change management skills and what should they be? If someone hasn’t done this before, how do you know you need to make a change and manage it?

When we’re looking at projects, the size of the project matters. If you’re doing a project in your department where you’re managing it and it affects 10 or 15 people, but they’re all aligned, maybe you don’t need that change management. When you’re looking at a system that spreads across the whole company, you’re going to need folks to help shepherd in that change. Change is hard. One of the things I always find so interesting is that change is the only constant, but as humans, myself included, resist it. It’s a dynamic that we know is there.

 

When we’re talking about a change that’s going to affect a number of people, that’s when we need to make sure we’re using our change management skills. The number one thing someone has to have is getting things done and listening. Formal training is important. I failed once at a project pretty hard because I didn’t have that training. Years later, after I saw qualified change agents, they had training, I realized some of the places I’d gone wrong. I’m an advocate for it. If you have somebody you think is good at this, get them on a one-week course.

In my life, it has made a huge difference to the projects I’ve been able to accomplish. That’s a big part of it. When we ask the questions, if we go right to the shiny technology or know we need to change, we have to ask the why and how questions. We have to think about what are the measures of success. The measures of success, if you’re changing a system, should be that you had what you had before. If not, more. It’s that why and how. What are the pain points? What do you need to change to make those better? Examining that before choosing the solution is critical.

Are there apps that can help us manage this thing? It’s got to be something you would download on your phone then do this.

There are project management tools you can use once you decide to make a change. There are some light tools that can be used in terms of asking ourselves questions. They can ask us what our measures of success are, have us reflect on them and converse about them as a team. An app can’t talk about the whys and hows for the business.

There are phenomenal apps to manage change and projects once we’ve decided to make those. I know whenever I say project management software, everybody says to me, “Jen, you mean Microsoft Project? I have to use Jira,” a commonly used tool to manage projects. They think of the project manager who is check boxing, but don’t understand the dependencies and items they’re managing.

If we get to the point where we’re ready to make the change, we do need solid, good, effective project management and that can make the difference between something succeeding and not. That’s also about visibility throughout the org. It’s an important thing, but there is no app that I’m aware of that will help you decide if you need to make the change. There are plenty of apps that help you manage them. Using them from a place of understanding, as opposed to check boxing is key.

What if you want to get an app to fix a problem, but the real problem is the team?

Early in my career, I was in IT at the time. The gift of IT is that you can see across the whole of Oregon. We had this project where we were going to implement it. It was going to improve collaboration, speed up communication and help us be generally more efficient. I could see something was wrong in all the meetings. I was a new manager at the time, all the department heads were in those meetings to defend their turf. They weren’t there to move the project forward. To be honest, we put that software on and it was a complete failure because we weren’t all coming at it from the right perspective.

Creating measures of success is critical to getting people where they need to be. Click To Tweet

Everybody was in it for themselves, not thinking about the effects for the company. No app can fix a broken team. The software couldn’t fix us. What did fix us was we had some serious work done as a management team. We worked with coaches to align our vision and mission. We had some staff changes. A year later, we had an IT steering committee. I will never forget this one department head said to another, “Your project can go first because it’s going to save us money and I’ll hold on mine.”

That had been unthinkable a year before. People have learned about what each other did and it mattered. We did re-implement that software the second time it went beautifully. Not without any challenges, because anytime you implement, there are challenges, but because everybody was on the same team and trying to move it forward, it was successful.

I keep thinking of the phrase that no matter where you are, the one thing every company has in common is people. How can you convince those who are romanced by the technology that they have to think about the human beings using the technology?

I’ve learned to talk about the business impact, retention and recruiting impact when I’m talking about a change and where there might be gaps. In the footwear example, the stakeholders were speaking up, but they weren’t being heard. Now I know to raise my hand and to directly talk about challenges that might occur. I’m in a position to do that. I’m not saying everybody has to take that particular method. For me to say, “This is the business impact.”

If I think about the shoe company and going to them and saying, “We’re not in the right position. We’re not going to be able to order shoes. This is the downward effect. That would have been good with the software.” I didn’t know at the time what was going on. I didn’t know why it was so broken, but thinking about that now software where everybody was defending their turf, I would have raised my hand. We would talk about, “What are we trying to get out of this? What is the why? What is the how?” I don’t think we were looking enough at it.

We want to be more efficient, but a lot of the issues were because of people not wanting to communicate and defend their turf. It’s about raising it in the right way, but talking about the business impact and always coming back to what does it mean to be successful. When somebody invests millions in a system, what does it mean to be successful? Those measures of success are critical. That’s how you get people to where they need to be.

I’ve heard you talk about what it means to be successful? What are the measures of success? What are we trying to do? I’ve heard you talk about following the formula. You’ve got a formula to help us have a project work. Mostly when projects fail, it tends to be expensive. The people who implemented aren’t necessarily the ones who pay, but except in the footwear company, I would assume that the C-level lost their jobs when they got bought out.

Things did not go well there. There is a formula for it. If you go and google technical projects or IT projects that fail, there are stats. I stopped looking when the stats got back to 1996. We’ve been tracking failures since 1996. Something like 50% of projects doesn’t get done on time on a budget, over 1/3 fail. Every one of your readers, if I asked them if they knew about failed technology implementation, could think of something, whether that is governmental or business. We know what’s out there. It’s a problem. There are a few keys to success. These are keys I’ve used for myself, other companies and I have shared with others.

 

First off is alignment. That’s alignment on who our stakeholders are and that we all understand the why and the how of what we’re trying to accomplish and we know how to measure our success. That alignment is the top thing. Next down from that is empathy when we hear concerns. It’s easy to see concerns as change resistance. I’m not going to say there is no change resistance out there. Listening with empathy, even if you can’t solve everyone’s problems, they’re going to be more on board and bought in to help something succeed if they feel heard than if they feel shut down.

Empathy is important for the team that’s implementing. If you’re not all in it together, it’s going to have problems. Next, we talked about having supported and skilled change agents is critical. To have supported and skilled change agents aren’t just on the change agents. It’s also on the sponsors of the projects to be involved, not just at the kickoff of the project or launch of the tool, but be involved and hearing stakeholders across the board throughout and making sure that change agent has what they need to be successful.

If the senior director says, “We’re going to do this. Jen, you’re responsible for making it happen,” they need to stay around.

It can’t be, “Call me in six months and tell me it’s done.” That’s not going to succeed. They need to be involved as a sponsor throughout the project. Finally, effective project management, not just check boxing, but using good project management tools and processes. There is a number, I subscribed to the agile approach, but there are other approaches. Having one and following it, not from the perspective of check boxing, but from how this impacts the project, what are my dependencies, measuring that success as we iterate and move along.

Those are the keys to successful implementations. I’ll be honest with you. I know this formula and I’m not going to tell you I haven’t skipped steps. I have skipped steps sometimes on small projects where I can get away with it because I don’t want to wait for the project to be done. I wanted to rush things because sometimes, when we’re using this software to solve a problem, we want to solve that problem as quickly as we can.

For me, when I have done this in the past, I’ve burnt my hands. As I’ve grown in my career, if I skip a step on a large project, it’s not just my hands that get burned, other people’s hands get burned with me. Try to remember and stick with these steps every time. When I do, things go well. That’s why it’s a successful formula for tech implementations because when it’s followed, things get done the way we want them to. I wish we could skip steps, but it doesn’t work.

It’s the human tendency to want to skip ahead, to think we know this. How do you keep yourself honest? I know you’re very experienced, so maybe you do this magically, but people like me, I like to skip steps and it always comes around and burns my hand. How do you keep yourself honest? How do you make sure that you don’t skip something crucial?

I’m not going to sit here and tell you that I’ve never skipped steps because I still do it and burn my hands. There are two things. One is working with people who feel comfortable giving you feedback. In case of my team, I always want them to know that they can give me feedback. I had somebody raise their hand and be like, “You’re going down the wrong path if you skip that step.” Having people who are comfortable providing that and checking in, always going back to the why, how and the measures of success. When I go back to those, it reinforces I can’t skip the step.

When you’re looking at change, assume the best intentions. Click To Tweet

I’m not going to tell you I’m perfect about it, but I will say when I start to see a project starting to slightly go off the rails, I start to think of this formula, “Am I doing all the things on here that I need to on my team doing all the things?” If something’s going off the rails, something’s been skipped. To be honest, as much as I try my hardest to do this, I have successfully done it many times, I still get caught by it. Keeping an eye on the projected trajectory and making sure people are willing to say to you, “You got to take a breath. You can’t skip this step,” is important to do.

It’s like the difference between cooking and baking. If you’re making a pasta sauce, you can play around, and maybe you throw in the spices later or earlier. If you’re baking, don’t skip the baking powder. Don’t jump ahead and then realize that you forgot the baking powder and what you have is brick instead of this lovely, light cake you thought you were making. This soggy brick comes out of the oven. It’s very interesting to hear about this. Do you have any examples of a project that worked?

I have one that’s close to my heart and I’m proud of. Years ago, I was hired to be the head of technology for a company. They felt they were a hospitality company. The industry they were in was citywide conventions, doing the registration, hotel booking and all the things that go around doing a citywide convention. Over twenty years, they had developed technology and got out of date. They hadn’t come to the realization that they’ve become a technology company. They weren’t aware of it. They were starting to lose customers and they hired me.

My first week there, I went to Minnesota to meet with one of our top customers. The first thing I did was to listen to their concerns. My job was to promise them a whole new system, which was a little intimidating on week one. After doing the listening tour with them, myself and others did a listening tour with all of our stakeholders, our daily users, the folks managing our big projects, the folks who dealt directly with our customers, talking to our customers, executives, vendors. Listening and understanding what the concerns were.

We aligned as an executive team as well as the company on how and why we were making changes and what we wanted the outcome to be. When I say that we did that, people think that this was like, “You did that and you’re done.” It was a huge lift. This company hasn’t updated some of its technology in fifteen years. Things were not supported anymore by software companies, hardware was falling apart and we did this huge lift. We also kicked the project off with vanilla ice cream, which still helped, but I can’t prove it.

We followed the alignment stuff. We heard people’s concerns. We had a change agent supported by all of the executives in the company who were all plugged in and involved. We did this huge lift while reporting out to our customers, using our project management and our agile approach on a regular basis to the improvements we were making. We’ve been poised to lose this customer. When we launched the new project or product, it was phenomenal. I’m not going to say it was flawless. There are always challenges with software, but it was functional.

It met their needs. When we had issues, we were upfront with our communications. We kept that customer, but the real win in this was these high-tech customers in the valley we wanted to use our software and signed up. That was a huge shift, but we followed every step alignment, empathy, supported change agents and project management. Along the way, we communicated to all of our larger defined group of stakeholders. It went well. To this day, I’m super proud of the changes that we made and how that results with the business. Eventually, the goal of that business was to be bought out and that was achieved because they redid the technology.

I love this idea of the formula. You’ve been talking about the people deciding the change needs to be made. Upper management, the people who are implementing the change. If you’re somebody who has had changes dumped on you, how do you manage that if people above you have suddenly changed everything and you’re not so sure it’s a good idea? Do you have any suggestions for navigating that nest of snakes, if you will?

 

I try to remind people that if somebody is making changes, they probably have good intentions. Assume best intentions is an important value to have when you’re looking at change. What are they trying to accomplish with the change? If you’re having changed dumped on you, I don’t like having dumped on me any more than anybody else, but I do try to think about why it is being done. It still comes back to the why and how. What are the consequences and the unforeseen consequences?

If you are using this technology daily or a process daily, what are the things that folks maybe aren’t thinking of and then finding the right place to raise it? You have to go in with not just change resistance, but why is this a challenge? You have to be able to articulate that to somebody, both your concern and what you think the business impact is going to be. That’s what it all comes back to. If we change a system or process, we’re trying to net a positive outcome for our business.

If we miss something like with the software for communication or footwear, it’s going to have a business impact and we want folks to raise their hands. Finding the right person to talk to after you’ve done that introspection is a way to handle that. We also always have to ask ourselves, are we looking at this because it change is hard or because we have business concerns?

Jen Cohen, it’s been such a delight to hear you talk about all of this. Nobody wants their projects to fail. If somebody is reading to this and thinking, “I need to follow a formula,” where would you start? What’s the first thing to do?

Always come back to the why and how and figure out where they’re at. If they need to follow a formula, I’ve published a formula on my Medium page. They’re welcome to look it up there. There are plenty of other resources on the internet for this. Check out my Medium, skill change agent leverage, an experienced project manager to help you find the gaps of, “I got to make this change. What is the formula to make sure it’s successful?” Those are ways you can approach it.

Jen, thank you so much for having been my guest.

Thank you so much for having me.

For those of you reading, if you liked this, please tell your friends and subscribe. If you’re curious about your presentation skills and how you’re doing, you can take our free four-minute quiz at SpeakForResultsQuiz.com. That’s where you can see where your presentation skills are strong and where perhaps a little support might get you the results you need and the recognition you deserve.

 

Important Links

• Toyota Research Institute
• The Phoenix Project
• Medium – Jen Cohen
• SpeakForResultsQuiz.com
• https://www.LinkedIn.com/in/jennifercohen415/
• https://Twitter.com/jencohen415

 

About Jennifer Cohen

Jen Cohen makes technology work for business. It takes a deep understanding of your company’s unique situation to strategically choose and implement technology and processes that meet both current needs and future demands. Jen helps companies do just that.

Companies hire Jen to transform strained teams and processes. Since the 1990s, she has helped large companies like Toyota Research Institute, Cisco, and Birkenstock adopt solutions that drive meaningful business results, including rebooting inefficient operations teams, establishing world-class best practices, and streamlining processes to optimize performance. She’s also helped several startups, including Line2 and Convention Management Resources, modernize platforms, streamline processes, and scale their operations to prepare for successful acquisitions.

Her specialties include improving uptime to 99.999%; rebooting and modernizing platforms and teams; streamlining, scaling, and automating processes; implementing change management processes; and rearchitecting aging core infrastructures.

Clients and colleagues know Jen as knowledgeable, personable, and enthusiastic about technology and operations. She cares as much about finding the right solutions as she does about easing users’ fears and getting them comfortable with new tools and systems.

Although getting technology and processes right is important, Jen believes the key to successful change comes down to one thing: the people. Her motto is “It’s always about the people, and when we value each other and work together, we can accomplish amazing things.”

She is committed to coaching and mentoring people at all levels within an organization, especially women in tech. And she’s in it for the long haul. Jen maintains and nurtures relationships with former direct reports and colleagues even years after they’ve worked together.

When she’s not working, Jen enjoys rock climbing and watching bad British mysteries and offbeat sci-fi movies. Now that her two children are in college, she has time to take ballroom dancing lessons with her husband.