Why You Need a Plan with J. Scott

Brett Harned:       Hey, welcome to Time Limit. I'm Brett Harned, the Director of Education at TeamGantt. Happy that you're here. The topic of today's episode is estimating and planning, and if there's anything you'll learn from this conversation is that you always need a plan. I'm not going to spoil it now, but my guest, project management consultant and author J. Scott, shares his point of view on how all methods require plans. He also shares a lot of tips on process that come straight from his book, The Irreverent Guide to Project Management, so check it out.

Brett Harned:       J., Thanks so much for taking the time to join me on Time Limit today. I'm really looking forward to talking to you about the importance of planning and estimating and kind of getting your unique perspective on those topics. I found you through your book, The Irreverent Guide to Project Management, which I think offers a pretty fresh or different take on topics specifically around estimating and planning. But I have to say the bold, irreverent take on project management is really appealing to me and I have to guess it's appealing to a lot of people, especially in the digital space. But that goes from the take of the book to your company's website and the way that you kind of talk about your stuff. It's really good stuff, so thank you for that.

J. Scott:           Thanks Brett.

Brett Harned:       Yeah, of course. Thank you for joining me. So I know that you're the founder of 120VC, which is a project management services company. Can you tell us a little bit about what the company is and what you do?

J. Scott:           Oh sure. Thanks for asking. I'd love to. We're a transformational services firm, which is essentially a fancy way of saying we help organizations change things. We started with a focus on project management 20 years ago and I quickly figured out that CEOs and CIOs are less interested in project management, which is about one project, than they are in program and portfolio management. Ideally they're interested in ensuring that they can complete as many projects each year for the amount of money set aside, and so we looked at how we were providing project management and we basically designed our approach in a way that would enable the program and the portfolio layers. Then Agile came on the scene and immediately I recognized the 73 word manifesto and the 12 principles as really human based principles that fit into a paradigm that I call servant leadership.

J. Scott:           And so we got pretty excited about that and we looked at Scrum and we looked at DevOps and realized that there was a really good use case for those types of things. We kind of stuck our nose up at looking at those things as them being a panacea, because anybody over the age of 23 should know that one solution does not solve all problems. But where it works, it really works. So we adopted that and started working with our customers to help them optimize their product pipelines in addition to their large global enterprise projects. With all this optimization on the enterprise side, which some people call a Waterfall, it's kind of ... Nobody's doing Waterfall, right? It's interesting, any time you employ the Critical Path method, people are like, "Oh, it looks like a waterfall." But if you put did you put Agile on a timeline, it looks like a waterfall too.

J. Scott:           Anyway, change management came on the scene and we were like, "Wow, this is really going to help organizations adopt all of this change that's being delivered quickly." And so we got into change management and then we realized that there was a missing component of project management called demand management, where essentially you've got all these projects running in an organization and all these matrix functional teams that are contributing and they've got more work than they can even keep track of, right? They're screaming, We're overwhelmed." And executives are screaming, "Just be creative." And we realized that they needed some tools to sort of manage that, so we got into demand management. And then somewhere along the way we realized that leadership is a change discipline. You've heard that leaders are born and not made, and there may be some validity to that. But the simple fact is if you understand people and you understand human nature and you understand what makes us tick, you can improve your leadership ability, so we started focusing on that.

J. Scott:           Those seven disciplines are what we call the change disciplines, and those all fit under the umbrella that we call transformational change services. So the idea is that we work with organizations to provide services, to deliver their projects, optimize their product pipeline, stick change initiatives, but also to develop those disciplines, to become more little a agile or more change-ready. Because we really believe if you look at an Amazon, their zeigeist of agility, they're going to have mastery around all seven of those disciplines. You can't just be great at project management and have great product outputs. You can't just be great at project management and get near a hundred percent adoption on day one. So that's kind of 120VC in a nutshell.

Brett Harned:       Cool. So it sounds like you're really kind of blending methods, right? You're pulling from Waterfall, Critical Path, but also pulling in some Agile principles, maybe some methods from Scrum. Is that accurate?

J. Scott:           Yeah, definitely. Our Enterprise approach or our Waterfall approach to large complex projects, we've literally integrated all of the Agile principles into that and a vast majority of their best practices. Our belief is that if you look at those seven disciplines distinctly, the idea is to help them work in concert. And more importantly, if you look at the basic concept of agility, that's where an organization can look at a problem and pivot if necessary, meaning apply the appropriate approach to solving that problem. So if an Enterprise approach is the most appropriate approach, use that. If an Agile approach is the most appropriate, use that. If a hybrid is the most appropriate, use that. At the end of the day, it's all about ensuring that organizations get the outcomes that they need to take advantage of the market, to infatuate their customers, et cetera.

