Estimating Projects

Nathan Gilmore:     Welcome to the third episode of Time Limit. This is the podcast focused on making the most of our limited time on our projects. Today we have myself, Nathan from TeamGantt, and we've got John from TeamGantt-

John Correlli:      Howdy.

Nathan Gilmore:     And we also have our good friend Brett Harned.

Brett Harned:       Hello.

Nathan Gilmore:     Today we want to dig into a little bit about estimating projects, and we've got a lot of good conversation coming up around that, but first, we want to talk to you, Brett, a little bit about your background. Just help everyone get to know you a little bit and your background and why you've been so passionate about project management and building community around that.

Brett Harned:       Sure, sounds good.

Nathan Gilmore:     Can you start with just telling us how you got started in project management?

Brett Harned:       Yeah. I think ... I was probably managing projects all along. My first job out of school was with a startup where I was doing a lot of things. I was hired as an editor, turned into a producer, and that meant that I was directing motion capture video shoots and writing flash movies and writing HTML pages and writing content. Kind of being a jack of all trades really early on I think helped me. As I moved through my career, I worked in an agency for a while where I was kind of the hybrid account manager/project manager, but my title was Account Director. I was then recruited by Razorfish as a project manager and I actually had to have them explain to me what a project manager was because I was doing all of that work already, but it was far more intense at Razorfish because they're such a large publicly traded organization.
                   From there, I went on to work at Happy Cog, which is a web design agency in Philadelphia. That's kind of where I was encouraged more to write about project management and talk about project management. Interestingly, it was a good time in my career because I was inspired to get back into writing, which I love doing. That turned into more opportunities for me. I started speaking at events and doing a little bit of community building. In Philadelphia I started what we call DPM Philly, which is a local meetup that has I think close to 300 members now, which is just crazy when I think about it.

Nathan Gilmore:     Wow.

Brett Harned:       The company I was working for started to take on events, and I had been to a lot of conferences on design and code and content strategy, but I never felt like there was a conference for me specifically. I went to my boss and I said, "I think we could do this thing." A year later we put on the first Digital PM Summit for 150 people, which was a sold out crowd at that time. Now six years on, we're selling like over 300 tickets a year and moving it around from city to city every year. It's pretty ... It's been pretty amazing for me. I feel really lucky to do what I'm doing, to talk about a topic that is ... Definitely needs more discussion. I think we're only part of the way there. I think that a lot of people when they come to the Digital PM Summit, they're just amazed that there are other people out there doing the work that they're doing. I think it's awesome that you guys have started this podcast. I feel like there's an audience for it and there's lots of valuable topics to cover.

Nathan Gilmore:     Yeah. Yeah, absolutely. What was some ... What's the timeframe on some of this? When did you first start managing projects? When was that?

Brett Harned:       I mean, I guess in my first job I was really managing projects. I wasn't a project manager. There were timelines, especially when you're organizing like video shoots, pulling together all of the details on that and keeping things in check. I mean, that was back in like 1999. My first formal PM role was probably around 2003, 2004, but really when I think about it, I've really been doing all this stuff all along, just on different levels, you know?

Nathan Gilmore:     Yeah.

Brett Harned:       Being an official PM, of course, the role is amped up to a hundred percent and you're doing a lot more in the realm of PM, but I really think like that the principles and the characteristics apply all throughout my experience.

Nathan Gilmore:     Yep, and then when you went to Happy Cog, you actually at some point earned the title VP of Project Management, correct?

Brett Harned:       Right. Yeah, so I was hired as Happy Cog's second PM. The PM that they had there, Dave DeRuchie, he's an awesome guy. He was a little more technical than me. I came from more of a creative background, so they wanted that balance on the team, and then he and I worked together to really kind of like transform some of the practices. Eventually I took over in a director role and started to hire a team, and then eventually became VP I think within the last two years of me being there.

Nathan Gilmore:     The Digital PM Summit that you started has been very, very successful. Not only that, but you guys have also started doing other events around that. Is that right? Some other meetups and different kinds of camps and everything for groups of people?

