Subscribe
Share
Share
Embed
Knowing when you're in over your head and recognizing when a project has gone off the rails are crucial aspects of successful project management.
But what are the red flags to watch for to prevent project derailment and how can you tell if a project is doomed to fail—even before you start?
This week, Jason Fried and David Heinemeier Hansson, the co-founders of 37signals, sit down with host Kimberly Rhodes to discuss the challenges of project management and share valuable insights on how to stay focused, recognize red flags early on, and foster creative problem-solving in order to see a project through to completion.
Listen in as they reveal the importance of finishing tasks before adding new ones, the pitfalls of multitasking, and the magic of setting clear endpoints. Plus they share Basecamp's tool for facilitating project monitoring without time-consuming meetings or derailing check-ins.
Tune in for practical solutions for rescuing a project before it's too late!
Show Notes:
[00:00] - Kimberly opens the show and the topic of how to rescue a project when it’s gone off of the rails.
[00:34] - Adding too much without finishing anything causes chaos. Jason shares the story behind his HEY World piece, Rescuing a project in progress, and shares the advice he gave his friend and how that applies to software development too.
[02:49] - David shares the reasons behind the “Shape Up” approach at 37signals.
[03:44] - You can’t do two things at once, every time you do you lose a little bit…
[04:33] - Clearing the decks, wiping the slate clean, AND deciding what you are going to do with 100% of your time and how it helps you avoid shiny object syndrome.
[05:20] - Why it's crucial for successful project management to avoid adding new tasks until all the existing unfinished ones are completed.
[06:11] - How the magic of deciding when you’re done helps lower the risk of multitasking.
[08:53] - In software development how can you tell things are going off the rails before it’s way too late?
[09:17] - Jason shares why you need to be tuned into those feelings of being in over your head.
[10:43] - David shares the major red flag moment for him that lets him know you’ve already failed before you even get started.
[12:28] - “The longer, the more complicated the project, the more deceivingly specific people believe they can be when the opposite should actually be true.”
[13:17] - Why you should never give yourself too much time for a project.
[14:13] - The work-in-progress unified system in Denmark for tax assessments of properties that will never be finished (it’s already eight years overdue, and a billion dollars in).
[15:53] - The easiest time to stay on track for a project.
[16:29] - The other problem with long projects is that you get more time to not fix the problem.
[17:17] - The curse of too much time and the sweet spot of creative problem-solving for any endeavor.
[18:06] - X is the epicenter of the problem, start there and THEN see how much of Y and Z you get to before your (set in stone) ship deadline.
[19:37] - Kimberly shares some people’s approach to rescuing projects and the difference at 37signals.
[20:02] - Jason talks about the false sense of security that comes from knowing everything that’s going on.
[21:12] - David shares how “sawing at the wheel” just makes you go slower.
[21:57] - Are we done yet? Are we done? How constant interruptions slow projects down.
[22:42] - How Basecamp’s “Hill Charts” can help a project’s interested parties see where projects stand without a bunch of time-wasting meetings and derailing check-ins
[23:17] - Did you know full video episodes of “Rework” are available? Check out our YouTube channel or find us on Twitter. As always, if you have questions for David and Jason about a better way to work and run your business, we’d love to answer them. Leave your voicemails at 708-628-7850 or send an email. And don’t forget you can find show notes and transcripts on our website.
Links and Resources:
Creators & Guests
Guest
What is Rework?
A podcast by 37signals about the better way to work and run your business. Hosted by Kimberly Rhodes, the Rework podcast features the co-founders of 37signals (the makers of Basecamp and Hey), Jason Fried and David Heinemeier Hansson sharing their unique perspective on business and entrepreneurship.
Kimberly (00:00):
Welcome to Rework, a podcast by 37signals about the better way to work and run your business. I'm joined by the co-founders of 37signals, Jason Fried and David Heinemeier Hansson. You know their company 37signals as the makers of Basecamp project management software. These two know project management from the inside out, but they also know that not all projects always go according to plan. Jason and David are here to talk about that, how to know when a project is off the rails and how to get it back. Jason, I'm gonna start with you. You recently wrote about a construction project with one of your friends. Kinda tell us about that.
Jason (00:34):
Yeah, so a buddy of mine is well started by repairing a little crack in his, uh, kitchen counter I think it was. And so he hired a handyman to do that and they started fixing that and then his wife said, why don't we just do the backsplash too? And so they added that on and as that was happening, the handyman goes, you know, I could do your lights too. And before you know it, like this, just small repair turned into many projects. And my friend called me like, not crying, but kind of like, just completely lost. Like, my house is a complete disaster. Nothing's getting done. Uh, I don't know when this is gonna end. And he, he'd never been involved in a project like this. I've done a few house renovations, so you know, I, I'm like, okay, well this is kind of normal.
(01:24):
It's kind of a mess for a while, but, but let's talk about what's going on. And basically he just kept explaining, he kept adding on projects and I kept asking, well is anything done? Or you just keep adding more stuff? And he's like, I'm just keep adding more stuff the guy's like, it'll be done in a few more days. And, and, and I said, okay, we need to stop here. We need to slow down and let's take stock of what's going on, and we kind of went through that process. And then I said, okay, the first thing you gotta do is you gotta finish something. You cannot leave all these things open and start adding more things on. And uh, that was sort of a revelation to him, like that, that you actually had to finish one thing before you can start something else. And this is actually pretty common, in software development too and, and all sorts of things where people just keep layering on more stuff and they wonder why nothing gets done.
(02:07):
It's because you never finish anything. You just start, you keep starting things. And so he just wasn't used to that. So I kind of laid that out for him and it really helped. And then, you know, we kind of finished something a hundred percent, get that outta the way so it's off the table, completely done, then you move on to the next most important thing. That was the only way that sort of saved the project essentially, otherwise I think it would've kept spiraling outta control. And then you get more frustrated and then you demand more. And what you don't realize is that you've created the problems. The general contractor or a handyman or whoever, they didn't really, they're just looking for work. You're giving 'em work and then you're wondering why there's so much stuff going on and nothing's getting done and that's it's because of you frankly. So that was, uh, a bit of the story there.
David (02:49):
I think the parallel here to all kinds of project management, including the stuff that we do at 37signals is just spot on. One of the reasons why we instituted Shape Up as a described method and this focus on having budgets instead of estimates and having cycles that end after six weeks was exactly to combat this phenomenon, that it's so easy to kick things off. It's so easy to start more things. It's so easy to say, hey, couldn't you just real quick also have a look at this. There are no real quicks. There are a bunch of people who will do what you tell 'em to do if you're paying them. And then they'll just start thrashing, jumping from one thing to another. And as with construction projects, so go software development, you can't do two things at once. You can try, which basically just means you're jumping from one thing to the other and back again.
(03:44):
And every time you do that jump you lose a little bit – you lose a little bit of attention, you lose a little bit of context, you lose a large bit of progress and momentum. So when you think, uh, set things up in the sense that, you know what, we're just gonna clear the tables entirely every six weeks as we do, you put yourself in a position or you vaccinate yourself against having this accumulation of unfinished stuff that's almost sort of kind of done, but not really. This is the other project or problem here. With these kinds of projects, it feels often quite easy to get to 90% done and then there's just the last 10%. And if you keep having projects that all miss those last 10%, it's just an absolute drain on your attention and your ability to focus on what's in front of you.
(04:33):
You have to clear the decks, you have to wipe the slate clean and like, okay, now we're deciding what we're gonna do with a hundred percent of our time for this next duration that we're gonna be working on. If you are like, oh, well we're deciding what to do with like, uh, 43% of our attention because that's what's left when we account to all these other things, it's not a good time. It's kind of this sense of like you're constantly paying the debt of past decisions and when you do that you just, you don't have all of it to spend on the best decisions you could possibly make today. So having some regimen of forcing function that enables you to clear the decks by saying like that's simply our process, I think is a really good way to push back against this natural human instinct of wanting to start new stuff all the time.
Jason (05:20):
The other thing to add too is when you pick something to finish, you can't add anything new until all the other stuff that's undone is done. I think that's another really important thing. 'cause otherwise you're gonna fall right back into the pattern of just adding more things on. And as David mentioned about like getting the first 90% done is relatively easy. There's some saying, and I don't know what percentage of the saying is, but it's like something like the last 10% is half the work or something like that. And it could be the last 5% is half the work, but it turns out to be true, which is why anyone who's ever built a house or renovated something has this punch list at the end of unfinished business. Things that need to be dealt with and it never seems to end. There's projects go on and on and on naturally. So you really, if you keep adding more things, it's just gonna get worse and worse and worse. You really gotta pick something, finish it and not add anything new until it's all done.
David (06:11):
I think the other reason for that is the sense of accomplishment that comes from truly finishing something. In software for us that comes that line is when you ship it, when customers are actually allowed to use the thing you built, you have to be done or done enough, right? Like you're never truly done. But that's, that's part of the magic here of doing product management or project management in general is deciding when you're done. Like there's no such thing as an objective done. Even with a house, as Jason say, there are almost any house you will work on, there will always be a punch list. At some point, like there's a handover and you say like, hey, it's done enough that we're shipping it. And I think this comes in very often in software as well, that if you don't have the forcing function and if you work with estimates instead of budgets, you are so inclined to constantly think, yeah, just a little more, let's just get it a little better.
(07:06):
Let's just get it a little more polished. Let's just add a few more things into it. And what's so interesting about that cycle is that it kind of feeds on itself in terms of your confidence in your ability to ship anything. So in some software organizations that work with estimates and that work with sort of commitment, we've said, we're gonna build this and we're gonna build exactly this, you end up in a situation where you ship quite rarely. And then there's even more pressure to jam every idea you could possibly have into the current project because that's the only ship that's actually sailing. If you come into port every six weeks and you allow the people who make the decisions to pick a new direction, you will build up confidence that, you know what, I get to change my mind. I get to set sail for a new place.
(07:54):
We're not just eternally stuck here. I don't have to cram everything into this one ship because that's my one shot at getting somewhere. You actually get to change your mind. And I think that interestingly enough lowers the incentives to layer on all this multitasking and lowers the incentives to say, can't you also just do this thing really quick for me? Because you know, there's gonna be an opportunity where you get to do that. Um, and if you can build that trust both ways, I think you end up in a such a better situation where a, you allow the builders and the makers to finish things that feels really good. Builders and makers generally love shipping finished stuff. That's a sense of accomplishments. And you build confidence in the people commissioning that work to know that, you know what? I'm gonna get another shot. I'm gonna get another chance of of doing this, and I will actually see things being finished. So many organizations end up in this, this functional low trust environment where you think you have to hustle to get things in because everything takes forever.
Kimberly (08:53):
Well, I'm curious 'cause Jason, it sounds like when your friend reached out, it was kind of a desperate situation. Like things were had been wrong for a while. So I'm curious from your perspective in project management, and especially with software development, like how can you tell things are going off the rails before they're way too late? I mean, I've heard stories of like, oh yeah, we're two months behind on this project. Well surely you knew that before today.
Jason (09:17):
Yeah, yeah, exactly. Well, I, you know, interestingly enough, he didn't know that. He'd never been through a project like this, had never really done a big project. And so he felt like this is just sort of the way it was, but then at some point you feel something different, something clicks in. It's a sense of desperation like, wow, or this, this is over my head. He kept saying like, I think I'm in over my head is how he said it. Which is a feeling, it's not a fact really. I mean it kind of is, but there's no dividing line or demarcation when it becomes a fact. And it wasn't a fact before, but it's a feeling. And I think that's part of it. You have to pay attention to projects. You get to be two months late, you know, what do they say one day at a time or however you wanna put it, but there's a feeling like we're just, this is not moving fast enough or why is this taking so long?
(10:02):
Um, again, it's not like it didn't yesterday and it does today. It's a culmination of something that's bubbling up and I think you need to be tuned into it. And so I think, you know, it's, I don't know how to guide people into being tuned into it, but I think when you pay attention to these things and you're a bit impatient, uh, and, and you're really close to the work, you know. You just know and, and that maybe is just experience, but it is something you have to know and feel. I I don't think it's like a number of checklists. It's not like you should be 30% done by this time or I am not into that kind of objective measurement. 'cause I don't, was it if you're 29% then it's okay. No, it's still wrong. Something is wrong. It's a feeling.
David (10:43):
I think the major red flag for me is actually not when you realize you're in trouble, but when you set out to sea. If you start a project going, hey, this is a six month project or a nine month project when it comes to product development, you're probably in trouble. If you're trying to make sort of precise estimates or even worse commitments about something speculative like many, many months into the future, you've signed up for failure in almost all cases when it comes to software development. Some parts of construction are a little different, but I've also been through a prob uh, a handful of construction projects and they're not actually that different. Like people often have this illusion of thinking like, oh, do you know what, uh, building a house is a a thing we've figured out totally. We've been building houses for thousands of years, this is a not a novel thing anymore.
(11:33):
And maybe that's true if you're building like, I don't know, row houses where you've already built a thousand of exactly the same thing, but a lot of houses are at least partially bespoke. And at any point where you're into the bespoke development and that's usually virtually all of software development, there's just that level of uncertainty. You can't be entirely sure how long something is gonna take. So if you submit to that and go like, well I want this big complicated thing, this big complicated thing, this cathedral is going to take in software terms maybe two years I'm gonna set off sails on the two year thing. And and now it's uh, 2023, we're gonna be done July 21st, 2025. You've already failed. Like I can tell you on day one, that is going to be a failure. There is no chance that you're gonna ship exactly what you wanted two years into the future because no one is that good.
(12:28):
No one has that level of oversight into all the things that come up during bespoke development. The only possible way you can hit a deadline like that is to not really make it a real deadline, is to make it a budget. We have this amount of time we will ship whatever is finished at that time. Those things never go hand in hand I find though. The longer, the more complicated the project, the more deceivingly specific people believe they can be when the opposite should actually be true. We sometimes set off on multi-year projects. For example, when we built HEY. HEY took about two years to build. When we set sail for that, first of all, we did not set like a deadline. This is when it's gonna be done. Second of all, we had a very vague fuzzy idea of what we're building. Yeah, we're building an email client, but there's about 5 trillion permutations of what that exactly could be.
(13:17):
And we let that be explicitly open from the get go. You really get into trouble when you try to specify upfront in any delicate amount of detail what you're gonna build for the long term. So for us, again, coming back to Shape Up and software, the easiest counter to this is just not to give yourself so much time. Like it's, it's to hold the rope tight system can never slack so long that you only, you hang yourself with it. So we give ourselves on all normal feature development, the six weeks, right? And we're off even on six weeks. We're very often off by at least a week, sometimes even two weeks. And you can just go like it gets exponentially harder, the more complicated and the longer the project runs. So if we are off with like 20 years of experience really being diligent about building something just in six week increments, how often do you think most software teams are gonna be if they try to specify something six months into the future, they're always off.
(14:13):
This is why sort of the history of large software development, particularly the kind of stuff that happens in governmental or large business commissions where you get someone else to build it and you think, oh, if we have an ironclad contract upfront then surely they will build exactly this, is a history of just total failure. Most large software projects fail. They have failed through history and we've gotten no better at building large software projects in the entire history. And to some extent maybe we've gotten worse. I'll give one brief example. So in Denmark, they're working on this, um, unified system for setting tax assessments of properties. They are eight years over schedule and I think 50 times it is currently cost because this thing is never gonna be finished, by the way, which is an interesting assessment itself. It's cost over a billion dollars and it was I think estimated to be something like 300 million when they started on like, you're eight years overdue, you're a billion dollars well into it, right?
(15:12):
And it's never gonna be finished. The only thing you we're waiting on in the Danish society is for them to admit that which is this another problem, right? As you say, when do you know that you failed? When do you know that you're off track? Usually very far in advance of when you do something about it because hope springs eternal. Humans are sort of built to believe, no, no, no, no, no. Next week is when we're gonna catch up. But as Jason say, it never happens. You never catch up. It never happens because you're late one day at a time. You can only fix that one day at a time. You can't suddenly leap jump. And if you were , this is the funny thing, if you start out on a complicated project, right? And you get late one day at a time in the beginning, right?
(15:53):
That was the easy time. The easiest time to stay on track was the initial phase of it. It only gets harder from here. So if you are already, let's say halfway through, and usually if you think you're halfway through, you're only at best a quarter through on a big project, it's only gonna get harder. So you're only gonna get more late. So this sense where the lag factor is of like, I actually know I'm, as Jason's friend would say "in over my head" and like, I'm gonna do something about it. That's usually the main tension. The one that gets me frustrated is when the people working on the projects, they know it's not gonna be finished, but we all sort of pretend that like maybe we're gonna catch up next week. No, you're not.
Jason (16:29):
To add one more quick thing to that, the other problem with long projects is that you get more time to not fix the problem . Like you wait. You won't get to the problem early because you have more time that you think you're gonna fix it and then you don't, but you put off fixing it for way too long, which is way worse. And, but that's, that's the luxury of having space and time like, oh we'll deal with it later. There's nothing easier than going yeah, later. Yeah, later. I mean that's like so easy. It's the easiest thing to do because there's no obligation and you can end the discussion. Yeah, yeah, we'll deal with that later. And then it's, you know, way too late. Um, and then you've piled up all this stuff and you have no time. It's, it's, it's usually, this is why people run into these issues like at the end of things also is 'cause they just didn't deal with 'em early enough. So yeah, it's, it's complicated.
David (17:17):
I think what's funny about this is also sometimes the language we use. Jason, you just used the term that people do all the time. We have the luxury of time and space. We have the luxury of a lot of it. No, you don't. You have the curse of too much time. You have the curse of too much space and too many resources and so on. The luxury is actually in the constraints. The luxury is actually in hard, fast boundaries that force you to come up with creative solutions to problems that would take too long if you were gonna solve them the quote unquote normal way or the long way or the luxurious right? It is actually much better to have the luxury of not enough. That is the sweet spot of creative problem solving in any endeavor. And I think particularly in project management, you want to recognize upfront you don't have enough.
(18:06):
And I think this is what's such a fundamental mental shift in the Shape Up approach that we go from these estimates, hey, how long is it's gonna take to build X, Y, and Z to say, do you know what? There's no way to specify insufficient detail, how long it's gonna take to build X, Y, and Z and then do it within the time we thought it would take. That never happens. Even the best of projects, even on the shortest amount of time. The only way to ship something on time is to say, yeah, we know building X, Y and Z is gonna take longer than we thought. We just don't have that long. So as we're building X, Y, and Z are all not equally important, X is the epicenter of the problem. That is what we have to fix and have to build in order to ship.
(18:48):
So we will start there first and we'll see how much of Y and Z we get to. But no matter what we are shipping on August 10th. That works and cuts with the grain of human nature. We know how to do this. This is one of the reasons that procrastination is such a universally felt emotion and driver of actual progress. When you're like, holy shit, I've been procrastinating the entire semester to turn in my long run paper, now it's the last week, I better get to it. And then suddenly you find these immensely deep reservoirs of motivation and productivity and so on to do it. You can also just be there or thereabouts from the get go, realizing upfront that there's not enough time. You have to make cuts, you're not gonna get all of it and that's fine. You're gonna get something good.
Kimberly (19:37):
I also feel like sometimes people think I'm gonna rescue this project by checking in on it every day and we, you know, hear of people doing like these daily check-in and daily standup meetings and that's how I'm gonna track the progress and make sure we're on track. I know at 37signals we don't do a lot of meetings, kind of tell, talk me through that of how you're keeping track of status without the need for all of this, like I'm just check in on it every day. We're gonna all get in a room and talk through it, see where everybody is.
Jason (20:02):
Yeah, I mean that, that can slow things down quite a bit too, but it's also this false sense of security and, and confidence that, well, as long as I know everything that's going on, we're gonna be all right. Like, well, you might know everything that's going on is wrong. Uh, now you could say like, well that's good, right? Well, you don't need to know that every single day either. Like, it's too often, it's far too often to, to actually be able to spot things that are going wrong every single day. It just, it's not the right cadence actually to figure it out because there's not enough time for things to go wrong really on a daily basis or you're picking out stuff that's going wrong that isn't really wrong. It's just, it's just happening and it'll be done tomorrow and it's not a big deal in the first place.
(20:40):
But then you overemphasize things that are quote wrong, that aren't actually wrong. So I think that that degree of meeting cadence is way too often. I've been involved with, with projects where like construction projects where we do a standing meeting once a week, every Wednesday for like an hour to catch up a variety of different trades on some things. And I think there's some value in that in specific kinds of projects. Um, but daily, way too much, uh, way too often. And also it's, it's too, you're almost too zoomed in to really see the big picture of what's going on here and what's taking so long.
David (21:12):
I think it also gives you the false confidence that you can actually make micro adjustments that often when what you're doing is really just sawing at the wheel. There's a saying in, uh, in, in racing that when you take a turn, you gotta do it in one smooth movement. The uncertain driver will be constantly, and that includes me by the way, my driving style is a little like this, will be constantly sawing at the wheel, constantly trying to make these micro adjustments, right? And you end up going slower, you end up going slower than just taking like one solid turn at it and that, uh, coming through on the other side. And secondly of all, this is what everyone hates about managers. If you ask any builder, it is having this nagging person on you constantly beating you. Where are you? Are we done yet?
(21:57):
Are we done yet? Are we done? You're like, dude, I fucking just answered you yesterday. Just chill out and let me actually do the thing you're so worried about us not doing. Your constant interruptions is slowing that down. And there's this sense that like if I'm sawing at the wheel, if I'm doing something, anything, I'm like I'm in control. No you're not. You're causing the thing to get out of control. If you would just back off and as Jason say, maybe you do a thing once a week, maybe you don't even do that. I mean for a lot of our projects, the way we quote unquote check in on them is asynchronously from a distance. The people working on the project, they might use the daily check-in questions, what have you worked on today that we use a bunch? Or they might use a feature Basecamp called Hill Charts where they update on their own accord.
(22:42):
Like this is where we are. And interested parties can kind of just watch from afar. And I find that accepting those constraints as a manager, as a stakeholder in a project who might be very eager to get this thing finished is really good. You have to know that the observer effect, the Hawthorne effect in this instant is usually net negative if the cadence is is too high. Now you can also flip too far the other way and like you're not paying attention and people get the sense that there's no urgency and so there has to be some injection of urgency, but I think it's easier to overdo it than it is to underdo it.
Kimberly (23:17):
Okay, well with that we're gonna wrap it up. I will link to Jason's writeup on his HEY World as well as a couple of podcast episodes. Your estimates suck is another one that I feel like is appropriate for this episode. So we'll link all of that in our show notes. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37 signal.com/podcast. Full video episodes are also available on YouTube and Twitter. And if you have a question for Jason or David about a better way to work and run your business, leave us a voicemail at 708-628-7850 and we just might answer it on an upcoming show.