Brett Harned:       Absolutely. I love it. One of the things that I think that the project management world is kind of missing these days is kind of like the value and need for a plan. People kind of abandoning this idea of a plan because they think Agile will solve their problems. And I don't know, I don't think that's right. I think, like you said, it's about pivoting and applying the approach that's appropriate to your project, to your team, to your stakeholders, all of those factors, but not just throwing away the idea that a plan can help you.

J. Scott:           Well, here's the thing that just burns me a little bit. Agile, when it comes to an actual Agile approach, so take a Scrum or a DevOps, rigor, defining a vision and a roadmap, which is basically planning, is a huge part of it actually achieving the results that it's intended to achieve. And then moreover, whether it's in ... You guys at TeamGantt obviously have more of a traditional tool where you're logging tasks, but, I mean, they really log tasks in a backlog or you're logging tasks in your tool. In Agile you log tasks and we call them stories, right? And then we do sprint planning, so we look at our backlog, which is a whole list of tasks or stories that would create business functionality or business value and they groom that backlog to figure out what's going to create the greatest amount of value. I mean, there's a lot of planning and rigor around Agile. So those people that use Agile as an excuse to wing it or like cowboy up are missing the whole point.

Brett Harned:       I absolutely agree with you. Yeah, it's interesting because obviously there are merits to all processes or methods, right? There are reasons why people have formalized these things, a lot of what you've even laid out in The Irreverent Guide to Project Management. It's all kind of there for the taking, right? It's for you to adapt and make the best process or the best experience for your projects to make sure that you're meeting budgets and that you're not exceeding deadlines. I kind of want to pull it back a little bit. I want to talk about your book. Can you talk to us about what inspired you to write The Irreverent Guide to Project Management?

J. Scott:           Well, they say necessity is the mother of all invention, right? I founded the company 20 years ago and I was our first consultant, and after a couple of years of just being an independent consultant under a corporate banner or the banner of a corporation, I was getting a lot of requests to take on projects that I couldn't. I was fully loaded. And no being the single most difficult word in human nature, I was looking for a way to say yes. And so I started telling my clients that I could bring on somebody else and they would deliver just like me, so finally someone took me up on that and I realized very quickly that I had accidentally lied to them, trying to bring someone on and have them deliver as consistently or similarly as I did without any training material or a training manual.

J. Scott:           I literally hired somebody and then took a tribal approach to telling the tales and telling the stories and sharing the approach. And it didn't go badly, I mean, my customer ultimately was satisfied. But it became very apparent in that that little experiment that if I was going to grow a brand and make promises to my clients, that we needed a guidebook. I needed a system for training. I needed to bring people in and train them and have them deliver a product, because really without a product you've just got, again, people out there winging it and you really can't promise any level of consistency in what you're delivering to clients. And project leadership being what it is, I mean, that's kind of all about a consistent approach, getting consistent results, optimizing cost and time outcomes, getting as close to a hundred percent user adoption or mass market adoption on day one. So that's where the first version of the Guidebook came from.

Brett Harned:       That's awesome. That was one of the questions in my mind because what I like about the way you approach the book is how it is that detailed, and I do think that a lot of people, specifically people who are just getting into project management, they're looking for that kind of step-by-step instruction from start to finish. And I think your book does a really great job of that, so I was wondering if it was almost like a playbook for how you work with clients or on other projects that you work on within the company even.

J. Scott:           It is exactly how we deliver our global transformational projects. We started out with the intent to use it internally to train individuals, and then my clients, as we're working within their organizations, they also had project managers and they started asking us to share and to provide training to their team members. And then we just were like, "Hey, we should actually publish this and make it available to the masses." And so that's exactly the intention, is that we're sharing the exact plays that we use to deliver large global transformational projects for Sony Pictures, Trader Joe's, DIRECTV, T-Mobile.

Brett Harned:       Awesome. Yeah, it's great. It's so informative. the only thing that I thought as a PM who's worked in a lot of different kind of environments or with different types of clients, thinking, "Wow, this is great. It's detailed. There's basically step-by-step instruction." But I kind of think there's no right or wrong way of doing things. I could go buy this and might think, "Oh, I could adapt that or there might be a different way for me to do that." Which is project management, right? That's what we do, and we've already talked about how we have to kind of adapt and flex to make things work. But I'm curious, just in terms of the way that you work, how much would you expect a PM to stick to the formulas in the book versus taking it as a foundational direction for how you operate as a project manager or program manager and then adapting it as they see fit?

