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. 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
[email protected]. 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]
