Episode 383: Project Failure Is Not An Option (Free)

Play Now:

Need Project Management Professional (PMP)® training? Here's PMP Exam Prep for your phone!

Kristy Tan Neckowicz, Connie Inman and Cornelius Fichtner

At some point in their career, every project manager has to deal with troubled projects.

This interview about project recovery with Kristy Tan Neckowicz and Connie Inman was recorded at the Project Management Institute (PMI)® Global Congress 2016 in San Diego, California. We discuss their presentation and white paper Recognize Warning Signs and Rescue Your Troubled Projects. Here are the abstract and summary:

Abstract: Come to this session to hear real stories of troubled projects and recovery journeys from two seasoned project management professionals. You will learn to recognize common warning signs of troubled projects, approaches to right-sizing your project management processes, and applications of stakeholder management lessons for project success.

Summary: The common theme across the case studies is a focused spirit of continuous improvement to rescue troubled projects. Although projects are temporary in nature, project management processes are always evolving.

It is tempting to move on to the next project when a troubled project has been placed safely back on track. However, you will have more assurance of the project manager’s future success by conducting a lessons learned evaluation focused on the practice of project management before claiming victory.

By sharing the warning signs, right-sizing approach, and lessons learned from these case studies, we hope you will leverage our experience to keep your next project “on track” to successful delivery.

Episode Transcript

Below are the first few pages of the transcript. The complete transcript is available to Premium subscribers only.

Podcast Introduction

Cornelius Fichtner:  Welcome everyone. You are listening to the Project Management Podcast™ at www.pm-podcast.com . We are coming to you live from the 2016 PMI Global Congress in beautiful and sunny San Diego, California. And with me this morning here in the hallways of the Conference Center are two people. We have Kristy Tan Neckowicz and Connie Inman.   

Podcast Interview

Cornelius Fichtner:   Hello, Kristy.

Kristy Tan Neckowicz:   Hello.    

Cornelius:   Good morning. Unfortunately I can’t say hello, Connie because I only have two microphones and Kristy’s wearing it but we will bring Connie into the mix in just a bit. So, your presentation is titled “Recognize Warning Signs and Rescue Your Troubled Projects”. Have you already given the presentation?

Kristy:   Not yet. We’ll be giving the presentation this afternoon.

Cornelius:   Wonderful. You have an opportunity for a dry run right now. [laughs]

Kristy:   Yes.

Cornelius:   Excellent. Do you know how many people are going to be attending?

Kristy:   I do not.

Cornelius:   Yeah OK.

Kristy:   I hope that it will be well-attended.

Cornelius:   Have they moved you into a different room? That’s always a good sign.

Kristy:   Oh no, they haven’t. [laughs]

Cornelius:   If they move you into a different it means, oh, there are a lot more people than we expect to be interested in this. Alright, what is your interest in Troubled Projects? Why talk about them?

Kristy:   It’s a good question. I saw Connie give the presentation on her case study back in the Spring this year and I thought to myself when I was sitting in the audience, I thought, “We could do this together” because we have a lot of similar experiences. We’ve been through a lot of troubled projects that you could substitute the players’ name, the company name, the product name, the technology name and you might have the same problems. So I had this idea that we could give a presentation together and sharing our knowledge on problems that we’ve had with technology projects implementation or development projects, even business process improvement projects because I’ve walked away from that case study presentation from Connie thinking, “Geez, a lot of the problems are very similar. They’re related to not doing the right risk management, not doing the right level of stakeholder analysis or management and so forth. So I said, “Wow! These are really universal lessons to be learned. That’s why we created this paper together to talk about our experience with troubled projects; how we rescued them and we hope the people will walk away with good idea for how to fix their troubled projects.

Cornelius:   Talking about troubled projects takes you out of your comfort zone because you have to admit that “I failed”. How do you feel about that? Why do we not do this more because lessons learned of something that failed are so important?

Kristy:   That’s really a good question because I’ve thought of that also that I’m used to teaching people how to do things. How to calculate earned value, how to do scheduling, how to do portfolio management, how to do the right things so you’re communicating with different behavior styles, etc. But, I never really talked about my own lessons about things that we did wrong that we had to rescue. Some of these were uncomfortable. On the other hand, I think if people could just suspend that fear or that judgment of “Oh, what happened to you won’t happen to me” type of thing; if they could just be open-minded, they’re going to learn so much. So I think this is a good presentation for people to discuss with us after they hear it, to talk about things that they’re walking away with because I really do think it’s universal.   