J. Scott:           I want to validate your point that there could be better, faster, stronger ways to deliver projects. That's absolutely true, so from our point of view, the purpose of a standard is first training. Once people have a certain level of knowledge they can adapt more effectively, and so the first is training. Two is quality assurance. If everyone in an organization is planning a project differently, assessing health differently, assessing impediments or blockers differently, and communicating differently, it becomes very difficult for a program or a portfolio manager to quality assure their work, to be ahead of it. So in organizations where you've got a whole bunch of project managers doing things differently, one, you figure their reporting, all that reporting goes into a system like yours, and then when the executives pull reports, what's red, what's green, what's yellow from one project manager to another project manager requires analysis. Executives cannot make decisions from a report if the criteria that project managers are using to report or assess risk or rate health is different.

J. Scott:           And so what we've done over the years, we're in version five, is that we're constantly evaluating and adding what we think works better, throwing out what doesn't work anymore. But our basic rule is, once you've got a process you can quality assure, you also can measure, and if you're not measuring, you don't know whether you need to improve anything or not. The other thing also is we have a brand promise. We over the last 20 years have delivered 98% of our projects on time and on budget with near 100% user and mass market adoption. If you look at the industry average, on average large IT projects come in 45% over budget, 7% late, and deliver 56% less value than anticipated.

J. Scott:           So we're doing, at least from a budget perspective, 100% better. And so in order to be able to promise and deliver consistently, again, we have to have a standard, we have to be able to measure our results. But we also follow one basic rule, if the process ever gets in the way of creating the value intended, break the process, break the rules.

Brett Harned:       Got it. Okay.

J. Scott:           The other thing also is to your point, one, projects are not all the same size. They're not all of the same complexity. So one of the first things that we do in on a project is look at, "Okay, we've got to get this planned. How long is it going to take us to plan?" And once we've interviewed the project owner and the executive stakeholders, we have some sort of sense of which of the tools would be necessary and which is the tools aren't necessary. And again, if we're trying to be efficient with time and money, we're not going to follow a process. We're not going to apply a tool that isn't necessary to get this particular project done.

J. Scott:           Barely sufficient is the approach to applying tools, techniques, documentation, so we literally identify for each project which of the standard meetings we're going to need to hold, which of the tools or techniques we're going to follow. And now we have a recipe that we've created, and this only takes like 10 minutes, we have a recipe that we've created from our playbooks for a particular project. And it's not like anyone's deviating, it's more like we've selected what we're going to use and that still enables that quality assurance piece. That still enables other project managers, let's say this PM that happened to be assigned to a particular project wins the lottery and decides to buy an island and go away. We then can take another project manager from our bench and have them take it over.

J. Scott:           And because, even though they didn't use all the tools, techniques, or meetings, but the ones that they did facilitate are similar, the documentation that they put together is familiar, this other project manager can take it over and carry it forward. So there's a lot of benefits to following a standard, but again, you have to be smart about it. Look at, "Hey, we've got this project, should we be Agile? Should we be Waterfall? Okay. If we're going to be Enterprise, cool. Which of the tools and techniques should we apply? All of them? Not all of them?" And then once you've got that all figured out, and again this doesn't take very long, especially when you're pulling from a set toolkit, then you just carry it forward.

Brett Harned:       Yep. I love that approach. I think it's so important to have a framework and even better if it's a little bit of a flexible framework where you kind of adapt to the project based on the needs or the team or whatever it might be. But also the plug and play aspect is really important, knowing even just as a manager that you can step in and look over all the projects that are happening within a program and making sure that things are being handled the way that they should, to the standard that you expect them to be, is really, really important. So I really like the approach to the book. I've been in organizations who would benefit from even using your book as an example for how a framework or guidelines for project management should be written. I think if anyone out there is looking for that kind of guidance, I think this book is really valuable for that, on top of just all of the tactical information you share.

J. Scott:           Thanks, Brett. One more important thing on that note, we even adapt to clients. Sometimes we look at a project and we think, "Hey, you know what? It would really benefit from this particular approach from our playbook." And the client's like, "No, I don't see it." So we will attempt to educate them to what we are seeing. We'll say, "In our experience, this is why this would create value for you." And if the client still doesn't see it, we're not going to try to force something on someone else that doesn't see value in it. We just acknowledge and move on and do the best that we can. So the other adjustment also is, if your client or your organization doesn't see benefit, you're not going to win trying to force them to see it.

