4 reasons PM methodologies fail

In this episode of Workflow, Brian and Tom talk about reasons PM Methodologies fail and how you can avoid it.

00:38   What’s happening Brian and Tom (movies, in-home tech ecosystems)
07:33    Inspiration behind this episode: Top 4 Reasons why your Project Management methodology Fails
08:24   1st reason: Complexity Creates Chaos
14:35    2nd reason: Process Overload 
18:11    3rd reason: Too Much To Do, Too Little Time
23:33   4th reason: People, Politics, And Budget
29:12   Bring it back to the basics
37:55   Tips for taking action!

Useful Links

Top 4 Reasons why your Project Management methodology Fails
Workflow episode 4: A baseline workflow for any team
Workflow episode 5: Finding your meeting Rhythm

Brian: 00:00 This is Workflow. Episode 16.

Brian: 00:14 Workflow is the Podcast that helps teams figure out the best way to work, collaborate and get stuff done.

Brian: 00:20 Brought to you by Rindle.

Brian: 00:29 Hey everyone, I'm Brian.

Tom: 00:30 And I'm Tom.

Brian: 00:31 And we're the co-founders of Rindle and this our Podcast Workflow. Today we are talking about four reasons project management methodology's fail. So before we do that, Tom, what's going on with you?

Tom: 00:43 Not much. You know, another week. We had an interesting discussion this morning about like, both Brian and I have kids, and you know, kids like to watch the same movie over and over and over again so you end up buying that movie, and it's so difficult now like when we were kids we just had, you know, VHS's or I guess DVD's and nowadays, it's like, oh, you have to purchase the movie but like what service do you buy it from, like, it's really an interesting thing.

Tom: 01:16 You can buy it from your cable provider or you can buy it from Apple or you can buy it from Google or Amazon then you can't play it in certain places. You make one decision over another. It's a headache.

Brian: 01:30 Yeah, it is really stressful. I mean, I think that people are generally, you know, making tough decisions about what ecosystems they live in. I think most of us are probably like torn between a couple like I know I am. You know, I love Apple. I have Apple TV and I purchase my content usually through iTunes and Apple sources so then I use Amazon and I have prime and prime video and I have Netflix so I have all these sources and when it comes down to your house too, like I have an Alexa and like things start to all tie together, right and then you know people have Nest thermostats and you talk about, "What should I do? What integrates with what? How does everything tie together?"

Brian: 02:13 So you end up trying to like live in an ecosystem so everything makes sense and it's easy but I think inherently we end up with multiple.

Tom: 02:21 But it's not yeah because Nest is a Google product right?

Brian: 02:24 Right.

Tom: 02:26 Yeah and they all, at this corporate level attempt to like, you know fight with one another so like-

Brian: 02:32 Of course, they want you to get, you know, into their ecosystem with their products with you know, Chromecast and all these things they have to network your house, you know.

Tom: 02:41 So it makes a consumer's life hell, right? Like, really it's not cool.

Brian: 02:48 Yeah. I think it's like you have to figure out what you like best and what's best for you. There's different price points, there's you know, different integrations and functionality but yeah, I mean as far as content I definitely, you know, I live in the Apple world for the most part outside of Netflix which is great for just, you know, you're paying one flat fee for a bunch of content which is awesome and they have some unique stuff on it and Prime Video, I just have because I'm a prime member and I use Amazon for like everything pretty much.

Tom: 03:16 Sure.

Brian: 03:16 I pretty much live in there but when I buy a video or when I buy a movie, you know, it's from Apple.

Tom: 03:26 Sure, yeah. Me and my wife, we try to stick with like Amazon for most purchases but like, before that we bought some stuff on Fios which is our cable provider and now we feel like, "Oh, that's kind of annoying," because we're stuck there and it's like we have to remember, did we purchase it on Fios or did we purchase it on Amazon and it's just ... I wish there was an easy way that you could just be like, "Okay, here's all the stuff I own." Doesn't matter what device that you're on right?

Brian: 04:07 It's tough.

Brian: 04:08 You could just never move, it's fine. You're just always or just move anywhere in Fios reach, and you will be fine.

Tom: 04:14 Yep.

Brian: 04:14 You'll be able to get back to your content.

Tom: 04:16 Yep, I guess that's it.