Cornelius:   OK. Can you give us a definition of what a troubled project is?

Kristy:   A troubled project—it’s interesting. Connie and I talked about this earlier. It may not just be that you’ve completed the project or the project is going on schedule and on budget but you also have to make sure that you have the end in mind. A troubled project, the way we see it, is any project that is not going to deliver the intended value or not performed to scope on budget and on time. Any of those.

Cornelius:   Right. You actually have a sentence in your paper. “We propose that a troubled project is one that although has not been terminated has significantly missed its defined scope, budget and/or schedule to a point of perceived no return”. The interesting thing I find about this is that the third last word, “perceived no return”. What is the difference between “no return” and “perceived no return” here?

Kristy:  That’s also an interesting point that you brought up. The perception phase is that even if the project team felt good about the state of the project or that they could turn things around, the stakeholder is either –users or sponsors are so disappointed that they’ve already written you off. They’ve already said, “That’s fine, go and finish it but we’re not going to use it.” Or, they’re resigned to the idea that the project is not going to succeed in their mind. That’s the key word there—perceived.

Cornelius:   Ok. When does trouble usually begin to occur in the project?

Kristy:   I think we’re getting into the case study so I would like to hand this over to Connie so she can talk about it.

Cornelius:   Absolutely.

Connie:   Thank you, Kristy.

Cornelius:   Now that we’ve made the switch over to Connie, hi Connie! Welcome to the program.

Connie: [laughs] thank you. We’re excited to be talking to you today. Thank you.

Cornelius:   So, when in the life cycle of a project, does trouble usually begin to occur?

Connie:   Trouble can begin at any phase of your project. What you have to start doing is figuring out how to recognize that it has occurred. That’s the point of our case studies here is it can occur from the very first day. If you’ve got a lot of requirements that you think you know about your scope and you’ve asked the right requirements, you think but you walk away, you don’t confirm that you identified everything there was to do and either made the logical decision to say, “That’s out of scope, this is in scope”, everybody agrees to it. When you walk away you could have a troubled spot right there, right then at the beginning. You just don’t recognize it until at the end when you’re delivering and those perceptions come out of “You didn’t do this, you didn’t do that”, but I delivered exactly what you asked me to do but I didn’t deliver what you intended it to do, so it can occur at any point in the project.

Cornelius:   Alright. Next, we’re going to jump into three case studies. Tell us a little bit about these case studies. How did you find them and why did you choose these three in particular—sort of on a high-level?

Connie: Excellent. Excellent. Kristy and I kind of went back and forth with the many things that we could talk about and we chose these three in particular because one is about implementing software; one is about developing it; and then one is about the user experience of that implemented software.

Cornelius:   So it’s not the same case study, right? It’s three different angles.

Connie:   It’s three different cases. Exactly. No matter where you are in the audience or in your project and what type of project it is, we’re hoping that one of these types will resonate.

Cornelius:   OK and all three are about software development. Is this interview still relevant for people who build roads and houses and engineering and things like that?

Connie:   It absolutely is because we don’t go into the actual software development, the actual aspects of that—this is more about—

Cornelius:   The art of project management.

Connie:  The art of Project Management. Exactly

Cornelius:   OK, wonderful. Let’s jump into Case Study #1. You’ve titled it as “Technology Implementation Project”. Tell us a little bit about that.

Connie:   We were charged with the sponsor to purchase a software solution that would help with our project manager’s scheduling. So we have a lot of project managers but we needed a software solution outside Excel or Microsoft project on one off bases to come up with something that was more an enterprise solution. That’s what the scope of the project was to do.

Cornelius:  What were the warning signs?

Connie:   Going through the project, when we finally got to the point where we could recognize them, the stakeholder engagement. They were not getting any different reports than they did the first time that they were getting out of Excel or other things. So the software was not providing any value to them. So then when you look past that, then you can say that the users are not using the software and there’s a lot of negative talks that when the name of the software comes up you get this grimace on their face.

Cornelius:   Or rolling their eyes.

Connie:   Rolling their eyes, a lot of bad chatter—those kinds of things. And then it’s just not effective as far as the objectives that were supposed to be as evidence that the maturity of the project managers would increase because of the software and that was not the case either. So those were the kind of things that popped up.

Cornelius:   The obvious question is what did you do? 

Above are the first few pages of the transcript. The complete PDF transcript is available to Premium subscribers only.