J. Scott:           Just keep it in your back pocket. And when the project ... if and when, because this doesn't always happen, sometimes we'll say, "Hey, this is the problem that we're trying to avoid." They don't get it. They tell us not to do it and then it doesn't manifest. Well what good would we have done if we had pushed it, right? And so then if it does manifest, we're never like, "Hey, see, I told you so." We just bring it back up again like, "Hey, maybe we do this." And at that point, usually they're like, "Yeah, we should probably do that." And we introduce it that way.

Brett Harned:       Totally makes sense. So you said something that I think is important here and I kind of want to shift the conversation over to planning. And I think that there are instances where someone sees the value and the need of a plan, but maybe a team member or stakeholder doesn't want to take the time to get through that plan. So I'm curious if you could talk our listeners through your thoughts and maybe even a little process for planning. I think, to give it a little bit of context, what I hear a lot from project managers is that a project gets dumped on them along with a team who will be assigned to the project. Maybe some information on what the scope is. Maybe there is a full SOW, maybe there isn't.

Brett Harned:       But basically that person has to scramble to get the details of the project together and essentially get started as soon as possible because the clock is already ticking. So in that context, obviously that breaks some preliminary process right away, but I'm curious what your tips are on when should you create a plan and what do you do in that situation where things are feeling rushed but you've got to pull some semblance of a plan together.

J. Scott:           Okay. So the answer to "When should you create a plan" is always. However, I get what you're saying in respect to, some people see the value of rigorous planning, others don't see the value of planning at all. One of the things that I think is pretty interesting about the way that the PMI frames projects for us, they tell us, "First you define it and then you plan it." So a definition is where you get all the stakeholders together, the executive stakeholders, and maybe even the people that are going to do the work, and you work with them to facilitate a clear, crisp scope if you can. And then from there you create a plan, like in TeamGantt, where you're identifying all of the tasks, their duration, who's going to be assigned to completing them, et cetera.

J. Scott:           I've taken on projects where the client's happy to have us define the project and create a charter. We've also taken on projects where the statement of work was already created and they wanted us to take that statement of work that was super vague, not very clear, and from there create a work plan where we identify all the tasks, their durations, their predecessor-successor relationships. And so what's kind of cool is that one's a deeper dive than the other, so even on projects where we have the time to work and create a clear definition, we take that clear definition as input into planning where we're identifying the tasks. And the process of identifying tasks actually continues to refine the scope. We're finding out things that we didn't know when we created the definition because we're digging deeper.

J. Scott:           This goes back to the Agile principle of you know the least amount about a project at the beginning, and as you dive into a project, every day you're learning more and more and more. So again, whether it's Enterprise project management or Agile project management, the truth of the matter is you always know the least amount about a project in the beginning. So even if I'm handed a vague scope document and told to begin planning, we're not going to fight it. We are going to take what we have and we'll start planning, working with the subject matter experts to identify the tasks.

J. Scott:           So pause there, there's also the pressure, human nature being what it is, especially in the United States of America. People really just want to start the work, so in organizations where they really just want to start the work, if I were to push back and say, "No, no, no, no, we have to plan first," now I sound like that old Waterfall guy that should be retired. That's how Agile won, that's how people fell into believing that Agile was a panacea, because Agile was like, "Go, go, go."

J. Scott:           So if you kind of combine those two concepts together, what I tell the client is, "Hey, you know what? If you guys want to start the work, cool, as long as you're also making time to work with me to plan the project." And at some point what happens is they're working, I'm working with them to plan, the plan gets done, I then update the plan, and we move forward. So if I'm working with a client that's like, "No, no, no, let's plan first. I don't want to make a move. I want to be really efficient until we know exactly what we're going to do.", that's great. If I'm working with a client that wants to start the work, I'm cool with that, as long as they also give me the opportunity in parallel to that to plan.

J. Scott:           And the other thing we're not going to do is take ownership of the work in progress. I'll take ownership of the work once it's planned. So one of the problems with a lot of project managers have in that scenario where they want a plan, the organization wants to go, is they get absorbed in all of these problems or these blockers. Well, here's the truth, if you don't have a plan, you don't have a blocker.

Brett Harned:       It's so true. Yeah.

J. Scott:           If you don't have a plan, this thing that everybody's freaking out about may or may not impact your ability to finish on time and budget, but you don't even know what on time and budget is yet because you don't have a plan. The tool or the technique that we use in that scenario is, "Be cool, honey bunny." We're like, "Hey guys, be cool. I get you're perceiving this thing as a challenge. Come up with a couple of options to overcoming it and keep moving. We're going to keep planning and at some point then we'll have a plan to where we can then measure the impact of progress, lack of progress, and those blockers, and start making real time decisions to control a future outcome." So that's kind of how we handle the urgent need to move forward in parallel to planning.

