Project Management Tactics, Episode 153

Episode Transcript

Carrie: Hey Diane, it is great to have you back on the show. How are you doing today?

Diane: I’m doing great Carrie, how are you?

Carrie: Just fine. Thank you, thank you. So, recently you and I talked about project management from the perspective of, kind of an overview from a strategy standpoint, and not necessarily deep diving into specific tactics or tools. And I love the information you shared in the previous episode, and so this episode I was hoping we could extend that conversation, [00:00:30] and get down into the dirty details. Ar you ready?

Diane: I am.

Carrie: Sweet. So, when it comes to project management, there are various approaches, I guess you could say, that you could take. So waterfall, agile, et cetera. Could you kinda overview what those different methodologies are, and outline their differences?

Diane: Sure. Kinda the classic [00:01:00] methodology for project management is waterfall, which is characterized by you having fixed elements, clear dependencies, lots of check-ins for reviews and approvals. So if you think of it as kind of lines moving across the page, you can’t proceed with section two until section one is complete, you can’t proceed with [00:01:30] section three until section two is fully done and checked off. So that’s really the classic approach, and where most software development started.

Then quite a few years ago there was a methodology that started getting publicized, called agile, and agile was completely different than waterfall. It was characterized by what are called sprints, which are defined [00:02:00] time periods of work. There is usually someone who acts as the product owner, and there’s a process of scrum and a scrum master. So, if you’ve watched this show, Silicon Valley, they are working in an agile methodology; so they have a board that’s full of post-it notes, and the developer goes up to the board, grabs a post-it note, takes ownership of it, and moves [00:02:30] it through the columns. You know, it’s in progress, it’s testing, it’s finished. Multiple things happen simultaneously.
Then there’s kind of a hybrid methodology, which is, in reality, probably what most people use. So, they have flexibility in that they’re incorporating elements of waterfall, they’re incorporating elements of agile, or maybe they’re even creating their own [00:03:00] mini methodologies that specifically work for them. Like, I’ve done things in the past where, we called it time boxing, and said, “Okay, we need to research and figure out a solution. We’re gonna give this three days, and do all our research, and test, and dig in and see what it looks like, and at the end of three days we’re gonna make a decision.”

So the real key with methodology, I think, is not to get hung up on it, you know? All methodologies are valid, [00:03:30] and you can mix them together. So you can have elements of a waterfall methodology, which is probably gonna happen for most of us because we need review and approval from clients at certain junctures, but we might also do things where, let’s say you’re engaged to work with some in-house resources and developing a plug-in, that might feel more [00:04:00] agile than waterfall. So, it’s good to know the background, but I don’t think you have to spend a lot of time, unless your official job is project management, to really dig in.

Carrie: Okay, I gotta say that scrum master sounds like something from a Dungeons and Dragons game, or … I don’t know.

Diane: Probably not an accident. Nerdy as it gets.

Carrie: So, I guess a couple [00:04:30] of questions to go back and wrap a little bit of context. And the first is, at what point in a project timeline are we thinking about what type of approach or methodology is gonna be most appropriate to the team, or most appropriate to the project? Is this, like, after we’ve got a project scoped and we’ve kind of, you know, money has exchanged hands, or a signed contract, or something of that nature has exchanged hands, or is it further back up the chain?

Diane: [00:05:00] It’s probably depending on the size of the project, and the complexity of the project. So, if you’re working on a website redesign that has elements that you’re familiar with, and you’re not doing a lot of new things, you can probably develop your project plan and methodology when contracts are signed and money changes hands, because it’s something [00:05:30] you’ve done before, and you know you can repeat that project plan. If you’re doing something that’s new and different, you should definitely be thinking about the project management process while scope and discovery are happening.

So, if you’re doing something that’s more complex, different, building something custom, managing a lot of disparate elements … Like, maybe you’re doing, [00:06:00] you know, six or eight things for this client that need to coincide at certain points, maybe there’s an app that goes with the website, or things that have relationships, you need to be very heads up about that early in the process. The one thing that characterizes a project, is the fact that it has a start date, and end date, and a budget. So, your goal, when you’re creating a project plan, [00:06:30] is always to be focusing on that period of time and that amount of resources. You know, you’re not looking at a three year, extended, multi-phased relationship, you’re focusing on something that starts, ends, and has a certain number of resources.

