Welcome to the everyday p.m. Podcast, the podcast, where we
discussed project management principles for your everyday
life. My name is Ann campea, and I'm a
certified project / program manager with over a decade of
experience working for healthcare.
Retail consumer goods and Tech Industries.
I am so excited to welcome two very special.
Yes, and if you are a Avid follower of the everyday p.m.
You will have seen or listen to another episode with both Mark
and Greg on it. So I am welcoming them back to
the podcast, Mark, and Greg. Thank you so much for joining me
again. And today we are talking about
why projects fail. This is such an exciting topic.
I can't wait to dig in. But before we do that, let's
have both of my guests introduce themselves to our audience.
So Greg, why don't we start with you for those who have not?
You yet, although you've been on, I don't know.
What is this. May be your fifth episode of the
everyday p.m. Podcast for those who have not
met you yet for our new audience.
Please take a brief moment to introduce yourself.
Thank you will. And thanks for having me on
again. And my name is Greg kristensen.
I'm, the vice president of project Hub.
That's a project management software solution and I'm happy
to be here with you. Once again to cover.
Another interesting topic that should help people get their
projects moving Faster by learning why they fail.
Awesome and Mark. Hey, thanks for having me and
I've written a bunch of books on project management.
I created the visual project management methodology called
Viewpoint and that's kind of what I'm promoting and I've done
lots of big projects. Lots of small ones, lots of made
lots of mistakes to so but we're going to talk about those are
are we now? So, let's go ahead and dig in
dig in here because this is such a great kind of very macro topic
that we can easily get into dive into the details about.
But I want to kind of start with some statistics that I pulled up
from the interwebs here in terms of, you know, the most recent
percentages of projects that are considered to have been
failures. So we're hovering at about 70%,
right? According to PMI and about 42
percent of the companies that reported in say that they the
reason they failed is just because they didn't understand
the importance of the project or of project management, which
baffling to me. The other percent here I have is
55% of project. Managed project managers cited
that it was budget overruns or or something of that sort.
That was the reason for project failure.
So anyhow, I think that those statistics kind of set us up for
this environment of you can plan to fail your project manager,
you doing. You can, but your project,
there's still a chance of that project going awry.
So let's start with your definition of failure.
I think it's important to kind of give us a foundation of what
we're talking about here. So, Mark, why don't we start
with, how do you define project failure?
Well, project will fail. If it doesn't deliver on time.
If it doesn't produce the result that the project was designed to
do and I think those are the two big things over budget.
I mean some people will Say, well, the project failed because
it was over budget, but I've never seen a project that is
actually came in at budget. So, sort of, you know, it's not
a failure. Just more expensive than people
thought it was going to be. Yeah.
Yeah, fair enough. And how about you Greg?
Well, interestingly enough. I hang my hat on the delivery
deadline. I think they had that everything
is all about delivering your project on time.
I would agree with Mark that budgets really common.
There is Few other factors, but I like to hang my hat on the
date. If you can deliver on time and
deliver, what was promised that right?
There should be a huge win. The other things can be dealt
with and then kind of adding onto both of your definitions.
There is, I tend to harp on quality.
I've worked in consumer goods for so long.
That if I put a product out there that has some sort of
technical failure. Then I feel like the project has
failed. We've missed something.
And so anything that is a Above are excuse me below, par in
terms of the our quality measures and what we expected
the product to do. I do I would consider that for
myself a project failure. So I think go ahead.
Well, I was gonna say I as well. That's sort of falls in the
project. Deliver what it was supposed to
do, you know, often it's a working project or product.
It's a working product or a product that will be successful
in the marketplace or the piece of software.
That doesn't work the way. It's supposed to.
Or, you know, anything that falls outside of this
specifications of what the project is supposed to deliver
is a failure. So, I'm sorry to interrupt.
No. No, that's this is a
conversation. Right?
So Mark, I think you've written about why projects fail and now
that we have our foundation for this conversation.
What? Why?
Why I think that's the question. We all want to know why do
projects fail. Well, I think there are there
five. Things that are contributing to
the project failure and none of those are the plan none of them,
you know, because plans no plan is no plan is perfect.
Right? There's just no sense.
So, I've got it. Boiled down to like five
different things. And one of the things that
happens in project management during execution is, That
project the project processes tends to focus on what have we
accomplished instead of what do we need to accomplish?
Right? And we talked about that.
The last time we were together. The other thing is, you know,
how, how flexible is the team is the team inflexible.
Well, this is not my job, but I sent this guy an email, but I'm
looking at, you know, people are, you know, do they have the
same objective? Right is everybody?
Beyond the project team had the same objective to deliver.
The project is a crystal-clear year in this project.
This is what you're going to do while you're here.
And so many times I've seen particularly in
multidisciplinary projects to me.
You've got the engineers. You've got the Fabricators a
production here. They're all operating in their
silos. And the only person that really
is owning. The project is the project
manager and the project sponsor, right?
Those are the other two people. And so I see that if Teams are
not don't have the same goal. Then project was definitely be
extremely difficult to manage highly unlikely to succeed.
The other thing that I see is that when the priorities the
test priorities, for the people who are on the project are
unclear or conflicting or constantly changing, you know,
that's going to be creating a lot of noise in the project
delivery process. And then fourth is.
We don't know where the constraint is for the project.
So I think take a page out of goldratt spoke.
You know, the constraint is the thing that is limiting the
product project from moving forward.
And it's not clear what that constraint is where that
Leverage is. So people would get focused out
of the weeds and they start working on the wrong things.
And so that project, and then number five is just Pain
sadness, you know, the tempo of the project, you know,
sometimes, you know, we send an email and then we played a week
and it's our next project meeting.
Oh my gosh, like, I never got back to me, you know, or
whatever, right? Then the team is slow.
So focusing on the past mixed messages on what the goal is
priorities. Constantly shifting.
We don't know where the constraint is and slow response.
That's five. So, I spent a lot of time
talking about this fight. Sorry, no, no don't apologize.
It just got me thinking about, you know, when I started my
career as a p.m. One of the things that I kind of
really just became ingrained in my the way I conduct myself is
that no matter who's failing within the project team that It
ultimately rests on the project, managers shoulders.
And so as you're talking through those Five Points, it kind of
brings me back to this the thought of do you believe that
of Those five the project manager has any type of control
over trying to bring the project back on track?
Yeah, no, not typically because I think if we take just take the
first one, the first one the project manager does focusing on
the on the future and you know, changing the emphasis of the
team from reporting on what they have done and telling you what
the problems are and Shifting the emphasis from that, to,
okay. What are we going to do today?
What we're going to This weekend who's going to do it.
That is the job of the project manager, but the project manager
can't fix the project manager alone.
Cannot fix the problem of mixed or incorrect, reward systems.
So for example, purchasing guy, you know, he is, he's being
measured on purchase price. Variance.
Did I get the cheapest one or did I get it?
You know, did I get the right vendor?
And so you're bringing this supply chain guy on.
Org are Gala on to your team? And they're you know, your
project is in trouble. And you need to this supplier to
get moving air freight Charter, playing whatever it is, to get
this item that you need. But the purchasing guy says,
well, if I do that then you know, I'm going to my metric is
going to suffer. So and so the project manager is
not going to have control over that because that's an
organization. You should not p.m.
Now, the p.m. Can recognize it and Elevate
that, but certainly the problem of the mixed.
Ward's of or incorrect rewards will definitely is out of their
scope. Got it.
Yeah, and that now project managers can work on the task
priorities. If we, if we know what the work
is and where we're going to do, you know, the project manager
can focus on that. But what I see is, you know, a
lot of project managers are playing whack-a-mole, you know
or just responding to the boss or whatever the thing is and
don't have a good sense of pushing.
Back and say, listen, you know, you giving me this priority that
I've got to do this thing. But if I do this thing, then
there's other things going to suffer.
And that's certainly something that the project manager has
control over the project manager can also know where the
constraint is. Damn straight shows up.
It's not it's not hard to spot. It's you know, I think if you
ask the project team or second string goes Herbie, he's over
there, you know, everybody knows who it is because that person or
that department, that supplier, they're being named in every
project meeting that you go to the, right?
So, it's not. But what project managers don't
necessarily recognize that, that is the critical leverage point
to push your project forward. And that's certainly the job of
the project manager to break that bottle leg and get it
elevated to the right person. And then of course, the
responsiveness the project manager, you know, I don't want
the project. I never thought that the project
manager should be the task police now.
Well, the project manager can say, Hey, you know, we're
getting slow response, you know, we need to pick up the tempo but
That goes back to the measurement problem that I
talked about a minute ago. I mean, if people are not aware
that, you know, we had the rule 24 hours, you know, any
question. Any problem, you have to respond
to 24 hours and that is the project manager can set that
expectation and enforce that expectation through smart
management. Meaning, you know, if I've got a
team of people and, you know, a little will pick on the supply
chain guy again, just because I like the supply chain, guys, you
know, the But the, you know, the the project manager can work
with the leader of the project of the supply chain
organizational, say listen, we need 24-hour.
Can you help me with that? And that's something that
certainly is in the control of the project manager.
Choi. Sure.
So really the big, the big everything is in the project
managers realm of control except getting all the people on the
project on the project. Got it.
Yeah. Sense, Greg.
What do you think about that? Well, as you know, and we talked
about it on previous episodes. I've been consuming a lot of the
things that Mark is written. I'm a little bit more, well,
versed than I probably really am if that makes any sense because
a lot of it makes sense to me, kind of naturally because of one
of our, what I've already consumed of his and then I'm a
little bit familiar with goldratt and his Concepts and so
I'm going to bring up something Mark brings up sometimes but
goldratt specifically says is a quote.
Show me how you measure me and I'll show you how I behave in
order. It really gets down to is the
behaviors. So you've got these project
managers that are trying to maintain and push and manage
that project. They've got a certain amount of
authority. They're empowered Etc.
But still who gets put in place that's not on them.
So they have to really fight at actually think I'm really
interested your answer on this and because you're really good
at that. You know, a lot of the soft
skills, a Zen approach to how to get people kind of moving in the
right direction marks, really big on.
Let's not worry about, who, what?
When yesterday, let's look at, where are we at?
Right now? Let's get things moving.
So I don't know if I really answered your question, but
that's what I'm doing here, is taking it in and realizing that
it's all about getting people moving the right way, focusing
on the right things and that's a behavioral change.
That is a challenge as you go down line.
Yeah, and Afraid to commit, right?
I think there's a lot of moving Parts here and one of the most
unpredictable variables is the people.
It's the people that you inherit on your team.
It's the people who are sponsoring the project and I
think what you're saying Mark is that, wow, we have so much
control over some of the parameters that are set forth
within our project as a project manager that there are really
some things that we either inherit or they come to us.
A specific way and it will it might take Moving Mountains to
get that to, to be able to be something that we can control as
project managers. Or maybe we just will never be
able to control that one variable in within the project
and that comes with. Even if you walk it back a
little bit, that could be company culture, that could be
the support of your leadership team, that could be, you know,
misalignment on company strategy versus what the project is
actually executing against theirs.
There's a whole plethora of things that I've seen in my
experience that have led to project failure.
That really ultimately is out of the control of the project
manager. I do think I inherited that
perception that everything is in the control of the project
manager because I do tend to lead so much with empathy and
that, that tends to weigh on your shoulders.
If you, if you lead in that way, because then you want to without
thinking about it. You are inheriting all All of
the problems around you and you're trying to fix all the
problems around you which can be come across as very authentic to
some people. And that's how you manage the
people part of it, but then can on the flip side of it Playing
devil's, advocate to my own way that I lead can.
Then weigh very heavily on your shoulders and you think that you
can control certain things of the project that are failing.
When ultimately if you look back at it or you look at the root
cause it was something that was never in my control to begin
with. So I think Mark, you make a lot
of great points about what is in our sphere of control as PMs.
And what is not and having this this mentality of don't harp on
the past for too long because the projects going to continue
to fail until you try to start focusing on the future and how
to get it back on track. So is there any I mean you
talked a lot about some of the signs and things that we can
look out for. But what what specifically are
some of the early warning signs that you've seen in your
experience in? And how have you been able to
troubleshoot that to get the project back on track?
Well, I think the, you know, the first, the first one is, you
know, focusing on the past and that, you know, that's, I want
to say, that's the easiest thing to fix, but it's easy because it
doesn't require a lot of process change or anything.
That's just changing your approach and how you approach
the task of managing the project, right?
So, you know, that sense of being future-oriented.
Do you know you can lead with mpany empathy and you know still
focus on the future. I think what happens is, people
get caught up in the we made this mistake or there was a
defect or the supplier is late or this engineer, you know, they
missed a deadline and we can get all caught up in kind of that
for the lack of a better term called all that drama of missed
expectations, right? So it's a great project manager
can Get caught up in the Miss expectation and say well or they
can say. All right.
Well, this is the reality as it is right now and going forward
we want to do it this way and you you know, us and we know
that people make mistakes and you know, Miss deadlines and
that, you know, that's just part of it, right?
And then, you know you, if you're doing software, you
rather through test and then it fails test in your account and
then you get to go do back and loop it, Loop it back again or,
you know, you didn't get the Certification that you wanted to
get you know, and now you've got to go back and change the
product again and you know, all of that stuff happens, but I
think the project manager can really have an influence on, you
know, alright. Are we going to beat up the guy
that miss their deadlines? Are we going to just say?
All right, let's go well and of course, you know that we're all
humans here so we can get mad. Get mad.
That happens to and and that's all right.
I'm just thinking that the project manager really has to
think about. All right, what's coming next?
You know, what's going to be the next obstacle?
Who needs to address that? So if you think about what the
project managers doing the project managers looking ahead
how far ahead, you know, you we don't know and anticipating
what's coming up and making sure that certainly nowhere.
He's my phone there. The, you know, the project
manager can be proactive in that kind of stuff.
And it's not, you know, we're not being authoritarian.
We're not, you know, beating people up.
You know, what we're at, what we're doing is were saying, hey,
you know, here's the expectation and, you know, thanks for coming
to the meeting, but the meeting is not about reporting, you
know, if you want to report, will have a separate meeting
about that. This is about planning our
activities for the next for the next step.
And that's the most important. You know, in terms of and of
course, you know, when we have these conflicts, you know that
we're you know, we're missing deadlines or you got somebody on
the project. It can't deliver when they're
supposed to excuse me, then it's up to the project manager to do
a dive on that and say why, right?
And I think that a lot of times what happens is we don't even
consider the fact that, hey, this guy's not going to get a
bonus or his, his other, his real boss, or her real boss is
Give them a problem. If they do what you want to do.
And I think that is a project manager.
We have to be sensitive to that and say, well, listen, you know,
it's not this guy's fault that he's stuck in a conflict.
Right? So, you know, the project
manager can look for those conflicts and be more of a
conflict resolution person than a task manager because we
already, you know, we don't have the project manager to be the
task manager, right? The task police.
That's not what we want. Absolutely.
So now I Lost my truth. Well, well Greg, you know,
you're learning all of this, right?
In terms of why projects fail, you're taking in some of what
Mark has written on this. And how has that really shaped
your understanding of project execution.
How does that intertwine with everything?
You've been learning? Well, I think overall, Got the
mascot in the background there. I was going to say, I think your
dog has something to say about it.
Well, you know, he might have a couple of project failures and
he's handling it wrong. I think my dog is now talking to
your dog. This is great.
Yes. So for me, I've been really
trying to differentiate and I'm trying to differentiate well
where things happen as it relates to.
Planning and execution. So I'm very focused on the
execution aspect of things. And what I'm actually finding
out when I take what I learned from you, and what I learned
from Mark and then what? I put my own spin on, when I'm
out talking to people about it. I'm finding that most people, I
even did a survey recently didn't get a heavy response.
But I did a survey in the majority of people think that
their projects fail in the planning phase, and I'm not
saying plans aren't important. They are.
Absolutely critical, but what I've really learned where I'm at
right now today is your plan is great, but it can't see what
didn't happen yet. And that's why execution is the
key execution is the only place a project can actually fail.
If kids in the view that's been shaped for me thus far, that's
where you're going to find the most impactful way to drive your
project. What's late for you?
Let's dig in there. Because why do you think then
that the survey response was so heavy on the on that part of the
project? And he thought, I actually think
that we are all often trained that way by our jobs, by life
and process in and of itself is process.
It's a great thing, it really is, but when you've set a plan
and initiated process, now, Now what happens, what happens when
the things come up that my plan could not have possibly seen
what happens when I discover something.
Like, well, we are actually taking our plan putting it into
motion and we're finding that the people that are a part of
that plan are overestimating. In other words, putting in too
much safe. Time on their estimated
completions. So it has an impact that, sorry
about that, an impact, that permeates the project execution.
It It's showing up throughout. So I think the reason people
responded in that way, as they think, that's where it happens.
And interestingly enough those that chose for example,
multitasking or unplanned constraints uncanny, unplanned
constraints are actually bottlenecks that you didn't see
in your plan. So it was the survey was
designed in a way to see what people really think.
Multitasking in. And of itself, actually is one
of the most problematic. Things that happens in the
execution phase because if you've got too much buffer on
what you're doing and she's got too much buffer on what she's
doing. It starts to create time gaps
where people aren't actually doing that for this project.
They're multitasking. The the reason multitasking is
such a bad thing is one. Person cannot do two things at
once with full force. It's not possible, right?
So the survey Was really designed to figure out what are
people thinking, and it's what I suspected and it's what I'm what
I'm really focused on now, so I'm trying to kind of stitch
that together and figure out how to resolve it for people and
it's challenging because they know they have to change
behaviors and they don't really want to because then their boss
is going to say, what are you doing?
I'm trying to do well and they're like, well, yeah, but
what about this? So becomes a mess, you know,
it's interesting that dot to because when I Remember when I
was studying for the PNP and and in some of the courses I was
taking that there was such a huge emphasis.
And I think it also, hovered around pmbok 6th edition where
there was a huge emphasis, and the inputs and outputs of what
you were doing in the planning stage and how it without saying
it directly to a project manager.
It almost felt like p.m. I was telling you that, that's
where your emphasis and all your efforts should be placed all the
time that you could. Put into planning, will solve
all the rest of the problems that come afterwards and and I
love the kind of the dichotomy of what you just said, Greg
versus what, at least the weight my takeaways from when I was
really heavily into studying for the PMP that I just felt like
there was some emphasis around the planning phase and that's
why I probably would have responded in that way to to the
survey where in fact you bring up some very very great and
valid points. Out the areas that were then the
residual responses are really not happening in the planning
phase. Those are all in the execution
phase. So I think all great points.
Greg Mark, any thoughts here. Yeah.
Well Greg that Echoes, the research that I commissioned a
couple of years ago before I wrote my book, you know on
visual project management that you know, what do people think
the problem is. Most people think the problem is
plans and If we thanks great. Surprisingly, you know, I don't
have the research, the research in front of me.
But if you're interested, you can go on our website and get
it. But, you know, we found that
most people think that the product, the reason, the
projects fail is planning. And and I think that's because,
you know, when you get into execution, You know, unexpected
things happen are like I should have done a better job planning.
I should have, you know, I should have anticipated that.
Why wasn't this in the risk register?
Oh, we didn't do risk registers. Oh, well, there's that as kind
of a planning part and I think. So what happens is people point
to a lack of planning because they get surprises during the
project and and of course, surprises are the very nature of
projects and people will get that.
So I think that's what leads people to.
I think that it's the plan because they say oh, well, I
didn't expect this and it wasn't because I didn't expect it, you
know, so therefore I did a bad job of planning and I think that
think that project managers are too hard on themselves on their
planning ability because it's you know, you think about a
project plan, you know, you're predicting the future, you know,
and who I mean, okay, you know, we might have built this steam
shovel, you know 20 times before but this is a special one that
goes. On a boat or something, you know
yaxha same and then you put it on the boat in the boat sinks.
Oh, well, you didn't think about that, you know, so we must have
had a bad plan. So I think it's really just a
people are seeing these events during project execution that
they didn't expect and they say, well, I didn't expect it without
realizing that, that's just kind of how we the Project's work and
you're going to get weird stuff happening.
Know, someone's going to drive a fork truck off the dock or you
know, You know, you're going to have a valve blow up or you
know, whatever that whatever the unexpected event happens.
It's going to happen and you can't know what you don't know
until it happens. Yeah.
Yeah, and it's not, I mean, you
can only plan, you know, for what you know now and project by
their nature are unexpected. The uncertainty is what makes a
project a project, right? Otherwise, we'd be in
manufacturing, when you build a production line.
Otherwise it You know, now it's a project because we don't know.
Yeah, absolutely. I mean and then when you think
about it, even in our everyday lives, right?
Consider consider the time that you you are planning a vacation
or something and you forgot all the kids jackets, I'm just
whatever. But you know, when you have the
conversation with your spouse, it's not it's not about oh,
well, we forgot the jackets. Let's just go buy new ones, you
know, you're not kind of caught in the moment you're thinking
about. Well, it's your fault because
when Were packing. You totally forgot.
So here you are now stuck in the pattern over Munch.
Yeah, exactly. Didn't, you know, didn't you
look up the weather? You know, it's always again,
looking retrospectively at the past and blaming the part where
you were planning on on things and oh, you missed that.
So I think I think we're actually and let me know what
you both think about this, but I do believe.
We'll start to see a shift here in terms of that response to
Greg survey because I feel like that is in many ways.
Is Antiquated thinking in terms of being stuck in the planning
phase and blaming everything on the planning phase where as we
get more and more hybrid or agile projects that are coming
to the Forefront. I feel like those types of
projects we spend maybe maybe two weeks planning maybe four
weeks at the most planning and then we just go, we go straight
to execution. We say we'll just figure it out
as we're executing as things come up and I feel like with
more of that type of those types of projects being Being managed
by project managers that you might start to see a shift in
that response, from blaming it all on the past and the planning
phase versus blame it on the execution part of it.
I think that's a really interesting take and because
something that you just said and I think Mark would agree with
this is Plans are good. But execution is where it's
going to happen. And if you're executing in a
certain way, if your setup say, for example, using a Viewpoint
philosophy, your setup to see quicker mitigate faster, keep
the project moving. And what's interesting about
that whole thing is one of my side projects that I'm working
on is something. I was planning and planning and
planning. And I was like, I gotta get
Eddie, it's got to be like this. It's got to be like that.
And one day I saw something where someone was talking about
this concept of stop that go and I did and it started to make a
heck of a lot more sense. Because in the planning phase, I
was stuck because I was trying to anticipate everything, you
can't do that. You can't possibly do that.
So, like, Mark says and and like you say, if only we can Can get
moving and go that way, it'll, it'll kind of fill itself in and
it sounds haphazard and Reckless, but it's actually not
because what you're doing is, you're simplifying and you're
allowing yourself the ability to get unstuck and moving.
So it's a, it's a, it's a human concept.
That's applicable to our mechanized concepts of work, and
project, delivery and all those things.
I hope that's a fair assessment. It makes sense.
No, absolutely. And I think it kind of
intertwines with the question I had for Mark, which is, you
know, When is it good enough? When is it?
When is your plans? Good enough to just go?
I think you've done a little bit of work and you've talked about
this. So would love to hear your
thoughts there. Yeah.
All right. Well, there's two kind of two,
two, two things. I don't think about, you know,
one is alright, if I'm planning a project for the first time.
All right, let's say that, you know, there's, there's two
different kinds of projects. There's the truly worn off, you
know, we've never done. Done this before kind or
anything like it kind of a project and you know, for that
kind of a project, you know, you want to get your stakeholders.
The people were actually going to do the work or at least
eight, your subject matter experts in the room.
Making sure that you have all the relationships defined.
I think, what's good enough is we have a sense of what are the
relationships of all the tasks that have to be accomplished?
What are the deliverables that each one of those?
Tasks, you know, we've identified any stage gates in
the projects and we don't get too hung up on task estimation
task time estimation. I mean, you know, I always tell
people, look, that give me the, give me the green light time on
your task, Greenlight time means.
Listen, I'm going to drive to work today.
I get all green lights all the way.
It's going to take X, nothing's going to go wrong, you know,
it's going to take, you know, three weeks.
I'm not going to, I'm not going to call the new a meeting.
Or get sick or whatever thing might happen.
I'm going to devote 100% to this task.
I think it's going to take X and you know, that's good enough
because we put buffers in the project, right?
And say the project has a buffer, you don't have a buffer
and I understand if something goes wrong.
We're not going to beat you up because you made a bad estimate
on that. We got a buffer and that's what
that buffer is full right to absorb all of that under an
overestimation of task times. The big thing we Is what are the
relationships of the tasks who's going to own them?
And that is good enough. Now for a project where we have
a series of projects, like let's say that we're an engineer to
order manufacturer and you know, are we make?
I don't know, cabinets, kitchen cabinets or, you know, kitchen
cabinets are pretty simple. All right there boxes, but they
have all the boxes and drawers, and they have doors and, you
know, framing elements. And stuff like that, but then
you get into, okay. What's the Finish?
What kind of knobs we want? What's the door look like, you
know, there's all kind of like these different plug-in
variables to know. By the way, we're going to go to
install this place that we've never installed before, you know
for those kinds of projects. I'm looking at the history and
say, all right. Well, how long does stuff take
where are the management points? And I'm just going to map out a
kind of just a simple flow chart and say we're going to do this,
this this and then we're going to stop and approve and there
are no this Justice or stop on the proof.
So we build more of a swiveling Sharp than a project plan for
those kinds of projects because we don't need to do that.
The other thing I want to mention is something that Greg
touched on was, you know, hey stuff's going wrong with the
project and stuff in. I think a lot of people get
confused about the role of a risk register in the risk
management process in the planning process, right, you
know, because, you know, you you make your plan and you say,
okay, if everything goes Goes according to plan, we're going
to be here. But here's the uncertainty in
the project. I did a, I did a project for a
company that was designing. A chip for the PS Sony.
PSP. PlayStations.
Right? And they were they were
upgrading the USB is going to use B to C.
So this is a couple of years, a couple of years ago and they're
like, man, we go to be when we go put that that that in the
ship then the chip melts and is hot.
You know, so you know, what we had to do was build kind of like
a little off ramp and say, okay. Well if we don't get this
problem solved, you know, then we're going to go do it this way
and that happens. It's not part of the project
plan necessarily. It's more of a contingency
planning process. That happens outside of the
normal. What are the what are the steps
that we have to accomplish and what are the resources that we
have to accomplish? So good?
Enough is just, what understanding.
What is the work who's going to be?
Do it? What's the sequence?
And we don't get too hung up on how long does it take?
And we don't beat people up in execution because you said it
was going to take a week. And now it's taken three.
Well, you know, that's just that's just another form of the
other project plan, you know, the other problem certainty that
I was talking about. So it really makes sense.
I'll I'm carrying that model with me all the time now and
just like Mark has told us what good enough means.
I think this podcast has been good enough for our audience.
See what I did there. So, You both.
Thank you both for joining me and speaking about why projects
fail. And also understanding that
there are moments where you have to tell yourself.
It's good enough. Let's just go Greg.
I love that also about what you've been working on.
So, looking forward to seeing what that's all about to.
So that will do it for Mark Greg.
And I, and this installment of the everyday p.m.
Podcast Mark for those that want to continue this conversation
with you. Where can they find you online?
You can go to projects in. Less time.com and you'll find
all of the books and white papers.
There's no Gateway that you have to enter your e-mail.
I just want to have a material out there.
First. You got to go to Amazon to buy
my book projects visual project management, but you know,
there's that definitely. How do I support you?
Absolutely. And Greg, what about if folks
want to follow, you know for me you can find me on LinkedIn.
Greg kristensen, you'll see the project Hub stuff and few other
things hopefully to get And then you could also go to Project
help.com. And if you were to sign up,
that's because you're intending to try it out, get in there and
have some fun with it. And you'll reach me that way
because I'm typically going to have visibility to that when
people engage and those are the two ways for me.
Well, it's been a pleasure to speak with you both again, and I
hope to see you back on the podcast for another engaging
topic. I think we can go off on good
enough in another complete series of this.
So folks you can also find me on on LinkedIn if you want to
connect as well as the everyday p.m..com.
Make sure to support the everyday p.m.
Podcast. We're on all of your podcasting
platforms Spotify. Google play, Apple podcast.
You name it? Give us a five star review.
Leave us a great comment. Let us know what you think about
why projects fail. You can also watch the video
version of this and see Mark scrambled for his phone and Greg
tell his dog to stop barking. And me tell my dog to stop
barking as well. You could watch us do all of
these shenanigans on my YouTube channel.
Tom Ford, slash and campea while you're there.
Subscribe to the channel. Click like on this video, leave
us a comment and click that Bell for notifications of when new
content goes up, so that will do it for all of us.
Thanks so much for joining me and Mark and great.
And until next time. Take care.