J. Scott:           And that's also why I said in the beginning, when do you need a plan? You always need a plan or you don't know where you're going. You've heard the old adage, "Take time to plan or plan to fail." If you don't have a plan that says how long what you're going to do is going to take or how much it's going to cost, you're just chasing your tail. And again, in a fully operational environment where there is no beginning or end and you just have a team that's funded, the use case there is Agile. "Hey, we're just going to, once every two weeks, identify the most important value-creating things for the business and we're going to work on those and everyday we're going to talk about where we're at and we're going to go forward."

J. Scott:           If you have a project that where you've got to get something done, you've got to fix duration or you have a fixed budget, well you have to take time to plan that out or you don't know whether you can get it done in the amount of time that you have set aside or for the amount of money that you have set aside. In that scenario, the best time to plan is at the beginning.

Brett Harned:       Yeah. So it's almost like, "Obviously, always create a plan." If you're not creating a plan right away, plan for the plan. Do the background research and digging to get yourself to a point where you can create a plan that's as realistic as possible. And what resonated with me out of a lot of the things that you said there is, working with subject matter experts to make sure that what you're planning is actually valuable work to be done to deliver whatever it is that you're creating, so not building a plan in a vacuum. I guess, is what I'm saying.

J. Scott:           I have to be honest, it still surprises me that project managers are still doing that. There's two problems with that. One, they're never going to be the subject matter expert of everything, and two, when it comes to accountability, you've heard the term, "Hold people accountable." Well, you can't. It's not a real concept. That's not reality. Too, it sounds like you're physically accosting somebody, like you've tackled them and you're holding down on the ground and you're in their face. First of all, if you do that to somebody they're going to fight you. When you bring a fight, expect to meet resistance. So really accountability is about a staff putting people in a position where they can be accountable to their own commitments.

J. Scott:           If you want people to be accountable, which we do as project managers, we need them to be accountable, they have to define the approach to meet the shared goal. So in the end, cultivating good commitments is what you're doing when you're working with the subject matter experts to define the tasks. And there's a formula to doing that. Good commitments are public, meaning that somebody says, "I will do this" in front of a whole bunch of other people. They're active, meaning that when they say, "I will do this", I as the leader am going to say, "Why would we do that? How does it tie to you?" And literally when somebody has finished committing to an activity, I'm super clear on what it is that they're going to do.

J. Scott:           And they know I'm super clear on what it is they're going to do because I've explored it. Have you ever been in a meeting where the leader says, "Somebody needs to order lunch for next Thursday." Nobody says anything. And then next Thursday comes and the lunch didn't show up because everybody thought somebody else was going to do it. Or have you ever been in a meeting where the manager looks at somebody and says, "I need you to take care of planning the retreat. Do you understand?" and then that individual says back, "I do understand." And then comes retreat time and the manager's like, "This isn't what I expected." Well, because you didn't explore what "Yes, I understand" means.

J. Scott:           So the active is, "Hey, this is what we need to do. Can you share with me how you see this ties to what we're trying to do and what your immediate next steps would be?" And as they then start to describe, I become clear on what they're seeing in their head and if what they're sharing with me doesn't match what I thought I'd asked for, meaning the steps that they're outlining aren't going to get us to the destination that I was perceiving. We're not on the same page, so I'm going to continue to actively negotiate that. So public, active.

J. Scott:           Voluntary, if no isn't an option, you can't count on yes. Period. If people don't feel like they can say no, they'll say yes to everything and you'll never get reliable results. So voluntary. Explicit, what by when, and then mission-based. How does this benefit the organization? You always want to cover the why. So again, a project manager can sit in a room and they can think that they have all the answers and they can outline all of the tasks and then they can show up like a boss and tell all these subject matter experts how they're going to do their jobs, and what will inevitably happen is at some point something won't get done. And when that project manager says, "Why not?", the subject matter expert is going to say, "Because I didn't think we should do it that way." And it will be a totally valid excuse.

Brett Harned:       Yep, I totally agree. I'm a big fan of maybe having a rough sketch of a plan or just sitting down and thinking through, what are the things I think the team needs to do and then maybe jumping into a planning meeting or just a general meeting with that team to say, "Here's what I'm thinking. This is a rough outline of how I think the project could work", just so that I'm creating a way or a frame of reference for how the project could work and then opening it up so that those subject matter experts can shape and shift that plan and we come to a point together and we're not just starting at ground zero. It's not like we're getting into a room and saying, "Okay, we have to build X" and then it's like, "How do we do it?" and then you have a bunch of blank faces staring back at you. Do you have any kind of tactics like that that you like to do when it comes to that level of collaboration when it comes to pulling a plan together?