The one thing that characterizes a project, is the fact that it has a start date, and end date, and a budget. So, your goal, when you’re creating a project plan, [00:06:30] is always to be focusing on that period of time and that amount of resources. You know, you’re not looking at a three year, extended, multi-phased relationship, you’re focusing on something that starts, ends, and has a certain number of resources.

Carrie: Imagine that, something clearly defined.

Diane: Clearly defined.

Carrie: You know, of these methodologies, do you find that … So [00:07:00] let’s say that we’re talking about a one man freelancer shop, or possibly a small agency with two to three players. And I know you said not to get hung up, but I’m just trying to get the picture. Does a particular methodology work better, based on team size, than other? Like, does it make sense to go agile if you’re just a one man shop?

Diane: I think, honestly, that most of today’s projects kind of fall into the hybrid model, because [00:07:30] even in a smaller team there are things that you can multi-thread. So conventionally we’re gonna have our research and discovery phase, but it’s entirely possible for the person or the team to be setting up the development environment, because that’s not a dependency. You know, you’re gonna need a development environment, or some elements of one, not matter what you’re going to do.

So, there are often things that can [00:08:00] be stacked because they’re not dependent on each other, and then there are some things that are clearly, you know, have to start and end before other things do. Like if your process, your agreement with your clients, calls for a complete design and sign off on that before any build out starts, then you have work that way. Now, there are a lot of projects [00:08:30] where that’s not the case, as the world moves to designing components, or styled elements, and not necessarily one fixed, rigid design. So all of those things are gonna factor into how you build your project plan.

Carrie: Okay, so let’s dig into this project plan that you’ve mentioned a few times. What exactly is that? Like, what does that entail?

Diane: The elements of a project plan are tasks [00:09:00] and sub tasks, which are actual granular items of work to be performed. So when you’re creating tasks and sub tasks you’re wanting to get down to a fairly specific level. When you put a group of task and sub tasks together, then you have something that’s called a phase; so a design phase, or a research phase, or a feature build phase. So you wanna get very specific [00:09:30] with your tasks and sub tasks, and group them into phases.

The other thing that you wanna do with the project plan, that’s so key, is understanding where your dependencies exist. So we naturally work with a lot of dependencies; we sometimes don’t call them that, but a classic example is getting design sign-off before you start the build process, or Q& [00:10:00] A’ing a plug-in before you finalize the build. Delivery of content might be a dependency. So anything that’s a prerequisite, or a required element, before you do something else, you gotta identify those dependencies.

Another element of a project plan is a milestone. When you’re working with clients, or even when you’re working for yourself, you [00:10:30] want pause points in the project, where you kinda review and asses, “Where are we relative to the timeline and the deadlines, how much budget and resources have we used, what kind of communication do we need to do?” So those typically come in the form of milestones. So when you initially build that project, you’re gonna set those points, and say, “This is where we’re going to [00:11:00] reflect, asses, communicate, before we mark this milestone as completed.”

And then, the last element of a project plan is resources. You are probably a resource, for your projects, but you wanna also think in terms of, “Who else are resources on the project?” Your client is a resources; you need them for input review and approval, you might need them for content. Perhaps there’s [00:11:30] someone that you’re outsourcing some specific or technical task to. Maybe you’re working with a writer, photographer. You know, all of those would be considered resources that you need to identify.

Carrie: You know, I’ve got kind of a random association going on in my head, which is thinking about it as a road trip. Like, if I say that my project is to drive from Texas to Florida, and my timeline [00:12:00] is, I’ve got five days to do it, and my budget is, I’ve got $500 to spend. Then I’m mapping out my points along the way, and maybe I’m not staying in a hotel because $500 I can chew up in gas, and my milestones are, you know, those points along the way. I don’t know, that might be ridiculous, it was just a visual I got.

Diane: It’s actually not. It’s a great analogy, because it also creates an easy way to think about contingencies. So, [00:12:30] you have a plan, you’re driving from Texas to Florida, these are your milestones, this is your budget. You have it all neatly planned out, and then a hurricane blows out through the gulf. Problem. So, a lot of project management is, we’re focusing on the initial creation of a project plan, but it’s important to remember that what you’re building for yourself is a tool to manage the project. [00:13:00] So this isn’t a static entity, this is a tool that you’re gonna use to manage something that’s never actually going to occur the way you’ve mapped it out. Things will finish faster, things will take longer, it’s very dynamic and always moving, so your goal is to create a tool that’s gonna let you see that and adjust [00:13:30] on an as needed basis.