Brett Harned:       Yeah, so the Bureau of Digital is run by Carl Smith and it really started with the camp events and the camp events are these kind of retreat-like gatherings where people actually apply to attend the event. Carl reviews their application and then decides whether or not they'd be invited. He's really doing a good job of curating the group that's in the room. If you think about what the event setup is, it's two and a half to three and a half days of moderated conversation. Essentially there's kind of like a UN-style setup. You've got like our own set of microphones and a system for moderating. We poll the people who are coming to the event before and asking them what their challenges have been, what kind of questions they have, and then we build kind of an agenda around that.
                   People that are coming to the event are actually getting the answers that they need and getting the inspiration from other people at the table through just really kind of like conversation and then networking, group dinners, things like that. I'm always amazed at how excited people are when they leave our events, and I'm sure it's like this for any event organizer because there are people that just go to events and end up loving them. It's really cool to see people who feel like they've gotten real value out of something. That seems to happen every time.

Nathan Gilmore:     Yeah, well, anytime you can connect people that are in the same similar situation and they can all compare notes and share ideas-

Brett Harned:       Absolutely.

Nathan Gilmore:     And get excited-

Brett Harned:       Especially 'cause we're focusing on the communities that don't have a really big community, if that makes sense. It's not just a general UX thing, like it's very focused. We do it a digital project management camp, and that's just like a really focused version of the Digital PM Summit.

Nathan Gilmore:     Yeah, and you do one for owners, right? Like owners of agencies?

Brett Harned:       Yeah, owners, operators, business development. There's one for design leadership specifically, so kind of taking that management angle to it. That's kind of a part of it, yeah.

Nathan Gilmore:     Yeah, I think that's awesome. If anybody is interested in attending one of these, they should look up Bureau of Digital and check out the PM Summit, all the camps, and see if there's anything that's of interest to you 'cause these are really good events. We've attended a few of the PM Summits and they're awesome. They really are good, so Brett and Carl have done a great job in building that community and executing these events. Also, the last five years or so you've been doing your own business as a Digital PM Consultant.

Brett Harned:       Yeah, so I've been working with a number of digital agencies, also internal teams within companies and product companies just to help them with their product management challenges. It's pretty consistent that people have challenges with product management because I think especially in digital, it's still kind of a new role. It's something that people have been doing all along, but people are trying to figure out the best processes, the best ways to communicate. Lots of challenges within just those couple of things that come up, but yeah, that's what I've been spending my time on.

Nathan Gilmore:     That's awesome. Yeah, we really wanted to go through that background to give everybody a sense of who you are and just how connected you are in the community. You've managed projects for almost 20 years now. You have built a big community around this and you're just always talking to project managers. That's really why we wanted to have Brett on this podcast is to get his opinion on what he's hearing and what he's talking about these days.
                   Let's get into today's topic about estimating projects. First thing we want to talk about is, why is product estimation so hard?

Brett Harned:       Yeah. I think ... The first thing is, people hear the word "estimate" and they think right away like, "duh-duh-duh!" It's gotta be set in stone. It's something that's like really important and it stresses people out. I think that's always a problem, but there's lots of reasons why an estimate should be done and why you should communicate the fact that it's not always gonna be perfect or on point. I also think it can be really difficult to accurately estimate a project.
                   In a lot of the work that I do with digital agencies, it's coming up with practices to properly estimate on the task level. If they're looking at doing a big project like, "How do we decide how we're gonna tackle this project and then essentially price it?" Same difference for an internal team. Like, "We want to do this project", or, "Somebody up high is saying we have to do this project and we need to figure out how long it's gonna take so that we tell higher ups basically how much it's costing the organization and whether or not it's worth the return." I think those two things are really stressful because it's like justifying a job on the in-house side in some cases. It's justifying a cost or risking the fact that you might not win a project because you have over or underestimated something.
                   I think those things lead to more problems because stress just leads people not to think as clearly as they should. I think along the lines of technical estimation, it's just really difficult. Unless you really know exactly what you're building and you've got consistent staff to do that and you've got a history, you're not gonna always be right with your estimates. I'm sure that you guys have found that, too, in TeamGantt that they'll take on a new feature and it might not be exactly what you expected in the beginning. Fast forward a couple of months and you're way beyond where you thought you'd be.