J. Scott:           We do that in a way. So we look at the charter as the beginnings of the work plan. When you think of the things that might be in a charter's table of contents, it's common for there to be objectives. It's also common for there to be scope. And so for us the objectives have scope items and the scope items are larger than tasks, so ultimately when we're working with the executives to identify the objectives and then we take those objectives as input to the meetings that we're going to have with the functional managers and the subject matter experts and we say, "Okay, here's the purpose, what we're trying to achieve. Here are the objectives. Here are the benefits that the executives want to achieve." Because that's what we define with them, the first half of the charter.

J. Scott:           Then we take that information as input to the functional managers and the subject matter experts and we say, "Okay, here's what they mean to achieve. Work with us to define the approach, what's in scope, what's out of scope, the assumptions, the risks, the constraints." We then work with the subject matter experts to define the scope, which ties to objectives. They define that, so when it comes time to develop the work plan, the objectives are outline level two and the scope items are outline level three in the work plan and from there the subject matter experts define the tasks. So they've literally had a role in creating this outline that you're talking about. And then we use that as input to planning to say, "Okay, we've got these scope items. What are all the things that we need to do to complete each of these scope items?"

J. Scott:           And what that enables us to do is, as we're rolling up status, meaning we're completing tasks, marking them 100% complete, that rolls up to a scope item that then rolls up to an objective. And so when we're reporting percentage complete to executives, instead of reporting on tasks, we're reporting on scope items that they had an opportunity to define. We're reporting on objectives that are meaningful to them as opposed to rolling up status to phases across projects which are meaningless to executives.

Brett Harned:       So in that same conversation, is that when you're alsoconsulting with the subject matter experts or the team on estimates for tasks and thinking about level of effort?

J. Scott:           When we're talking about the tasks, right?

Brett Harned:       Okay.

J. Scott:           Once we've got the charter defined, we've got the objectives and the scope items, those are then input into the definition of the work plan, where we're identifying the tasks. And so when we're actually planning a project, we do that in three steps. The first step is what we call, work plan step one. And what we're doing is we're working with the subject matter experts to identify only the tasks, the level of effort. We won't talk days, so it's the tasks, the level of effort, predecessor-successor relationship, and then who's going to do the work? The reason we focus on hours is because we have a rule where we break up our tasks, we break them down into no more than three days and 12 hours of work effort.

J. Scott:           And that's because if somebody tells you something going to take 10 days, it's a bad estimate. It's totally made up. If somebody tells you something's going to take six hours, you're like, "Okay, explain it to me." And as they start explaining it to you, if you're like, "Well, that seems like it will only take three hours", assume you're not clear. So then you're like, "Well, this thing, you said it would take six hours, and as you're explaining and I'm trying to understand, I see X, Y, and Z and that would only take three hours" and the subject matter expert is going to go, "Oh, I see you're missing these four steps." And so that's how a project manager not being the subject matter expert of all these varying complex subject matter experts can actually become the leader of a project through working with the subject matter experts to identify the task and understanding why it would take six hours, ten hours or twelve hours.

J. Scott:           The other thing that that enables the project manager to do is when they take that final plan and they put it in front of the project owner and the project owner looks at the end date and says, "Nope, I need this done a month sooner", because they never like the end date, right? "I need this done a month sooner. I need this done a month and a half sooner." You then as the project manager can say, "Well, you know what? Do me a favor. Let's kind of look at these." And the first thing they're going to notice is, these tasks are no longer than twelve hours in duration. So where are they pulling time from? They're going to know instinctually that that's a good estimate.

J. Scott:           Second, as the project manager, I can explain every single task. If a subject matter expert tells me that something's going to take ten days, and I take that on face value, one, I'm not going to understand why it's going to take ten days and I probably wouldn't understand the explanation, two, when I put that in front of the project owner and they say, "I want this done a month sooner" and I open up the plan to start going through stuff, they're going to be like, "Why is this going to take ten days? Why is this going to take fifteen days?" These, then, tasks become undefensable, so they're going to arbitrarily cut my deadline and now my team didn't get what they need. So in work plan step one, we focus on the number of hours. We then, once we interviewed everyone, we pull together this plan. We set up a task, the predecessor-successor relationships. We create a duration, based on the Halftime Model, in days.

J. Scott:           So if somebody gives us four hours, it's a day of work. If they give us eight hours, it's two days of work. If they give us twelve hours, it's three days of work. And so when we build this plan, we add the days of duration. In work plan step two we put it back in front of them and we say, "Okay, let's go through this." The first thing they notice is now there's days. And so somebody might have told us something's going to take ten hours worth of work. We will have then given them three days. And in the vetting meeting, they might say, "No, three days isn't long enough. I need five." Well, we have an understanding of why it's going to take ten hours, because we asked. We explored it and so we're going to say, "Well, here's my understanding. If it only takes ten hours, and here's my understanding of why it only takes ten hours, why do you need five days?" Often that exercise helps us figure out that we've missed steps.