Brian: 04:20 Cool. Yeah, I'm working on a new exercise routine even though exercise is not my forte but I am walking every day.

Tom: 04:30 Wow.

Brian: 04:32 You know, about 15 minutes to a half an hour usually but you know for various reasons but just breaking up the day, actually doing some activity and then obviously I'm going to try and build on that, but you know, not my forte so I'm pretty excited to actually have like a week under my belt of actually doing something every day and getting out of the house especially working remotely.

Brian: 04:52 You know, I tend to want to sit in front of my computer and get stuff done but you know I have to force myself sometimes to you know, get outside. I used to try to go to Starbucks but that's kind of annoying to work sometimes because it's loud and you can't have meetings necessarily or video calls real easily so getting outside so far is helpful but you know we will see what happens when it gets colder.

Tom: 05:14 Yeah, this time of the year, I mean, you know, I run like most of the year and this time of year it's so tough, like as soon as it starts to get cold and dark early it's like ... Because in the summer, I mean, I usually go for my runs in the night time right?

Brian: 05:29 Yep.

Tom: 05:31 Now it's like, come 7:30, it's pitch black outside so you're like, "I'll just pass."

Brian: 05:36 Well, if we were standing next to each other, you'd definitely be able to tell which one is the runner and which one is the walker. Yep.

Brian: 05:43 So one day I'll get up to running.

Tom: 05:45 There you go.

Brian: 05:46 I'm also growing a beard. So I grew a beard last winter, so I'm starting my beard. I already started it because I started a little late last year, and I actually really enjoyed having a beard, a longer beard so I'm starting to grow it now, but I'm getting into beard products now. You know, because it is ... Like last year it was really rough right, a little coarse and I didn't really ... I'm not that fussy so I didn't really get that much into it but this time I did a little research and they have like beard oils and it's basically like hair conditoner and beard wax and other things and I also got a really good like trimmer because my trimmer really doesn't make nice lines.

Brian: 06:28 Anyway, so I'm not equipped for my growing beard season and shaping up my beard now and keeping it conditioned so we'll see what happens.

Tom: 06:38 You will have to let me know how that works out.

Brian: 06:40 Yeah. It really is, you know, there's an ecosystem of products as well for any kind of hobby or interest or anything you're doing. There is somebody making money off that which is always pretty interesting.

Tom: 06:54 Cool.

Brian: 06:55 So before we get started do you have any questions, topics as always reach out to us. Let us know, we can tear them down, answer any questions you might have. You can call us on our voicemail number at 860-577-2293 or email us at workflow@rindle.com.

Tom: 07:13 Also don't hesitate to leave us a review. It really helps us reach more people and it also keeps us motivated to keep doing this every week. Which some weeks it could be a little tough.

Brian: 07:25 Yep but we need those reviews.

Tom: 07:27 Yes.

Brian: 07:29 If you're liking what you're hearing, and you're liking the content, we would must appreciate it.

Brian: 07:33 Alright, so onto the main topic. This was an article written by our very own Julie Ann on our blog, and it's a topic that we always talk about generally in kind of a core to our beliefs, so I thought it would be interesting to talk to about. The article title is "Top Four Reasons Why Your Project Management Methodology Fails," and we'll link that up in the show notes, so you can go check out that article.

Brian: 07:59 But basically Julie Ann outlined, you know, a few reasons why some of the complex project management methodology's that are out there and there are a bunch and she actually, you know outlines them. Probably the most popular are Scrum and Kanban but really talking about why, you know the project management methodology though proven and very processed orientated may fail you, which I thought was pretty cool.

Tom: 08:24 Definitely. So I guess we should hop right in and get to the reasons. So the first reason is complexity creates chaos.

Brian: 08:34 Yeah and you know most project management methodologies are generally more complex. If you think of like you know, a task list. The simplicity of a task list saying, "Hey, I'm going to make a list of things I need to do every day and everyday I'm going to check those things off," compared to some of the more formal project management methodology's that have a lot of process and what I always call overhead to them and generally the more complex you make things, you know, the more chaos happens and typically I see this mostly in my experience as you know, people are just generally confused.

