Project Management 3 of X — Transcript
[00:00:00.01] Ken: So here we are in project management three of X and the X is because we really don’t know how long we’re going to spend on this or how many how many how much time we’re going to spend but I thought it worth maybe taking a step back we started talking about this without really without really giving much of a justification, and I want to kind of come back to why project management is important and all that. This started for me with something, there was a group in the 90s, and they’re still around and they still do this. It was called the Standish Group, and they produced something that became known as chaos report. It was specifically about IT projects and more specifically that the majority of IT projects are late and behind schedule and fail. That was sort of followed up in a lot of places, including something McKinsey did. he found that it doesn’t matter whether it’s an IT project or not, half of any large capital project exceeds its budget, cost overruns of 40 to 45 percent, IT projects are even bigger, most projects are over time. one really struck me as I read the results here that 56% deliver less value than predicted, and even some up to 20% of projects threaten a company’s IT project specifically threaten a company’s existence because they fail. So that’s kind of where we started with all this. I got thinking about, you know, some of these things, I’ve always I was always a little skeptical of the Standish Chaos report that kind of started our interest in project management and project assistance, quality assurance, those sorts of things. Often, you know, how do you define failure is. failure mean we cancel the project? Does failure mean the project took longer? And if so, by how much? Does two weeks matter on a 10-year project or a two-year project? Does that mean the project’s a failure? Often these don’t really define what failure is, or worse, they rely on the memory of of someone involved in the project, which is just basically anecdotal data. So there’s really no predictive research done in this area. To my knowledge, none’s been done, and most of the projects are kind of from North America or Western Europe, which is a little like psychology experiments, which is kind of… my educational background, where the old joke was psychology is the study of white middle-class college students, because the sample base is often just that, white middle-class college students. So that’s kind of where we started with this, and we kind of jumped in. to this by talking about some important things. I think our first episode was really about sponsorship and our second was about team formation and that’s great, but we didn’t really talk about the, why are we even talking about project management? Do you have any thoughts? I’ve got more to say, but do you have any thoughts you want to jump in with?
[00:03:45.06] Jim: I would say that in a previous episode, I forget which one, we talked about how frequently we would be called in for a specific problem, and we spent the first three to four weeks finding out that that wasn’t the problem at all, that the problem to be solved. solved was substantially different, and so in this case, I would say that very few of the agencies we worked with were willing to say we have project management issues and we need that fixed. So much easier to say. we have a late system delivery or we have an over budget or we have a you know any anything that gets away from the people aspect of it because it was simply too hard to get a project funded and advertised and through the procurement process if it was directed at a project director, project sponsor, project manager, very, very rarely did we see that as the stated problem, that’s my, that’s my opinion.
[00:05:07.97] Ken: Yeah, no, and I think you’re right about that, it was always the human factor rather than technical factors that cause problems. You know, we have a vendor whose technology doesn’t work. That is the reason we were brought in. But more often than not, I mean, a matter of fact, most of the time it was a people issue. That’s sort of what some of these studies that I mentioned, both McKinsey one and the Standish. chaos report that I think it’s still published to this day where every year they go and look at “project failures” but it really seems to me a lot of stuff is, a lot of the problems, and we’ll talk about remedies to these in future issues, but are kind of planning deficiencies meaning, you know, optimistic schedule for one reason or another. or another, bad scope definition, little or no planning or management of risk on a project, and just bad scheduling techniques. Often some of that stuff is done like the misrepresentation of schedule to get funding or schedule or cost to get funding in the places we work. It was very clearly defined by, often by funding windows. So, you know, you have to have this project done in two years because that’s the funding window we had, and that would derive the schedule independent of the amount of work that was required to complete a project. often costs or schedule were misrepresented just to get that funding. Yeah, I think the other things that I saw were sort of like, you know, weak governance. Okay, we got a project, project manager, go take care of it and fix it and come back when, or, you know, do it and come back when it’s done. Coming from senior management of an agency. and we talked a little about the importance of sponsorship. We’ll talk about maybe in a future episode how sponsors should actually conduct work. I think there’s another human component to it too. As you said that it brought this to mind that there’s almost a fear of telling the truth. Sometimes when you get into a project. into a big project, people will, particularly staff members, will see things that are perhaps going awry, but won’t say them for fear of, you know, “Oh, you’re just a naysayer,” or for psychological pressures, they won’t bring up problems they see arising. So it kind of becomes a group think thing, you know, we’re gonna, I’m not going to say anything. Everybody’s sitting there thinking I’m not going to say anything, but this is going to crash pretty soon. So anyway, those are kind of my, and I think the other piece that I. see a lot of is maybe not adequate measure of real progress. They measure progress in terms of weeks gone by rather than work that’s gotten done. So it’s like, yeah, we’re 10 weeks into a two-year project and we’ve gotten nothing done. Or worse, we’re 52 weeks into a two-year project. year project and instead of 50% of the project or they counted as 50% of the project being done when it might only be 10% of the work that’s been done in that two year in that year.
[00:08:47.58] Jim: Yeah, and I would even say at the at the height of our working in project management, whether whether our client called it. that or not, by then we had so much data and experience that I think we both felt comfortable telling a client, even though you’ve spent two years working on it, you actually have more work left to do than you did on day one. a maddening thing to hear for our clients. But in too many cases, it was true. Yeah,
[00:09:31.17] Ken: They had created more work. Yeah, and sometimes that was “scope creep” where they added stuff without really accounting for that, and sometimes it was simply, we didn’t have a very clear was to begin with, and we got clarity on it after a year, and holy smokes, this is a lot bigger project than I thought.
[00:09:52.49] Jim: Yeah, or they had set somebody up for failure. I can’t tell you how many times I heard, “Well, our best project manager is, but she’s not Then they’d bring somebody else up, “Well, Fred’s available, let’s use him.” Or, I heard this a lot of times, “Everybody else on the team has managed a big project, but so-and-so has not had a chance to do that, so let’s make them the project manager.” Um, yeah, no, bad, bad idea.
[00:10:34.06] Ken: Yeah. So the, the, you know, to me, the bottom line about why we’re talking about this is there, there is, uh, some studies, you know, how accurate they are. I don’t know, um, that suggests, uh, a lot of projects simply are. or failures or return less than they intended to. They take longer and cost more than people thought, and there’s, they’re often, gosh, what was the book? I’m gonna draw a blank. I’ll probably have to cut this segment out because I can’t remember the name of the book, but it was, oh, “Death March” was the title. Yeah, where they become death marches in the project just psychologically brutal on staff, and we can talk about why they’re brutal on staff in another episode. But the other thing I wanted to mention before we quit is some people call, sometimes a project gets the plug pulled on it. Management gets… Sick enough and people or you know get sick of what’s going on. It doesn’t matter what the reasons cost overruns, etc And they pull the plug on the project to me. That’s not necessarily a failure. That could be a success. You know, we explored this and Found out it just wasn’t simply wasn’t possible at this time with the resources we have or something like that that. So I wonder how often some of these failure reports are really, we came to the realization it couldn’t be done, or priorities change, or in our case, the regulatory environment changes, which happened often. Those sorts of things. So I take these reports with a bit of, or with a. of salt, but we did see a lot of what I would consider underdeliver over over promising and under delivery and those things always, you know, do you count that as a success or failure? And it’s a bit semantic, but we can talk about, we’ll talk about over the next few episodes, we really saw that caused projects to take longer than anticipated, and then we’ll talk about some of the things we always recommended to clients about it. Do you have anything you want to add to the end of this?
[00:13:01.22] Jim: Yeah. Well, so the visual that comes to mind for me, and maybe I spent too much time on it, time in airplanes when I was working but if a two-hour flight is 15 minutes late that’s just routine right yeah not usually not a big deal if it’s 30 minutes late you start wondering what’s what’s going on but if a two-hour flight is two hours late And going into the fourth, fifth hour, something’s wrong, and the thinking at that point should be, just land this thing. I don’t even care where anymore, get on the ground, and you know, how many projects did we see like that, where there were two two opposing outcomes possible? and one was pretty benign. The time that went by meant that it’s almost done and that’s what the contractors that we worked with would always say, “Oh, it’s almost done. It’s almost done.” But there were too many projects where that thing
[00:14:06.51] Ken: Should have been down on the ground early and never got there. Yeah, that’s a good point. Yeah, I mean, this is what I meant by pulling the plug or, often the plug was never pulled completely on a project, say we’re going to be done, it’s just we finished this module, that’s good enough, let’s call it good, and the whole project, whatever it was, was never really completed, but you got value out of what you delivered. Is it what the original value? I don’t know, but yeah, you’re right. there’s a point at which you do have to land the plane so that’s a great analogy. All right.