Carrie: Excellent. And we’re gonna get into those, I’m gonna ask you about some of those tools in just a moment. I did wanna kinda dig in though, on maybe some examples of what you … So you said there’s tasks, there’s sub tasks, and then there’s phases that’s, you know, sort of umbrella over those. If we took … Let’s say that I’m doing a brand redesign or something, so [00:14:00] I’m doing this project scope and one of those things is, create a logo, which I know is not at all a brand strategy, I’m just throwing easy examples up there. So in that case, as part of my project scope I’m saying, “Okay, well in order to build the logo, first I’ve gotta determine a type face, or a color palette, or mood board, or …” blah, blah, blah. Are [00:14:30] those examples of things that would be tasks and sub tasks?

Diane: Yes, and sub tasks are kind of optional, depending on how big your project is, and how you wanna manage things. So, let’s say that the process of creating the logo has three phases, roughly. You’re gonna do your research and preparation, you’re gonna do design work, and then [00:15:00] you’re gonna do revisions. So within doing your research and preparation you might have tasks like gathering examples for inspiration, creating a mood board. You might have tasks like creating a color palette based on what the client already has in place; maybe they want a new brand identity, but they’re happy [00:15:30] with their brand colors.

So you may have a series of tasks within that phase, and sometimes some people like sub tasks and some people don’t. So, I tend to like everything broken down as much as I can get it, so I have a tendency to use sub tasks. So I might have a task that’s, you know, competitive research, and within that I [00:16:00] might have sub task to figure out who their brand competitors are, creating a folder of what people are doing in that space, type of thing. And it doesn’t truly matter whether you have 14 tasks, or 10 tasks and five sub tasks, as long as it works for you and what you’re doing.

[00:16:30] Another consideration with tasks and sub tasks is, people resources. So, if you have multiple people working on a team, breaking things out into sub tasks is an opportunity to easily delegate something to someone else. So, if I create a sub task, it could be something that I assign to a junior designer or a VA to go do, and it makes that easy in terms of utilizing [00:17:00] software.

Carrie: Okay, well let’s talk about software. I know project management is a skill and not a tool … Which actually, love that quote from you. But indeed there are software tools out there, so can we move in and talk about some of those?

Diane: Yes, there are many, many software tools, and what I think is kind of interesting is, most of the tools that we call project management tools, and I’m thinking of [00:17:30] Basecamp, Asana, Trello, Freedcam, Teamwork, there are so many. Actually most of them offer features that go beyond project management. So they give you communication boards, places to upload files, they’re very, very rich. When we look at the process for project management, the classic approach is using [00:18:00] a Gantt chart, and that’s a feature that most of these tools offer, as an extension, or an add-on.

A Gantt chart is a visual tool that shows you bar lines that go from left to right, and has the ability to connect them, so that you can actually create dependencies. [00:18:30] It has a function where you can designate milestones, and it has the ability to associate resources with tasks. Using a Gantt chart is probably one of the easiest ways to build a project plan, because it’s very interactive. So, when you begin and you start loading in tasks, you can just load all your tasks, for example, that you’ve identified. [00:19:00] Then you can start grouping them into phases, then you can start applying timelines, and you can take a phase and make it dependent on another phase. And so, what happens is, as you go through this build process, which is quicker and easier than I’m making it sound, as you start to push and pull, and change dates, everything’s gonna change for you.

Carrie: What I love … The first time I laid eyes on a Gantt chart, I think the nerd in me squealed with delight. [00:19:30] And because it’s so visual, it’s easy to show, “Okay, look, here we’ve got this dependency, and this entire phase can’t move forward until this dependency is complete. So if we just scoot that dependency, the completion of that, back by two weeks, we’d see the entire chart shift, and all of a sudden our project is now [00:20:00] extended beyond … There was a hurricane blowing through the gulf coast.

