Welcome to Pragmatic.
Pragmatic is a weekly discussion show contemplating the practical application of technology.
Exploring the real world trade-offs, we look at how great ideas are transformed into products and services that can change our lives.
Nothing is as simple as it seems.
This episode is sponsored by Typeform and we'll talk more about them during the show.
I'm your host, John Chidjie, and I'm joined by the show's producer, Ben Alexander.
How you doing, Ben?
Doing good, John.
How are you?
I am doing exceptionally well because this is episode 20.
And I like, I know, I like round numbers for some reason.
Every 10 episodes, I just want to shake something up a little bit differently.
So that first was one thing different.
But the other thing that's different about this particular episode is that for the first
time in the show's history, I have said, I asked you actually, what you wanted me to
talk about.
And it was something that was not on the list of things to talk about, and you sort of threw
it at me.
Which is, John, which is such a dangerous thing.
That was like, I'm like, "Oh my God, John, you don't want me to choose."
What have I done?
It's funny, you know what, because I was almost, you know what I was going to do before I suggested
the one we picked was the next one on the list.
- Oh, really?
- I was gonna do, yeah.
But we'll do that next week.
- Okay, we will.
But I think you picked a cracker of a topic.
And it's weird because it's the sort of thing
that I've been around my whole career,
and I never stopped to think that anyone would be interested
in hearing me talk about this.
So what are we gonna talk about?
What would you like me to talk about today?
- Well, I wanna talk about the critical path,
and there's a lot of critical paths.
But the one I wanna talk about
is the critical path method, right?
Not Buckminster Fuller, although he's great, and not Horace Tedue, although he's amazing.
It's a great show, that one.
Right. I'm interested in the process, right, this idea, because it's something I've read about,
I've bumped into, and it looks really cool to me, but I don't think it's something that I
totally understand. All right, cool. Well, very good. Then I suppose we should dive in. So,
Ultimately, it comes back to project management. And honestly, I do understand that it is a very
often hated discipline. And there's a litany of really good reasons as to why it's not a liked
sort of discipline or function, if you want to call it that. But the problem is that project
management is actually quite a broad topic. If you read what Wikipedia has to say, and again,
it's the source of all knowledge and wisdom apparently. They have a nice definition I think
says it well which is "project management is the process and activity of planning, organizing,
motivating and controlling resources, procedures and protocols to achieve specific goals." And
that's pretty damn broad right there but yeah it does encapsulate what project management is all
about. So to get to the critical path method and understand how it applies, how you use it,
it and what it has to do with. Because it's an aspect of project management, we have to
understand what on earth project management actually is, which is why we're starting with
project management. The funny thing is most people don't realize that every day what any
given person may do is actually a form of project management. We do it subconsciously
for the most part, and it may not be structured, it may not be written down,
but it actually... so many tasks that we do, we just don't stop and think. We don't realize,
"Okay, well, I'm actually managing a little mini project," whatever that project might be.
And I keep using the word "project," obviously, you know, going to brush your teeth in the morning,
you want to call that a project? I guess it's a project.
It's that's pretty often a project for me.
Well, I guess it will depend on...
The most important project of my day is the AeroPress, right? And yes,
That is a project, right? That is several complex steps that need to happen in the right order.
Absolutely right. Well, and this is the whole point of what I want to do is illustrate
using a relatively simple example, an everyday example. Now, obviously,
you don't write all this stuff down necessarily, but it's just to illustrate the point. So,
for the next little while, I'm going to keep coming back to this example. So,
We are going to start with "I need to get some Monroe apples" and I have my own reasons for
picking that specifically. And we need to get them before the kids get home,
otherwise the kids will be angry or upset or hungry. Choose one of those. So there's a list
of activities that you might need to actually perform in a certain order to complete that task.
All of those tasks will be broken down into little subtasks and each of those subtasks need to be
be performed in a certain order to achieve that end result.
So as I was saying, it's more of an unconscious, subconscious, not unconscious goodness, unless
you sleep, project managing, I guess.
Anyhow, it's a subconscious thing.
But the point that I guess you don't write it down because I guess the bottom line is
that the end result is not a big deal.
If the repercussion is that the kids are cranky, well, okay, they're cranky, but that's probably
not the end of the world.
They'll just eat something else, I suppose, like, I don't know, broccoli or something.
But anyway, I think that before you even consider the detail of trying to plan something and
doing actual genuine "project management" using whatever tools we're going to talk about,
there's three or maybe four conditions that would dictate, I think, when you would actually
consciously choose to plan something in a structured way.
The first one I think is when the repercussions of failing at the end, at the result are extremely
unpalatable, expensive or dangerous.
When the second one is when many or most of the tasks are not straightforward and cannot
be subconsciously executed.
Third one, when there are a significant list of tasks that are difficult to keep in your
head in any one moment in time.
So the fourth one, I said it's kind of a fourth one.
Well, I hate to say this one, but I'll be honest,
in my career, half the time, this was the case.
So potentially, number four,
the fourth reason is your boss tells you you need to do it.
And I know that kind of sucks,
and maybe that's a bit of a cop-out,
but frankly, I've been told to produce plenty of Gantt charts
over the years that really did not benefit me
in any way, shape, or form.
And that's tragic, but that's life, right?
doing rough drafts in English class. I always had to do them and it never made a difference. I always
just go back and I would write the thing then I'd go back and fake the rough draft. Well, see,
I think I see it as it's a tool and a tool that you can use to help improve your end result.
But the problem is though that often it will not improve the end result and it'll simply be a
time drain, time suck. But when someone else tells you that you need to do it and you know
straight from the outset that no matter what you do, it's not going to improve the end result,
and eventually you're just going to get beaten over the head by it.
They're your boss and you could be wrong, right?
Well, that's true. You could be wrong, yeah. But anyway, let's not dwell too much on that,
on number four. The first three are the ones that matter. So it's the repercussions,
it's whether or not it's straightforward, and it's a quantity of tasks is too great for you
to keep in your head at any one time. So I think those are the three main reasons why you would
want to consciously plan and structure your tasks. So now you've made the decision that you're going
to structure your tasks, the method or the tool that's most popular in the world today, I'm sure
plenty of people heard of it, I mentioned it before, is the Gantt chart. So the Gantt chart was developed
by Henry Gantt, who would have guessed that? Well, maybe not the first name anyway, in the 1910s.
So it's now officially 100 years old and thereabouts. And it's a project planning tool
that displays all the tasks on a linear x-axis with respect to time. It's evolved to include
resource allocations and a few other little features here and there, but it's been mostly
unchanged from its original design over 100 years ago. And a little-known fact about the Gantt chart
is actually a Polish gentleman by the name of Karol Ademki, I think it's pronounced, in 1896
developed what he called the harmonogram, which is the translation from Polish to English,
the harmonogram, through his work operating a steel mill. But the problem was that it was
written in Polish and there was a version of it translated into Russian, neither of which was
actually widely publicized in English until 1931 and when it was translated into English,
Gant had already sort of been around for a while. So, Gant was actually credited as the original
creator of the Gantt chart. Yeah, still carries his name, but the truth is he wasn't actually the
first one to come up with the idea. Anyway, there's a lot of software around these days
that can produce Gantt charts. So, one of the big ones is Microsoft Project, which actually I think
of as Microsoft Project but now they call it Project Professional 2013. It's the current version.
More serious software, however, for construction projects that I've personally been involved with
over the last six or seven years is actually some software made by a little company called Oracle
and it's called Primavera. Its current version is actually the name that usually goes by. When
people say Primavera, sometimes they'll say it, usually they'll just say P6. That is to say
Primavera, you know, edition number six, version six. So I'll say, "Oh yeah, I've been hacking away
in P6." And I have a knowing nod. Yep, that sounds painful. Knowing nod. Yep, painful.
You say Primavera, I say Primavera and I think of pasta.
Well, yes.
It sounds much more serious the way you say it.
Well, the thing is that once you see some of these Primavera Gantt charts that have come out
for these projects I've been on and some of them take 36 pages of A3, so that's 11 by 17 inch
paper. 36 pages of that and it's enough to melt your brain, basically. But I mean, these are huge
projects. This is a $350 million pipeline, so it's not like there's one or two tasks like
lay pipe, turn on water. You've kind of got to break that down a little bit.
However, for all that expensive, brilliant, beautiful... I say brilliant. Anyway, professional
software that there is out there, there's also a few free versions. I've actually also used
a one called Gantt Project. There's a link in the show notes. It's for the Mac.
There are also, I think actually there is a version also for Windows and I think it's one of
those cross-platform ones, so possibly one for Linux. I've used that actually in a professional
capacity. The last company that I worked for, we didn't actually have a license for Microsoft
Project, so we were required as one of the tenders that we submitted to submit a Gantt chart with
our project plan as part of the tender submission. And so I used Gantt Project to create that and
Yeah, it was okay, but I mean I'm used to Microsoft Project. I've been using that for a decade more
and yeah, it was just it was not as nice an experience, but frankly it did the job and
honestly it's well it's open source, it's freeware and it does the job. It's sort of the open
office equivalent of Project. Anyway, it'll create a Gantt chart that's good enough for what a lot
of people need. So, and I've actually used it later on. We'll talk about that. So, the concept is simple
enough, right? You make a list of all the tasks and all the subtasks, you assign a duration to
each one of them and that's represented as a bar and the bar is sort of extended to the right. It's
on a bar graph like where the bars go up and down, the bars go left and right. And the length of the
bar is the duration of the task. After that, you've got that list of tasks. You then can connect
each task to each other task upon which it depends. So in other words, you're creating
your dependencies. So I have to finish task number one before I do task number two, that sort of
thing. And they don't have to all link together obviously, but yeah, you have to highlight the
dependencies between which tasks. Some tasks are independent and some tasks aren't. Once you've
got that, you've created a map of all your tasks, how they relate, what the timeline is for each of
those, and it illustrates what needs to happen by when. And you can then use that to plan backwards
and figure out what you need to do first. That's the whole point. Going back to our earlier example,
So let's say our final deliverable milestone will be six apples, six Monroe apples in the fruit bowl
by 4pm. That's the kids are going to be home by 4pm. And now the deadline is sort of set,
we're probably starting at 11am in the morning. So yeah, we've got five hours to do this.
And that's plenty, right? I want to break it down with some pretty simple steps. And these are not
necessarily in the final order that are going to happen. Empty the old fruit out of the fruit box.
You've got some manky old fruit in there that's had it, needs to go on the bin.
That's going to take time and effort, so got to do that.
Second thing, find some clothes and get dressed.
Simple enough.
Find the car keys and start the car.
Next one is eat a muesli bar.
Why?
Because you don't want to be cranky when you get home, right?
So you got a muesli bar in there somewhere.
Then you got to drive to the gas station and fill the car up because you're low on gas.
You don't have enough fuel to make it all the way out and all the way back.
you're going to have to stop, drive to the fruit shop or the orchard if you're lucky enough to
live near an orchard that actually has these apples and drive home quite obviously and then
put the beautiful apples in your empty fruit bowl and that is your final completion milestone and
that's the end of the Gantt chart. So the sequence of driving probably doesn't really matter so long
as you stop the gas station you know there but at one point either on the way out or on the way back
but it's implicitly in this example that you have to stop there at some point.
But because we want to be forward planning, because this is all about
planning and project managing, well we're gonna do stop at the gas station first
and that's fine. And also as I say to make sure you know we've got we got to
have the muesli bar to make sure we're not cranky too. But and I'm not
necessarily advocating that you should be eating when you're driving but it's a
muesli bar a minimal distraction. It's not like a bowl of soup or something, which I can't imagine
trying to drink even when you're driving. Anyway, irrespective, please respect your local laws and
do not take this as any kind of advice. For the purposes of illustration, we're going to have
our muesli bar in one hand while we're driving at some point in our Gantt chart, because we can do
that task in parallel. Whether we should or not, it's for the courts and the law to decide and
common sense to decide. I mean if it's icy on the road and it's okay anyway. So the interesting
thing though is about emptying the fruit bowl is we don't technically have to empty the bowl of fruit
we can do it before we leave the house or when we get back but we have to do it before we put
the fresh apples in. So because we sort of choose to sort of forward plan that as well we'll do that
first before we go out the door because we'll make sure everything all our ducks are in a row
it's all nice and good to go we get home to put the apples in with we're done. So the rest of the
activities beyond the ones I've just put I've quoted individually are essentially sequential.
So you need to get clothes on before you get the car keys and start the car and drive out the
garage. Of course if you don't mind going around naked or in some crummy old clothes I guess maybe
that doesn't matter but we're going to assume that you have some kind of level of decency and
you're not going to do that and you're going to need keys to start the car so you can't drive the
car around without finding the keys first. It's all pretty straightforward obvious and very sequential.
So what I've done is I've created a Gantt chart for this using Gantt Project and there's a link
to it in the show notes. I've got a png file and I also have the gan file which can be opened by
the software if you're really curious and what it does is it illustrates the float which we'll talk
about a bit more later for emptying out the fruit bowl and eating the muesli bar and all of the
dependencies between the tasks. We'll come back to that in a little bit and expand on that a little
bit further. And for those that aren't able to sort of read the notes as you go, then feel free
to check it out later if you're interested. So, we'll just press pause on the Gantt charts. And
now I want to talk a little bit about PERT charts. PERT charts. I'm not sure. Have you heard of PERT
charts before, Ben? I've seen a simple example of it on the project management wiki page and I think
on the critical path method page too. It looks like nothing I've seen before. It's a very
different kind of chart. It is. And the reason I bring up PERT charts is because there is a sort of
a loose, maybe a causal connection perhaps, between the critical path method and PERT charts.
So that's why I'm bringing them up. They were developed around about the same time. So what does PERT
stand for and how is it different from a Gantt chart? Well PERT stands for Project Evaluation
and Review Technique. It was developed in 1957 by the US Navy and a PERT chart resembles more of a
state transition diagram if you know what that means. The tasks are referred to as nodes and
each node contains the information about that task or at least the information in the node
style does. The original PERT chart actually didn't. The original PERT chart was referred to
now as activity on arrow. So as the arrows go between the different states you would put the
detail of the activity on the arrow, whereas it's fallen out of favor now and it's now more of an
activity on the node. So, you show the details of your activity on the individual nodes and the
arrows going between the states are in fact empty. They're just an arrow with no other information on
them. It seems like a subtle difference, but in any case that's what's become popular for a bunch
of reasons we'll get to in a minute. Each of these nodes will contain information about the task in
question. They'll obviously have the name of the task, the expected, otherwise known as normal
duration, an early start time, an early finish time, a late start time, and a late finish time.
And the crowd favorite, it contains slack. Slack.
I know. It contains slack. I know. Also known as float, which I mentioned about a few minutes ago.
We should talk about our sponsor, Slack. I'm working on it.
You're working with, I wish, oh yeah,
I hope that they do come on,
because honestly, Slack is pretty cool.
- Unfortunately, I don't think they need to advertise.
They seem to have figured out how to create evangelists
without spending any money, so.
- Exactly, yeah, exactly, kind of, yeah,
a bit like Apple, sort of, in some respects.
- Yep.
- Anyhow, so, the point is that, is there a point?
Yes, there is.
The point is, each of the tasks is connected
to each of its dependent tasks,
and it ends up looking a little bit like a web, sort of, a little bit like a spider's web, kind of.
Now, most of the items in that list of things, like the early start time, early finish time,
that's all pretty self-explanatory, but the one that isn't so much is the idea of float.
So what on earth is float? What does it mean?
So the idea of float has to do with task concurrency,
whereby, I guess, if a task must be completed by the end milestone, but you could conduct that
task in parallel to another set of tasks, then technically you could float that up and back
down the timeline. You could say, "I could bring that forward, I could push it back. So long as it
doesn't go any further than this line, I will still get it done in time to meet my milestone,
my final milestone." That's the whole point of float. And float is meaningless if you have a
single path PERT or single path Gantt chart. It only applies if you have a series of tasks that
are in parallel. I guess in terms of software for developing PERTs, it's not uncommon for people
to prepare PERTs in conventional drawing tools that are cheaper, more readily available,
such as Visio even, for example, or even PowerPoint. I've seen them done in PowerPoint.
But honestly, both Project and Primavera have got PERT analysis tools included in them, so
you can use them and it works. But in any case, the last PERT I was involved with was actually
back at Nortel in 1997 and I actually haven't come across them in any of the projects I've
worked on since I've been back in Australia. And I mean, it doesn't mean they're not used,
It's just I haven't seen them and I've come across them in my line of work. It may be very popular
in some industry, I'm just not part of that, so I couldn't say for sure. But a hundred years on,
certainly my observation based on all the projects that I've been involved with and what I've heard
and seen, the Gantt chart is still the king. So a hundred years on, the Gantt is still the king,
basically. Anyway, I don't want to talk any more really about PERTs, but they're interesting
because, as I say, they relate to the same kind of time and they were partly part of the inspiration
for the critical path method. So before we go any further, I was wondering, Ben, if you could tell
us a little bit about type form. Forms are a key component of asking questions online,
but up until now, they've meant a lot of work to design, configure, and administer. And after all
that, the results have usually been unflattering. There are form builders out there that take care
of some of the problems. They make it easier to get something basic up, but creating something
great with them is still hard. What we need is a tool that's easy to use, feature-rich,
and something that looks and works great on any device. And this is where Typeform comes in.
Typeforms are beautifully designed and have cross-platform compatibility baked in.
They're tailored to look and work differently on desktops, on smartphones, and on tablets.
Design is about how it works, and typeforms are built to really work, regardless of the device.
The platform itself is a joy to use, both as a customer creating a typeform
and as a user interacting with one. The UI is sexy, clean, and fast,
and designing even complex series of questions is made simple through their dashboard.
The experience is focused on asking and answering one question at a time,
so it doesn't feel overwhelming and nobody gets lost.
Typeform champions good user experience and design.
This helps you to create a space in which users will be more willing to answer
and more likely to give honest answers.
From customer feedback and surveys, contests and landing pages,
event organization, and in the classroom, Typeform lets your imagination fly.
People are using Typeforms in a variety of ways.
To make interactive stories, holiday cards, team presentations, avatar creation,
the list goes on and on.
Typeform is the only online form builder that lets you get unlimited responses for free.
As many questions as you want, as many answers as you get, Typeform doesn't limit your interaction.
It just lets you ask awesomely. For a limited time, Typeform is offering a three-month free
trial of their new Typeform Pro service. Check out what you can build by visiting
www.typeform.com/fiatlux. If you like what you see and sign up, be sure to use the coupon code
of Fiat Lux to get your free three months.
Thank you to Typeform for sponsoring the show
and for making it easier for people
to get to know each other better.
It's awesome.
- Thanks very much for that, Ben.
So now, I'd like to talk about the critical path methods,
what it's all been building up to,
and hopefully it's not too much of a letdown.
I mean, you may be thinking
after everything I've just talked about,
thanks for the high-level crash course
in project management, John.
See, this is one of the reasons I wanted to talk about it.
And actually I was talking with our audio engineer,
Lorenzo, about a week ago,
he asked me if I used OmniFocus.
And I told him, I was never able to get into it.
And it's something that, I've struggled with this
for a long time, like how to organize my own time
and what I need to work on and do.
And I read David Allen's stuff and getting things done.
And it just, I get it.
I get the idea, but it's never really worked for me,
and it's always seemed like it just was
cargo culting a little bit.
And I know that sounds bad, and maybe it is bad,
and I'm disorganized, but every time I've tried
some sort of time management or personal productivity thing,
it just ends up being more work, right?
Like we were talking about with,
sometimes your boss asks you to do it, right?
And so we were talking about Goodtask,
which is a new iOS app that basically
it combines all your calendars as well as reminders,
which I love reminders, like I really like reminders,
that seems to work for me, into one thing
and it adds stuff in and has like URL schemes.
It's just a really cool app and so we were talking about it
but it really stuck with me 'cause I'm like,
why is this weird thing the thing I like
and I don't like things like Clear or,
you know, which is really minimal but it just seems stupid,
like why not just use a text file?
You know what I mean?
Should I make a checklist?
Should I do something like OmniFocus
and spend two months learning how to do it?
'Cause I mean this Fiat Lux and these projects we're doing,
it is a huge amount of stuff, right?
And I think I hit all four of those things, right?
Like mostly that I can't keep this all in my head.
- Sure.
understanding what it even means is really helpful. It's good that you went through that.
Okay, cool. Well, that's good. I'm glad you've got something out of that and hopefully other
people will as well. But I guess the point I'm getting at is that in order to understand what
on earth a critical path method is, it applies to project management and the tool that you use
typically for iterating is a PERT chart or a Gantt chart. So, anyway, I guess what gets me about
the critical path," is that it's become used as an expression. And I really hate it when that
happens. But I mean, the sorts of expressions that I've heard are, and all of these expressions,
just do little air quotes in front of your head with your head tilted to the side, roll your eyes
slightly, and a little tone of sarcasm, okay? "We're on the critical path right now."
This is a critical path activity. It does sound pretty intense.
And we are critical path here, people. You're in a hypercritical path.
And I hear it too often and it's like fingers down the chalkboard, right? It just sets that
irritating thing in the back of my spine. It frustrates me because the critical path method
is a good thing, but it's not. It's like everyone likes to say, "Oh, we're critical path." It's like,
well, is it a critical path activity? Yes or no? No? Then stop saying that it is.
Anyway, so I guess like all good expressions that encapsulate what it was originally a good idea,
they tend to get overused, usually by people that don't understand what they mean,
and that devalues the expression overall such that when it is used in the correct context,
people tend to roll their eyes and go buzzword bingo, and like I just kind of did, right?
Like disruption.
Well, I was going to say that. Two more examples that I can name off the top of my head are
Proactive and disruption. Synergy. Synergy. Synergy. Oh, hey, synergy is another one. I mean,
if I remember correctly, that was one of Stephen Covey's, right? Well, it goes deeper older.
But you know what I mean? It's like, "Oh, we need to be proactive about this." And I hear that
once a week. What does that even mean? Do they even know what that means? When people say that
to me, I'm like thinking to myself, "Do you actually know what that means?" Being proactive
would be you not coming to me and telling me I need to be proactive. In fact, if you're being
proactive, you wouldn't have come to me at all to tell me that. Slap, slap, slap, slap, slap. Come on.
So, the correct usage, as you pointed out, is not the critical path, but its full name is actually
the critical path method. There's a good couple of links in the show notes. Please check them out.
It was developed in the late 1950s, around about the same time as the PERT chart was developed by
the US Navy, but it was done by two people, a guy called Morgan Walker. He was from DuPont,
collaborating with James Kelly Jr. of Remington Rand. And the thing is, well, I guess one of those
little-known facts is that an early form of the critical path method was used and partly
attributed to the success of the Manhattan Project during the Second World War, which is rather
interesting. It wasn't fully fleshed out with all the maths and everything behind it until later on,
until the late 50s and everything. And the name of it was also partly attributed to
one of the expressions that was used in the paper that was put out on Percharts originally in '57
as well. So there's a whole bunch of little interconnections there that like I say I thought
was interesting to worth mentioning. So okay what the hell is it? Well this build up. Essentially
the method is the idea of mapping the path between the longest paths between tasks to get to the end
deliverable or milestone and you take into account the earliest and the latest each activity can
start and finish without making the project any longer. So if that doesn't immediately make sense,
it's not so much about the path, but it's the idea of iteration that matters. The method is about the
iteration. So once you plan your project, are there ways that you can shuffle around tasks and say,
well, if I get this task done before that task, I had the dependencies one way. What if I am able
to break them into subtasks and shuffle the order of them and run some in parallel,
will that improve my final deliverable date? Because what was a critical path item can be
broke down into sub-items and said, "Okay, well, of the sub-items, it's really only this one item
that's actually on the critical path between start to finish. Therefore, I should throw
resources at that." So, if I can do that, I can reduce the amount of time for that individual
task or subtask and that therefore means logically I've just reduced the amount of time it takes to
get from start to finish. So what it does is it's a method of of analyzing your PERT chart or your
Gantt chart and you can there's a whole bunch of mathematics behind I'm not going to go into that
if you want to there's some stuff in the article where you can quantitatively assess that. I mean
I have issues with the quantitative assessment of schedules which I'll talk about in a minute but
honestly, it was the first, I think, first real attempt. I mean, the PERT sort of started that,
I guess, but the method of iterating and splitting out tasks and identifying what the critical path
was sort of goes hand in hand with either a Gantt chart or a PERT chart, whatever management tool
you're trying to use to plan. So, in terms of concurrency, concurrency is what a project manager
wants to achieve. They want to have concurrency and people that you can throw at a project because
what you're trying to do with Critical Path is, I guess, is you're trying to optimize for end date,
for overall duration, not cost because you're trying to reduce your duration. Now, you say,
"Okay, I've got an infinite budget. I can add 10,000 people to do one task." So, instead of it
taking 10,000 hours, it'll only take one hour because I've got 10,000 people working in parallel.
Now, of course, we know that's BS. That's not the way it works exactly, but...
and there are some tasks that's difficult to do that with, and I'll talk about that in a minute
as well. But the issue is... let's say in our example, okay? So we'll go back to our Apple
example. So by increasing the number of people, we can now start to perform some activities
concurrently. So let's now say we've got person A, person B. Person A is the one that's going to
go and do the driving. Person B is their assistant who's at home. While person A is getting dressed,
person B could be finding the keys and stay in the car in parallel. Okay? That works. That's just
saved us one of our elements of time, one of our tasks worth of time. Now, the other thing is that
while person A is out of the house, person B can empty the fruit bowl. That's another thing we've
just put in parallel because, "Yeah, we have another person, so now they can come along."
And what we've done is we've reduced the overall project schedule by two-sevenths
of the total duration just by adding an extra person examining the critical path and saying,
"You know what? I can now add resources to reduce and bring back my end date and time."
Now, maybe you didn't have to do that and on the Gantt chart I've done earlier,
okay, hand up in the air. I'm sorry. There's limitations to the tool because
what I've done is I've gone and said, "Every task is a day because these management tools
don't work in terms of hours. So, I couldn't create a chart that started at 11am and finished at 4pm.
I tried. No can do. It only works in whole days, unfortunately. And I even left the weekend thing
turned on. So, please ignore the numbers along the top of the chart. And yes, every task is a day
long. Okay, whatever. I mean, assume it's like 30 minutes for each task. It doesn't really matter.
It's just meant to be illustrative. Okay. Okay. So, this whole exercise of what we're doing
by adding that extra person, there is a name for that and this is another buzzword that has been
overused. But as part of the Critical Path method, they described that activity as fast-tracking.
Okay. So, that is the origin, as I understand it anyway, of the expression fast-tracking.
So, now we have a whole bunch of extra words in our vocabulary. We can all speak management BS
whenever we like. Isn't that great? Anyway. Okay. So, to be honest, I don't have too much else to
say about critical path, but what I do have something else to say is how do you use these
tools to actually be a useful project manager? And this is one of the things that I realize it's
a little bit on the fringe, but frankly, what's the good of having tools if you don't use them
correctly? I think that there are two big issues. There's a lot more than just two issues in total,
but the two big issues with effective project management that so often drive the negative
behaviors and responses that people have when they're affected by a schedule or a timeline or
a deadline milestone up against them. And these things then feed into mistrust and lack of faith,
lack of belief in the usefulness of the schedule, the PERT, the Gantt chart, whatever the heck
they're using, and of course, by extension, the project manager that put them together.
So, the first and biggest one, I think, is incorrectly broken down tasks, durations,
and dependencies. The problem is that too many people in project management are disconnected
from what they're actually managing. So, in construction projects, I've been a lot involved
in a lot of construction projects and there have been numerous occurrences when the project manager
simply does not appreciate what is required with the software development because their experience
in civil construction. Once you set your concrete, you don't break it up and iterate and say, "Well,
maybe we could lay a little bit better if we try it again." That iteration is unheard of,
unless there's some kind of major drama like, "Oh, we set the concrete and after three days,
it's starting to powder and fall apart." Okay, well, that's probably not going to fly, right?
This bridge may fall down as a direct result if we're not careful. Yeah, okay. Okay, we might do
that again. But with software, iteration is part of the process. Whereas with setting concrete,
it's not. But they attack their schedule in such a way that leads to essentially where there is
no iteration with the software and they say, "Well, okay, well, you have a task, complete
software. When you're done, you're done and that's it. You can move on to the next thing."
What about bugs? What about defects? What about iteration? Now, there's none of that
because this is like pouring concrete, right? Yeah, that's like it's making me think of the
doomed startup. Yeah. Which one we talk about patents, we'll talk about that. Oh, the patent
one. Yeah, okay. Episode 30. Yeah, it's on the list. The number is not specific. It's a guideline.
Anyway, I've been the programmer, I'm the electrical designer, I've been the electrical
site supervisor, a lot of what you do in those sorts of roles is trying to explain to project
management how long things are going to take because that's what they need to do is they need
to assemble this into a schedule report back to their management, they then come back down to you
and say you need to do this quicker, you're on the critical path, blah blah blah, all that sort of
thing, right? So the other issue with the breaking down, so still on the issue of breaking down task
durations and dependencies is on the duration and the parallelism problem, the concurrency problem,
sorry is a better programming term if you prefer, in the end the throw more people at it mentality.
So if you've got six concrete footings you've got to pour for your building or your structure,
if you had six cement trucks and six crews you could actually do that all at the same time.
Okay, that would work, but when you're doing software, that's not how it works.
In fact, when you're doing a lot of design activities, that's not how it works.
See, that presupposes you have a fixed design. That presupposes you've got the end
design result. You have everything you need to run in parallel, but that's not the case,
generally speaking, with software. Software is a little bit more like a living thing,
a little bit, not entirely, but a little bit. My absolute favorite example of this problem,
illustration of this problem, is from the sort of software famous book called The Mythical Man
Month. Have you read that at all, Ben? Yeah.
Yeah. Yeah.
Required reading. If you're a programmer, for goodness sake, read it. I know it's,
what, 35 years old now? Well, I'm saying it's almost as old as me. Yeah, it said 38.
reading that book was life-altering, right?
Oh, sure.
Especially since it's 35 years old, and I looked at it and I said, "Wait a second,
they figured this out?"
Yeah, I know.
Why do we keep forgetting this?
Yeah, exactly. I read this later in my career. I'll be honest, I put my hand up and say,
"I only read it four years ago," and I felt just the same emotion. I'm like,
"How did I not read this before?"
Apparently, nobody reads that book until they've experienced some sort of
horrible disaster in software. Yeah, pretty much. It's a fantastic book. If you're in software development and you're doing larger projects,
frankly, you have to read this book. I cannot recommend it enough.
Anyhow, there's one part of it in particular. The book, by the way, is written by Frederick Brooks.
Okay, and
this one particular part is referred to as "Brooks Law," which is that
you can't... adding more people to a project makes it go longer. Right.
Okay, but the one quote is a sort of a it's not quite maybe it's a bit of a throwaway comment
Maybe it isn't but it's my favorite which is nine women can't make a baby in one month
It absolutely beautifully. Yeah simply
illustrates the problem
That project managers fail to get time and time again, and it doesn't apply just a software
It's it's iterative design and development
So it doesn't matter what that design is and this is one of the big problems
I've caught so much flack and I know there's a lot of programmers out there that have you know
I've gone up through the ranks and end up doing some degree of project management or reporting schedule to project managers
And we're asked time and again how long is it gonna take how long is it gonna take?
And you say okay. Well, let's see
We've got there we're gonna all of our tests to run on it and then we've got an additional period of time for
you know iteration fixing bugs clean up and so on before we can get to factory acceptance test for and go to site and
The the project managers come back with it and they shake their head and say okay
Well, can you can you cut that in half? Do you really need to do the testing? Can we just go out with something?
And it becomes this long protracted
Painful bloody experience where you're trying to negotiate with these guys that have no idea
Exactly how software development is done and how design is done right and they try and they'll try to treat it to make an
analogy to something else
Typically something that's like an ancient profession that has been understood forever like like like building which was our problem
Like it's just like building a house. No, it wasn't I thought it was at the beginning and it didn't turn out that way
You don't have to redesign the basement of the house three times during the process of building a house
We know how to do it. Exactly, exactly right and in many respects
You know software is different insofar as most software is not reused. I mean sure there's libraries that get reused and all that
But honestly between companies and between projects there is nowhere near enough code reuse. Right?
You know, it's if you look at like um iOS development
It's crazy how and it's getting a lot better really quickly, but um I compared to you know
I do ruby stuff I compared to the amount of
Just crazy huge numbers of libraries and gems and all that stuff there that moving over to try doing doing iOS like
It's like dude you guys do you share anything like yeah?
So anyway didn't want to go too far down that right hole either, but the point of the illustration is
you cannot do a lot of tasks concurrently or if you can't with some parts of development and
That's a whole nother topic, but that is how project schedules can get screwed up
So I said there were two things two big issues with you know
Being effective project managers dealing with projects and so on is if you understand
What it is what's required?
Then you can more appropriately break down the tasks set to correct durations and get the dependencies, right?
So that was the first big one.
The second big one is the tendency to use the schedule as a motivational tool rather
than a planning tool.
And this is a trap that so many project managers fall into.
It stops being about planning for the future and helping your team achieve the result and
it starts to become a negotiation.
And the thing is, after the negotiation has been had, then they use that renegotiated
schedule to apply pressure, more pressure to those performing the tasks in question.
So it's funny because I'd sit down with this project manager on the last major project
that I was a software lead on and he would say to me, "Can you shave a couple of days
off this task?"
And I'm like, "Well, of course I could shave a couple of days off if things go well and
so on but you know we need to have some kind of buffer he said well we don't have time for that so
um you said we can take a couple days off we'll take three days off like whoa whoa whoa whoa whoa
the guy that doesn't know how it works gets to choose that's it right because he's the project
manager right he gets to tell you and then and then it becomes your responsibility i mean this
is yeah and and of course the next week i get told well you committed to this date right and i laughed
in his face and I said, "Actually, no. You committed me to that date, but thanks for playing."
How'd that go?
Well, it took as long as it took.
No, but how'd that go after you said that to him?
Yeah, we were frosty for a while, but you know, the problem...
Yeah, oh, that's a long story.
Did he get over it? I mean, was it or was it...
Yeah, he's... we're friends again now, but...
I mean, that's the thing. I think a lot of, like, programmers don't push back like that.
Well, yeah, but I'm easily irritable, I suppose. But I mean, I can't take it when someone says to me,
"You need to do better, go faster," and so on. When you know that these guys have been under
the pump for 12 months, and you're telling them, "You need to pull in more. You need to give more."
Like, how they can give any more? "We need to get more people." Oh, really? And of the last people
that we got in, how well did that go? And the schedule goes out to the right. I'm like,
"I want to get rid of the people that are underperforming." We can't do that. They're
a resource because they don't see the value in resource. They say, "Well, you've got six people
on your staff and they're all equal." No, they're not. I've got two people doing 80% of the work.
Anyway, look, that is a bad, still festering sore that I need to just move on with. My life
has moved on and I need to forget about it anyway. I think we're both working through similar issues.
I'm working through my issues. This show is becoming my therapy and I've got to stop that.
Okay, right. So, ultimately, and I guess this is ultimately the point of all this is that
Gantt charts, Pert charts, using the critical path method, they're just tools to help you to
understand the best way to plan your activities to get the end result you want in a known period
of time. And just like any tool out there, for any purpose, it can be abused if it's incorrectly
applied. So, you should be very careful when you use them. Otherwise, take that care and time and
think it through and be honest with yourself how long things take, what really are the dependencies.
Because if you don't take that time up front and you misuse those tools,
you'll inevitably get a bad result and then you'll blame the method. And it's not the method.
It's how it's applied. For all the angst and frustration I have with project managers through my
experiences with them, and they were generally not good. I don't hate Gantt charts.
I don't hate Pert charts or the the critical path method or any of that stuff or fast tracking.
I don't hate any of it. It's the way it was applied and misapplied that I have issue with.
What do you think the key is to applying it right? Because I mean have you had good project managers?
Is there something you could see that one type does and one doesn't?
Yeah, it's a good point. I've been very negative about this whole thing, but the truth is you're
right. There have been examples of project management that has been done right. The two
things that the project managers had in common on those projects were, one, they knew what it was
that they were managing. So, in other words, you had an electrical engineer, for example, doing the
schedule on the project that it contained electrical components. They knew exactly what
was required in constructing and testing a switchboard. They knew that you couldn't shave
time off here and there, so they didn't ask. They understood how software was developed to a point,
or at least were more accommodating and interested in talking about it. At least they listened.
But the other thing that they have in common, I think, was that they did not turn it into a whip.
They took it from the perspective of, "I'm going to use this as a tool to figure out what you need
when." And there's this one meeting in particular, I remember crystal clear because it's the only
time that I've ever been truly grateful to a project manager. When at the end of the meeting,
we'd mapped it all out on the whiteboard and he turned to me and he said, "You need two more
people here." And I sort of looked it up and I said, "Yes, I do, but I'm told I can't hire anyone."
And he said, smiles at me and he goes, "You know what?
Let me take care of that."
And within a few weeks, I had two more guys, problem solved.
The problem is that's generally not what happens.
And I can count the number of times that I've had good project management on one hand in
how long we've been doing this, 20 years.
That's the thing.
What you're describing to me doesn't sound like management.
That's leadership, right?
That's...
Sure.
He's going to go to bat for you.
Yeah.
He's figuring out the problem and he's going to go fight someone.
Yeah.
So how often do project managers get sucked in by the tool and simply say, "You know what?
My job is to manage the project and I will map out all of the dependencies and I will say,
'Okay, well, we'll get this going here. We'll get that going there,' and so on,
and someone else go do it." That's different from the next step, which as you say, is more of a
leadership step. "You know what? Now I know what needs to be done. I am going to be the person
that makes it happen. I am going to grease this wheel. I am going to make sure that they have
what they need when they need it in all respects. Not just, "I need to order a box from wherever so
that it arrives in time." Not just that, personnel as well. And that next step, so few of them,
in my experience, ever took. Right. Why? Because that's actually really hard work. Because what
if you don't know what you actually need? I suppose we presuppose that that is known.
Right. But how many of the project managers have that? You have to really think. I mean,
because you're dealing with people, right? So, you've got to... When that guy you were
working with then in that situation, he really got it, right? Did you realize you needed the
extra people before he did? No. I was much younger at that point. And I
sort of saw it and I sort of... You had a sense that something was not quite right.
And you could see that it was probably going to be a crunch. And I was thinking, "Yeah,
"Yeah, okay, that's gonna be tough,
but we'll probably do it."
And then once he sort of put his finger on it,
I'm like, "Hallelujah, this guy, he's right."
And he's spot on, and not just that,
he's gonna make sure that I get the people that I need.
The shame was that it wasn't a huge project
and it was a long time, it was a while ago now,
it'd be 10, nine years ago, something like that.
And it was an isolated incident.
And I've spent years trying to figure out
What on earth is it exactly?
What's the difference between these tools
correctly applied and incorrectly applied?
And it comes back to those two things,
knowledge of what on earth you're managing.
And I guess, to paraphrase you,
taking that next step and being a leader
and helping as opposed to whipping.
- So I shouldn't get OmniFocus.
I've never used OmniFocus.
- From what, from what, so what, honestly,
what you're saying is, is I've been doing it right.
Like, I don't need to worry about that.
Like, it doesn't matter.
- When you want me to talk about the critical path method,
it sounds to me like it's, you were thinking more about--
- So I was thinking about it like it was a--
- Productivity tool.
- Like that, yeah, like, like somehow
that I, that I had the wrong tool.
So maybe--
- Productivity, yes, it is the thing is--
- I was thinking about it like, like, am I organized, right?
'Cause there's so much stuff going on
and we're trying to move forward.
And we are, but you know what I mean?
It's a lot.
- Well, honestly, I think the problem is,
ask yourself the question,
do you believe that a project like tasks,
reminders, calendar, any of those,
do they describe dependencies?
- No.
- And I would say the answer is no.
Do they describe durations?
No, I don't think they generally do.
Are they an effective tool for managing everything
is going on right now with what you're pushing for with the direction of Fiat Lux?
Is it sufficient?
See, my answer to that would be no.
I think that you would benefit.
No.
It's necessary but insufficient.
I need to have a calendar.
Yes.
And setting up that big, gigantic, shared calendar with 24-hour view, that's beautiful
because now I can see everything.
I know when you're available.
I know when people are recording and all that.
Yeah.
that's that's not enough and then setting up or setting up a reminder to call back.
You know someone who wanted to pitch a show in a couple of weeks like I did that last night like
that's helpful, but it's not enough, but I just don't I guess it was the issue was like I.
Can I find a tool that is an is enough and I sort of think that maybe that tool is something more
like intuition right like something that holds it together because I just kind of gave up on it like.
I don't know how to draw a map that covers everything that needs to happen, so I'm not
going to try.
I'm going to do something else, and that's why I want to talk about it because it seemed
interesting.
My opinion?
If you want to do it that way, that's obviously up to you, but if it was up to me, that is
not the way I would do it.
What would you do?
Well, what I would do is I would start going back to something that one of my favorite
managers of all time, Rob McKenzie, taught me.
It wasn't one of his.
It was something he got from someone else.
Anyway, the idea is you start with the end in mind.
You start with a detail of where you want to be,
where you want to get to exactly.
And once you've got that point,
you simply work backwards and break it down
into the subtasks required to get you there.
And as you do that,
you are essentially creating a Gantt chart or a Perth chart.
You can figure out how long
roughly each of them is gonna be.
- But John, where I wanna be is to have a base on Mars.
- That's gonna be more difficult.
So maybe I need to think more short term.
Yeah, you may need to revise that.
But that's the thing.
Like, what if the goal is years long, right?
Well, then that's okay.
Because for example, the last project that I was, the massive one that I was on and I
was providing a lot of feedback on the Northern Pipeline Interconnect, that one, it had several
charts.
It had several Gantt charts.
And the top level chart, which summarized all of them, it was the roll-up chart, right?
So it was the top level three-year plan.
And then underneath that, you would have shorter-term plans for different components that would
finish at different points along the development of the project.
So it's perfectly okay.
I'm pretty dumb.
It's so obvious.
Yeah, yeah.
No, no, it's not.
Maybe it is, maybe it isn't.
end, start with a high-level plan, keep it high-level, and then look at the next big milestone
and say, "You know what? I'm going to plan out to the next big milestone." And say, "Maybe that next
big milestone is, I don't know, update to the website. I don't know, whatever it is, you know,
not for me to say, for you to say." And then you can start iterating down the detail of that,
going down through tasks and subtasks to get you there. So, you're gradually getting more focus,
Right. Exactly. And then once you've done that, it will literally jump out at you. It'll become
obvious to you. And maybe it's okay to rely on intuition to an extent, but the reason that these
tools were created was because intuition alone cannot guarantee you a reliable, consistent result.
It's chaotic. That's the problem with it. Chaos is not your friend.
Intuition is great because you can make jumps, right? You can see things and follow through, but
But it's, I mean, well, we chat,
I mean, you know what my schedule is like.
It's a whirlwind, like, I'll die
if I don't change the way I do it, right?
- Well, it's not about this.
This is the funny thing is that everyone's busy, right?
Everyone says, "I don't have time for this,
I don't have time for that."
The funny thing about planning
is that planning takes more of your time,
and that's the natural reaction.
People say, "Oh, but that's gonna take more time.
I don't have time for planning."
Well, actually, you do need to make time for planning
because if you do, it means that what time you do have left,
you will spend on the right things.
And that's what matters 'cause time is a form of currency,
really, and different currencies for different things,
but honestly, you have to learn how to spend your time
on the right things, and if you do that,
you will get a better result, and that's the truth.
- That wasn't what I expected, but I like the answer.
I like it. - All right.
- I'm gonna do that.
I'm gonna take your suggestion.
- Cool, well, thank you.
And honestly, I think that you will be more relaxed
and more relieved with the end result, so.
- That's it, actually.
I wanna get rid of that anxiety.
- So on the whole, yeah, I think you picked a good topic.
Yeah? - Yeah, I thought it went well.
I hope people enjoyed it.
I imagine lots of our listeners have.
I'm sure, actually, all of you, right?
What we just decided, right?
Everyone has projects.
- Absolutely.
If you feel the urge to create a 300 page long Gantt chart
for the rest of your life, however,
I would suggest to resist that urge.
But apart from that, hopefully something can be a benefit
to everyone and I think that it is a useful thing
to have a look into.
So.
- So since you, since we flipped the script
for this episode,
actually wanted to do a call out,
shout out to a listener that didn't get in touch,
but I found something that they wrote about us
doing, you know, looking through our stats
in their referral logs.
And it's, so this is to Cookie,
who is on greenpowerstudents.freeforums.net.
You wrote, "For anyone interested in engineering
"as a career," parentheses, let's face it,
if you're here, it's fairly likely,
Pragmatic, and the URL,
is a great podcast that covers all kinds of topics
across the spectrum of engineering.
Anyone else found things they'd like to share?
And I love this because this is a little forum for-- I'm not
even sure.
It looks like these are a bunch of car guys.
It's some sort of racing thing, which
sounds interesting anyway.
Like there's someone here called Don Rotary Racer.
So, Cookie, I don't know who you are,
how are we getting in touch, but you
should contact us. Say hi, because we found your thing. Glad you liked the show.
Hope Green Power Students is doing well. Cool. Thanks for that, Ben. If you want to
talk more about this, you can reach me on Twitter @JohnChijji, the same on
app.net, and you can check out my site techdistortion.com if you like. If you
would like to send an email, you could send it to John@techdistortion.com. You
can also follow the show account @PragmaticShow on Twitter or @Pragmatic
on app.net to see show announcement and other related materials. Final thank you to our sponsor
Typeform for sponsoring this episode. Make sure that you check them out and thank you for listening
everyone. Thanks Ben. Thanks Dan.
[Music]
(music)
[Music]
(dramatic music)
[BLANK_AUDIO]