J. Scott:           So we then get a much more comprehensive plan. And sometimes you realize that people are just asking for more time because they're uncomfortable, and that's where we let them know that in work plan step three we're going to sit down with their functional managers and we're going to look at how all these tasks fall based on predecessor-successor relationships and then schedule them around the rest of their workload. So in following these three steps, we get a comprehensive plan with good estimates. We vet it and we identify where we've missed things or maybe need more time for certain things. We can update that.

J. Scott:           We put it then, in work plan step three, in front of their functional managers so they can plan where these tasks fall around the rest of their projects or their operational workload. So by the time we put it in front of a project owner, they may or may not like the end date, but we can literally defend that plan and the time our team needs to get that work done. And really that's stress relieving for the project owner because the second they realize we've done that level of diligence, they feel really comfortable with the conversation of, "Hey, we can get it done sooner, but we need to do less." So you're literally walking them through either cutting scope or giving them the information they need to go to their boss and ask for more time or more money.

J. Scott:           The reason most executives don't like that conversation is they feel like you're going to hang them out to dry, like they don't have enough information to go ask for more time or more money and your plan's not comprehensive enough for them to feel comfort with the duration and the amount of money that you're asking for.

Brett Harned:       Yep. It's such an airtight process and all I can do is think of the first opportunity that you present something to a stakeholder and they end up delaying the project because they can't get feedback or consensus just can't happen. You have every answer in your back pocket for why that timeline then needs to move out because of the delay that they've created. I feel like that's just a scenario that's happened to me time and time again, and if you're not really up to speed with what it takes to get every task done in that plan, you're going to be lacking a lot of answers that are going to be questioned to you.

J. Scott:           You lack the information you need to be an effective leader.

Brett Harned:       Exactly.

J. Scott:           Which is just a different way to say exactly what you just said.

Brett Harned:       I'm curious, when it comes to plans, what types of mistakes do you see project managers or even just project leaders making?

J. Scott:           Well, that's an unexpected question. I see ... Let's start with the way that most people become project managers and that's that there's a critical need to start a project, all of the existing project managers in the organization are overloaded already, they call me, I don't have anyone on the bench, and so this director with this urgent need to start a project thinks, "God, who do I have in my organization that I can promote to project manager that's been reliable?" So they walk out on the floor and they say, "Hey, bright eyes. Would you like to be a project manager?" There's two problems with this. One, the fact that the director is asking implies that they believe that they can do an effective job. Two, this promotion that this person is about to sign up for, this job, this project manager job that they've never done, they have no idea what they're getting themselves into. The next problem is that, especially in America, most people go to school to get their first job and then wing it the rest of the way up.

J. Scott:           So what happens is somebody gets this promotion to this project manager job that they're feeling like they deserve. And they also feel like they get it, they understand what the job entails. And then they maybe get some light orientation around an organization's methodology, which is far from project management training, but they don't know that because they think this must be project management training. God knows, I mean, Nestle must be producing the best project managers ever ever, because they make great chocolate and cereal.

J. Scott:           So they're basically underprepared for the job. They're not educated for the job. The biggest mistake I see project managers make is not investing in their training. Often when I meet successful project managers who basically have been winging it, to me, that's a diamond in the rough. That's somebody that has been successful in spite of themselves, in spite of our culture, and ultimately what I do is I then give them some training and some tools and they become rock stars. When I look at, "Hey, this project manager put a bunch of bologna as assumptions in the charter", I can't really call that a mistake if they don't really understand what an assumption is, what the purpose of assumptions are, how do they use that. Let's say they create fixed durations for all the tasks in a work plan, obviously that's wrong, but can I call that a mistake if they've never been educated? No.

J. Scott:           So I would say the biggest mistake that most people make in the role of a project leader is that they don't take getting educated serious. And again, there aren't a lot of real how-to training programs out there for project managers or leaders. God bless the PMI but they don't teach you how to do anything. It's a great start, get your PMP certification or your ACP certification or your program manager certification from them, but the only thing they'll actually teach you how to do is calculate earned value, which confuses executives so you can't use it. Because if they're confused, the information is not actually-