Brian: 09:16 Sometimes you'll pick a methodology that you as a project manager, lets say or a team lead are researching and saying, "Hey, we need to change the way we work, let me go find a way to work," and you bring it back to the team but you know, same thing with the software adoption Podcast we did. Some of the same issues but you know, you come back and their like, "Well, what's Scrum? Like what is Scrum?" So you have a team possibly that doesn't know what the methodology is all about. They are not experienced in right, so it can be very, very confusing for people to kind of adopt, really process complex, heavy project management methodology's.

Tom: 09:51 Sure. If there's a big learning curve to the project management methodology, you're probably not going to have an easy time having it be adopted right? If there's like a lot of steps to it or you're having a lot of overhead as you said, it's not going to be easily adopted, and I know ... I for one, like if it's too complicated I will just opt to not do anything with regard to it instead of like, "Well, let me try to figure this out." It's not worth my time to try to figure that out for the most part right, because it becomes a waste of time, clearly it's missing the mark right?

Brian: 10:28 Obviously things take time to ramp up, right?

Tom: 10:30 Sure. Yes.

Brian: 10:30 And sometimes you have to put some time in and training and all that stuff, and you know, nothing's perfect where even though some of our more simplistic approaches, you know, are definitely meant to get up and going like the visual workflow we promote or even like Kanban which is to me the most simplistic PM methodology which is, I think a quicker up time but yeah, it takes a little time to get going with anything but I think when anybody comes to you with like, "Okay, here's what we're going to do, we're going to roll our Scrum and here's what Scrum's all about." You know we're going to have Sprints and those Sprints are going to be two weeks long.

Brian: 11:03 Okay, wrap my head around that. In order to do a Sprint, we have to plan a sprint and planning a Sprint has a bunch of rules. You know, you have to assign story points, you have to figure out how many story points are in your sprint and that's the velocity, right and you start talking about all this stuff and then the glazed eyes start happening.

Tom: 11:19 Oh yeah, yeah, yeah.

Brian: 11:19 Right. Where it's like wait a minute. What? And we're not even into you know the rest of how the project runs yet. We haven't gotten into retrospectives and all of these things that happen in Scrum specifically.

Tom: 11:32 Sure.

Brian: 11:33 I think that's the worst part of it, like where it's just difficult when you start introducing something like that where people generally, whether it's a PM methodology or something different. When they're kind of approached with complicated instructions or process, they're like, "This is going to be a nightmare." Like, "I don't want anything to do with this."

Brian: 11:52 Like you're saying, I'd rather do nothing than do this.

Tom: 11:55 Sure. And even more than like these formal processes, it's even very specific processes that some project manager decided to make within your organization.

Brian: 12:08 Well I think the challenge too is that with some of the complexity, you may not realize it until like you implement it so everything looks great on paper. Sometimes you research something, you look at some case studies, you look at examples of teams using whatever methodology you're looking at, you can envision yourself and your team using it but in order to get to a point where you are implementing it, it's going to cost probably money and training and resources and time to get there and then you probably won't realize the complexity or the challenges you are going to face until you get to that point.

Brian: 12:41 So, it's very hard to see the future with anything you do, right so when you start with a lot of overhead and you have to get from point A to point B, and that's going to involve training and time and all those things that I mentioned, that makes it a higher risk, right, a failure.

Tom: 12:56 Yep.

Brian: 12:57 At the end it could be much more complex as opposed to saying, you know, even with any methodology, "Okay, here's the whole methodology. We're going to start with this piece of the methodology first," right or start with something very simple and then it's a lot easier to kind of grow on to it and you'll be able to tell a lot quicker hopefully that, "Hey, this may not work or this part's working great, let's move onto the next part," or something like that.

Brian: 13:17 It's just really hard to predict the future and it's definitely going to be an investment depending on the complexity.

Tom: 13:23 Well and it also requires real dedicated project manager who ... Or project manager depending on your scenario, who's really focused on, you know, just the methodology and just actually managing the project, right, which a lot of times project managers aren't lucky enough to have that luxury to actually just manage the project, right because project managers have to be doing a million other things in most organizations.

Tom: 13:53 You see it a lot especially in agency world right, where project managers not just actually managing the project, their testing, they're writing copy, they're doing a bunch of other stuff because-

Brian: 14:04 I used to do all that stuff.

Tom: 14:05 Exactly.

Brian: 14:05 I did copy, testing. I actually did UX, wire frames, all kinds of stuff that I probably shouldn't have been doing.