Nathan Gilmore:     It's funny. We were literally talking about that this morning. John heads up our Development Team here and we got a feature we're working on right now. John, if you want to talk about that and just the difficulties you see with estimating technical projects.

John Correlli:      Yeah, I think for us it's there's a lot of factors that get involved into coming up with an estimate and then sort of handling it when things are different. We're doing a big rewrite right now and one of the big pieces that we're working on is refactoring just the whole list view portion of TeamGantt. New everything basically from the ground up. Sometimes you just ... You run into things where as a PM, sometimes I don't fully spec things out. Scope can get a little misinterpreted. You run into some hidden complexities.
                   One big thing for us that's been a hangup for a little while has just been drag and drop to reorder your list. Sort of what seems potentially simple on the surface, there's just so many different possibilities of where a task or a group can fall when you reorder it. There's a lot more to it than what's on the surface. We've tried a few different approaches that haven't really worked out, so we did what I think was a great move is the past three days we met up ... Three of us, sort of the three that have been working on list view and just got together in person and really hashed everything out. We came up with an approach I feel is gonna be the best of everything. We sort of experimented with some built-in libraries, but none of them really worked the way needed to, so we're kind of resetting the clock a little bit here and doing it ourselves.

Nathan Gilmore:     Yes, so that's a good example of something that we thought would take a certain amount of time, but ended up taking a good bit more just because of the hidden complexities. That's I think always happening with technical projects. I think everybody knows that. Just very, very hard to estimate.
                   What are some of the common mistakes you guys see with estimating projects?

Brett Harned:       A common mistake that I see is that people just jump right into it an estimate without asking questions. You can't just estimate something on face value. You have to ask a lot of questions about goals and intentions and what the intended outcomes are gonna be. If you're working with stakeholders, you have to ask about their involvement in the project, their availability for the project, because those kinds of things can really affect your scope, but also your timeline. I think definitely jumping in and being thorough about what this thing is that you're actually estimating is a conversation you should have first.
                   Beyond that, sometimes it's overthinking. It's trying to apply a specific process or deliver goals to something that you're just not sure you'll actually take on. You can end up with an estimate that might not feel right. I know in my kind of agency life that happened all the time. We would ask all the question. We still would have like a general sense of what the project would be. We'd jump into creating an estimate and say, "All right, we're gonna do all of these things. Here's our estimate and related costs." Then we'd get into the project, do a little bit of discovery to get to know stakeholders and get to know what the project really is, and then completely change our scope, but try to keep it within the boundaries of what we estimated. We were just like shuffling numbers around. That's where things get tricky and go off track really easily.

Nathan Gilmore:     Oh yeah, absolutely.

John Correlli:      Yeah, I would say on top of that is saying ... I say a lot is it's an estimate, not an exact. Sometimes people just ... You really want to try to find that perfect estimation and at the end of the day, it's just an estimate. You're not trying to be perfect, so don't ... Like Brett says, don't overthink it, but also don't take it at face value, either. Sort of do your due diligence, but understand you're just making an estimate and that it's not an exact.

Brett Harned:       I think you're right. I think you don't have to be exact, but I do think another mistake people make in estimating is that they don't try to get a little more granular. I think that a good practice is sitting down and thinking at a task level or like a group of tasks level. Even if you think about building a plan on TeamGantt, if you're building out a group of tasks and there are subsequent tasks underneath, each of those tasks has some kind of estimate associated with them, right? I like to think of estimates in that way.
                   If I'm thinking about for instance building out a set of wire frames, I'll come up with all of the steps that I know will need to go into building those wire frames up to completing and getting an approval on them and assign time estimates to each of those, and then I feel a little more confident that maybe it's not gonna be exact, but at least we've done the thinking that gets us to the process. I've got those time estimates for each step that then kind of translate into a timeline in some way. To me that's really helpful.
                   I also think a mistake people make is like not learning from the projects that they've done in the past. If those estimates weren't exact, you have some kind of way of saying like, "Okay, so this is how much time it does take for the next time around." Do you guys do anything like that? Like using retrospectives or time tracking or anything like that to kind of gut check your previous estimate?