Brett Harned:       [crosstalk] right away too. Right? Your job is then not really worthwhile. And to me that's an even bigger issue that is a part of the training issue that you're talking about, people not being ready for the role. If an organization doesn't actually invest in or believe in the value of project management to hire professionals to do that job, then you're starting with problems at the beginning of any project because nobody has that foundation or guidelines like you've pulled together to actually run a project efficiently.

J. Scott:           Exactly right. The good news is, today for the bottom price of 9.99, you can get a how-to book on project management.

Brett Harned:       Very true. Very true. So we're kind of coming up on time and I always ask a final question on the podcast, just in the vein of the idea of Time Limit, the idea that we're all kind of limited on time and resources, doing our best to deliver great work. And I'm wondering if you can maybe share some time-saving tips when it comes to creating work plans, creating estimates. Are there any must-dos or things that you would absolutely never cut from your process if you're really scrimping on time? I know we kind of talked about this a little bit before, right? You could be working on a plan in the background while some work is already happening, but I'm wondering if on the more tactical level, if there are things that you think you have to do that will save you time later in the project or even time in that moment.

J. Scott:           Absolutely. I can give you two things which I think are super critical and I think often overlooked.

Brett Harned:       Awesome.

J. Scott:           One, the agenda that we're supposed to create but almost nobody does isn't so your audience can be prepared when they show up to the meeting. It's so you are actually prepared to lead that meeting. The other thing that we've got to consider in creating the agenda is that it's easy for people to identify agenda items but they need to be things that you need to accomplish in a meeting to move your project forward. And then probably the most important thing is considering the bare minimum number of people that you need to be there to either come up with an approach or make a decision to close out that action item or accomplish that agenda item. And then the last thing is you need to model out how long you think it will take to accomplish that agenda item.

J. Scott:           Because the biggest problem in corporate America today is meeting lead time. In Outlook, when I need to invite five people to a meeting, and let's say I'm working in a large organization like Sony Pictures or DIRECTV, I plug five people into a meeting invite and then I look at the soonest time that all of those five people are available together and it could be a week out, it could be two weeks out. So if I don't take time to, one, identify the outcomes that I absolutely need those people for and how long it's going to take me to accomplish those outcomes, I might have five things that I plug in as agenda items, wait a week and a half for that meeting, accomplish three, and have to wait another week and a half for the next meeting. That is so inefficient. What would have been efficient, had I modeled out the amount of time I thought it would take to accomplish those five things, I might've realized that would take me an hour and a half.

J. Scott:           And so what I could have done is I could have sent a meeting invite for a week and a half, the soonest possible time that all five of those people are available, for three of those items, and then a week and a half and one day, like the next day, for another hour for the other two agenda items. What that would have allowed me to accomplish with a little planning was to get all five of those things accomplished in a week and a half plus a day, versus three weeks because I didn't get finished the first time and I had to wait another week and a half for those people to be available again.

J. Scott:           The other thing that I think is critically important and that's often overlooked is blocking time on our calendars to get things done. I see people crossing their fingers, making commitments like crazy, and always running out of time because here's what happens. They look you in the eye, they make a commitment to do something. They have every intention to do it and they employ hope as a strategy. They literally hope they're going to get to it, instead of sitting down at the end of every day and asking themselves, "Okay, what all did I commit to do today?" Opening up their calendar and blocking time to accomplish those things. So really planning your meetings through the use of agenda and time modeling to close the meeting lead time gap and blocking time to actually execute on the commitments that you're making in a day will save you a ton of time.

Brett Harned:       Love it, and I love that you brought everything back to planning. There's no doubt that when you plan for things, whether it's a work plan, project plan, Gantt chart, or if it's just a mental model for how things should play out, a plan is critical to meeting goals and being successful.

J. Scott:           Absolutely.

Brett Harned:       Thank you so much for joining me. I really enjoyed this conversation. I hope we get to talk again. I know that you've got another book that I'm going to have to pick up now after reading this one. But yeah, thank you. Thank you for joining me and I hope we do stay in touch.

J. Scott:           Yeah, Brett, thanks. It was great. I enjoyed it.

Brett Harned:       Thanks.

J. Scott:           Hope to talk to you soon. All right.

Brett Harned:       All right. There you have it, folks. Always plan. Invest time into being a great project manager. Follow that training to make great decisions, be flexible, and involve the expertise of your team and you're golden. If you want to learn more about J. Scott, check out the show notes for links to his site and his books. If you're interested to learn more about the value of a solid project plan, check out TeamGantt. They can help you to create an easy-to-use flexible plan in minutes, so it'll never be a problem when you've got to pull together a plan really quickly. We've also got tons of content on planning and management, so check out our blog and classes at teamgantt.com and come back to Time Limit for more interviews with process and project professionals. Thanks.