Tom: 14:13 And it's a topic for another time but like the project manager should be like focused on managing the project. Is the project going smoothly? Are all the steps like being taken, right?

Brian: 14:26 Are we staying organized? Are people doing the things needed to get done to stay organized, have conformity and you know make sure everybody knows what's going on.

Tom: 14:34 Exactly.

Brian: 14:35 So the second reason is process overload. So processes definitely key for business operations and managing projects so you know we just went on and on about how complex project management methodologies can confuse team members but you know, process is necessary for sure but I think it really comes down to possibly too many processes, you know can further complicate the project so we even kind of touched that in the last topic. The first topic, the first reason. When you start tacking on-

Brian: 15:00 ... topic, the last point, the first reason is like, when you start tacking on process, to process, to process, to process, that's when the eyes glaze over. All those things happen and it definitely elevates the risk of human error. The more you have the human doing, and understanding, and remembering and all those things, the harder it is to actually make sure that stuff executes every day.

Tom: 15:23 Definitely. The more people have to remember, the more easily they forget different steps, especially small steps.

Brian: 15:32 Yeah. Like you were saying, notifying somebody when you're done with a task, that's a very simple thing, and especially if you're working in multi-team environments, or whatever your scenario might be. Letting the next person know, "This is done," or, "This is ready for your review," or, "Now I need your part of it. Here's my part." Whatever that is, I always had trouble with actually multiple teams potentially talking to each other. A lot of times, they might tell me and say, "Hey, Brian, I'm done." "Okay, can you tell George? 'Cause George is actually the next one." I don't want to be the stop gap for everything. Sometimes they don't say anything to me or George, and then there's a drop-off that happens. Asia and I even talked about this in an episode, but the drop-off happens, and now there's a delay. I'm not aware of it as the project manager until the next day. We've already lost a day in a project, on a tight timeline. That happens over and over again. Before you know it, you're in trouble.

Tom: 16:31 But even worse than that, if you have a software in place, and the person is using the software and say they just mark it complete, that they're portion is done, however you're doing it within the software. If the other person isn't using that software, then there's already a breakdown, because they're not gonna see it, or if there's no way for them to be notified in the software that that's done.

Tom: 16:53 It shouldn't be that you have to mark it complete in the test software, and then go, and also talk to them, or send them an email, or tell the project manager and have them do it. Now you're just having multiple people do the same step over and over again, where it was actually just already done. Person finished their task and marked it complete, and the next person should be able to pick up and do whatever they have to do.

Brian: 17:20 Yeah. This is big, as we've discussed in previous episodes as well, a big reason why we created automation. You even just now saying, when you're doing the same things over and over again. You need to notify people on certain steps, over and over again, and that process is very custom to your workflow, how do you handle that? Checking off a task, like you're saying, in the software, is what you're supposed to do. But the person who needs to know that and may not look at the software that day, may not even log in, how do you make sure they get notified specifically? That scenario could always be different, which is a challenge. Depending on what software you're using, it can be interesting how you handle that. But that's how we handle it with automations, as far as creating custom rules where you can notify who you need to notify at certain stages in your workflow.

Tom: 18:05 Cool. The third reason that Julian mentions is too much to do, too little time.

Brian: 18:11 Too much to do, too little time really comes into these formalized complex project management methodologies may cause more overall busy work for team members, including the PM. There's more time managing the work than actually doing the work. You feel almost obligated to the project management methodology like, "This is how you do Scrum. This is how you do [inaudible 00:18:34]." You may actually end up doing things within that methodology that you may not even agree with, or want to do, or your team doesn't want to do, but because the methodology says you have to do it, you end up doing it. Sometimes that ends up causing busy work that is really not doing much for your team, for whatever reason. Maybe it's a unique scenario, maybe it's a unique team combination, maybe it's a unique project.

Brian: 18:57 A lot of times people don't veer, especially when you're starting out with something new. You want to follow it to a T, just like following a recipe. You want to make sure you have all the ingredients and you're doing it "right". Of course, some people who are more experienced might veer off and adjust on the fly. But sometimes people get very locked onto the ingredients of the methodology, that you have to follow every ingredient and every instruction, which may cause just a bunch of work for everybody where they're not actually doing the actual work, they're actually focusing more on the process.

