March 6, 2024 • 29 mins
In this episode, we share our thoughts on the Big Picture of Project Management.
We start by sharing our agility, resilience, and agile development story. Here, we discuss the ideas and approaches to developing products, including Big Bang, Iterative, and Incremental Development.
Then, we offer our counterpoints to some of the myths and narrow thinking associated with waterfall, agile, hybrid, and traditional project management.
We presented the myth of early and fixed detail planning.
Next, we addressed the myth of lack of communication in a non-Agile environment.
We addressed other points that Agilists often portray as anti-traditional Project Management.
Well, traditional project management IS project management. It has always been adaptive!
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.
Speaker 1 (00:08):
Welcome to the 4pm podcast.
My name is Munir Ajam and I'mthe founder and CEO of Aruq
Project Management.
My core passion is projectmanagement and community
development.
I came to you with decades ofglobal experience.
I have worked on projects invarious industries, countries
(00:29):
and roles.
In this podcast, I aim to helpyou and your organization
transform how to lead yourchange initiatives with the 4pm.
What are the 4pm?
4pm stands for project program,product delivery and portfolio
(00:51):
management.
It is all about integrations todeliver value.
We want to hear from you, soplease share your feedback and
suggestions.
Enjoy your listening.
Good day and welcome to the 4pmpodcast Today's topic.
(01:12):
I'm going to give it the titleof seeing the big picture of
project management.
In other words, in order to seethe big picture, we have to
respect our diversity.
I usually structure my topicsand I like to go through a
specific part.
Today, I'm going to do itfreely.
(01:34):
It's something that has beennagging me for a while and I
feel like I need to get it out.
It could be part of venting,but, however, we will always
keep it professional andeducational at the same time.
However, in this episode, Iwill be offering many
(01:56):
counterpoints to some of themisses and the argument that we
see online today in the projectmanagement community.
First, as you know, we callthis podcast the 4pm podcast in
order to have a view of the bigpicture, which means project
(02:20):
management is all about managingproject program product
portfolios.
It's about establishing PMOs tobuild the OPM.
If you haven't been listeningto project management podcast
before, you might find theseabbreviations annoying, but I'm
(02:40):
sure most people here would know.
What I mean by PMO is thatproject management office, and
OPM is organizational projectmanagement.
In order to see the big pictureof project management, we need
to understand it's in thebroadest sense of the term.
It's not about managing asingle project or managing a
task or managing the stage ofthe project.
(03:01):
It is a holistic view ofproject management that includes
the 4pm, as I mentioned, thePMO on OPM.
So before I go into the happypart of the topics, I would like
to do a disclaimer, but thebest way I can do that
disclaimer is through a story.
For those who've been followingus and following me, they know
that I am the founder and CEO ofOOP project management, a
(03:24):
company we established few yearsago to build OOP platform as a
digital solution to manage the4pm.
So when we started the company.
Obviously I will be doing at UTData Project Management
Symposium in May.
I invite you to register andjoin that event.
I will be presenting a casestudy of founding OOP PM and
(03:46):
building OOP platform and thatwill be a case study that
focusing mostly on strategicproject management, launching a
business startup, programmanagement, project management,
agility All of these topics arecombined into our case study and
I'm just going to give you apreview of that in probably one
minute.
When we launch OOP projectmanagement as a change.
(04:07):
Strategic initiative for me andmy partners is the idea we
started as a business, we usestrategic program management,
but I'm not going to focus thereright now.
I'm going to focus on buildingthe OOP platform.
If you like to learn the wholecase studies, you're welcome to
join us in Dallas or maybesometime in the future you will
be able to hear or read my paperon that topic Building the OOP
(04:33):
platform.
Here I have to remind everybodyof something in the agile
manifesto that everybody youknow a lot of people understand
it differently to mean differentthings.
The agile manifesto and mostliterature I've seen on agile
and the argument for agile talksabout basically delivering
working software to the customer, adding value continuously.
(04:57):
These are some of theprinciples and values that are
discussed in the manifesto theidea of delivering value to the
customer, delivering value tothe product owner, basically
delivering working software.
Right, and this is our.
I'm stressing this word for apurpose.
(05:18):
So, when we started to buildthe platform, obviously I'm in
this case, I am the business, Iam the customer for the
development team, but I am mycustomer is you the people who
would use my platform in thefuture?
Right, so you don't get anyvalue from my software until you
start using it?
Okay, and even me, as if I amthe customer of the development
(05:40):
team, I don't get any value fromthe software until the team
give me a product I can put outin the market.
Okay, let's reflect on what Ijust said.
Right, the ultimate customers,the end users.
They cannot get any value fromthe root platform and to
subscribe to it.
And me, as the product owner orthe customer of the development
(06:02):
team, I get no value from thesoftware until it's released.
I can release it to my customerso I can sell it or deliver
value or even grant it right asa free service for people.
Okay, so with that in mind whenwe start to build the platform.
(06:22):
My development team is usingScrum, so it's a form of agile
and they do sprint and Instagramit.
However, that is not agileproject management.
That is basically how theydevelop the product.
However, that is not fullybeneficial to me.
So what we have done is that inthe very beginning.
(06:45):
Obviously, the first few monthsis when we are building the
proof of concept.
Yes, the team were doing asprint and increment and they
were showing them to me and allof that stuff.
However, if we talk about from abusiness perspective, not just
technical project management hat, that is of no value to me.
It's accumulated, maybe they'rebuilding.
(07:07):
It's like when you're cooking ameal right, you start cooking
something, you put oneingredient, you add more, you
put some spices, you heat, youlower the heat, you do different
things and if you try to eatfrom that food before, either
you're going to burn your tongueor you're going to get a bland
or tasteless meal, right, sothere is no value on that until
the full meal is finished andcomplete and is ready to be
(07:28):
eaten.
Okay, same thing.
So, when the team was workingon my proof of concept, they are
releasing me.
They are building the Legopieces, they are building the
sprint and the item for me toview, to review, to test
whatever the case might be.
But there is no value untilthey deliver the proof of
concept.
Now, I cannot sell the proof ofconcept, so I'm still not
(07:51):
getting a commercial value fromit, but at least I can start to
get my people, my team, somepotential customers, some
potential friends out there totest and use.
Right, so in a way, that iswhat we call Big Bang, what we
call in a room right, becausethere is no product.
The product was being built inpiecemeal, but it wasn't
(08:14):
released until at the end of theday, a few months later.
Here you go, munir, this is theproof of concept, right, so
what we call that in a roomagain is Big Bang.
At the end of the day, onedeliverable.
And after that point, and westart to test and use, we start
to collect information, so westart to basically do iteration,
(08:35):
right.
So basically, from proof ofconcept, from the point of a
proof of concept to the point ofwhere we have a minimum viable
product, right, there will bemany iterations because you
identify bugs, you fix, youimprove something here, you
improve something there and youalso add increment.
Those were actually what wecall iterative development,
(08:58):
incremental development, or inother words, agile development.
Now, notice, everything I'mtalking about here is about
development, right, agiledevelopment, not the management
method, not the projectmanagement method.
Now, why is this relevant?
I can tell you is very clearly.
If it wasn't for agility here,not agile, for flexibility, for
(09:24):
being resilient as a company, wewould have shut down a long
time ago.
When we started, we startedjust before COVID hit.
Covid affected us significantlybecause we cannot go out and
communicate anymore.
People were going throughturmoil to adjust to the idea of
everything is remote, zoom,whatever the case might be, and
at the same time, my partner gotsick and later on, died.
(09:47):
Then, when we finally get ouract together again, we resumed
our operation.
All of a sudden, money driedout, invested and not investing
anymore.
So if it wasn't for us to beextremely resilient, agile or
being, you know, adaptingagility to the maximum, we could
(10:09):
have shut down a long time ago.
However, we are here today.
So in this story I shared withyou, I've talked about agility
and I've talked about agiledevelopment.
Notice, it's not agile projectmanagement.
I must repeat that it's notwaterfall project management
right.
That is where we can work in anadaptive way.
(10:33):
That's why we always and as arecent article, the episode we
published we talked aboutbasically project management,
traditional project managementhas always been adaptive.
It's not waterfall.
Now, with that story in mind,let us move to the next part of
(10:54):
the discussion, which is some ofthe argument we hear from agile
a jealous promoting agileproject management.
Recently, we're seeing a lot oftrend for hybrid and even,
jokingly, we've seen somethingcalled digital project
management and I don't know whatelse.
There are many things out there.
(11:16):
Now, what are some of theargument they always make?
That they are so much more thanjust a little bit of a joke
that they are the best, they arethe answer, they are the future
, right, and waterfalltraditional.
All of that is garbage and weshould throw away.
One of the things they talkedabout is that we often talked
(11:36):
about is that, oh, waterfall isbad because the plan is fixed in
the front.
We spend a lot of time detailing, planning, doing getting
charged, doing extensive detailand then, at the end of the day,
basically we fix the plan andwe're not allowed to change, and
(11:57):
if we need to change something,we have to go back all the way.
Well, obviously, clearly,anyone who is listening now, who
have worked on capital projector work in many industries,
understand that some of thatstuff is bullshit.
And I'm going to be straightbullshit.
Why?
Because we never do that way.
There is nothing there is wherewe never work on something
(12:20):
called fixed plan.
We work in very early stages,very detailed planning.
We do something called PMI usedto call it progressive
elaboration and unfortunately,even PMI forget where they came
from.
In the Pomba guide they used totalk about progressive
elaboration.
In my community we didn't usethat term, but that's a good
(12:40):
term.
We call it rolling wave planning.
In other words, when we startthe project, we try to visualize
it even at the idea stage.
As a good, competent projectmanager, we visualize the whole
project.
In a way, we'll have a veryhigh level plan for the whole
project, but it's very highlevel.
It's more about we need to dothis stage before this stage,
(13:03):
before this stage, or we need todo this, or these are some of
the key decision points.
That's it.
Then the project manager wasdone and said what do I need to
do?
I need to focus on what I needto do next, the next three weeks
, four weeks a month, I willcome up with more.
Maybe I need to do stage.
For the first stage, I need tohave a semi-detailed plan.
Then I'll have maybe a detailedplan for the next week or two.
(13:27):
This is what we call rollingwave planning.
We do this part.
When we start a new project, westart with the concept, the
statement of work, and then wecollect requirements, we evolve.
Even when we finally have arelatively planned that we can
use to go get funding, that planis not fixed.
Once we go into implementation,we implement something called
(13:50):
change management, projectchange management, where any
ideas for change it's collected,reflected on, reviewed and
approved or rejected.
This is one way.
There is nothing set in stone.
Detailed plan in the beginningand then if you move a second
(14:12):
out of the plan, everything willfail or you'll have to go back
and do everything again.
This is a lot of garbage thatis being promoted.
The problem is because it'sbeing promoted by people who
probably never done it, oractually they're saying this is
bad, but they've never done itso they don't understand it and
(14:32):
yet they label it as bad.
So, fixed plan, it's nothing.
We do something called rollingwave planning, progressive
elaboration.
Another argument we've seen fromagile people in the past is
talked about basically, oh,there is no customer interaction
except at the end point, likeat the beginning and at the end.
(14:53):
I work in capital project,which is highly predictive and,
if I want to use the languagethese guys use, I spent 15 years
in that industry in the oil andgas industry, petrochemical
industry and I can tell you, inthe first 10 of those years,
(15:16):
eight of them was working out ofthe contractor office.
Now reflect on that.
What does that mean?
Remember the argument oh, weonly customers and contractor
only talk at a certain milestone.
Right, we were working from thesame office.
(15:36):
You know what that mean?
That mean we see each other forbreakfast and dinner and
sometimes even on evenings andweekends, and we do team
building together.
We're always together.
If I want to talk to mycounterpart, I was on the owner
side.
I want to talk to mycounterpart on the contractor
side.
I just walked down the hall, Igrab a cup of coffee and we chat
(15:57):
.
It's not like we talk about,you know, once every blue moon.
We talk regularly.
We have weekly meetings, soit's a continuous interface.
So again, the people who arguedthat in waterfall, or
predictive or traditional, thereis no communication.
Again.
Another bullshit.
(16:17):
Later on I will stop sayingthat.
I'll say BS and you get thepicture.
Another one that a Wanderer'sPMI came up with a few years ago
is the idea of predictive.
Oh, we have predictive andadaptive Again.
What a piece of C.
You complete the word.
(16:39):
What is predictive?
Yes, if I want to build abuilding, I'm predicting that I
want to have a building.
But can I predict myperformance?
Can I predict that I will bedelivering the building exactly?
Can I predict, or I'm certain,that no changes will happen
along the way?
It's impossible.
Yes, we follow a certainmethodology.
(17:00):
There are certain things thatguideline rules, ground rules
that we must follow, but there'snothing we can predict.
I mean ideally, yeah, I mean wepredict what we like to have
Now.
Would we have it Exactly as weimagined it?
Most likely no.
Would we have it for the samecosts and schedules that we
(17:23):
exactly imagined?
Probably not right.
So what does that mean?
Let me predict it doesn't exist.
We go back to the idea thattraditional project management
has always been adaptive.
I keep repeating this and Iwill be repeating this probably
for the next.
And the lie die.
Predictive doesn't exist.
(17:43):
Adaptive project management isadaptive.
We follow competent projectmanager that work an
organization with good, maturesystem.
That's how I define traditionalproject management, because
there is no clear definition.
A lot of people equatetraditional to waterfall.
I don't agree with that.
Right To me, traditional is theway we've always done it, as
(18:07):
competent project managerworking in an organization with
good, mature project managementsystem, which mean we understand
they need to be adaptive, to beflexible, to be dynamic, to
allow change where it makessense.
Again, where it makes sense.
We're just not gonna add changesand allowing scope creep and
allowing no planning and noestimate and a lot of that stuff
(18:29):
that we've been hearing.
We will not.
We need to have some structure.
If you drive on a highway, youmight over speed, you might
drive a little bit crazy, right,but as long as maybe you're
breaking the law.
But if you're breaking the lawwith a reason, right.
If you're deviating with areason, police will probably let
you go.
If you go become crazy, thenwhen police need to maybe step
(18:53):
in.
So there are some ground rulesand some rules that we can
deviate from somewhat, whetherwe are driving, cooking or
building project.
However, there are certainrules we cannot violate.
So we need to establish theground rule and we define what
is set, what is standard, whatmust be followed and what are
(19:13):
those things that are flexibleand we can change.
The third miss we talked about,I just repeat, with the first
miss.
We talked about fixed plan.
Second one we talked about nocustomer interaction.
Third one I just talked aboutpredictive versus addictive.
Adaptive I was going to sayaddictive.
Maybe some people are addictedto being so.
(19:34):
Now time for the first oneservant leader.
How often we see all of thesedebate about, ah, the scrum
master is a servant leader, theHI Goche is a servant leader and
they probably dictators inhiding.
I don't know right, but what Iknow is that since when servant
(20:00):
leadership is a projectmanagement topic?
Okay, or if it is, I mean,obviously servant leadership is
a leadership topic which isextremely relevant to us in
project management.
But these people who promoteservant leadership is an agile
thing.
What do they think?
We think we are on the capitalproject industry or the
traditional people who followtraditional project management
(20:20):
dictators?
Command, and they do think thatway.
That's why, at some time, wehear about command and control.
What command and control?
Command and control is amanagement style that existed
years ago and is dead.
No one.
I've been working for 40 yearsand rarely where we have command
(20:42):
and control.
I don't remember ever workingin an environment where I had to
be, you know, the boss order meand said, yes boss, yes boss,
yes boss.
There's no command and control.
People are human, they'reintelligent, they have input,
they have value, they can weighin, they are part of the
planning, right?
Except in situation, maybe,where there is a need to be more
(21:02):
directive.
That depends.
That's not.
I had nothing to lose.
Project management.
It's all situational.
Actually, leadership issituational.
Sometime I need to be a servantleader.
Sometime I need to be moredirective.
Sometime I need to be moresupportive.
Sometimes I need to be just afriend and a coach or a mentor,
right.
So that is what servantleadership.
(21:24):
But who made it exclusive agilething?
It's in every industry, inevery domain.
It's up to the management andorganization culture and the
people involved whether theyfollow.
That has nothing to do with themethodology Number five,
self-driven team andself-managed team.
Whatever the case might be, howdoes that work?
I walk down the street and I seefew looking people and then say
(21:47):
, hey guys, why don't you comeand work with me and we will
have a project?
And you know, come with me andthen we figure out a project.
Maybe Hekasson work that way.
They bring in strange peopletogether, say, okay, think about
something, but at leastsomebody will give them a theme.
Right, it's not like this.
People work in an organization.
They don't decide on project.
They don't decide that A, b andC and D are gonna work together
(22:10):
on project X, okay, and F and Gand H gonna work on project Y.
We don't do it that way.
Organizations have culture,have structure, have sponsored.
When we work on project, weassemble a team to work on
something.
Now, whether we are an eye and,by the way, there is no one
(22:30):
team If we follow project lifecycle across the life cycle,
stages from beginning to theteam will change.
We might start with a businessteam, with a market research
team, then we might come up withmaybe Design team, then we come
up with maybe with anengineering team, so the team
change over the life of theproject.
Now, if you are working on astage and that maybe I need to,
(22:51):
probably I will end.
This forecast was going back tothe idea of respecting the
diversity and project managementlevel is that the team would
typically change unless you areworking in one stage when we
come together and we work.
But even with that, let's sayyou are an IT department and you
come together to work on aproject and that project is you
(23:14):
call it a project and thereality you are working on a
piece of the project because youmight be implementing a
software or an app for the HRunit or for the finance unit or
for the engineering unit.
So in a way you are, youreceive that project after it
has been deliberated for a whileand guess what, when you start
(23:36):
your project, you are probablystarting with a product backlog,
correct?
Where did that product backlogcome?
From?
Ghosts?
No, it came from the productmanagement team, the team who
did the development of theconcept, the requirement for the
product.
Before that they should havedone the feasibility for the
product, before that they shouldhave done the business case of
(23:58):
the project.
That is traditional projectmanagement.
If you are only involved in onepiece of it, which is a stage
or managing a few tasks, thatdoes, and then you see that as
project management something iswrong, then in reality you are
working from a narrowperspective.
(24:26):
Now here I need to share a funstory quickly before I go back
to respecting our diversity.
One of the reasons I calledthis article, this episode, is
that the big picture.
Recently someone and, by theway, this, this episode, is not
a response to a person or toanybody, just the title was
triggered by one person thatbasically posted something about
(24:49):
the new innovation of theproject, the new innovation of
project management, the greatproject management, the future
of project management is digital, using Trello and Jira is that
is the future of projectmanagement.
That's the amazing discoverythese people find that are each
so when I basically commented tothat person, that person
basically a joke responded in away, in a very insulted way,
(25:13):
that basically that I'm oldfashioned and I don't see the
big picture.
I mean, after you know, I wasgoing to do this at the
beginning of the episode and Idecided to put it at the end
because, as you see, when I'mtalking about is that we need to
see the big picture.
We need to see the big picturewhich is a project.
Start was an idea, not with theproduct backlog, unfortunately
(25:36):
in the agile movement and nowthe hybrid movement, or maybe
the digital movement, right orthe movement, I have no idea.
Every day we keep coming upwith a new flavor of you know,
of this ice cream and then welose sight of the big picture.
Yet those people who are comingfrom an extremely narrow
picture see people like myselfand I'm not alone in this as old
(26:01):
fashioned and don't see the bigpicture.
The big picture is tounderstand project management is
not limited to softwaredevelopment in a service
provider organization.
I mean, most of what we seetoday come from that angle, from
that narrow angle.
Software development serviceproviders that mean they're not
(26:21):
even the project owner.
Because if they were theproject owner, they will see the
project from the idea, fromwhere it originate, from
business planning, from HR, fromfinance, right Project start.
There there is a business casestart, there is a feasibility
study that need to be done.
After that they need to definethe business requirement, they
need to define some technicalrequirement.
(26:43):
Then they will end up basicallywith the product manager and
the product owner and developingthe product backlog.
Then we get hey guys, I T comeon board and start building
right.
So when we see things from thatangle and projected to mean the
whole thing, that is where weare narrow minded and we are not
seeing the big picture, andthis is very important.
(27:05):
So, again, this is not aboutthis person.
This is about many of theargument about the agile people
who say agile transformation youmust transform or die or who
need project manager anymore.
Now we have scrum masters,right.
All of these argument in theway that we've seen is
misleading.
Now I said I'm going to closewas going back to my respecting,
my respecting our diversity.
(27:27):
First I go back.
I did a an episode on thisbefore and that episode I talk
about the project managementlevel as five level Task
management, stage management,technical project management,
product delivery management andvalue delivery management.
How well are respecting ourdiversity is not limited to the
PM level is also aboutunderstanding that we need to
(27:49):
manage project as organization.
We're not here as individuals.
We need to understand the fourPMs.
We need to understand what theorganization project management
systems all about.
Right.
We need to understand thatproject don't come only from it
service provider.
Right.
Project could be inpharmaceutical, could be in
medical, could be in defense,could be in oil and gas, could
(28:09):
be a renewable energy, and everysector, every type of
organization have its uniqueness.
So we cannot take what thesoftware or it service provider
view of the word, which seems tobe dominant in organization
like the am, I and others Okay,control the big picture of
(28:33):
project management.
That is where we spent years anddecade of my life in my career
focusing on something about theidea of tailoring which I did
not invent.
Bill Duncan and the 1996edition talked about tailoring.
I don't know if he invented itor he bought it as well, but we
built on each other right.
This 1996 edition of the Pumbakfocus greatly about tailoring
(28:58):
and the need for tailoring, and2007, when I start working on
methodology, I had that as acore principle that we need to
have.
Project management has torespect the diversity of
different industries, domain,type, size, complexity of
project.
We must reflect all of that andour tailored method was this.
(29:21):
I'll end it here and I wish yousuccess today, tomorrow and
always.
Thank you.
Welcome to the 4pm podcast.
My name is Munir Ajam and I'mthe founder and CEO of Aruq
Project Management.
My core passion is projectmanagement and community
development.
I came to you with decades ofglobal experience.
I have worked on projects invarious industries, countries
(00:29):
and roles.
In this podcast, I aim to helpyou and your organization
transform how to lead yourchange initiatives with the 4pm.
What are the 4pm?
4pm stands for project program,product delivery and portfolio
(00:51):
management.
It is all about integrations todeliver value.
We want to hear from you, soplease share your feedback and
suggestions.
Enjoy your listening.
Good day and welcome to the 4pmpodcast Today's topic.
(01:12):
I'm going to give it the titleof seeing the big picture of
project management.
In other words, in order to seethe big picture, we have to
respect our diversity.
I usually structure my topicsand I like to go through a
specific part.
Today, I'm going to do itfreely.
(01:34):
It's something that has beennagging me for a while and I
feel like I need to get it out.
It could be part of venting,but, however, we will always
keep it professional andeducational at the same time.
However, in this episode, Iwill be offering many
(01:56):
counterpoints to some of themisses and the argument that we
see online today in the projectmanagement community.
First, as you know, we callthis podcast the 4pm podcast in
order to have a view of the bigpicture, which means project
(02:20):
management is all about managingproject program product
portfolios.
It's about establishing PMOs tobuild the OPM.
If you haven't been listeningto project management podcast
before, you might find theseabbreviations annoying, but I'm
(02:40):
sure most people here would know.
What I mean by PMO is thatproject management office, and
OPM is organizational projectmanagement.
In order to see the big pictureof project management, we need
to understand it's in thebroadest sense of the term.
It's not about managing asingle project or managing a
task or managing the stage ofthe project.
(03:01):
It is a holistic view ofproject management that includes
the 4pm, as I mentioned, thePMO on OPM.
So before I go into the happypart of the topics, I would like
to do a disclaimer, but thebest way I can do that
disclaimer is through a story.
For those who've been followingus and following me, they know
that I am the founder and CEO ofOOP project management, a
(03:24):
company we established few yearsago to build OOP platform as a
digital solution to manage the4pm.
So when we started the company.
Obviously I will be doing at UTData Project Management
Symposium in May.
I invite you to register andjoin that event.
I will be presenting a casestudy of founding OOP PM and
(03:46):
building OOP platform and thatwill be a case study that
focusing mostly on strategicproject management, launching a
business startup, programmanagement, project management,
agility All of these topics arecombined into our case study and
I'm just going to give you apreview of that in probably one
minute.
When we launch OOP projectmanagement as a change.
(04:07):
Strategic initiative for me andmy partners is the idea we
started as a business, we usestrategic program management,
but I'm not going to focus thereright now.
I'm going to focus on buildingthe OOP platform.
If you like to learn the wholecase studies, you're welcome to
join us in Dallas or maybesometime in the future you will
be able to hear or read my paperon that topic Building the OOP
(04:33):
platform.
Here I have to remind everybodyof something in the agile
manifesto that everybody youknow a lot of people understand
it differently to mean differentthings.
The agile manifesto and mostliterature I've seen on agile
and the argument for agile talksabout basically delivering
working software to the customer, adding value continuously.
(04:57):
These are some of theprinciples and values that are
discussed in the manifesto theidea of delivering value to the
customer, delivering value tothe product owner, basically
delivering working software.
Right, and this is our.
I'm stressing this word for apurpose.
(05:18):
So, when we started to buildthe platform, obviously I'm in
this case, I am the business, Iam the customer for the
development team, but I am mycustomer is you the people who
would use my platform in thefuture?
Right, so you don't get anyvalue from my software until you
start using it?
Okay, and even me, as if I amthe customer of the development
(05:40):
team, I don't get any value fromthe software until the team
give me a product I can put outin the market.
Okay, let's reflect on what Ijust said.
Right, the ultimate customers,the end users.
They cannot get any value fromthe root platform and to
subscribe to it.
And me, as the product owner orthe customer of the development
(06:02):
team, I get no value from thesoftware until it's released.
I can release it to my customerso I can sell it or deliver
value or even grant it right asa free service for people.
Okay, so with that in mind whenwe start to build the platform.
(06:22):
My development team is usingScrum, so it's a form of agile
and they do sprint and Instagramit.
However, that is not agileproject management.
That is basically how theydevelop the product.
However, that is not fullybeneficial to me.
So what we have done is that inthe very beginning.
(06:45):
Obviously, the first few monthsis when we are building the
proof of concept.
Yes, the team were doing asprint and increment and they
were showing them to me and allof that stuff.
However, if we talk about from abusiness perspective, not just
technical project management hat, that is of no value to me.
It's accumulated, maybe they'rebuilding.
(07:07):
It's like when you're cooking ameal right, you start cooking
something, you put oneingredient, you add more, you
put some spices, you heat, youlower the heat, you do different
things and if you try to eatfrom that food before, either
you're going to burn your tongueor you're going to get a bland
or tasteless meal, right, sothere is no value on that until
the full meal is finished andcomplete and is ready to be
(07:28):
eaten.
Okay, same thing.
So, when the team was workingon my proof of concept, they are
releasing me.
They are building the Legopieces, they are building the
sprint and the item for me toview, to review, to test
whatever the case might be.
But there is no value untilthey deliver the proof of
concept.
Now, I cannot sell the proof ofconcept, so I'm still not
(07:51):
getting a commercial value fromit, but at least I can start to
get my people, my team, somepotential customers, some
potential friends out there totest and use.
Right, so in a way, that iswhat we call Big Bang, what we
call in a room right, becausethere is no product.
The product was being built inpiecemeal, but it wasn't
(08:14):
released until at the end of theday, a few months later.
Here you go, munir, this is theproof of concept, right, so
what we call that in a roomagain is Big Bang.
At the end of the day, onedeliverable.
And after that point, and westart to test and use, we start
to collect information, so westart to basically do iteration,
(08:35):
right.
So basically, from proof ofconcept, from the point of a
proof of concept to the point ofwhere we have a minimum viable
product, right, there will bemany iterations because you
identify bugs, you fix, youimprove something here, you
improve something there and youalso add increment.
Those were actually what wecall iterative development,
(08:58):
incremental development, or inother words, agile development.
Now, notice, everything I'mtalking about here is about
development, right, agiledevelopment, not the management
method, not the projectmanagement method.
Now, why is this relevant?
I can tell you is very clearly.
If it wasn't for agility here,not agile, for flexibility, for
(09:24):
being resilient as a company, wewould have shut down a long
time ago.
When we started, we startedjust before COVID hit.
Covid affected us significantlybecause we cannot go out and
communicate anymore.
People were going throughturmoil to adjust to the idea of
everything is remote, zoom,whatever the case might be, and
at the same time, my partner gotsick and later on, died.
(09:47):
Then, when we finally get ouract together again, we resumed
our operation.
All of a sudden, money driedout, invested and not investing
anymore.
So if it wasn't for us to beextremely resilient, agile or
being, you know, adaptingagility to the maximum, we could
(10:09):
have shut down a long time ago.
However, we are here today.
So in this story I shared withyou, I've talked about agility
and I've talked about agiledevelopment.
Notice, it's not agile projectmanagement.
I must repeat that it's notwaterfall project management
right.
That is where we can work in anadaptive way.
(10:33):
That's why we always and as arecent article, the episode we
published we talked aboutbasically project management,
traditional project managementhas always been adaptive.
It's not waterfall.
Now, with that story in mind,let us move to the next part of
(10:54):
the discussion, which is some ofthe argument we hear from agile
a jealous promoting agileproject management.
Recently, we're seeing a lot oftrend for hybrid and even,
jokingly, we've seen somethingcalled digital project
management and I don't know whatelse.
There are many things out there.
(11:16):
Now, what are some of theargument they always make?
That they are so much more thanjust a little bit of a joke
that they are the best, they arethe answer, they are the future
, right, and waterfalltraditional.
All of that is garbage and weshould throw away.
One of the things they talkedabout is that we often talked
(11:36):
about is that, oh, waterfall isbad because the plan is fixed in
the front.
We spend a lot of time detailing, planning, doing getting
charged, doing extensive detailand then, at the end of the day,
basically we fix the plan andwe're not allowed to change, and
(11:57):
if we need to change something,we have to go back all the way.
Well, obviously, clearly,anyone who is listening now, who
have worked on capital projector work in many industries,
understand that some of thatstuff is bullshit.
And I'm going to be straightbullshit.
Why?
Because we never do that way.
There is nothing there is wherewe never work on something
(12:20):
called fixed plan.
We work in very early stages,very detailed planning.
We do something called PMI usedto call it progressive
elaboration and unfortunately,even PMI forget where they came
from.
In the Pomba guide they used totalk about progressive
elaboration.
In my community we didn't usethat term, but that's a good
(12:40):
term.
We call it rolling wave planning.
In other words, when we startthe project, we try to visualize
it even at the idea stage.
As a good, competent projectmanager, we visualize the whole
project.
In a way, we'll have a veryhigh level plan for the whole
project, but it's very highlevel.
It's more about we need to dothis stage before this stage,
(13:03):
before this stage, or we need todo this, or these are some of
the key decision points.
That's it.
Then the project manager wasdone and said what do I need to
do?
I need to focus on what I needto do next, the next three weeks
, four weeks a month, I willcome up with more.
Maybe I need to do stage.
For the first stage, I need tohave a semi-detailed plan.
Then I'll have maybe a detailedplan for the next week or two.
(13:27):
This is what we call rollingwave planning.
We do this part.
When we start a new project, westart with the concept, the
statement of work, and then wecollect requirements, we evolve.
Even when we finally have arelatively planned that we can
use to go get funding, that planis not fixed.
Once we go into implementation,we implement something called
(13:50):
change management, projectchange management, where any
ideas for change it's collected,reflected on, reviewed and
approved or rejected.
This is one way.
There is nothing set in stone.
Detailed plan in the beginningand then if you move a second
(14:12):
out of the plan, everything willfail or you'll have to go back
and do everything again.
This is a lot of garbage thatis being promoted.
The problem is because it'sbeing promoted by people who
probably never done it, oractually they're saying this is
bad, but they've never done itso they don't understand it and
(14:32):
yet they label it as bad.
So, fixed plan, it's nothing.
We do something called rollingwave planning, progressive
elaboration.
Another argument we've seen fromagile people in the past is
talked about basically, oh,there is no customer interaction
except at the end point, likeat the beginning and at the end.
(14:53):
I work in capital project,which is highly predictive and,
if I want to use the languagethese guys use, I spent 15 years
in that industry in the oil andgas industry, petrochemical
industry and I can tell you, inthe first 10 of those years,
(15:16):
eight of them was working out ofthe contractor office.
Now reflect on that.
What does that mean?
Remember the argument oh, weonly customers and contractor
only talk at a certain milestone.
Right, we were working from thesame office.
(15:36):
You know what that mean?
That mean we see each other forbreakfast and dinner and
sometimes even on evenings andweekends, and we do team
building together.
We're always together.
If I want to talk to mycounterpart, I was on the owner
side.
I want to talk to mycounterpart on the contractor
side.
I just walked down the hall, Igrab a cup of coffee and we chat
(15:57):
.
It's not like we talk about,you know, once every blue moon.
We talk regularly.
We have weekly meetings, soit's a continuous interface.
So again, the people who arguedthat in waterfall, or
predictive or traditional, thereis no communication.
Again.
Another bullshit.
(16:17):
Later on I will stop sayingthat.
I'll say BS and you get thepicture.
Another one that a Wanderer'sPMI came up with a few years ago
is the idea of predictive.
Oh, we have predictive andadaptive Again.
What a piece of C.
You complete the word.
(16:39):
What is predictive?
Yes, if I want to build abuilding, I'm predicting that I
want to have a building.
But can I predict myperformance?
Can I predict that I will bedelivering the building exactly?
Can I predict, or I'm certain,that no changes will happen
along the way?
It's impossible.
Yes, we follow a certainmethodology.
(17:00):
There are certain things thatguideline rules, ground rules
that we must follow, but there'snothing we can predict.
I mean ideally, yeah, I mean wepredict what we like to have
Now.
Would we have it Exactly as weimagined it?
Most likely no.
Would we have it for the samecosts and schedules that we
(17:23):
exactly imagined?
Probably not right.
So what does that mean?
Let me predict it doesn't exist.
We go back to the idea thattraditional project management
has always been adaptive.
I keep repeating this and Iwill be repeating this probably
for the next.
And the lie die.
Predictive doesn't exist.
(17:43):
Adaptive project management isadaptive.
We follow competent projectmanager that work an
organization with good, maturesystem.
That's how I define traditionalproject management, because
there is no clear definition.
A lot of people equatetraditional to waterfall.
I don't agree with that.
Right To me, traditional is theway we've always done it, as
(18:07):
competent project managerworking in an organization with
good, mature project managementsystem, which mean we understand
they need to be adaptive, to beflexible, to be dynamic, to
allow change where it makessense.
Again, where it makes sense.
We're just not gonna add changesand allowing scope creep and
allowing no planning and noestimate and a lot of that stuff
(18:29):
that we've been hearing.
We will not.
We need to have some structure.
If you drive on a highway, youmight over speed, you might
drive a little bit crazy, right,but as long as maybe you're
breaking the law.
But if you're breaking the lawwith a reason, right.
If you're deviating with areason, police will probably let
you go.
If you go become crazy, thenwhen police need to maybe step
(18:53):
in.
So there are some ground rulesand some rules that we can
deviate from somewhat, whetherwe are driving, cooking or
building project.
However, there are certainrules we cannot violate.
So we need to establish theground rule and we define what
is set, what is standard, whatmust be followed and what are
(19:13):
those things that are flexibleand we can change.
The third miss we talked about,I just repeat, with the first
miss.
We talked about fixed plan.
Second one we talked about nocustomer interaction.
Third one I just talked aboutpredictive versus addictive.
Adaptive I was going to sayaddictive.
Maybe some people are addictedto being so.
(19:34):
Now time for the first oneservant leader.
How often we see all of thesedebate about, ah, the scrum
master is a servant leader, theHI Goche is a servant leader and
they probably dictators inhiding.
I don't know right, but what Iknow is that since when servant
(20:00):
leadership is a projectmanagement topic?
Okay, or if it is, I mean,obviously servant leadership is
a leadership topic which isextremely relevant to us in
project management.
But these people who promoteservant leadership is an agile
thing.
What do they think?
We think we are on the capitalproject industry or the
traditional people who followtraditional project management
(20:20):
dictators?
Command, and they do think thatway.
That's why, at some time, wehear about command and control.
What command and control?
Command and control is amanagement style that existed
years ago and is dead.
No one.
I've been working for 40 yearsand rarely where we have command
(20:42):
and control.
I don't remember ever workingin an environment where I had to
be, you know, the boss order meand said, yes boss, yes boss,
yes boss.
There's no command and control.
People are human, they'reintelligent, they have input,
they have value, they can weighin, they are part of the
planning, right?
Except in situation, maybe,where there is a need to be more
(21:02):
directive.
That depends.
That's not.
I had nothing to lose.
Project management.
It's all situational.
Actually, leadership issituational.
Sometime I need to be a servantleader.
Sometime I need to be moredirective.
Sometime I need to be moresupportive.
Sometimes I need to be just afriend and a coach or a mentor,
right.
So that is what servantleadership.
(21:24):
But who made it exclusive agilething?
It's in every industry, inevery domain.
It's up to the management andorganization culture and the
people involved whether theyfollow.
That has nothing to do with themethodology Number five,
self-driven team andself-managed team.
Whatever the case might be, howdoes that work?
I walk down the street and I seefew looking people and then say
(21:47):
, hey guys, why don't you comeand work with me and we will
have a project?
And you know, come with me andthen we figure out a project.
Maybe Hekasson work that way.
They bring in strange peopletogether, say, okay, think about
something, but at leastsomebody will give them a theme.
Right, it's not like this.
People work in an organization.
They don't decide on project.
They don't decide that A, b andC and D are gonna work together
(22:10):
on project X, okay, and F and Gand H gonna work on project Y.
We don't do it that way.
Organizations have culture,have structure, have sponsored.
When we work on project, weassemble a team to work on
something.
Now, whether we are an eye and,by the way, there is no one
(22:30):
team If we follow project lifecycle across the life cycle,
stages from beginning to theteam will change.
We might start with a businessteam, with a market research
team, then we might come up withmaybe Design team, then we come
up with maybe with anengineering team, so the team
change over the life of theproject.
Now, if you are working on astage and that maybe I need to,
(22:51):
probably I will end.
This forecast was going back tothe idea of respecting the
diversity and project managementlevel is that the team would
typically change unless you areworking in one stage when we
come together and we work.
But even with that, let's sayyou are an IT department and you
come together to work on aproject and that project is you
(23:14):
call it a project and thereality you are working on a
piece of the project because youmight be implementing a
software or an app for the HRunit or for the finance unit or
for the engineering unit.
So in a way you are, youreceive that project after it
has been deliberated for a whileand guess what, when you start
(23:36):
your project, you are probablystarting with a product backlog,
correct?
Where did that product backlogcome?
From?
Ghosts?
No, it came from the productmanagement team, the team who
did the development of theconcept, the requirement for the
product.
Before that they should havedone the feasibility for the
product, before that they shouldhave done the business case of
(23:58):
the project.
That is traditional projectmanagement.
If you are only involved in onepiece of it, which is a stage
or managing a few tasks, thatdoes, and then you see that as
project management something iswrong, then in reality you are
working from a narrowperspective.
(24:26):
Now here I need to share a funstory quickly before I go back
to respecting our diversity.
One of the reasons I calledthis article, this episode, is
that the big picture.
Recently someone and, by theway, this, this episode, is not
a response to a person or toanybody, just the title was
triggered by one person thatbasically posted something about
(24:49):
the new innovation of theproject, the new innovation of
project management, the greatproject management, the future
of project management is digital, using Trello and Jira is that
is the future of projectmanagement.
That's the amazing discoverythese people find that are each
so when I basically commented tothat person, that person
basically a joke responded in away, in a very insulted way,
(25:13):
that basically that I'm oldfashioned and I don't see the
big picture.
I mean, after you know, I wasgoing to do this at the
beginning of the episode and Idecided to put it at the end
because, as you see, when I'mtalking about is that we need to
see the big picture.
We need to see the big picturewhich is a project.
Start was an idea, not with theproduct backlog, unfortunately
(25:36):
in the agile movement and nowthe hybrid movement, or maybe
the digital movement, right orthe movement, I have no idea.
Every day we keep coming upwith a new flavor of you know,
of this ice cream and then welose sight of the big picture.
Yet those people who are comingfrom an extremely narrow
picture see people like myselfand I'm not alone in this as old
(26:01):
fashioned and don't see the bigpicture.
The big picture is tounderstand project management is
not limited to softwaredevelopment in a service
provider organization.
I mean, most of what we seetoday come from that angle, from
that narrow angle.
Software development serviceproviders that mean they're not
(26:21):
even the project owner.
Because if they were theproject owner, they will see the
project from the idea, fromwhere it originate, from
business planning, from HR, fromfinance, right Project start.
There there is a business casestart, there is a feasibility
study that need to be done.
After that they need to definethe business requirement, they
need to define some technicalrequirement.
(26:43):
Then they will end up basicallywith the product manager and
the product owner and developingthe product backlog.
Then we get hey guys, I T comeon board and start building
right.
So when we see things from thatangle and projected to mean the
whole thing, that is where weare narrow minded and we are not
seeing the big picture, andthis is very important.
(27:05):
So, again, this is not aboutthis person.
This is about many of theargument about the agile people
who say agile transformation youmust transform or die or who
need project manager anymore.
Now we have scrum masters,right.
All of these argument in theway that we've seen is
misleading.
Now I said I'm going to closewas going back to my respecting,
my respecting our diversity.
(27:27):
First I go back.
I did a an episode on thisbefore and that episode I talk
about the project managementlevel as five level Task
management, stage management,technical project management,
product delivery management andvalue delivery management.
How well are respecting ourdiversity is not limited to the
PM level is also aboutunderstanding that we need to
(27:49):
manage project as organization.
We're not here as individuals.
We need to understand the fourPMs.
We need to understand what theorganization project management
systems all about.
Right.
We need to understand thatproject don't come only from it
service provider.
Right.
Project could be inpharmaceutical, could be in
medical, could be in defense,could be in oil and gas, could
(28:09):
be a renewable energy, and everysector, every type of
organization have its uniqueness.
So we cannot take what thesoftware or it service provider
view of the word, which seems tobe dominant in organization
like the am, I and others Okay,control the big picture of
(28:33):
project management.
That is where we spent years anddecade of my life in my career
focusing on something about theidea of tailoring which I did
not invent.
Bill Duncan and the 1996edition talked about tailoring.
I don't know if he invented itor he bought it as well, but we
built on each other right.
This 1996 edition of the Pumbakfocus greatly about tailoring
(28:58):
and the need for tailoring, and2007, when I start working on
methodology, I had that as acore principle that we need to
have.
Project management has torespect the diversity of
different industries, domain,type, size, complexity of
project.
We must reflect all of that andour tailored method was this.
(29:21):
I'll end it here and I wish yousuccess today, tomorrow and
always.
Thank you.
Popular Podcasts
United States of Kennedy
United States of Kennedy is a podcast about our cultural fascination with the Kennedy dynasty. Every week, hosts Lyra Smith and George Civeris go into one aspect of the Kennedy story.
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.
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