January 10, 2024 • 28 mins
Are we measuring our project triumphs through a blurred lens? Join me, Mounir Ajam, as we challenge the prevailing norms in project management. With more than three decades of expertise at the helm, I dissect the perplexing reasons why many projects sink despite seemingly calm seas. We're not just discussing the metrics of success; we're redefining them. As we navigate the murky waters of high failure rates and the desperate need for standardized success measures, we tap into the pulse of what makes or breaks a project's outcome—unfiltered client feedback, quantifiable objectives, and the art of aligning anticipated benefits with actual results.
In our latest exploration, I unravel the threads of communication breakdowns and executive support, revealing how they weave a tapestry of project outcomes. We take a critical look at the lack of robust management systems and policies that often lead us astray and ponder the transformative power of diversity within project management. The conversation turns introspective as we consider our own reluctance to revamp flawed procedures and the vital impact of earning executive buy-in. As we close, the stage is set for our next episode, where we'll delve into the role of diversity in building a stronger, more inclusive project management community. So, lend your voice to this vital discourse and arm yourself with the insights needed to steer your projects towards uncharted territories of success.
Explore more project management insights at www.urukpm.com
Connect with Uruk Project Management:
Uruk PM | Blog
Uruk Project Management | LinkedIn
Uruk PM | Twitter
Uruk PM | Facebook
Uruk PM | Instagram
Uruk PM | Youtube
#UrukPM #ProjectManagement #Podcast
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Mounir Ajam (00:05):
Good day, howdy, and welcome to the 4 pm podcast.
My name is Munir Ajam.
My core passion is projectmanagement and community.
I come to you with at leastclose to 35 years of experience
and my eagerness to shareknowledge and to mentor and
(00:26):
coach and grow to see where wecan help organization transform
the way they manage project to ahigher level.
4 pm which means projectprogram, product and portfolios.
A lot of our topics will bearound this 4 pm.
Let's get going.
Welcome to the 4 pm podcastepisode number two.
(00:54):
In the last podcast episode weasked a question which was what
do you think?
How are we doing as a projectmanagement domain?
Is the project managementdomain in good health or
something else?
If you haven't had a chance tothink about this or maybe to
(01:15):
listen to our previous episode,just maybe you can pause this
episode today and just thinkabout that before you continue
listening.
So what do you think?
Obviously, unfortunately, inthese kind of things we cannot
collect your input, buthopefully you have thought about
this Now.
We have been thinking aboutthis for a long time and
(01:36):
obviously our view is that weare doing good overall.
I mean, we cannot say that weare in a bad shape.
The project management communityhas been around, formally or
informally, for many years anddecade.
However, we still see a lot ofpain points.
Although many professionalassociations have existed for
(01:57):
more than 50 years, projectmanagement literatures and
content have been there foralmost a decade.
In some cases, we're still notdoing enough, and so what we
felt is that there is a need fortransformation, and this is why
we are calling this episode,the current state of practice,
(02:19):
the case for transformation.
Why do we need to transform?
Or do we need to transform?
Obviously, we believe we needto transform, and this is why
this episode is here and now.
We can only believe we need totransform.
We made it our mission as acompany to help organization
transform, and here I will readfor you our mission statement
(02:40):
Through integrating people,processes and technology, we aim
to transform how organizationmanage project, while leading
the way to making projectmanagement indispensable for
organizational success.
That is our mission as acompany, and everything we do
(03:01):
whether for commercially,business coaching, mentoring,
these episodes, the blog views,videos whatever we do is
centered around this mission isto help transform the way
organization manage project.
(03:37):
.
(06:17):
So the question here do youmeasure project or program
success today in yourorganization?
How do you ask for feedback andsurveys, opinion?
Do you use quantifiablemeasures?
Do you establish successcriteria early on in the project
or the program and assesssuccess later on in line with
(06:39):
the criteria you define?
So, basically, you set thebaseline and you measure against
that baseline.
And maybe one final questionhere Do you ever evaluate the
outcome, success and benefit ofyour project compared to the
anticipated benefit when youlaunch a project or program?
Obviously, every organization,when they launch a project,
(07:00):
regardless what it is, whetherit's for money or profit or
non-profit or government,whatever the case might be, they
are expected anticipatedbenefits from that project.
Do we actually measure thatafter the project is finished?
Do we come back in organizationtoday and measure whether that
(07:21):
project delivers that outcome,again in a quantifiable way.
I can give you an answerbecause from my experience, I
can give you my experience.
Often enough on most of thesequestions we've seen that
organization don't do that.
And one reason again going backto the main header of this topic
, which is the absence ofproject management success
(07:44):
standard or project successstandard.
So we don't have definition.
If we don't have definition, orat least a common definition,
every company could have its owndefinition, but if we don't
have a common definition, thenas an industry, how can we
measure?
How can we measure whether weare making some good progress or
we are basically reducing therate of failure of project or
(08:05):
increasing the chance of success?
Again, without properdefinition and standardized way
of measuring, how can we tell?
Now, I don't think there is asingle way we can measure.
However, in each industry, atleast in each type of industry
that uses project management, wecan define and we can establish
some common guideline andstandard.
(08:26):
So we don't clearly distinguish.
Another area here another factorthat we have a problem with is
that not only we don't haveproper definition or standard or
guide, we also often do notdifferentiate or distinguish
between a project success orfailure and project management
(08:46):
success or failure.
In other words, when you askpeople, when we talk about
project success online and oursocial media and our link in
post, what are we talking about?
Are we talking about technicalsuccess?
Are we talking about projectmanagement success, or are we
talking about product deliverysuccess, or are we talking about
(09:06):
business or objective success?
Notice, I've mentioned fourthings here, and the reason I
mentioned those four thingsbecause they relate to something
we have developed years agocalled the four dimensions of
project success.
Now, I'm not going to explainthem today.
We will dedicate in a futureepisode for this topic and we'll
include maybe a link to a videoand maybe a blog article,
(09:30):
because that includes thevisualization of this topic, but
one of those topics that itwill be good to see, some
illustration of these fourdimensions that I just mentioned
.
So I will close this part bysaying we need something that we
can depend on, at least withineach domain or industry, that in
order to, when we talk aboutproject success, we have a
(09:53):
common reference.
Otherwise, we only end up withgetting subjective statement.
Now the second part of thisepisode, part two, is the high
rate of failure.
Now, I'm not saying definitely.
I need to be absolutely clear.
I'm not saying project failbecause we don't have definition
(10:17):
right.
That has nothing to do with it.
Just the lack of definition orcommon standard doesn't allow us
to measure properly.
However, what we know and basedon the numerous research
information that is publishedout there and some of it might
be questionable, some of itmight be sensational reporting
and I'm using this term where wetalk about only one in 1000
(10:40):
project fail, if we don'tprovide the criteria, when
someone tell me, regardless whothat person is or whatever they
come from, or whether they comefrom a respected organization or
not, when we say one in 1000project fail or 80% succeed,
doesn't matter either way.
What is the standard?
What is the foundation?
(11:00):
What is the basis of thoseclaims?
I'm not saying one in 1000success, only one in 1000
success.
That is a lie, of course, Idon't know.
The question is that what isthe basis for that number?
When I say 30% success or 60%success or 70% success or
(11:21):
failure, what is the referencefor that information?
If we don't have that, then weare basically just creating a
lot of posts where we debate anddebate and debate, but with no
conclusion or no proper passforward.
What we know is that, despitethis argument, if you look at
certain I'm not going to nameany, but example I will mention.
(11:42):
There is one without the name,one organization that often
people question their surveysbut for many years they've been
publishing surveys so I can saymaybe I don't trust their way of
measuring.
However, when for 20, 30 yearsthey've been measuring, let's
say, using the same method,right or wrong, and they're
basically telling us thatproject success is only about
one third of project aresuccessful and two thirds are
(12:04):
challenge or are failure, thendefinitely that raises flag.
That means a lot of, at leastsubjectively, we can say maybe
this is the case when we look atstudies by Oxford University.
They publish a lot on capitalproject and infrastructure
project.
They publish a lot of reallyserious stuff where high degree
(12:24):
of failure.
One organization I respect iscalled Independent Project
Analysis and they do a lot ofbenchmarking in the capital
project industry and they havedone quite a bit of intensive
research right and one bookpublished called Industry and
Mega Project that talked aboutonly 35% of mega project under
that study were successful andthe average size of a project
(12:46):
under that study was about 3.2billion dollars, in some cases
over budget and over run were upto 40%, if not more.
Now imagine 40% on a billiondollar.
2 billion dollar, 3 billiondollars.
How much money is that?
What can we do with that money?
And this is only one study ofmaybe 300 projects.
(13:09):
Today there are trillions ofdollars being spent on project
and project management and yetwe still see a high degree of
failure.
Now in my books I talked a lotabout the actual research and
our pitch tech.
We talk about that, so I'm notgoing to go through a lot of
percentages here, but I'm goingto say basically, whether we are
dealing with industrial,petrochemical, oil and gas,
(13:31):
renewable infrastructuretechnology, the rate of failure
is high.
Now here I need to again remindyou to distinguish between
project management failure andproject failure.
Now project management failurecould be obviously the project
might end up being over budgetor behind schedule, but still
(13:51):
deliver something of benefit,and now, maybe lower than what
we anticipated.
Maybe we don't achieve the fullbenefit we expect, maybe our
return investment is lower thanwhat we expect, but at least the
project is completed, withproject cost schedule problem
and maybe some quality problem.
However, the project wasultimately finished and is in
(14:13):
use.
Then we have project in general,when we talk about project
failure or success, in some timewe end maybe some project that
actually fail, and usually thoseare either terminated early,
they're never finished or whenthey're finished, nobody care
about them, nobody uses theirproduct.
So, in a way that is waste, alot of waste of resources, of
(14:34):
money, of budget, of you name it, not to mention the frustration
and probably the career endingfor many people.
So we know, based on a lot ofliterature, including some of my
work and my own research, thatwe do have a high degree of
failure.
Again, I mentioned OxfordUniversity, ipa, others as well.
(14:55):
Pmi basically tell us incapital project, at least 70% of
these projects suffer from costor schedule.
Again, there are a lot ofresearch studies by independent
expert all over the world.
So failure is more common thansuccess.
This is a problem for all typeof organization, all sector,
(15:20):
whether technology,infrastructure, oil and gas,
industrial, medical, whateverthe case might be, and it's all
over the world.
So this is a problem.
Now, we highlighted the lack ofstatistics where we will be able
to share some good numbers thatare understood.
We talked about failure andsuccess and the high rate of
(15:40):
failure.
Now, what are the causes?
And here, if we ask 10 peopleto tell us what caused the
project to fail and if you likeyou can pause and start to think
about it, and I'm sure we couldhear 50 to 100 reasons.
(16:03):
I mean, even if you pause rightnow and you think about it, you
probably come up with five orsix reasons on your own.
So why do project fails?
Is it 50, 100 reasons?
Are there cause or failure?
Now, if we think about the rootcause, for example, there are
many ways to determine the rootcause and there are many
(16:23):
techniques and businesstechniques.
So I'm not going to go into anacademic discussion right now,
but let's give you an example.
So, for example, if we saycommunication, recently we've
seen a lot of posts to say thatcommunication is the number one
problem for project failure.
Is communication the problem,and in this case, what I mean by
that?
Is it a root cause or is it asymptom of something else?
If you really think about it,most likely it's a symptom
(16:49):
Communication problem, materialproblem, delays, resource
problem, competency problem,whatever you call you might call
a problem that we face on aproject.
If you think about it, you willprobably can understand that
that is a symptom, not a rootcause.
(17:11):
Why do I say that?
Because if we have a problem incommunication, it's probably
because we don't have the propersystem, the policies, the
guidelines, the procedure of howto communicate effectively and
here I'm not talking about howwe talk basically the
communication on project, theability to keep people informed,
the stakeholders, who weprobably do not have a proper
(17:34):
systems in place.
In that case that's a rootcause.
Or, if a system is in place,it's often ignored or not used
or not followed properly.
And it's interesting to findthroughout my 30 plus years of
life and the professional workin my career, I've always
experienced that it's easy forpeople, including me in the past
(17:57):
, before I learned and I woke upit's easier for us to violate a
procedure, to ignore aprocedure, to bypass a procedure
or a policy or a guideline ifwe don't like it or if we don't
think it's practical.
Rather than trying to raise thediscussion that we need to
change that policy, procedure orguideline, we take the easy way
(18:19):
.
We shouldn't be.
The easy way is by deviatingfrom the process, violating it,
ignoring it, whatever the casemight be, but we don't spend the
time and effort to raise theissue with our management or if
we are the manager, to spend thetime, to take time out of our
daily busy running life to tryto change something that we
(18:44):
think is not logical or shitdoesn't work.
So this is why we have manyoften we run into problem that
we might have a system but thesystem could be outdated.
So here what we are saying isthat the root cause partially is
related to the system.
But let me be more elaborate onthis.
Here is what we think.
Obviously, we cannot generalize, because this is a likely
(19:05):
scenario and it could vary fromone organization or one industry
to another.
The root cause this is, in ouropinion, as a root, project
management and obviously myopinion as Munir Hajjan.
The root cause is two sides ofthe same coin.
The primary issue, the primaryside, is that the lack of
adequate lack of adequaterecognition of the strategic
(19:32):
value of project management byexecutive.
Sorry, guys, I am an executive,obviously in a small company,
so I'm not trying to badmouththe executive here.
However, executives rightfullyso probably have seen a lot of
failures in project management.
So it's getting to the pointwhere project management is
(19:52):
becoming a bad word.
Executive don't to a largedegree.
They might not say this, but Iknow they feel it inside that
they don't trust projectmanagement enough.
Now, I know I might beexaggerating here, but really
think about this.
(20:13):
Often a lot of organizationsstill do not have proper project
management system, policies,guidelines or even project
management departments or PMO.
I will talk in the future aboutPMO versus PM department.
But for now, what we're saying?
They don't have projectmanagement formalized in their
organization.
(20:34):
Why?
Because they don't see thevalue.
If they see a value, they willorganize it because they don't
see the value.
And again, whether they don'tsee it because they have not
been given enough informationfor awareness or because they've
seen in their past projectmanagement failed to deliver.
(20:55):
So whether it's we caused thatproblem, we shut ourselves I'm
talking about we meaning projectmanagement community.
We shut ourselves and the footby not delivering success.
As a result, we lost the trustof executive.
Or maybe because the executiveare not aware about the value
and we haven't spent enough timeeducating or sharing or helping
(21:15):
them understand the value, andof course, not through theory,
through practice and throughdemonstrated value.
As a result of that, we end upwith a situation where, again,
the lack of adequate recognitionof strategic value of project
management by executive whichcontribute to the second side of
the common, because executivemay not see the value.
(21:39):
As a result of that, we noticein a lot of organizations there
is an absence of any effectiveor sustainable organizational
project management system.
And when you say system here Idon't talk about technology, I
mean system that includespolicies, guidelines, procedures
, including technology and PMIS,and whatever else that needed
to help us effectively manageand lead project program and
(22:02):
entire portfolio.
So which one comes first?
I think both you know in a way.
That's why we say to side ofthe common you know we don't
have a proper system.
So every project person,project manager, manage project.
You know we end up withbasically what we call the
accidental project manager.
People practice projectmanagement on their own way of
thinking, but that they leave isbest, and obviously that used
(22:23):
to be the case for many, manyyears, recent years, maybe, with
certification more formalized.
But I can tell you I'm notgoing to go there today.
I don't think certification hashelped, unfortunately.
But again, that's a huge topicby itself.
We leave it for now.
What we know is that today inmany organizations we've seen or
worked with, obviously we don'thave a proper system.
(22:45):
Now why?
Maybe because the executivedon't believe.
Now in some cases we haveorganization, have system, but
again is like what I said beforeit could be outdated, people
might choose to bypass it.
Maybe I can share a case here,an example years ago a client of
mine, a major global company,asked me to come in and to
evaluate how can we improvetheir project management system.
(23:07):
And when I was meeting withmany of their managers said we
don't need you, we have ourmanuals.
Said okay, one, two, threemanager, executive, basically
all the, we don't need you, wehave our manager.
So we had a meeting with manyof their project manager and
project team leader at the lowerlevel and we start asking
questions how do you do this,how do you do that?
And everybody will come up witha different answer.
(23:28):
Said wait a minute, I thoughtyou guys have manuals.
Who use them?
And the old days manual used tobe created and sit on the shelf
collecting dust.
Maybe when they first release,people use them.
But then, sooner or later, maybesomebody say ah, you know this,
this guy doesn't work and thisguy does out of date and this
guy doesn't make sense and thisguy is full of BS, so ignore
(23:52):
them.
And all of a sudden we start toignore those system and we go
back to an ad hoc scenario whereeverybody does it whatever,
which way they want, so that andmaybe that start to get into
the cycle of doom.
Then project suffers, executivedon't?
They start to feel like, heyguys, you're not delivering and
of course we end up basicallywith you know, repeated cycle of
(24:14):
doom.
So what is the proper OPM that?
We will have many episodes onthat in the future, so I will
not talk about it today.
I just want to introduce it.
That brings me to the last partof the presentation or of the
episode.
We should talk abouttransformation.
So how can we transform projectmanagement?
(24:36):
I will keep it very brief todaybecause, again, we will have
many episodes on this.
These are huge topic it's justimpossible to cover in a short
episode.
How can we transform projectmanagement In this context?
Remember the 4pm.
So when I talk about, I'm nottalking about only managing
project, we're talking aboutproduct, we're talking about
program, we're talking aboutportfolio.
We believe we need somethingthat is centered, focused,
(25:00):
emphasized, all over the idea ofvalue delivery, value delivery.
We must deliver value.
Project owners, all companies,renewable energy companies,
hospital, clinic, hospitality,hotel, restaurant.
They don't care about physicaldoing, project or project
(25:23):
management.
They care about the value theproject gives them.
When we do a new software, wedon't care about the project
itself, and I mean by this wedon't care or executive don't
care in the sense about themechanism of getting that result
.
That's important.
They obviously they care.
However, what they care aboutthe most is the value that is
(25:46):
delivered.
You can have great systemprocesses, guidelines, software,
fancy chart, beautifulperformance chart, dashboard,
but if you cannot deliver value,it means nothing.
Think about that.
We must learn how to delivervalue and unfortunately, even
(26:09):
some guide and projectmanagement in up to recent years
they think project only.
We should care as a community,as project management.
We should only care aboutdelivering output, which means a
physical product.
Ah, I delivered this wall,great, but the value of that
wall.
So from that perspective, weneed to focus on that, and then
(26:29):
I will be again.
I will be expending on this inthe future topic.
Today I want to say there arenumerous ways to help us
transform project management andthis is why this is an
objective and a mission for us.
Our approach as a group projectmanagement as a company is
centered on the principle, ideaIntegration to deliver value.
(26:51):
So back to value right Now.
What does that mean?
I will leave you on suspensefor now.
Time to close this episode.
Remember, we talked about thelack of definition of project
success standard or guide on aconsistent way of measuring
success.
We talked about the highfailure in project and project
(27:13):
management.
We talked about the root causesand we talked about the need
for transformation.
Now I want to close, and we'llprobably make it a habit in
every episode.
We'll try to help you thinkabout the next episode, which is
in the next episode, we willdiscuss something related to
transformation, but as basicallydeal with the idea that to
(27:37):
transform, we must first respectour diversity in the project
management community.
So what do you think that meansin the project management
context?
What diversity means?
How can we respect ourdiversity?
Again, think about thisquestion, and when we start
(27:57):
posting on our social media, I'dlove to hear your opinion and
feedback.
With this, I want to close bysaying we wish you success today
, tomorrow and always.
Good day, howdy, and welcome to the 4 pm podcast.
My name is Munir Ajam.
My core passion is projectmanagement and community.
I come to you with at leastclose to 35 years of experience
and my eagerness to shareknowledge and to mentor and
(00:26):
coach and grow to see where wecan help organization transform
the way they manage project to ahigher level.
4 pm which means projectprogram, product and portfolios.
A lot of our topics will bearound this 4 pm.
Let's get going.
Welcome to the 4 pm podcastepisode number two.
(00:54):
In the last podcast episode weasked a question which was what
do you think?
How are we doing as a projectmanagement domain?
Is the project managementdomain in good health or
something else?
If you haven't had a chance tothink about this or maybe to
(01:15):
listen to our previous episode,just maybe you can pause this
episode today and just thinkabout that before you continue
listening.
So what do you think?
Obviously, unfortunately, inthese kind of things we cannot
collect your input, buthopefully you have thought about
this Now.
We have been thinking aboutthis for a long time and
(01:36):
obviously our view is that weare doing good overall.
I mean, we cannot say that weare in a bad shape.
The project management communityhas been around, formally or
informally, for many years anddecade.
However, we still see a lot ofpain points.
Although many professionalassociations have existed for
(01:57):
more than 50 years, projectmanagement literatures and
content have been there foralmost a decade.
In some cases, we're still notdoing enough, and so what we
felt is that there is a need fortransformation, and this is why
we are calling this episode,the current state of practice,
(02:19):
the case for transformation.
Why do we need to transform?
Or do we need to transform?
Obviously, we believe we needto transform, and this is why
this episode is here and now.
We can only believe we need totransform.
We made it our mission as acompany to help organization
transform, and here I will readfor you our mission statement
(02:40):
Through integrating people,processes and technology, we aim
to transform how organizationmanage project, while leading
the way to making projectmanagement indispensable for
organizational success.
That is our mission as acompany, and everything we do
(03:01):
whether for commercially,business coaching, mentoring,
these episodes, the blog views,videos whatever we do is
centered around this mission isto help transform the way
organization manage project.
(03:37):
.
(06:17):
So the question here do youmeasure project or program
success today in yourorganization?
How do you ask for feedback andsurveys, opinion?
Do you use quantifiablemeasures?
Do you establish successcriteria early on in the project
or the program and assesssuccess later on in line with
(06:39):
the criteria you define?
So, basically, you set thebaseline and you measure against
that baseline.
And maybe one final questionhere Do you ever evaluate the
outcome, success and benefit ofyour project compared to the
anticipated benefit when youlaunch a project or program?
Obviously, every organization,when they launch a project,
(07:00):
regardless what it is, whetherit's for money or profit or
non-profit or government,whatever the case might be, they
are expected anticipatedbenefits from that project.
Do we actually measure thatafter the project is finished?
Do we come back in organizationtoday and measure whether that
(07:21):
project delivers that outcome,again in a quantifiable way.
I can give you an answerbecause from my experience, I
can give you my experience.
Often enough on most of thesequestions we've seen that
organization don't do that.
And one reason again going backto the main header of this topic
, which is the absence ofproject management success
(07:44):
standard or project successstandard.
So we don't have definition.
If we don't have definition, orat least a common definition,
every company could have its owndefinition, but if we don't
have a common definition, thenas an industry, how can we
measure?
How can we measure whether weare making some good progress or
we are basically reducing therate of failure of project or
(08:05):
increasing the chance of success?
Again, without properdefinition and standardized way
of measuring, how can we tell?
Now, I don't think there is asingle way we can measure.
However, in each industry, atleast in each type of industry
that uses project management, wecan define and we can establish
some common guideline andstandard.
(08:26):
So we don't clearly distinguish.
Another area here another factorthat we have a problem with is
that not only we don't haveproper definition or standard or
guide, we also often do notdifferentiate or distinguish
between a project success orfailure and project management
(08:46):
success or failure.
In other words, when you askpeople, when we talk about
project success online and oursocial media and our link in
post, what are we talking about?
Are we talking about technicalsuccess?
Are we talking about projectmanagement success, or are we
talking about product deliverysuccess, or are we talking about
(09:06):
business or objective success?
Notice, I've mentioned fourthings here, and the reason I
mentioned those four thingsbecause they relate to something
we have developed years agocalled the four dimensions of
project success.
Now, I'm not going to explainthem today.
We will dedicate in a futureepisode for this topic and we'll
include maybe a link to a videoand maybe a blog article,
(09:30):
because that includes thevisualization of this topic, but
one of those topics that itwill be good to see, some
illustration of these fourdimensions that I just mentioned
.
So I will close this part bysaying we need something that we
can depend on, at least withineach domain or industry, that in
order to, when we talk aboutproject success, we have a
(09:53):
common reference.
Otherwise, we only end up withgetting subjective statement.
Now the second part of thisepisode, part two, is the high
rate of failure.
Now, I'm not saying definitely.
I need to be absolutely clear.
I'm not saying project failbecause we don't have definition
(10:17):
right.
That has nothing to do with it.
Just the lack of definition orcommon standard doesn't allow us
to measure properly.
However, what we know and basedon the numerous research
information that is publishedout there and some of it might
be questionable, some of itmight be sensational reporting
and I'm using this term where wetalk about only one in 1000
(10:40):
project fail, if we don'tprovide the criteria, when
someone tell me, regardless whothat person is or whatever they
come from, or whether they comefrom a respected organization or
not, when we say one in 1000project fail or 80% succeed,
doesn't matter either way.
What is the standard?
What is the foundation?
(11:00):
What is the basis of thoseclaims?
I'm not saying one in 1000success, only one in 1000
success.
That is a lie, of course, Idon't know.
The question is that what isthe basis for that number?
When I say 30% success or 60%success or 70% success or
(11:21):
failure, what is the referencefor that information?
If we don't have that, then weare basically just creating a
lot of posts where we debate anddebate and debate, but with no
conclusion or no proper passforward.
What we know is that, despitethis argument, if you look at
certain I'm not going to nameany, but example I will mention.
(11:42):
There is one without the name,one organization that often
people question their surveysbut for many years they've been
publishing surveys so I can saymaybe I don't trust their way of
measuring.
However, when for 20, 30 yearsthey've been measuring, let's
say, using the same method,right or wrong, and they're
basically telling us thatproject success is only about
one third of project aresuccessful and two thirds are
(12:04):
challenge or are failure, thendefinitely that raises flag.
That means a lot of, at leastsubjectively, we can say maybe
this is the case when we look atstudies by Oxford University.
They publish a lot on capitalproject and infrastructure
project.
They publish a lot of reallyserious stuff where high degree
(12:24):
of failure.
One organization I respect iscalled Independent Project
Analysis and they do a lot ofbenchmarking in the capital
project industry and they havedone quite a bit of intensive
research right and one bookpublished called Industry and
Mega Project that talked aboutonly 35% of mega project under
that study were successful andthe average size of a project
(12:46):
under that study was about 3.2billion dollars, in some cases
over budget and over run were upto 40%, if not more.
Now imagine 40% on a billiondollar.
2 billion dollar, 3 billiondollars.
How much money is that?
What can we do with that money?
And this is only one study ofmaybe 300 projects.
(13:09):
Today there are trillions ofdollars being spent on project
and project management and yetwe still see a high degree of
failure.
Now in my books I talked a lotabout the actual research and
our pitch tech.
We talk about that, so I'm notgoing to go through a lot of
percentages here, but I'm goingto say basically, whether we are
dealing with industrial,petrochemical, oil and gas,
(13:31):
renewable infrastructuretechnology, the rate of failure
is high.
Now here I need to again remindyou to distinguish between
project management failure andproject failure.
Now project management failurecould be obviously the project
might end up being over budgetor behind schedule, but still
(13:51):
deliver something of benefit,and now, maybe lower than what
we anticipated.
Maybe we don't achieve the fullbenefit we expect, maybe our
return investment is lower thanwhat we expect, but at least the
project is completed, withproject cost schedule problem
and maybe some quality problem.
However, the project wasultimately finished and is in
(14:13):
use.
Then we have project in general,when we talk about project
failure or success, in some timewe end maybe some project that
actually fail, and usually thoseare either terminated early,
they're never finished or whenthey're finished, nobody care
about them, nobody uses theirproduct.
So, in a way that is waste, alot of waste of resources, of
(14:34):
money, of budget, of you name it, not to mention the frustration
and probably the career endingfor many people.
So we know, based on a lot ofliterature, including some of my
work and my own research, thatwe do have a high degree of
failure.
Again, I mentioned OxfordUniversity, ipa, others as well.
(14:55):
Pmi basically tell us incapital project, at least 70% of
these projects suffer from costor schedule.
Again, there are a lot ofresearch studies by independent
expert all over the world.
So failure is more common thansuccess.
This is a problem for all typeof organization, all sector,
(15:20):
whether technology,infrastructure, oil and gas,
industrial, medical, whateverthe case might be, and it's all
over the world.
So this is a problem.
Now, we highlighted the lack ofstatistics where we will be able
to share some good numbers thatare understood.
We talked about failure andsuccess and the high rate of
(15:40):
failure.
Now, what are the causes?
And here, if we ask 10 peopleto tell us what caused the
project to fail and if you likeyou can pause and start to think
about it, and I'm sure we couldhear 50 to 100 reasons.
(16:03):
I mean, even if you pause rightnow and you think about it, you
probably come up with five orsix reasons on your own.
So why do project fails?
Is it 50, 100 reasons?
Are there cause or failure?
Now, if we think about the rootcause, for example, there are
many ways to determine the rootcause and there are many
(16:23):
techniques and businesstechniques.
So I'm not going to go into anacademic discussion right now,
but let's give you an example.
So, for example, if we saycommunication, recently we've
seen a lot of posts to say thatcommunication is the number one
problem for project failure.
Is communication the problem,and in this case, what I mean by
that?
Is it a root cause or is it asymptom of something else?
If you really think about it,most likely it's a symptom
(16:49):
Communication problem, materialproblem, delays, resource
problem, competency problem,whatever you call you might call
a problem that we face on aproject.
If you think about it, you willprobably can understand that
that is a symptom, not a rootcause.
(17:11):
Why do I say that?
Because if we have a problem incommunication, it's probably
because we don't have the propersystem, the policies, the
guidelines, the procedure of howto communicate effectively and
here I'm not talking about howwe talk basically the
communication on project, theability to keep people informed,
the stakeholders, who weprobably do not have a proper
(17:34):
systems in place.
In that case that's a rootcause.
Or, if a system is in place,it's often ignored or not used
or not followed properly.
And it's interesting to findthroughout my 30 plus years of
life and the professional workin my career, I've always
experienced that it's easy forpeople, including me in the past
(17:57):
, before I learned and I woke upit's easier for us to violate a
procedure, to ignore aprocedure, to bypass a procedure
or a policy or a guideline ifwe don't like it or if we don't
think it's practical.
Rather than trying to raise thediscussion that we need to
change that policy, procedure orguideline, we take the easy way
(18:19):
.
We shouldn't be.
The easy way is by deviatingfrom the process, violating it,
ignoring it, whatever the casemight be, but we don't spend the
time and effort to raise theissue with our management or if
we are the manager, to spend thetime, to take time out of our
daily busy running life to tryto change something that we
(18:44):
think is not logical or shitdoesn't work.
So this is why we have manyoften we run into problem that
we might have a system but thesystem could be outdated.
So here what we are saying isthat the root cause partially is
related to the system.
But let me be more elaborate onthis.
Here is what we think.
Obviously, we cannot generalize, because this is a likely
(19:05):
scenario and it could vary fromone organization or one industry
to another.
The root cause this is, in ouropinion, as a root, project
management and obviously myopinion as Munir Hajjan.
The root cause is two sides ofthe same coin.
The primary issue, the primaryside, is that the lack of
adequate lack of adequaterecognition of the strategic
(19:32):
value of project management byexecutive.
Sorry, guys, I am an executive,obviously in a small company,
so I'm not trying to badmouththe executive here.
However, executives rightfullyso probably have seen a lot of
failures in project management.
So it's getting to the pointwhere project management is
(19:52):
becoming a bad word.
Executive don't to a largedegree.
They might not say this, but Iknow they feel it inside that
they don't trust projectmanagement enough.
Now, I know I might beexaggerating here, but really
think about this.
(20:13):
Often a lot of organizationsstill do not have proper project
management system, policies,guidelines or even project
management departments or PMO.
I will talk in the future aboutPMO versus PM department.
But for now, what we're saying?
They don't have projectmanagement formalized in their
organization.
(20:34):
Why?
Because they don't see thevalue.
If they see a value, they willorganize it because they don't
see the value.
And again, whether they don'tsee it because they have not
been given enough informationfor awareness or because they've
seen in their past projectmanagement failed to deliver.
(20:55):
So whether it's we caused thatproblem, we shut ourselves I'm
talking about we meaning projectmanagement community.
We shut ourselves and the footby not delivering success.
As a result, we lost the trustof executive.
Or maybe because the executiveare not aware about the value
and we haven't spent enough timeeducating or sharing or helping
(21:15):
them understand the value, andof course, not through theory,
through practice and throughdemonstrated value.
As a result of that, we end upwith a situation where, again,
the lack of adequate recognitionof strategic value of project
management by executive whichcontribute to the second side of
the common, because executivemay not see the value.
(21:39):
As a result of that, we noticein a lot of organizations there
is an absence of any effectiveor sustainable organizational
project management system.
And when you say system here Idon't talk about technology, I
mean system that includespolicies, guidelines, procedures
, including technology and PMIS,and whatever else that needed
to help us effectively manageand lead project program and
(22:02):
entire portfolio.
So which one comes first?
I think both you know in a way.
That's why we say to side ofthe common you know we don't
have a proper system.
So every project person,project manager, manage project.
You know we end up withbasically what we call the
accidental project manager.
People practice projectmanagement on their own way of
thinking, but that they leave isbest, and obviously that used
(22:23):
to be the case for many, manyyears, recent years, maybe, with
certification more formalized.
But I can tell you I'm notgoing to go there today.
I don't think certification hashelped, unfortunately.
But again, that's a huge topicby itself.
We leave it for now.
What we know is that today inmany organizations we've seen or
worked with, obviously we don'thave a proper system.
(22:45):
Now why?
Maybe because the executivedon't believe.
Now in some cases we haveorganization, have system, but
again is like what I said beforeit could be outdated, people
might choose to bypass it.
Maybe I can share a case here,an example years ago a client of
mine, a major global company,asked me to come in and to
evaluate how can we improvetheir project management system.
(23:07):
And when I was meeting withmany of their managers said we
don't need you, we have ourmanuals.
Said okay, one, two, threemanager, executive, basically
all the, we don't need you, wehave our manager.
So we had a meeting with manyof their project manager and
project team leader at the lowerlevel and we start asking
questions how do you do this,how do you do that?
And everybody will come up witha different answer.
(23:28):
Said wait a minute, I thoughtyou guys have manuals.
Who use them?
And the old days manual used tobe created and sit on the shelf
collecting dust.
Maybe when they first release,people use them.
But then, sooner or later, maybesomebody say ah, you know this,
this guy doesn't work and thisguy does out of date and this
guy doesn't make sense and thisguy is full of BS, so ignore
(23:52):
them.
And all of a sudden we start toignore those system and we go
back to an ad hoc scenario whereeverybody does it whatever,
which way they want, so that andmaybe that start to get into
the cycle of doom.
Then project suffers, executivedon't?
They start to feel like, heyguys, you're not delivering and
of course we end up basicallywith you know, repeated cycle of
(24:14):
doom.
So what is the proper OPM that?
We will have many episodes onthat in the future, so I will
not talk about it today.
I just want to introduce it.
That brings me to the last partof the presentation or of the
episode.
We should talk abouttransformation.
So how can we transform projectmanagement?
(24:36):
I will keep it very brief todaybecause, again, we will have
many episodes on this.
These are huge topic it's justimpossible to cover in a short
episode.
How can we transform projectmanagement In this context?
Remember the 4pm.
So when I talk about, I'm nottalking about only managing
project, we're talking aboutproduct, we're talking about
program, we're talking aboutportfolio.
We believe we need somethingthat is centered, focused,
(25:00):
emphasized, all over the idea ofvalue delivery, value delivery.
We must deliver value.
Project owners, all companies,renewable energy companies,
hospital, clinic, hospitality,hotel, restaurant.
They don't care about physicaldoing, project or project
(25:23):
management.
They care about the value theproject gives them.
When we do a new software, wedon't care about the project
itself, and I mean by this wedon't care or executive don't
care in the sense about themechanism of getting that result
.
That's important.
They obviously they care.
However, what they care aboutthe most is the value that is
(25:46):
delivered.
You can have great systemprocesses, guidelines, software,
fancy chart, beautifulperformance chart, dashboard,
but if you cannot deliver value,it means nothing.
Think about that.
We must learn how to delivervalue and unfortunately, even
(26:09):
some guide and projectmanagement in up to recent years
they think project only.
We should care as a community,as project management.
We should only care aboutdelivering output, which means a
physical product.
Ah, I delivered this wall,great, but the value of that
wall.
So from that perspective, weneed to focus on that, and then
(26:29):
I will be again.
I will be expending on this inthe future topic.
Today I want to say there arenumerous ways to help us
transform project management andthis is why this is an
objective and a mission for us.
Our approach as a group projectmanagement as a company is
centered on the principle, ideaIntegration to deliver value.
(26:51):
So back to value right Now.
What does that mean?
I will leave you on suspensefor now.
Time to close this episode.
Remember, we talked about thelack of definition of project
success standard or guide on aconsistent way of measuring
success.
We talked about the highfailure in project and project
(27:13):
management.
We talked about the root causesand we talked about the need
for transformation.
Now I want to close, and we'llprobably make it a habit in
every episode.
We'll try to help you thinkabout the next episode, which is
in the next episode, we willdiscuss something related to
transformation, but as basicallydeal with the idea that to
(27:37):
transform, we must first respectour diversity in the project
management community.
So what do you think that meansin the project management
context?
What diversity means?
How can we respect ourdiversity?
Again, think about thisquestion, and when we start
(27:57):
posting on our social media, I'dlove to hear your opinion and
feedback.
With this, I want to close bysaying we wish you success today
, tomorrow and always.
Popular Podcasts
Cold Case Files: Miami
Joyce Sapp, 76; Bryan Herrera, 16; and Laurance Webb, 32—three Miami residents whose lives were stolen in brutal, unsolved homicides. Cold Case Files: Miami follows award‑winning radio host and City of Miami Police reserve officer Enrique Santos as he partners with the department’s Cold Case Homicide Unit, determined family members, and the advocates who spend their lives fighting for justice for the victims who can no longer fight for themselves.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.