Tom: 19:32 Playing a little devil's advocate here, it does strike me that a lot of these project management methodologies typically are front-loaded. Initially they start of with a lot of work, but that initial work is meant to ease the work that happens later on in the project. It is difficult to determine if that's causing a lot of busy work, or is this gonna be this the entire time we're doing this project?

Brian: 19:58 Yeah. It is tough to tell, and every scenario is different. Obviously somebody tried-and-true came up with the methodology and the steps, and the things that they found value in, things like a retrospective. That's something when I was executing scrum, always felt like a challenge where we were having daily stand-ups. Why do we have to have a retrospective at the end of the week, and what are we actually doing? Nobody really wanted to record the problems, and the issues, and we were talking about them during the week. But we did it because it was part of the methodology.

Brian: 20:34 We ended up eventually doing something slightly different and modifying it, but the point is, it's front-loaded because they basically figured out a process that makes sense, whoever figured that process out, and tested and tried it, and then it's up to whoever's implementing it to either customize or follow exactly.

Tom: 20:55 I do also think that team size has a lot to do with the success of failure of project management methodologies. The smaller team, like you have just a two or three person team, and a project manager, it might be too small of a team for a formal project management methodology because there's almost not enough overlap with the amount of work, and everyone keep track of what everyone else is doing.

Brian: 21:25 Yeah. It might just be overkill, if you have a two or three person team, maybe you're sitting in the same office together, or you're on a video call every day together, whatever it might be, you're just communicating all the time. You're just outlining work, getting it done, moving things along in a very ad hoc way. That might make complete sense for you. Why add overhead when you don't need it.

Brian: 21:53 I agree, if you have a larger team, a larger business, whatever it might be where you have a lot of cogs in action, something like a methodology very well might make sense, 'cause it's giving a lot more structure potentially, giving exact steps to follow. Definitely could possibly work. But I would agree, the smaller teams for sure might be overkill. I think that's really why we always typically recommend starting out simple, especially if you're a small team, 'cause a lot of people see the shiny stone or the shiny gem on the internet and they're like, "Yes, this makes sense. I want to work like this. I want to be agile, I want to do this." But a three person team, its like, "Why? You're already being agile most likely." Why add a whole bunch of overhead, and process, and learning, and things that don't necessarily need to happen. Maybe it makes sense for your team, but most likely you could probably start off much simpler.

Brian: 22:52 I personally find that if you over complicate it and the process, you're tying multiple processes together, and the process is very complex, typically the process is the first thing that drops off. The people are still gonna get their work done, but things will just start to slowly fall apart because people just are overwhelmed, they forget whatever the case might be, and it's a large adoption process and learning curve for everybody, but it's lot of maintenance. You have to be on top of everything to make sure things are happening the way you want it to happen. That just will slowly start to fall apart if it's too complicated.

Brian: 23:33 The fourth reason, and final reason, are people, politics and budget. People primarily meaning buy-in. A lot of times buy-in can happen at multiple levels. It could be management. They may fail to see the value in whatever you're proposing, they might not give you the time and/or budget to get it done properly and implement it. That is a huge red flag, if you don't have that.

Brian: 23:58 It may be hard also to get the budget for the research and training that you might need. This is something that's typically is overlooked. The amount of time that it actually takes to train, get people up to speed on a methodology, any kind of formal training that might be needed, in-house training, whatever it might be, and maybe even just research into your own education, maybe it's new to everybody kind of thing. It just maybe hard to get that, especially if you're in a chaotic, busy environment, and setting time to actually get that stuff done.

Brian: 24:27 But the other side, the people side is team buy-in. You have to have your team. You have the management side to get you rolling with budget and training, and all that stuff. Then you have your team buy-in. Same thing with software adoption. You still have to get your team to buy in to the process, and be supportive of it, be excited about it, and actually implement it every day.

Tom: 24:45 Also, as I mentioned before, having management that buys in to the importance of a project management in general, is really important. It's pretty important to keeping all those cogs turning, and turning smoothly. They're the ones that oil the cogs.

Brian: 25:06 Yeah. Also when you have something that's working for your time, obviously it makes for a happy team too, which in any environment you always want. The smoother those cogs turn, the happier everybody is. Hopefully the better the work is, the more efficient the team will be, and the happier ... If you have a customer, or end-users, whatever you're building for or creating for, that's gonna be a better situation all around.