Diane: Exactly. Or when you think about something like, as you’re laying out milestones, like maybe there’s a milestone of design approval by the client. And maybe the client is in Dubai for three weeks, on vacation. While in your mind you thought that that might be not more than [00:20:30] five days between phase one and phase two, the client isn’t even available at that time. It’s simply not going to happen, because they’re gone for three weeks, then they’re gonna come back and it’s not gonna be their first priority. So juggling those dependencies starts to become really, really helpful, because it’s quick and easy, it’s visual, and all of a sudden you can see, “Oh, well I thought this was a six week project,” [00:21:00] and it probably is in the purest sense of pure effort; in the real world, this project is going to take about four months.

Carrie: So you bring up an interesting point, which is, clearly there needs to be communication with the client, and there would be, ideally anyways, but as you’re laying out sort of this timeline beyond what you’ve already agreed to in the [00:21:30] contract, when it gets into sort of the daily details of laying out the Gantt chart and saying, okay, these by such and such a date, I’m gonna be looking for this for you, from this for you, et cetera. So you’re giving that client the chance to say, “Hey, I’m in Dubai, so I’m not even gonna be available then,” so you can adjust as needed. So that’s a process that’s happening, I guess, from the get go.

Diane: Yeah, this is kind of a critical project [00:22:00] management practice. So, you build your project plan, which is somewhat hypothetical. You know, you took the information that you had available, you sat down and build the project plan, you’ve created your Gantt chart that shows how things are all fitting together. Now you need to go around and you need to skillfully fact check that with the members of your team. [00:22:30] So you need to go over it with the client, and then you say to the client, “So, we have you schedule to do design review on such and such a date,” and the client’s like, “Oh, no, I’m gonna be in Dubai.”

Maybe you’re working with the developer who’s doing your build for you, or you’re working with the firm that’s doing a custom piece of functionality, and you say, “Okay, we have you scheduled to start June 27th, and finish by this date,” [00:23:00] and they say, “Oh, well, since last time we talked, this has changed, so we need to start a week earlier,” or, “We’re not available until two weeks later,” and this circle of input, and then adjusting your project plan with a couple clicks, so a Gantt chart becomes very powerful. And the same thing continues to apply once you start managing the project. You keep updating [00:23:30] and modifying things, so you always have a realistic view of what’s happening.

Carrie: Wow, that’s great stuff to think about. And I know, as a freelancer, or somebody who’s working alone, you’re wearing all the hats … And I’ve kinda come to hate that phrase, but I don’t what else there is for it, other than, you’re multitasking a whole lot of roles. And as the technician, which most freelances, that’s the part they’re good at, right? They’re good at doing whatever … Developing, or designing, or writing, painting, whatever the [00:24:00] skill is. But this project management piece is a whole other kinda entity to sit on top of that technician layer, and so, when things happen, like delays, or … Then the fact that there is that huge need for communication up front, that’s where I think, you know, a lot of projects can just end up in frustration for that technician, if the project management [00:24:30] piece hasn’t been handled well.

Diane: Right. I would say that that’s the number one cause of conflict, frustration, less than ideal feelings between folks and their clients, is if the last work you do on expectations is kinda that scope discovery contract process, and you think to yourself, “Okay, I laid out what I’m going to do,” and [00:25:00] then you kinda just go off and do it, you’re leaving the client in the dark, and it makes a lot more sense to build a project plan where you actually incorporate content delivery, communication, all these things that projects get hung up on. Projects get hung up on them because we’re not giving them enough focus and attention.

You know, it’s not enough to say to a client, ” [00:25:30] Oh, and I’m putting you down basically to have all the content done by such and such a date.” You know, that’s just not enough. Or, “We’re going off now for six weeks, and we’ll come back to you when we hit the first milestone.” You know, clients aren’t project managers, they’re not technicians, so this concept of communication, and feedback, and updates, in a structured manner, [00:26:00] makes all the difference.

Carrie: Good stuff. Oh my gosh, we’ve almost been talking 30 minutes and I’m not through asking you questions, so we’ll just charge ahead. So, another thing I wanted to ask you about, I’ve heard discussions, or, kinda different philosophies of, “Well, I use Basecamp. For every project, I use Basecamp. And it doesn’t matter what my client is used to using, or maybe they’re not used to using anything at all, [00:26:30] they’re gonna use Basecamp if they’re gonna work for me,” or, insert whatever piece of software.