Nathan Gilmore:     Yeah. Yeah, we have a ... We actually had a feature in TeamGantt. It's called Baselines, and this is something a lot of people don't know about, but when they find out about it they get really excited. Basically when you start your project, you do your initial plan and you can mark a baseline, and a baseline puts like a little thin gray bar for each task. It kind of takes a little snapshot of your project, so then two months later, you can compare where you're at versus your baseline or at the end of your project to your baseline and you can see what happened and then you can learn from that. That is super valuable. Learning from your previous projects and your previous experience, you can then make better estimates going forward. Absolutely.

John Correlli:      Yeah, and I think to connect the two dots there with the baselines and with retrospectives ... Our dev team here, we do sprint retrospectives every two weeks. Sort of the day before a sprint ends, we've got our schedules in TeamGantt as well that we work off of. I'll take a snapshot of the project for the baselines at each retrospective so we're able to see sort of how the project is growing. What things are we faster on than we initially thought and what things take longer than we initially thought and able to accumulate all of this data to make ourselves ... Make our estimates more accurate.

Brett Harned:       That's awesome. I think that's absolutely the way to do it. If for nothing else, like just knowing that you can learn from some of that old data and apply it to a future project if something similar comes up. I think that that's really valuable.

Nathan Gilmore:     What do you guys do when a client or boss thinks it should be done faster? You've got your estimate, but someone else thinks it should be done faster. How do you balance that?

Brett Harned:       When someone is asking for something to be done faster, it's usually because they don't actually understand what you're doing. I've come up with this a lot, both internally with stakeholders who just feel like they need something done. They're not seeing enough progress, or with clients who just say they need something quickly because they're setting the deadline and they're paying for the work. Usually, like I said, they don't understand the work, so the first thing that you have to do is sit down and educate them about what the estimate is. If you've got that kind of broken down, line-by-line estimate, it's really easy to sit down and say, "Okay, so you want to have your wire frames done quicker. This is how we estimated it. This is the time that it takes, and this is how that translates into into a timeline."
                   When you're looking into a timeline aspect, you're also taking into consideration other work that people have going on, other deadlines that are in the way when you're working with a small team. You're able to kind of lay things out in a way that makes a little more sense to them. How I would usually end that conversation, or at least try to advance that conversation to my ... Like sticking to that estimate or timeline is to say, "We can talk about doing this faster, but I think we'll have to remove some time. We'll have to remove some steps from this. I worry about the quality of that, but we can do it if you feel like that's really necessary."
                   Usually when you educate someone and put them on the spot like that, or you even say, "We might have to add some budget or scope to the project", they'll usually drop it and let you move on. Unless it's like a deadline where something is ... Like your project is dependent on something else. I've worked on website redesign projects where it's tied to like a media campaign or a live event or something where you just cannot move it. At that point, the conversation turns into, "The timing is this and we can't change it", and we have to be really rigid about deadlines.
                   I think it really comes down to having a conversations about it. You can never say, "No, not gonna do it." Obviously and especially if it's a boss or a client, but you can say, "No, but, and this is why." If that makes sense.

Nathan Gilmore:     Yeah, yeah. Absolutely. Now, what about the scenario where you're in the project, it's going along and you're coming up towards the end and things don't look like they're gonna finish on time? You're gonna have that conflict where you want to protect your team because you know your team's doing the best they can, but they run into issues, but yet the client or the boss is saying it's gotta be done by this certain deadline. How do you handle that balance?