Tom: 25:30 One of the companies that I worked for, our product manager actually left the company. He resigned. He had been there for a really long time. It's actually a difficult position, just to fill an experienced project manager. Especially for a product that's pretty far along in the life cycle. We actually just went without one for a while, and it definitely changed the entire mood of the organization.

Tom: 26:04 We had been really bought in to having this person that's helping to manage everything. When that disappears, it's really difficult to replace. It's also something that a lot of people probably don't experience because it doesn't necessarily happen too often.

Brian: 26:21 Yeah. Even in our team, at Rindle, I am probably the PM person overall. My thing is I get [inaudible 00:26:30] when things are not organized, generally. Even if things are free flowing and we're doing lots of things at once, and we have a lot of moving targets going on, when I feel unorganized, I say it. I'm like, "I feel unorganized. We got to do something. We got to talk about this stuff. We got to get things in a row here so we all know what's going on."

Brian: 26:48 If you don't have that person, that can go on for weeks. Before you know it, you're at a point where people are just generally unproductive and not really understand what is going on. It creates chaos.

Tom: 27:02 No one's driving the boat, to some extent. Obviously work is still kind of getting done, but no one's putting all the pieces together.

Brian: 27:12 Usually a project manager or the team lead, or whoever that person is, generally if they're good at their job, they're generally on top of that stuff. They generally are probably like me, where they're organized, or at least they want to be organized. They see things from a different level, and just want those pieces to connect and make sense. Even if the people on the team who were executing some of the work, may not feel the same way, and that's fine. But not having that piece, things are just floating. Then all of sudden you're like, "Whoa. Things are floating. We don't know what's out there right now." Get pretty interesting.

Brian: 27:50 But the politics side of this too, we had a used case even at our agency that we work together, we had somebody who was heading up the development at the time. We were doing waterfall as our methodology there. They had been doing, even before Tom, you and I, our time there, they've been doing waterfall for a while, since they started building interactive website type application products, and things like that.

Brian: 28:15 We wanted to move to a more agile flow, and we, meaning Tom and I, and a few other core people in the New York office. There was a few people voicing, saying, "We'd like to work a little differently. Here's the reasons why." But there was a lot of politics involved in that because the person who implemented waterfall and brought that, which brought a lot of organization, a lot of good things, was being like, "No. I don't want to uproot everything I've built over the last 10 years to make this drastic change." He was basically putting a stick in the ground and saying, "Nope. I'm not budging. You guys can push as hard as you want."

Brian: 28:58 We ended up actually doing some experimenting in a smaller team, which ended up being interesting, and trying some different ways of working which is cool, but definitely politics can play a part if you want to make some kind of drastic change.

Tom: 29:12 There were the four reasons. But I think one of the best things that we do with project management is bringing it back to the basics. Especially if you don't have a formal project manager, or you're not a project manager by trade, you're not PM certified in any capacity, you just want to bring it back to the simplicity of what project management is supposed to be.

Brian: 29:41 This is, really the person you just described there, we call internally here the non-PM. Founders of companies, or team leads, or managers, people who are not formally PMs, they're not trained to be project managers, but they fall into having to execute on those things, and lead teams, and manage projects. Even people who fall into PM ...

Brian: 30:00 ... and lead teams and manage projects, even people who fall into PM positions have the title of Project Manager, but they're not really project managers by trade, they're going to kind of learn on the job. Instead of again, over complicating things, go back to the basics.

Brian: 30:16 The first basic is, get tasks into a software like Brindle. Again, we talked about the value of software over whiteboards and paper and stuff. This day and age, generally most teams are going to use software. If you're using a whiteboard, that is awesome and probably works very well if you're all in the same place, like we mentioned on a previous episode, and every day you go to the same office and you can sit around the same whiteboard, that may very well work for you.

Brian: 30:40 But make sure tasks get entered somewhere. The tasks cannot live in people's brains, on scrap paper, on desks, it has to be organized in a central location, whether that's software or whiteboard or whatever you're using.