I know you’ve got a comment, I’m gonna finish my question. You’re ready, you’re coming out the gate. So, I guess it’s a two parter question. One is, how do you consider working with your, kind of suite, of comfortable project management tools, versus stepping into a client’s environment, when maybe they’ve already got kind of that structure [00:27:00] set up? So that’s the first part. And two is, I don’t know, I guess it’s a piggyback question, but kind of putting a square peg in a round hole in terms of, every project is gonna fit in this particular structure, or use this particular tool.

Diane: I think, in my opinion, that the mentality of, “This is my tool, and by gosh, you’re going to use it,” is incredibly flawed. [00:27:30] Because, I think, fundamentally you have to make a decision whether you’re a service provider or a technician, really. Is your goal to deliver code and design, or is it to deliver a good product, with a good experience for the client.

And so, clients can fall in a lot of pockets. There are clients who’ve never used [00:28:00] any of the tools that we use for any reason, and it’s not gonna make sense to them, they don’t know where to do things. Then there’s another scenario, where you’re working with larger clients who may have familiarity with different tool sets. I think it’s an important conversation to have, and it’s an important conversation to have before you write the proposal, or do the scope for the project. [00:28:30] If you make an assumption that you’re gonna introduce a new tool to a client, and it’s just gonna work perfectly for them, and your process isn’t gonna change in any way, and then that turns out not to be the case, you’re gonna spend time, energy, and frustrate your client.

So it’s really better to figure that out during discovery and scope. You know, that concept of, “How are we going to work together? [00:29:00] How are we gonna communicate? How do I wanna receive input from you? How do you wanna receive updates from me when tasks need to be assigned? How do we wanna do that?” Have that conversation as part of your process, just so you get a sense of what’s gonna be possible, and what’s gonna work well. I don’t think there’s one size fits all, and [00:29:30] I think you can say, “This is my process, fit in it or I won’t work with you,” but that seems like a very limiting strategy.

Carrie: Oh Dianne, I always enjoy what you have to say, frankly regardless of the topic, but these are little golden nuggets. So I guess, you know, let’s say that you’re working with a small client, and many use the word unsophisticated, and that does not mean [00:30:00] that they are stupid, it just means that they don’t understand my world and my technology; I’m coming to them as the expert, providing a service. So, in that case, would the approach be, “Hey, we’re gonna need to be communicating about things, we’re gonna need to have a way that I get information from you and you get information from me. I have some suggestion on that, do you have anything in place that you would like [00:30:30] me to know about?” Or, like how would you approach that conversation?

Diane: I would approach it just like that. “During this project we’re going to need to get items from you, we’re going to need you to complete tasks,” and Aaron Flynn has some really good stuff on onboarding, which is where I would have these conversations. So, [00:31:00] you know, I’m bringing this client on board for this project, and I need to be really clear about how we’re gonna communicate on things. And maybe that client is comfortable getting task assignments from a project management system, and that’s fantastic. If they’re not, if you’re getting that sense of, “Oh, um, okay. I’ve never done anything like that [00:31:30] before,” or you can end up with a client who assigns you a task in a project management system that says things like, “Can we have a quick call today?” That happens over and over, you know, something is not working there, right?

So you need to, I guess plan for some flexibility. And I think we, as technicians, have a lot of skills in making things work in different ways. So, if you [00:32:00] have somebody who isn’t super great at, maybe logging into a system and utilizing it, I think almost every system has the ability to capture tasks by e-mail address, leveraging, you know, things like that. Just try to be flexible, try to think of yourself as a customer service provider, and don’t make assumptions that a very [00:32:30] rigid process, that you’ve come to love, is going to work for everybody.

Carrie: That’s fantastic. I actually had a couple follow up questions, but that was such a good note to end on, I’m gonna call it. But, I’m gonna follow up this, a couple of notes for you guys that are listening. I had Aaron Flynn on the show earlier this season, to talk specifically about onboarding, so I’ll be sure to link to that in the show notes. And then, Diane, not to put you on the spot here, but if I go and write maybe a blog [00:33:00] post over on my website, CarrieDils.com, could I maybe ask you those couple of extra questions and get you [crosstalk 00:33:07]

Diane: You certainly can.

Carrie: Excellent. Okay [inaudible 00:33:10], well I will let you plan for the next hurricane that’s gonna be coming through Florida, or whatever storm awaits, but Diane, I always appreciate your expertise, and just coming on the show to share, so thank you so much.

Diane: You’re very welcome.