Brett Harned:       Yeah, that's really a tough one. That's where it's kind of like the project manager's job to be looking forward on the project or ahead on the project to make sure that those issues aren't coming up. Doing a weekly assessment on where you are with your percent complete, hopefully putting that into a status report and being open and clear about where things stand on the project. Again, like educating along the way so that those stakeholders or bosses understand just how much time it takes or what problems people are running into because that can also be an issue, too.
                   I think the inevitable will happen. If people can just not figure it to work out, and I've been on projects like this where developers are just having problems with a new technology or working on like a really old technology that they have to catch up where things just take longer because they have got to get caught and learn and do what they can to make something work. Yeah, you just have to keep open communication flowing about that and hope for the best, but also prepare them for the worst.

Nathan Gilmore:     Yeah, that makes sense.

Brett Harned:       I think sometimes it comes down to the fact that you'll just missestimate something and you just have to deal with that. John, I wonder as a developer and someone who manages a lot of developers, how do you handle that situation?

John Correlli:      I think a good chunk of it comes down to owning your own estimate. We do team-based estimating, so you've got the protection of your peers who can sort of watch for your blind spots and things you might miss. At the end of the day, I think a lot of it comes down to owning your estimate, because if you're falling behind you sort of know it's your fault and you're gonna hold yourself more responsible to a deadline that you put on yourself or an estimate you put on yourself than you will if it's what someone else gave you.

Brett Harned:       Yeah, I totally agree. One of the things that I love doing is using an estimate almost as a constraint, especially with designers. Nathan, this might be something you can talk about, but I've been in situations where I've got a budget that feels like it's less than we need on a project for design. I've been in situations where I'll think ... Pass by a designer's desk and it just feels like they're sitting there looking at their screen looking at something thinking. Which is totally a part of the job and it's not something I'm judging, but I'm also thinking, "Oh man, that's like time's ticking away and it's not getting done."
                   I've had the situation where I've sat down with someone and talked about constraints and how maybe for our first presentation something doesn't need to be absolutely perfect. I don't know if you've been in that situation or if you guys agree, but it's definitely a reality on a project.

Nathan Gilmore:     Man, I love the idea of constraints. I think in a way constraints can help creativity and it's just like Parkinson's law, which we've talked about before. If you don't have any kind of constraint, like the work will just keep going. That's the way it definitely is with design. If I've got two weeks to work on design, I'll use a little over two weeks probably to work on that design, but I know if I only have four hours, I'll do it in four hours. It might be not as good, but sometimes I think we can surprise ourselves what we can do with a limited amount of time and then you get something out the door. There's always chances to iterate and improve, especially on designs and software. I mean, it's software, right? It's not hardware. We can always iterate and improve, so absolutely.

Brett Harned:       Yeah, and it's like in that case it's like an estimate is a budget and you're setting a budget for yourself on how long you can take to do something.

Nathan Gilmore:     Exactly. Do you guys have any other last tips? I feel like we've covered a lot on estimating here, but anything else that you guys want to add to this?

John Correlli:      I think constraints really are gonna allow you to be more creative. You're gonna know your boundaries. You're gonna know your limitations. It's gonna force you to be more focused.

Nathan Gilmore:     Yeah, absolutely. I think it's just kind of like we talked about before with having a financial budget, right? Even at home, if you have this financial budget, if you know you can only spend this much money on food this week or this much money on whatever it is, it forces you to be creative and it forces you to maybe think about it a little bit more. You can end up coming up with some pretty cool things.
                   All right, so we want to end today with a question that's kind of related to this, and this is something I wanted to ask John specifically, and Brett, we're gonna be asking you, too. This is about powering through a day. One reason I want to ask John this is because with working with him now for probably over 10 years very closely, I've always seen how he can power through a day. He can get so much done in one day and be incredibly productive that I think it would be interesting to hear how he approaches that.
                   John, can you talk a little bit about your tip for just personal productivity to get through a day?