Tom: 30:53 Cool, yeah. And then make sure once you get those tasks in there, you just track it through some sort of stages that you have. It could be as simple as to do, do, and done or we typically have a backlog that things sit in, and then they go into a doing type column, and then we have multiple columns for done, depending on where it's ... We create software depending on what server this is done on, more or less. Is it done on staging, is it done on production? That's what we do, but it can be very simple, just as simple as to do, doing, and done.

Brian: 31:33 Yeah, definitely. We're big fans of the visual workflow, having those visual stages of seeing where tasks are at, so if you can make that happen ... We talked to you even about Excel spreadsheets and how hard they are to read, right, when they have a whole bunch of text top down, and you're reading through a bunch of things, figuring out where things are at. Try the visual thing. It's hugely helpful, but either way make sure that you're getting tasks into places they need to be and then you are tracking them through whatever stages you're working with. However you want to do that, preferably visually.

Brian: 32:05 Make sure you assign and delegate tasks to people. Make sure people understand who is doing what. If it's not assigned, obviously that needs to be assigned, but if people have work on their plate, make sure everybody can see and understand who is doing what so it's very clear as to what's on their plate, what needs to get done, and when it needs to get done.

Tom: 32:26 Also, just one little suggestion that we had mentioned from a previous episode, like to get buy in of the person who is doing that particular task, should probably assign themselves when they claim it, when they go to do it, right? Because then they're like, "Hey, I'm taking this. This is something that I'm working on," and it gives you that instant buy in, if you will.

Brian: 32:53 And it also prevents the stop gap, like the extra step like, "Oh, I'm waiting for a task to be assigned to me from whoever's leading or the project manager," or whoever, right? Be proactive, grab it, or you could check with that person if you needed to check with somebody. Say, "Hey, I'm going to grab this task, is that cool?" And be proactive about getting it to work. It also just keeps things moving a lot quicker, as opposed to waiting for other people to chime in.

Brian: 33:18 Make sure you discuss things and talk about the tasks at hand. I actually just recently had an issue where I had somebody just really working in a silo, not communicating about what was going on, and there were issues happening. As a basic rule, you need to communicate. It's not always going to be a perfect situation where you're working on something, you're going to go into your silo, you're going to get it done with no issues and you're going to deliver a perfect result.

Brian: 33:42 Make sure you're collaborating and talking to your team members. Make sure that's organized, generally around the task at hand, what you're discussing, so there's context. It also keeps other people in the loop as to what's going on. If there's an issue, there's specific things being talked about on a task, everybody can see what's going on and be a part of that without having to be in the loop on every single communication.

Tom: 34:05 Complete tasks. This is, I think, a big one and I sometimes struggle to do this myself. I bring tasks partly over and then I never actually get them to the final stage. You complete the task, move on to the next thing. Don't have too much stuff sitting in your doing column. Just complete a task fully, move it to the next step, and then go on from there.

Tom: 34:31 If there's something blocking you from completing that task, we talked about this in a previous episode, it's fairly fine to have a blocked column or to move stuff back to the backlog. I guess some people just do that, but through a comment on that, move it back out of the doing column, and move on to something else. But one way or another, either complete a task or move it back before you start something new.

Brian: 35:04 I think a lot of times what happens is that people will be like, "Oh, yeah. I can do this, this, this, and this." Right? They have four or five things they pulled over into doing, and of course they're not doing all five things at once, they can only do one at a time. Then they do two of the five, and then the priority changes, right, and they have to work on something else they didn't plan on working on. They pull that over and start working on it, and then those two or three tasks that were not really ever worked on, end up sitting in doing for a week or two. Right? Never moving, and actually I've seen this happen on our own boards, where it's just kind of sitting there, it looks like somebody's supposed to be working on it, but there's no actual work being done. That ends up just getting lost in the shuffle.

Brian: 35:43 Completing tasks, but also taking on what you're actually working on, and not signifying that you're working on it a lot more than you are, and moving things around where they don't need to be moved on. That will keep you focused, and Kanban does this with limiting your work in process, so instead of taking five tasks, you can only take two or you can only take three at one time because literally, you cannot work on more than that as a human being.

Brian: 36:12 I always use that as a mental check, even. I might have a couple things going on different projects, but I don't want to ever see more than two or three [inaudible 00:36:22] in a doing column for me, because I'm just not really doing it, so I like to do a mental check there.

Tom: 36:28 I also typically find that this is more of an issue at the end of a project life cycle, when you're trying to wrap everything up and put all those pieces into place. I find it a little more difficult, and sometimes stuff lingers a little bit longer.

Brian: 36:47 And the last thing is, define a meeting rhythm. Obviously, you need to get a task in the system moving through your workflow, assign them, get them done, but you need to be collaborating and meeting as a team, generally, in some fashion. We do daily stand ups here, a lot of agile methodologies follow that. You could do weekly, you can have a meeting every month, whatever works for your team, but you need to have some kind of meeting rhythm so that everybody is in check with what's going on, outside of what's going on in your software or your whiteboard.

Brian: 37:22 You need to be discussing things or talking about things so there are no roadblocks, there are no issues, things are being dealt with in a timely manner, and things are just moving forward. If you don't have that communication, a lot of times people just assume things are going swimmingly and then you get to Friday and you realize that you didn't get half the stuff done you were supposed to. So it's really important to establish something that works for your team.

Tom: 37:45 If you want to learn more about that, we have a whole podcast episode dedicated to that, Episode Five. Check it out.

Brian: 37:53 How to Find Your Meeting Rhythm.

Tom: 37:55 There you go. Cool, so let's move on to some tips for taking action.

Brian: 38:01 We did this ourselves, if you're going to try something, if you are set on a methodology or you're going to try something simpler and start with the basics, or what we talked about, the visual workflow, start in a small team on small projects. That will keep the cost and the risk a lot lower, instead of thinking about, I'm going to roll out a complex project management methodology across my entire department and I'm going to get it done in three months time.

Brian: 38:27 Because like we said, a lot of times at the end of that you'll realize oh, this is really complex, and this is falling apart, and you've already implemented three months of effort to get it done. Try to think smaller, start with small teams, test it out. If it's something drastically different especially, try it out on a project but keep it small, keep it controlled, figure out what's going to work, what's not going to work, and then maybe you'll get to a result that you can roll out to bigger parts of the team or company.

Tom: 38:55 Sure, and follow the recipe for the first project and take notes as you go, because obviously you'll most likely make it your own to some extent, as people do with ... That's why cooking's a good analogy. You make out a recipe cooking your own ... You will make your methodology your own at some point.

Brian: 39:17 And I think just generally not over complicating things, always starting from the simplest point. We talk about that over and over again, just because we always try to catch ourselves from over complicating things all the time. It's really hard to do. Your brain starts going, you're thinking about all the great things that can happen and the magic that's going to happen, but whether you're rolling out a project management methodology, building a software feature, or putting together a marketing plan, the more complex it is the harder it's going to be to get done and execute. So keep things simple, and then build on that from there, and build momentum.

Tom: 39:55 Absolutely. And the more things that can go wrong, too. If you are looking for a simple process, check out Episode Four, Baseline Workload for Any Team. That's another podcast episode. We're really plugging the podcasts today.

Brian: 40:07 Lots of podcast references.

Tom: 40:09 Definitely.

Brian: 40:10 We mentioned visual work flow a couple of times, we talk about that. But we do have a baseline work flow that we recommend to our customers that we use, generally, ourselves. It is simple, and we actually go into how to set up that workflow, how that process should flow, and it's very simple to wrap your head around. So if you're looking for that easy starting point, that would be a great episode to check out.

Brian: 40:34 It is generally easier than Kanban, and again, I consider Kanban one of the easiest methodologies out there. That's a great place to start, but this is even easier than that. It has less rules and less guides to follow that might be that kind of ground starting point that you can graduate into something like Kanban or beyond. So it's a pretty interesting listen.

Tom: 40:56 And again, if you do have questions or you want to run anything by us, Brian will literally talk your ear off about management.

Brian: 41:06 Oh, you figured out that I can talk about this stuff all day?

Tom: 41:08 Yeah, and he seems to actually enjoy it. So again, don't hesitate to reach out to us. The email again is workflow@rindle.com.

Brian: 41:17 Well, I think that about wraps us up for the day. If you have a question for us, you can call it into our voice mail number at 860-577-2293, or you can email it to us at workflow@rindle.com. Our theme music is an excerpt from Thunder Rock by MagikStudio, used under creative comments. Subscribe to us on iTunes by searching for Workflow, and visit rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening, and we'll see you next time.