John Correlli:      I think a lot of it for me really comes down to like five key points. You need to know what you're working on. You need to know why you're working on it. Kind of connecting those two, what I like to do at the end of every day, I like to look forward and see what I've got coming up tomorrow, and then sort of that brings me into the third piece, that's prioritizing the day. I like to create a checklist for myself. Sometimes it's just the checklist is just in my head, but it's basically I'll take what I have to work on and I'll prioritize what needs to be worked on.
                   I'll prioritize them sort of for ... To answer the why question, where we know what we're working on sometimes, but sometimes we don't always know why. When we do understand why, we do understand the priority and we do understand the importance of it. Sort of connecting all three of those, I'll know what I'm working on, I'll know why I'm working on them, and then I'll have sort of like a run sheet almost of my day of things that I need to get done.
                   The next piece from that sort of continuing is I'll set goals. I'll say like, "Hey, I want to get to this point before I go to lunch", or, "Hey, I want to get to this point before I skim through my email", or something like that. Set yourself attainable goals throughout out the day so that you can feel accomplishment. You sort are checking things off the list and you know you can sort of feel that you're making that progress.
                   The last piece which is potentially just as important as all the other ones, is limiting your distractions. Whether it's muting Slack, whether it's quitting your email so that you're not getting alerts every time an email comes in, or putting your phone on silent. Just limit your distractions. They're gonna lead to context switching, which isn't gonna allow you to get back into what you were working on with the same sort of momentum that you were carrying before.

Nathan Gilmore:     Yeah, I think that's ... You made a lot of great points there, especially the context switching. That's something we've always really focused on here at TeamGantt is trying to limit those distractions. One reason that we all work remotely is so that we can have that focus time without people interrupting us and without the questions and the walk-by-the-desk interruptions. It's made a huge difference and one reason we've been able to do so much with a small team.
                   Brett, what are your thoughts?

Brett Harned:       I totally agree with you on the context switching thing. It can really drag you down and make you less productive. I'm also big on limiting distractions. I actually just for the first time in like six months re-downloaded the Twitter app to my desktop because I felt like Twitter combined with Slack and things that are going on in Slack were just sucking all of my attention out away from the work that I needed to focus on. We'll see how I do with Twitter now. I actually don't even have it opened. I've gotten used to not really using it, but realized like I kind of disappeared for a while, so I need to get back into it a little bit.
                   I think for me like in terms of productivity, I kind of live and die by to-do lists, so right now I use an app called Wunderlist that is also can be used as like a shared to-do list. If I'm working with somebody directly, I'll share that with them and we can have like kind of updates on that progress. I make ... I switch back and forth. I'm one of those people that tries new apps and then abandons and then ends back into a notebook.
                   Everyday, the first 10 to 15 minutes of my day is sitting down and organizing my thoughts and what I'm gonna do so that then I can start crossing things off or checking things off on my list and feel good about making that progress. If I don't do that, and I've had days where I just jumped right into work, I don't feel as organized and I don't end up feeling as productive at the end of the day 'cause I'm not tracking what I get done. For me, that's like a really big part of my day and how I'm prioritizing my work. The same thing as like setting goals. I love John's idea of setting a goal to get something done and then your reward at the end is like a little break or a coffee or whatever it might be. I might start trying that one.
                   Okay, so if we were to summarize our conversation and tips on estimating, I think it would be, one, you've got to recognize the fact that an estimate's always gonna be an estimate, right? It's not always gonna be set in stone. Second, when you approach an estimate, you've gotta ask the right questions and take an approach that's gonna get you to a place where you're as accurate as possible. I think also we talked about breaking things down on a level that makes sense. Also, we talked about learning, using project data and information and conversation you've had on previous projects to help you estimate further projects.

Nathan Gilmore:     Well, good. Well, that concludes the episode today. That covers everything that we wanted to talk about. We hope everyone is enjoying this, and this is our third episode, so please let us know what you think. Please feel free to shoot us an email at timelimit@teamgantt.com. We really do want to hear your feedback. We want to hear what you think about the direction this should go. This is only the third episode, so I'm sure we will be shifting direction as we go. We really want to hear your feedback 'cause this is for the community here so please let us know. Thank you everyone for listening.