PM Roundtable: Keeping the Gantt Charts Gantting

0:00 0:00

Mike and Matt are joined by technical project managers Darren Petersen, Monica Flores, and Chris Albrecht to discuss the ins and outs of managing large Drupal projects.

Episode Guests

Darren Petersen

Darren Petersen wearing a blue button down shirt with white polka dots in front of a gray background

Director of Projects with expertise in enterprise-level Drupal projects.

More about Darren

M. Nikki Flores

Nikki Flores wearing an orange sweater in front of a gray background.

Nikki Flores is a Technical Project Manager who has been building websites since 2004.

More about M.

Chris Albrecht

Chris Albrecht wearing a dark button down shirt in front of a gray background.

Back-end Drupal Developer turned Project Manager, Chris has worked on high-profile projects for IBM, Syfy, and more.

More about Chris

Mentioned in this Episode

Transcript

Transcript

Matt Kleve:
For September 12th, 2019 it's the Lullabot Podcast!
Matt Kleve:
Hey everybody, it's the Lullabot Podcast. Episode two, three nine. I'm Matt Kleve, senior developer at Lullabot. With me as always close to the show, senior front end Dev Mike Herchel. Hey Mike?
Mike Herchel:
Hey Matt. How are you doing?
Matt Kleve:
Awesome. So we are here on the Lullabot Podcast. We talk about all things Lullabot. Lullabot is a strategy, design, development company, and we work primarily building websites using Drupal. Right?
Mike Herchel:
I agree with that statement.
Matt Kleve:
Just trying to, you know, set the scene for everybody.
Mike Herchel:
Yeah, absolutely. But to manage those projects, we have an elite group of, the seal team, six of Lullabot, our technical project managers.
Matt Kleve:
I was going to say something about a trinity of managers or project managers.
Mike Herchel:
Yeah. Well, within like the seal team six of Lullabot, there is that trinity. And we have those with us here today.
Matt Kleve:
Yeah. And we're going to talk a little bit about project management, kind of keeping the ducks in the row. Keeping the Gantt charts, gantting.
Mike Herchel:
That is going to be the title of the podcast, keeping the Gantt charts granting. That's it.
Matt Kleve:
First up we have Darren Peterson, senior technical project manager. Hey Darren?
Darren Petersen:
Hey Matt. How are you?
Matt Kleve:
Coming to us from Texas?
Darren Petersen:
Yes, close to Dallas.
Mike Herchel:
Darren, what Lullabot projects have you been involved in?
Darren Petersen:
I've been with Lullabot about six and a half years, so I've gone as far back as MSNBC back in the early days. Lately, I've been working on the state of Georgia's gov hub platform for about the last year, which is maybe 85 sites all on the same code base for a hundred sites. Lots of automated migration and moving parts in a big multi-site. And there's been everything in between. Small potatoes, one off sites for cities and private companies as well as, higher Ed and all kinds of other stuff in the middle. So.
Mike Herchel:
Okay. Cool. Next step, we have a technical project manager, Chris Albrecht, coming from Golden, Colorado. Hey Chris?
Chris Albrecht:
Hello.
Matt Kleve:
Chris, you started here as a developer. I know this because I've worked on a project or two with you and then you transitioned into project manager. What type of stuff have you worked?
Chris Albrecht:
Oh man, we started together on Sci-Fi, you and I did.
Matt Kleve:
Yup.
Chris Albrecht:
And then, yeah, that was an intense migration, a seven to eight redesign, the whole forklift and lipstick and everything you can throw on a website.
Mike Herchel:
What about for project managing? What exactly-
Chris Albrecht:
Project managing.
Mike Herchel:
...what exactly do you do here Chris?
Chris Albrecht:
Well, I think that's the beauty of being a project manager, Mike, is we really don't do a whole heck of a lot because Lullabots are so good at self-starting digital work.
Mike Herchel:
Chris is really more of a people person.
Chris Albrecht:
I have been working with IBM alongside Jared Bittner with their cloud projects to help migrate a number of different sub-sites into the ibm.com ecosystem and sort of push that forward a bit.
Matt Kleve:
Also with us today, we have technical project manager and one of the newer Lullabots joining the team, Monica Flores. Hey Monica.
Monica Flores:
Hey, thanks so much for the introduction. I'm very excited to be a Lullabot, I just joined two months ago. Just raring to go and use some of these PM skills.
Matt Kleve:
Where are you?
Monica Flores:
I am based in Arlington, Virginia outside of DC.
Mike Herchel:
Awesome. So are you on a project now that you can talk about?
Monica Flores:
So we're just starting up an IBM project, and I hear this is a great opportunity to just get to know the team, get to know how Lullabot works, work with the different kind of developers, strategists and just understanding the back part of it and then working forward, getting to know people. I've been apprenticing to Darren, which has been great because he's been leading the ropes at the georgia.gov transformation.
Matt Kleve:
That's awesome. Has he been also teaching you saxophone?
Monica Flores:
He is actually writing some saxophone rifts for the brass sections. I'm excited about that.
Darren Petersen:
Yeah, we need any fanfare when georgia.gov actually comes online.
Matt Kleve:
All right. So let's kind of jump off right here. So one thing that if you go to the Lullabot about page, it's not project manager, it's technical project manager, what does that mean? Like what does that technical mean? Are you all developers also? And if so, what am I doing here?
Darren Petersen:
I'll feel that first. The technical project management title here sort of indicates that our PMs live pretty close to the work as opposed to maybe somebody that sits in a room and counts beans and asks developers when will it be done. A lot of times our technical PMs are also acting as business analysts and even talking through questions about how the implementation might get done, just to be a sounding word for the Devs as they plan things. And that's usually because we came from the ranks of the developers.
Darren Petersen:
I was a backend developer, and we've had other folks that have come from a design background or whatever. But however it shakes out, usually our PMs come from the work and stay close to the work. And we think that's sort of a secret sauce in terms of how our success is because if a PM knows how it's done they can help the developers clear the blockers, and it's a shorter communication gap.
Matt Kleve:
Yeah, I can imagine that. And it also gives a little bit of empathy for the developers from the project management standpoint.
Darren Petersen:
Right.
Matt Kleve:
So they maybe communicate to the relevant stakeholders.
Darren Petersen:
Exactly. It's a lot easier to work with the project manager if they're not standing over your shoulder with their foot tapping, arms crossed like waiting for it to be done kind of thing, if they're immature. So that's we think it's a big deal.
Matt Kleve:
Yeah. There's a certain level of trust that you need kind of going both ways in order to do that. Right?
Darren Petersen:
I would say so. I mean, Chris, you've been doing this for almost a year now with us in the PM side. How would you say that that's worked out for you and what's the big thing being a PM who's working with devs now as opposed to being a Dev PM like this?
Chris Albrecht:
It was a tricky transition coming from a role that... my whole background is in back end development and for four years, over four years doing that with Lullabot, little bits of PM-ing kind of tucked into the margins. So to do that full time, to step out of that development role where you're part of the team, and it could be a very big team. You don't know where other cogs are moving, how the other pieces are coming together, but you know, you can trust them to do the work.
Chris Albrecht:
So to sit that high above it and not have your hands in the code was a really, it took a few months for me to get through that transition of just letting the team work and watching the team, kind of guiding them from a higher level, watching the system work over, like, just overall. It's amazing to watch it happen once you get comfortable not having your hands in the middle of everything.
Chris Albrecht:
And I really like being able to affect the team on a larger scale and help the team kind of interact together. Watching a couple of those pieces or helping a few of those pieces connect, and use that business, that marketing term, that synergistic response you get from it. But it really is you can evoke a lot of really great positive work responses energy from getting those... from working together with the people instead of just being one of them and having everything sort of work around you, so to speak.
Chris Albrecht:
Yeah, it's been a great challenge, and I've really enjoyed kind of stepping into that larger sphere of watching the project go.
Darren Petersen:
Yeah. I found that to be a tough transition too when I basically couldn't code anymore. There was a long transition time where I was sort of coding a little and then managing a lot. And breaking the habit of jumping into how shall I implement this as a member of the team and letting it, sort of standing back and trying not to get involved in that was a really important lesson to learn because I would like pick up one little piece of work because I could do it and then find that I didn't have the time to actually finish it the way that I needed to.
Darren Petersen:
So if anybody is transitioning from Dev to project management or in the middle of that, keeping a loose hold on the work and letting the developers actually do it is one of the biggest skills to learn. I think.
Monica Flores:
I can definitely jump in and talk about that. I've been coding probably since 2004 when I switched, and I think of it like In-N-Out, which is a brand out in California. The managers have typically gone through every single station in the store. So they do like fast food hamburgers.
Matt Kleve:
Yeah. You're talking about the hamburger joint, like the West Coast?
Monica Flores:
Yeah, exactly. They know French fries, they know the meat [substitution 00:09:14] They know the buns, they know the fish, they know how to take orders, they know how to do the shipping and the handling of all the input. So I sensed that.
Monica Flores:
From this side, I think there was quite a lot of emphasis placed on the PM having a deeper understanding of Drupal and different modules. That was the defining question in my interview, "Is what is Views Bulk Operations?" And I laughed, a softball question. But in general, I feel a certain sense of empathy for people who are working because I understand exactly what it is taking them to understand the process.
Monica Flores:
I do think that from the project management perspective to be able to sit at the higher level and help assign people's work. I think of the people in the forest, right? If the people in the forests are just chopping stuff down, you got to get somebody up high to figure out where are you going? Are you in the right direction? Are you even getting to your destination? And then shouting out instructions to the people below to make sure that they're not chopping off in this other direction.
Monica Flores:
I hear you Darren, as a coder, as somebody who wants to build and who wants to commit code and wants to engineer stuff, you have to let go of that sense of your only meaning is in this commit and start to think about your meaning is in collaborating with client, understanding the deadline, understanding the limitations a client has, figuring out how our team can fulfill those limitations and make it a smooth process and enjoyable for everybody involved.
Darren Petersen:
Yep. Absolutely.
Matt Kleve:
That's a great way to put it. Let's kind of talk about maybe getting started on a project. What tools do we frequently use? Is our Gantt charts a thing? And we use Jira?
Chris Albrecht:
I've been at Lullabot for nine years and I haven't seen but one maybe Gantt chart. Is that because I'm a developer?
Darren Petersen:
Probably. I have an opinion about Gantt charts, which is that they are useful for reporting upward to stake holders who are not actually in the work all the time. They just want to see the timeline and the dependencies and the schedule is shifting.
Darren Petersen:
For a long time I tried to use a Gantt chart as if it was the primary planning tool to run the team with, and I don't actually think the team benefits from that nearly as much as it helps you surface how the schedule is working upward to someone who's maybe signing the contracts and the checks and stuff. So I don't do Gantt Charts unless I'm in that kind of a conversation, and usually the work works out just fine.
Matt Kleve:
It's more of we are here, is that what you're saying?
Darren Petersen:
Yeah. And or if we feel like there's a risk to a schedule, sometimes it's good to quantify what that critical path is more like this task depends on that task. That's all the, you know, and that's what's great about a Gantt chart is you can see what all the things that have to go end-to-end are going to be and therefore what your deadlines are going to be.
Matt Kleve:
And that was kind of a tongue in cheek example of a project management tool. I think that's something that people think project managers, it's like, hey, we're going to have a Gantt chart because that's what they do. And there's a bunch of other tools though, right? I mean people know about Jira, right? Jira software, which is you know, ticket tracking and a bunch of other stuff, right?
Darren Petersen:
Yes.
Matt Kleve:
That's kind of normal in a lot of projects these days. Yeah?
Darren Petersen:
For me, I think Jira is the norm but there's other folks on our team who use lighter weight ticketing systems. Like GitHub for example, has issues that are attached to the code repositories, and you can totally manage a project just with the issue queue and the boards on GitHub. And there's all kinds of other tools out there.
Darren Petersen:
A lot of times we choose to use whatever the client is already using and if they're not using something, I would go to Jira because it's got all the capabilities that we might be used to.
Mike Herchel:
Jira also integrates with a bunch of other products from Atlassian, the company that makes Jira. So with Jira often comes Bitbucket and the whole nine yards of that software suite. I mean that kind of helps kind of keep the project contained.
Monica Flores:
Yeah, I would still definitely say that from the paper trail perspective because as Darren so far said, is important to keep a chain of accountability to not just the client that you're working with, but the client's boss, or the boss's boss. And so with something like Jira, if you have a commit that's against every ticket, then you can have that whole paper trail of we talked about this user story, we converted it into this epic and each of the tickets associated and this is what was committed. So there's a auditing prebuilt into the software that you're using.
Mike Herchel:
When I started at Lullabot, I remember somebody saying, "Yeah, we really want the client to start the or open the ticket software, own the ticket software because there will be a day when we're no longer there, and we want them to... they're going to own the project." At the time we were using Unfuddle, which I don't know if it still exists or not, it was a ticket tracking. There might've been a code repository in it and it just kind of... It was Jira, Diet Jira, I don't know, Dr Pepper Jira.
Mike Herchel:
It was important that they opened the new instance, and they owned it because it's their project at the end of the day, we're just kind of transient in their world. Is that something that's-
Darren Petersen:
And that way we ended up working within their systems. A lot of times they've got a subscription to a cloud-based Jira product or something else. Right? But in cases where we work with a client who doesn't have anything, we'll just set up whatever works. A lot of times that's Jira, but it could just be, you know, again, lightweight, like GitHub issues or whatever.
Monica Flores:
Cool. One thing I appreciate is that we do tend to be flexible to what the client is using so that we work into their system, and they do have that sense of ownership, but they also know that we are using it to make it easier for them.
Matt Kleve:
Alright. So let's move on to the most important, what would I consider the most important responsibility of a project manager and that's communication. And when I say communication, I'm talking to client's stakeholders, to client developers, to our developers. This can involve meetings and things like that. How do we approach that? And that could even go to like, how do you tell if someone's not doing their job and how do you approach that?
Mike Herchel:
Man, that's a big question. Every client's a little bit different, which is a fun piece of this job. We as a client services company get to work with lots of different organizations who have their own systems set up and their own way of doing things, their own culture around that.
Mike Herchel:
So making sure you communicate throughout the different levels of the project from your top level stakeholders down to your developers takes different skill sets. Starting at the very top. Some organizations, their answer to everything is throw people in a meeting. That's a really detrimental way in my opinion of trying to solve problems because it's "just passing the buck."
Mike Herchel:
So learning the skills about how to read a meeting invite and reject it or counter it or just ask for a clarification I think is a big one. That's something I've had to get really good at. Looking at how many people are listed on a meeting invitation, what their range of jobs, their job skills, their job... like what their jobs are, their roles in the company. And then is there... what's the time slot allotted? How much time do we have for this meeting? And is there an agenda?
Mike Herchel:
So if there's 30 people for a 30 minute meeting, ranging from a developer to the design lead up through the, I've had some like marketing leads on there and there's no agenda on that, that's what I'm going to learn to sort of push back on. So we try and adapt what we do with the communication skills and the preferences of the client, but at the same time learning how to kind of guide that or facilitate that so that you're not getting your developers pulled into meetings they don't need to be, so that I'm not spending my time in those meetings because my time needs to be focused on communicating through the people that need that attention to get the work done.
Mike Herchel:
So a lot of times I'll try and... I'll take the bullet and sit into the meetings so that the developers can get back to work. If I feel like the meeting would benefit from having the insight of a developer there, I'll bring in developer in. But then when you get to the other side, I like to try and keep those high level discussions, sort of compartmentalize to where they need to be.
Mike Herchel:
If it's a high level talk about what work is possibly coming down the pipeline that we're going to need to do next or are we going to hit these milestones, that's something I can take on myself and then relay that down to the developers as needed. I can do that. How we set up our regular Scrum events, if we're going with a strict Scrum process or that could just be a regular Standups, which is part of Scrum, but it's a pretty common piece of just any sort of Agile framework, which is generally what we work in. Kind of let the developers do their own thing.
Mike Herchel:
We have some really smart, talented self-driven developers at Lullabot and generally that kind of bleeds into the project that we work into as well. So if we're working with a team from another company, generally we get a really good vibe going between the two and anyone can just sort of take that motivation to do what they need to do, ask the questions when they need to ask the questions and work within themselves. They don't need a lot of micromanaging. I think it's the succinct way to say that.
Chris Albrecht:
Yeah. So something that I've seen on some projects that I've been on is that the PM also tends to set the expectations with the non-Lullabots early in the project. One of my favorite PMs to work with who's not on the call, is Jared Bittner and we were on this project, and he went up there and then when he got in, his first meeting was to kind of get rid of meetings. And so he was talking about he had discussion with the stakeholders and said, "Hey, listen, these meetings are spread all over the place, it interrupts our flow, there's too many of them. We don't need all these people on there. So let's roll it back as far as we can and then if we need more, we'll start gradually adding them."
Chris Albrecht:
And that little bit of work that he did right there like made a huge difference. It allowed us to get these unbroken blocks of time where we were just kind of able to actually get stuff done. And I'm a big believer in that. Have any of you had any similar situations where you've said, "Hey, hold your horses here. Let's-
Monica Flores:
Oh, I have super strong opinions about this. I totally get what you're saying. Paul Graham talks about this with YCombinator. There's maker time and then there's manager time, and the two are completely different. And even if you think about a meeting, if you have five people in the meeting and they're billing at $175 an hour and they take 20 minutes, it's 300 bucks right there. So if you're rambling or not organized or don't know how to communicate the issues at hand, it's costing.
Monica Flores:
So a couple of things that I think about when setting the tone for a project is I'm protecting the developers time so that they do have those big blocks of time to really chunk and work on a project. You cannot work on something in an hour. Sometimes it takes an hour to just get yourself set up, right? So if you can protect the developer's time, that's key. But then also if you can be respectful of the client's time and understand that they just want to know what the blockers are, what the deadlines are, what the key deliverables are. They want to have an opportunity to get stakeholder feedback from their people and then come back and give you feedback.
Monica Flores:
So one thing that I like to see is having kind of internal Standups. Let's say you have a 15 minute round with the people on the team, then you have your scheduled meetings with the client to do design review or go more in depth or talk about anything that's happening with the project. But keeping those totally separate, and like you say, not having the developer be a part of the client engagement unless it's absolutely necessary.
Monica Flores:
And then if it is something that that developer does want to be a part of, then supporting them in that. But I can see how, let's say you had a meeting at 10:30 and then meet at 1:30 and a meeting at 3:30, you're not going to get the time to actually focus on that bug, or that issue, or that deployment.
Matt Kleve:
Sounds like it's something we're a PM needs to be a clearinghouse for communication. Does that sound like a good descriptor?
Darren Petersen:
I find that to be the case. In hearing, Chris and Monica described that stuff, I'm nodding my head vigorously and since it's a podcast you can't see me, but I'm nod, nod, not on all that. I think-
Matt Kleve:
I think you got your hands in the air, and you're saying preach.
Darren Petersen:
That's totally what I'm doing. But the thing I would add is that for the team, you're trying to protect that with those blocks of time, you're trying to advocate for them and get the right kind of requirements so that they don't have to spend all the time in meetings in order to do the work. At the same time I find PMs also have to advocate for the client to the developers in some ways, which is to say, I've had times where I've talked with the developer and said, "Hey, I think that thing isn't going to pass muster. It's not going to be what the client needs." And I've had devs like come back on me and challenge me and say, "Is that you talking or is that the client talking?"
Darren Petersen:
And I feel like the longer you occupy the technical PM at Lullabot, the easier it is to switch hats between, "Okay. I'm the Dev advocate towards the client, and I'm the client advocate towards the Dev." And so you know what the product owner is going to say and so you don't have to wait until the client sees that it's not quite working the way they expected to be able to give that feedback back to the developer. And as it turns out, as you develop those instincts, it usually turns out right, and the QA process reveals, "Oh yeah, man." Darren's opinion over time has turned out to be similar to the clients in terms of quality control and stuff to that.
Darren Petersen:
I feel like that's the thing we occupy. We look in both directions and try and interface for either side.
Monica Flores:
I'd also say that English or just the ability to communicate is very helpful in that if you can write something out that has the exact screenshot, the link to the data dictionary, the link to the illustrator file. If it's really clear what it is, then it reduces some of the back and forth and back and forth that might come from something that wasn't worded so clearly or so succinctly.
Mike Herchel:
Monica, I think even though I haven't worked with yet, I think you are now my most favorite project manager. Because that's like that... That's totally like as a developer that's like my pet peeve when I have to like what exactly do we want right here? And having a screenshot with the big a red arrow, this thing matters so much along with like any links to designs or et cetera.
Monica Flores:
Yeah. It goes really deep into that because even things like categories as opposed to say a link list, or it would be something like how would you style something? Or something that we're working with Darren right now. Is it a views an embedded from an argument? Is it pulling from somewhere else or is it something where you just attach it into the actual node?
Monica Flores:
These are all kind of structural questions, but you're trying to think from the perspective of say the end content editor who doesn't know any of that. All they want to do is post their block, right? Or they just want to put the press release to the announcement, or their event up, and how can we build a system that supports them in that process but is also straightforward and easy for our team and is also something that doesn't involve a lot of technical debt that we'll have to come back to you in two or three or five years and deal with again.
Mike Herchel:
Yeah, totally.
Matt Kleve:
So we've talked a little bit about communication, and it being an important skill of project managers and I think there's another one and that's to be a prognosticator. That's a big word, Mike. Do you know that one?
Mike Herchel:
I have to Google that word. Excuse me for a minute.
Monica Flores:
Does it have something to do with pig snouts.
Matt Kleve:
No.
Darren Petersen:
It's telling the future.
Matt Kleve:
It is. Yeah.
Monica Flores:
Yeah.
Mike Herchel:
Yes. A person who foretells or prophesizes a future event.
Matt Kleve:
Yes. Yes.
Darren Petersen:
Yes.
Matt Kleve:
I think that's probably a little bit important to start because you end up doing some estimation work.
Darren Petersen:
We certainly do. I have a jar of chicken bones on my desk that I use every day. No.
Mike Herchel:
Oh yes.
Matt Kleve:
Is that like tea leaves or?
Darren Petersen:
Fortune telling is... Yeah. Yeah. No, sort of a roll the bones and see what happens. But yeah, we end up doing estimates, some are more formal than others. Sometimes it's presales estimates where we know this is going to be a fixed bid project, and we've got... I'm doing something right now where I have like 400 line items in a spreadsheet trying to figure out a way to size that project and get it back to the clients, say, "Here's the budget that we think is actually feasible for the complexity that you have." And sometimes it's day-to-day estimates just with a ticket where your counterpart, your product owner, whomever on the client side wants to know, are we going to be able to get this feature in by the particular deadline that they have? Like they have some internal stakeholder that wants to see that feature out there.
Darren Petersen:
And of course those are gut level checks. A lot of times my estimation technique in those moment to moment things is to say I think it's feasible, but I have a secret rule that I have, which is never commit to a thing on the same day that it's being asked. I say, "I think it's feasible, but I'm going to have to go talk to my Dev team." You go back and ask them about it, get that ticket from the client and let the Devs asked all the questions they need to ask before we commit to this thing at this particular deadline. That helps for scope control and a whole bunch of other stuff, but there's definitely estimation wrapped into all of those kinds of conversations.
Monica Flores:
I would say that a lot of it is about planning, and I fully believe that these projects get built twice. First, they get built in our minds with data documents, almost like the blueprint of your project and then it moves into actual build out where you're putting into reality the vision that you had from the original content strategy or design and architecture.
Monica Flores:
So I say every hour that you spend in the planning process really saves you time in the build out because you've already thought through what these different relationships are between the content and who's allowed to do what in terms of roles or permissions, what types of content are, how they relate to each other, if they're reference to each other. Think about that first instead of in the middle of a build having to think about those questions, and you'll save the time.
Matt Kleve:
But isn't that like almost the opposite of agile where you're kind of doing more Waterfall at that point?
Monica Flores:
Yeah, Agile. I would say-
Matt Kleve:
Right?
Monica Flores:
Yeah, yeah. No, this is... so I am interested in Chris's talk about this because in a product where there's an actual end delivered product that you're doing, you have a roadmap, you have a feature set, you have priorities and stakeholders are advocating for different parts of this features, and you can build out some of those things as you move us through the kind of mapping. However, if you're appended to a project that's more of a maintenance or more of a, like an ongoing project, I think that would be a different set up, or a different way to measure, how are you doing?
Matt Kleve:
Let's talk a little bit about some of the methodologies coming up after a little bit if we could.
Darren Petersen:
Yeah.
Matt Kleve:
When it comes to estimation, Chris, do you have any thoughts or any magic secret sauce that you lean on?
Chris Albrecht:
No.
Matt Kleve:
You just guess?
Darren Petersen:
Like the general rule is-
Chris Albrecht:
Random number [crosstalk 00:28:52] pretty much that is accurate as you can get.
Matt Kleve:
The Zodiac sign of Jupiter while it's in retrograde right now.
Darren Petersen:
Yeah. I mean, I will say this, right? There's this joke that everybody says about whatever you're asking just double it and that's not inherently wrong, but you can be sharper about that by saying the developers typically, and no offense intended here, typically thinks about the time it will take for them to build the code, but they don't always think about review time, QA time, deploy time. And that's where that estimate has to get doubled.
Darren Petersen:
And then there are times when like a developer just misunderstood, or the product owner misunderstood the complexity of the thing to the point that it really does take longer, and this causes a phenomenon called submarining where the developer works it gets frustrated, says, "I just have to work harder. I have to double down." And that happens for several days in a row, and they keep not popping up, or they keep coming up to the Standup and saying, "I'm almost done, man. I'm 80% there," and you're like, "80% there all week long?" That's not right.
Matt Kleve:
80/20 rule applies, right? Where 20% of the work takes 80% of the time.
Darren Petersen:
Exactly. And so when I hear a developer saying, "I'm almost done to Standups in a row," I want to check in on them and see if they're okay. Because it may be that they're having a lot of problems, and it's hard to surface that in front of the client or whatever. So being able to reach out to the developer and say, "Hey, I see that you're giving me the same update multiple days in a row. Is everything all right? Do you need to get a work in progress, pull request out for the rest of the team to see your approach? And maybe that'll help.
Darren Petersen:
A lot of times a client developer will have this problem more so than a Lullabot developer on our projects where they'll have a task assigned, they're failing at it and they don't know how to say that to everybody because they're like in front of their boss and in front of the Lullabots or whatever. And sometimes we have to like, it's like pulling teeth to get them to get whatever the state of their work is out in front of us into a pull request where we can get a more senior developer or just another pair of eyes, not even more senior to just get a different perspective. And then usually it moves forward.
Darren Petersen:
So transparency and early and often getting that stuff out there sometimes makes the difference.
Matt Kleve:
I've seen that before.
Monica Flores:
I'd say definitely fail early, fail often, ask questions. There are no stupid questions because if you have a question, most probably somebody else has it's view, and so it's just the bravest person to ask it. But I do appreciate that at Lullabot there's a culture of like fail forward, like you can make the mistakes so that we can all learn and get better from it.
Chris Albrecht:
Yeah. Internally we have a very good culture of saying, I don't know how to do this. Even if it's within my purview as a friend and web developer, I can say, "Well I don't know how say like react works or something," and no one's going to come down saying, "You should know this." And I feel comfortable saying that and I know who to reach out to. But yeah, if you're in another company and your boss is there or standing over you and you're thinking, I don't know what the hell I'm doing, it's little scary and intimidating and stressful.
Monica Flores:
Yeah. And the flip side of that is I see the wins, I see west figuring out something with purely CSS and then being able to share that [inaudible 00:32:05] able to be shared through all the other projects. So it's a big brand with lots of other people working on that one big brand.
Matt Kleve:
Does Parkinson's Law apply? Are you familiar with Parkinson's law?
Darren Petersen:
Yes. Work expands to fill available time.
Matt Kleve:
Yeah. So [crosstalk 00:32:23] yeah?
Darren Petersen:
It really, really does.
Monica Flores:
Or is that the Peter Principle where you reached the level that you're-
Matt Kleve:
Close.
Darren Petersen:
It's like that. Yeah.
Matt Kleve:
Yeah.
Darren Petersen:
No, Parkinson's Law being if you have two weeks to do one task, it'll take two weeks. And if you have a day to do that one task, it'll take a day. You'll either gold plate it or whatever you have to do, but the work expands to fill available time is totally true.
Darren Petersen:
A lot of times we work on retainer. We sell weeks of a developer to a client, which is a very different experience than working on a fixed bid project where you have a set of features and you're supposed to deliver them, and you're getting paid for the feature, not for the time. It's two sort of totally different ways of having to manage the project. So scope creep enters in on a fixed bid project much more easily because you have maybe a long list of things and the client just expects that they're going it get done. It's easy to slip an additional one in there if you're not managing it super carefully.
Darren Petersen:
On the flip side of that retainer situation, if the client has a certain set of things that they want to work with, our job at Lullabot from the developers and the project manager is to carefully protect the core thing that we know they need when we only have two weeks to do it, or we only have three weeks to do it, or whatever. To be sure that they're going to get the maximum value out of that three weeks, one of the ways to protect that is to not overload ourselves with additional requests. So it's almost like scope control is necessary in both cases.
Darren Petersen:
It isn't just time and materials are going to work until the clock stops, and we're going to walk away. We really have to finish within the time and so Parkinson's Law is a thing to consider there. Can we cram that extra thing in there or do we need to finish this with such a high degree of quality that's going to expand to fill that extra week or whatever?
Monica Flores:
I'll say also that this is the beauty of open source, right? This is something that we're using. We have so many thousands of lines of code that are doing some of the exact same problems that you face. It's easier or it takes, you say weeks for you to implement something that might've been more difficult or be more time costly on another platform.
Monica Flores:
I know we just did that project in two months and even the clients thought that that was a quick turnaround in the support and maintenance team, something like that. And just thinking about if we already have a theme, if we already have all these components, we have modules that are ready and raring to go. It makes it so much easier for everybody. So that's the plug for #Drupal.
Matt Kleve:
We're talking project management on the Lullabot podcast with three of Lullabot's all star project managers. Coming up right after this, we're going to get a little bit into methodologies. The ones that our PMs like to lean on, what they prefer. And we'll also talk a little bit about pushback. Coming up right after this.
Abby:
Hey, it's Abby from MidCamp. What's happening with the next camp, Bobby?
Bobby:
Hey, we're super psyched about oh, MidCamp's coming March 18 through 21st 2020. The big deal is it's coming back right up against St. Patrick's Day in Chicago. It's going to be at Saint Paul, University of Lincoln Park campus in Chicago. Wednesday is summits and trainings. Thursday and Friday are sessions and Saturday is going to be our contribution day.
Bobby:
Coming in fall 2019. We have $50 early bird tickets and our call for proposals is going to open up.
Abby:
All right, check out mid camp.org for more and see you on St. Patrick's day in Chicago for mid cap 2020.
Matt Kleve:
Welcome back to the Lullabot podcast. We are talking with our project managers on keeping the Gantt Charts gantting. So let's talk a little bit about different methodologies, obviously Agile is the one that businesses like to throw around a lot. We hear the terms of Waterfall and then we also heard the term Kanban, which I'm not quite sure if it's pronounced Kanban or Kanban.
Darren Petersen:
Kanban's good.
Matt Kleve:
All right, thank you. That's what I've been using. Kanban.
Darren Petersen:
Kanban.
Mike Herchel:
Kanban. Kanban, Waterfall, Agile.
Matt Kleve:
How do I know... What are the differences and how do I know when to you use one over the other?
Darren Petersen:
Sure. I'll jump on this because I'm-
Matt Kleve:
Let's just get real quick definitions here. Waterfall, who wants to describe Waterfall real quick?
Darren Petersen:
Waterfall is the idea that you plant it and then you build it and then you test it and then you show the client.
Matt Kleve:
So you get it all figured out and then you build it?
Darren Petersen:
Right.
Matt Kleve:
And here you go again. Okay.
Darren Petersen:
That's a great idea, except the big unveiling usually is six months after the planning was done and the client's needs have changed. And so what you built for them wasn't actually what they need anymore. And so there's a lot of dangerous ways to do like a sort of a stairstep one after the other fashion. Which is why Agile is what it is, the idea that you want to cycle through short development-
Matt Kleve:
So Monica, do you want to talk a little bit about Agile or Scrum or something like that?
Monica Flores:
Yeah, absolutely. Agile is taking... I remember distinctly my mentor, Dean Thompson walked us through how to implement Agile. So it's daily Standups, 15 minutes max. Some people I've seen do Standups all around-
Matt Kleve:
And it's literally like you're supposed to be standing. Right? And that's the point-
Monica Flores:
Yeah. I've seen them in a circle doing push ups to make sure that you're not being extremely wordy and that Standup-
Matt Kleve:
...is to be short. That sounds a little [bro codery 00:37:34]
Monica Flores:
...that Standup is to identify blockers and figure what the plan is for this week's or for the day's work so that everybody's on the same page. And then of course it's all clearly defined and your ticket is in the queue. And again, in terms of Agile, to Darren's point about Waterfall, if you're in an engagement with a client, it's helpful because we have tools like Tugboat for QA. Your client can see exactly what is happening as they're asking for it and they can test it, they can give you early feedback, they can surface something that they might not have thought about when they first asked for this feature.
Monica Flores:
So having a tighter cycle between implementation and then feedback is probably the best thing for clients in terms of Agile. And then in terms for the team, there's definitely the psychological aspect of it that Chris can definitely talk about. The wins you get after two weeks sprint where you had said you were going to work on say the user registration page and a log in and the first version of the whatever glossary, and at the end of the two weeks you have all these working elements, demo it to the client, demo it internally, and kind of checkbox, what did we do well? What did we do wrong? And then move into the next step.
Monica Flores:
So I would say at least in today's climate where people ship early, they ship often. If they're not embarrassed, then it's like too late, that kind of thing. It is good to have some sort of system where you can keep track of what's being created, get feedback on it, and then have clear wins during the process.
Matt Kleve:
So it's still very similar to Waterfall in that we going to plan it, we're going to build it, we're going to deliver it, but we're going to iterate through that process more often. Right?
Monica Flores:
No, no. Has Waterfowl ever worked for anybody here? I know-
Matt Kleve:
Sure. I mean like building a skyscraper or something. Right? That would be-
Darren Petersen:
Is was a Waterfall process. Yeah.
Monica Flores:
Yeah.
Mike Herchel:
You can think of it, I like this analogy or using these terms for it, it's iterative versus incremental. Agile is iterative. Waterfall is incremental. So if you want to take that skyscraper metaphor, you're going to build a skyscraper incrementally piece by piece, but the skyscraper is not usable until it's done. Until every increment has been completed.
Monica Flores:
Yes. And in physical-
Mike Herchel:
It depends how you approach it from an iterative process where after each iteration you should have a new version of a working product. That would be, all right, well first I build this little tent on the ground and then I go for two weeks sprint. My next iteration is I have a wooden structure. My next iteration is I put some bricks around that structure. My next iteration is levels, car park, all the way up. That's the bigger... I really like that, looking at it from that perspective, the difference between Waterfall methodologies versus Agile methodologies.
Mike Herchel:
And really Agile encompasses everything that we generally toss around as project managers is terms of frameworks, which is Kanban, Scrum, Extreme Programming XP.
Matt Kleve:
Oh, I forgot about that one.
Monica Flores:
I guess it also depends on what you're building. Because the skyscraper, you know, is not going to be changed mid way through into kind of shopping mall. So that's also part of it.
Matt Kleve:
You would hope not.
Chris Albrecht:
So what is Extreme Programming and is it related to Windows XP?
Darren Petersen:
I think windows XP stole its terminology from that, but Extreme Programming is the same as Scrum in terms of its small units of deliverable software, but the key thing about XP is that it mandates pair programming like two developers working at the same screen which is kind of unique and not very cost effective, but certain internal teams it's hard to do in a client service kind of situation, but internal teams can get some good benefit out of it. Like it produces really quality software. It just doesn't produce quite as fast
Chris Albrecht:
But Windows XP was not quality. How do you explain that?
Matt Kleve:
Windows XP was awesome.
Monica Flores:
Marketing.
Matt Kleve:
Are you kidding? Windows XP stuck around for ages. It was in... like every other release of Windows was good and XP was on the good one, right?
Darren Petersen:
Yeah.
Chris Albrecht:
Yeah, yeah. I can see that.
Matt Kleve:
All right. All right. I'll be quiet now.
Darren Petersen:
I'll say about Kanban. It's worth noting that Kanban comes from factory like factory methodology. Toyota invented this thing in Japan back in the 1950s and 60s. But the idea that basically you want to be able to see all the work that's going on at any given time and you want to minimize how many things are happening at once. Those are the two big things about Kanban. Is visualize your work and then limit your work in progress.
Darren Petersen:
What that ends up meaning is a developer works on a task, usually only one task, maybe two if you need to alternate because you get blocked or whatever. But then the other big thing about Kanban is the product owner is prioritizing the backlog and the developer shows up and pulls the next thing off the stack as opposed to like packing a sprint for two weeks and going to deliver all this stuff at once.
Darren Petersen:
The developers are just continuously pulling tasks through the workflow and delivering those things and getting frequent deployments and stuff. And what that means for us Lullabot is early in the process we might do a big design sort of Waterfall design process to get our comps and our stuff together and then switched to iterative delivery of that stuff. So we really start Scrum as soon as the comps and the planning is done. And then we deliver that every two weeks until the project's ready to launch. And then after that product is launched and you still have a team that's working to add new features, it really sort of transitions into Kanban where the work is flowing and you're just grabbing new work or fixing bugs or whatever and deploying as rapidly as possible.
Darren Petersen:
So on my project, on georgia.gov, we went from two week demos to almost never doing a demo anymore. Because we're deploying every week and we have a continuous flow of QA with the client. So we don't have official demos because we've really sort of achieved that flow state where the work is just moving through the process.
Monica Flores:
Yeah. All of these methodologies are intended to assist your team in getting their objectives done in a quicker, easier, better format for everyone. So I can fully understand something starting out some way and then evolving to make it better for everybody involved.
Matt Kleve:
So how do you choose what to start with and how do you know when to change it up?
Darren Petersen:
I think, for me, the shape of the project evolves over time, like the needs of the team evolve time. We had a large team on georgia.gov to start with. We had a lot of design processes happening, a lot of planning going on, and we were trying to achieve a critical mass of features so that we could ship our first website and that took months and months and months to do. And along that time period, we had to be able to show the client progress and get their feedback as quickly as possible. We couldn't do that continuously because we didn't have enough built and we needed to be sure, hey, we built this. Is this right?
Darren Petersen:
So Scrum is perfect for that. Like two weeks sprints. Show what you did at the end of those two weeks, get feedback, adjust and keep going. That's perfect for Scrum. But once you have a product in hand and you're in ongoing maintenance mode, like I said a second ago, demos stopped being useful because there's not enough new material out there to wow the client with. And you're really just trying to get feedback as quickly as possible and then put out features to production, add value as quickly as you can. So you really transition away from Scrum to a Kanban.
Darren Petersen:
And that's been the shape of most of the products that we've built at Lullabot that I've been on. Is that later in the project it moves to sort of a flow state as opposed to an incremental delivery, dropping demos every two weeks kind of thing. It just turns out that way.
Mike Herchel:
Right on. It sounds like these traditional methodologies are very useful kind of in their own way and it's just kind of you get a feeling for what needs to be done and you get it done.
Darren Petersen:
Yeah.
Matt Kleve:
A lot of them end up being combined in ways too. It's hard to, especially when you're working in a remote team, like most of the projects that we work on, because Lullabot doesn't have an office anywhere. We're all distributed. So the ideas that sort of formed what we know as a Scrum, Kanban, they were formed with a co-located team in mind. Like Monica was describing having a Standup literally be a Standup. You're at a table. Really, you wouldn't even need a Scrum master for it, the developers could get together at a table, say what they're doing, go to the left, what you're doing, go to the left, any blockers. Done in no more than 15 minutes, you go back to your desks.
Matt Kleve:
So having the remote teams the non-collocated teams as a trick to that. And I think what we've seen come out of that is these sort of hybrid systems, especially if you're not developing a particular product. If it is somewhat maintenance bug fixes, new features, and then somewhat we need to migrate this site over. It's hard to pin that level of project into one framework. And I think that's really the great thing about what we know as Scrum and Kanban is that they provide a framework for you to develop the processes that work for your team and figuring out what those processes are is really on the project manager. To get the team working in the most effective, most efficient way.
Matt Kleve:
And I've heard some fun terms come around to describe those like ScrumBut, we're doing Scrum but not really. It takes some of those pieces from the Scrum methodology and then we've built sort of a framework around that. One of the examples might be we're kind of doing everything that we would normally do in Scrum, but we're not doing strict sprint planning or just sort of flowing cards through because everything we're doing is maintenance. But we do still have a regular release cadence. We do select regular Standups, which comes from... everything. You can kind of pull pieces from different areas, but the idea is ultimately you've got to, as a project manager, figure out which processes get your team to work the right way to fit into what the project's asking.
Matt Kleve:
And I'd say, Darren, you probably have more experience with this or Monica maybe like how do you, is there a way to get the project to shift to sort of fit the way the team works or is it always one side? Is it always we need to make the team fit the project?
Darren Petersen:
No, I think Agile, like I'm not a subscriber to strict Scrum or religious Kanban observance or any of that stuff. I feel like Agile is a toolbox where you need to pick and choose based on the needs of like what's wrong with my project. We don't have enough communication? Oh we need a Standup meeting or we're not delivering fast enough so we might need to think about more regular delivery and that means not doing two week sprints. It means you Kanban and stats. So there's not a one size fits all answer. I don't think.
Mike Herchel:
Being distributed my present other challenges to having this strict adherence to some of these procedural things like, correct me if I'm wrong, but isn't like a tenant of Agile a physical Scrum board where you're supposed to move sticky notes around. Am I wrong?
Monica Flores:
Yeah. Agile, you do have a set list of what you're going to work on and estimates attached to each it, strict Scrum you have to figure out and that fills up your whole two week period and figure out the [inaudible 00:48:52] I mean, if you get into the needs of it, you figure out how far off you are on your estimate. But I think to Darren's point, I think the nuance of PM-ing a project is really understanding who are your people and what are their needs and what are some of the emerging issues. Maybe somebody's going on leaves, somebody's having problems, personal issues or the client has a deadline that they need to shop around to their stakeholders.
Monica Flores:
So part of this is being sensitive to the humanity of what's going on and using the tools to support the overall project.
Matt Kleve:
Is doing that remotely hard?
Chris Albrecht:
It does add an extra challenge. It's like instead of having the, I think you're right Matt, like the initial idea was having a Scrum board on a wall with sticky notes that you moved around. There's a lot of software that's coming to the market to help sort of fill that gap now.
Matt Kleve:
Sure. I mean, Jira has the Scrum board, but back to what Monica was saying, Chris like you were talking about the humanity of the project and is that hard remotely? Like you don't necessarily see my facial expressions when I'm pissed off that I've used bug or something.
Chris Albrecht:
Yeah. You learn how to read people a little bit better. And I think that's one area that has been really beneficial for me being a developer in the past, is that I recognize some of those qualities that other developers are displaying because I've looked through them like those times when I submarine myself and I'm just like, "I have to get this done. I'm really pissed that I can't figure out this bug. Why is this not working?" I'm just going heads down for as long as it takes to figure it out. You start to recognize and empathize with some of those things.
Chris Albrecht:
So knowing your team is really an important part. When you can't see their facial expressions, you can't watch it at set across the room if they're getting frustrated with something. But conversely also when there's like a big win, when they come up to a Standup or a meeting and they say, "I finally got this done, I'm so excited about it." Like being able to share that. If you're all in the same room, you can high five each other, you can give a hug, you can have a happy hour after work if that's your thing. But when you're all remote and distributed, it's very easy to lose those wins as well. So-
Matt Kleve:
Do you use emojis?
Chris Albrecht:
Yeah. Emojis become a very important part of communication.
Matt Kleve:
So like one of the questions that I had was probably the most important question, which emojis are appropriate for which situation?
Monica Flores:
Applause emoji always.
Matt Kleve:
Yeah. Applause.
Mike Herchel:
The fried shrimp, that's my favorite.
Matt Kleve:
The little party emoji and of course there's the thumbs up. Right?
Chris Albrecht:
Mm-hmm (affirmative)
Matt Kleve:
I'm impartial to just using banana.
Mike Herchel:
What? We've got that one on the IBM site. I don't know if we... I'll see if I can snag that one for the Lullabot one, but you know the peanut butter jelly time banana.
Chris Albrecht:
Oh yeah. From Family Guy or something. Yeah.
Mike Herchel:
Yes.
Matt Kleve:
Of course. Of course.
Monica Flores:
I think you can use certain kind of standards or etiquette in order to facilitate a sense of community and kind of camaraderie. So I appreciate, for example, Lullabot, a lot of people are using their conference calling zoom or meet or go to meeting and always having the front facing camera on. So that's helpful that I see people's faces. I've seen Darren in online before I met him in person and it was totally fine. So I think that's one part of it.
Monica Flores:
I think we alluded to this a little bit. How do you deal with when somebody is maybe not performing? I do sense that at Lullabot there's a high level of kind of personal, always bringing your personal best and being accountable to that. And so in a Scrum situation where you are discussing an actual ticket, if you do see somebody slacking, it's very visible. It's very apparent. It's very easily surfaced.
Monica Flores:
And so there's an opportunity to communicate on that, but I think working remotely, it does have its benefits in that you are bringing everything to the table and when you're on, you're on.
Darren Petersen:
Yep. Just got to be intentional when you see somebody is needing help because you can't just like look at their facial expressions. You got to look for other signs and then maybe reach out to them on a private message or whatever and be able to say, "Hey, is everything all right?" And you just have to try to do that intentionally as opposed to hoping it's going to happen because it doesn't just happen if you don't have a water cooler to gather around.
Monica Flores:
So would you say that we need to have a lot of the kind of soft skills, the communication, empathy team building kind of bringing your heart to the business? That kind of thing.
Darren Petersen:
I think that's totally true for any PM in any situation because the people stuff is the stuff that's hard to train for. Like you can learn about Scrum or you can learn about how to run a spreadsheet, but the so-called soft skills are actually much harder. And so they kind of misnamed it.
Darren Petersen:
I think though that again, you have to be more intentional when you're remote because you can't rely on like being in the same space as somebody to pick up on that kind of thing. So you actually have to ask and it's sometimes less comfortable, but it's important to do
Matt Kleve:
Along the lines of the soft skills that we've been talking about, I think they can probably be put to use with our last question here, which is a pushback against our clients. It seems that throughout my history at Lullabot, we have a lot of really great client relationships. And they've come back for more after we finish long projects. Year after year we end up working with a lot of these same people. And it's not because we always tell them, yes, so how do we handle that in the right way? Or how do we screw that up sometimes? Like what's the right way to do it?
Darren Petersen:
I mean, I think the biggest single way to screw it up is to not talk about problems early. I have a, a sort of a Pee-wee Herman reference here that if I'm uncomfortable with a particular thing or if you have that pit in my stomach feeling that maybe something's not right, I shouldn't sit on it. I need to scream real loud. Like a word of the day, scream real loud. Because it's not going to get any better by me hoping that it will get better. It has to get better by talking with the client about it.
Darren Petersen:
So letting bad news get communicated really early when it's not even sure it's going to be bad news, but it might be bad news is probably a key discipline and a key lesson that I had to learn early on.
Chris Albrecht:
I had a previous boss that always liked to say that bad news doesn't get better with age.
Darren Petersen:
You never want to surprise your client with bad news at the end. Like, "Hey, guess what? This is going to cost more or we're going to have to tell you no," and now you're in a bind and we've left you with no options or choices. So you want to do that conversation as early as you can and come to the table with options and say, "Hey, this looks like it's going over. This is how we're going to have to adjust the schedule. This is the feature that we think is the least important that we could probably cut or reduce its complexity in order to get to a finish line that you're happy with."
Chris Albrecht:
There are plenty of companies that might come with a low ball estimate and then have a change order later.
Darren Petersen:
Yeah, and I think that's a lie and we shouldn't do that, honestly.
Chris Albrecht:
Yeah.
Monica Flores:
Yeah. I think people come to us because of that culture of kind of we're a thought partner, we're your equal partner in this, we're committed to getting this done. But we'll also flag with you early on often if we're having an issue or something that we see potentially becoming an initial, but we'll surface that to you and not kind of pretend that it's not there. And that's part of our values, right? Collaborating openly, being really clear up front. I think people appreciate that in this day and age of having somebody who talks to you straight.
Matt Kleve:
Yeah. And that goes kind of throughout to... we've had discussion with our sales teams because as just was said, like there's other agencies that will low ball stuff and throw out change orders, knowing ahead of time that we're going to have to throw out change orders, which is very dishonest. And Lullabot does not do that, which costs us an occasional project or two. But the benefit is, is our projects are typically successful with a minimum of those change orders. And so we get the clients coming back, which of course is another way to do business.
Darren Petersen:
Yeah. For sure.
Chris Albrecht:
So how do you limit scope creep when the customer says, Hey, we need these three other things?
Darren Petersen:
So this is my favorite technique, right? So scope creep is seen as an evil bad thing. Like these darn clients are always asking for additional stuff outside of the scope of the agreement. And I feel like that's the wrong way to look at it. It's very human to like have a new idea and the new idea is a good idea and it suits your business. I want to validate everything the client says with respects to what they need on their website. Even if it's like, I just need more bubbles floating around my website, which I've literally heard people say-
Chris Albrecht:
Make the logo is bigger.
Darren Petersen:
Yeah. Can I get the logo bigger? If that's what's gonna make the sale for you or make your boss happy or whatever, that's a legitimate thing. So instead of saying, "Argh, clients," I need to say, "Yes and dot, dot, dot." So the yes and thing that we steal from like comedy, sports and theater improv and stuff like that is when the client says, "Hey, I need the logo bigger." I say, "Yes and that means we're not going to be able to put the search in the main Navbar because your logo is so big," or whatever the consequences. Like if you want this other feature it's going to have a trade off.
Darren Petersen:
So being able to identify what that trade off is and say yes and that's going to probably add another week to the project. It isn't that you had to say no, it's that, sure we'll give you what you want and we're going to need different changes to the paperwork in order to make that happen.
Chris Albrecht:
What if the client offers you a steak dinner?
Matt Kleve:
Then you just say yes., and you tell the developers we're going to need you to work on Saturday.
Chris Albrecht:
That was an inside joke because I was actually in a room where four other developers and I were offered a steak dinner for features. It was pretty good.
Darren Petersen:
Awesome.
Chris Albrecht:
We didn't get the steak dinner.
Darren Petersen:
Right. I would imagine.
Monica Flores:
I would guess too, again, this is why our tool set are kind of deeper knowledge helps because for our clients they may be building a website once every four or five years. Right? And we're building it every day. We know what it will take or if it'll take two minutes or if it'll take two days. So it makes it easier because we can understand the capabilities and with experience we understand what people are asking for because we've see it. If you see it in one situation, it's possible that another situation we'll want it to.
Monica Flores:
So I think that is part of it is the experience aspect, the open source nature, the collaboration aspect and then telling somebody straight, this'll take you an extra two weeks. Are you willing to deal with that? If it's a yes, then yes and if it's no, it's no, but at least they know what it takes.
Mike Herchel:
Yeah. Some of the best, I think most... some of the most successful projects that we've been on have ended with the client saying something like, what you said Monica, We appreciated having Lullabot there for their thought leadership and their collaboration and their people skills. And it was a lot of fun to work with them." That part generally tends to supersede, by the way, the project was awesome and the product that we got was fantastic. Like that always comes in as well for most of the stuff that we do, but it's really encouraging to know that we're finding good partners to work with that have the same values that we do.
Mike Herchel:
And it's not always the case though. That's when the push back, that's when you're flexing your Hulk muscles as I think a good project manager when that situation arises where you aren't necessarily seeing eye to eye with the customer and they're saying, "Okay."
Mike Herchel:
When the CEO comes down to hand you a CSS file full of colored links that don't at all match with the comps and just hand them to the developer and say, "Here this is ready, implement this." There are some challenges that can come along with that where you've got to try and figure out where to push back? Where to let it in and then how that communicates through to developers? And it's that iron triangle is the metaphor we use to describe scope of work, so the features you're going to get versus the budget you have to implement those features versus the resources and time to get those done. And it's if one moves, it affects the other too.
Mike Herchel:
So kind of keeping that in the back of your head and explaining those things as best you can. And if you explain that and say, "Yes, we can absolutely implement this nice colored CSS that you gave us, sir, but unfortunately now and we're going to have to remove this whole big block of text that was approved by your other team." If they say, "Well no, mine's more important," you end up down these rabbit holes of who's reporting to who? Who's not communicating with who? And sometimes there's only so much you can do.
Mike Herchel:
But I think one thing that we tend to try and find is when we look for good projects, we look for people, as well as the work, as well as the budget piece of it. We try and get all sides of that triangle together.
Matt Kleve:
Time, money and resources. That's kind of the triangle, right?
Mike Herchel:
Yes, sir.
Matt Kleve:
Okay. All right, well I think we need to point towards wrapping this up. So let's get some final thoughts and I have a question for each of you three project managers and it'll kind of give you your last chance to say something magical.
Matt Kleve:
Chris, I think sometimes the hardest part of communication is getting people inside of organizations to communicate with other parts of that organization. Yeah?
Chris Albrecht:
Yes, absolutely true and can be very frustrating. Is there a question there or?
Matt Kleve:
No, I don't know. I figured you were going to wax-poetic there for a second.
Chris Albrecht:
I mean, there are times where I've wanted to offer our services as Lullabot to other potential clients or other people. Like I've seen this before. Here's what we can do to help your team communicate better. I recognize there are some gaps between this side and that side, and say sometimes there's interest in helping them. Sometimes there's not and sometimes you have to realize you can only affect what you can affect. You can only... your purview is only so far, your reach is only so far and you have to deal with really difficult constraints whether they're within your team or your team is being affected by them somewhere else and work within that.
Chris Albrecht:
I'm lucky that we have such a great team to back us up here when those situations happen. I feel like I've got the resources behind me to help me through really tricky situations. Darren's been there for me and a lot of them. It's, we have a really great system to deal with those types of things. Yeah. It's not always easy when you've got teams outside of your team that are disconnected but are directly affecting the work you're trying to do in your team.
Matt Kleve:
Darren, you've been a PM at Lullabot for several years now. How would your family say that it's affected you?
Darren Petersen:
The first thing they would say is they're glad dad's home to make dinner every day after school.
Matt Kleve:
Yeah, that's pretty awesome.
Darren Petersen:
It is a great thing to be able to work at Lullabot. My commute is to go chop vegetables in the kitchen and not have to be on phone calls anymore. But I would say that in general it's easier to complain about your work to your family. Like, "Oh, things are happening. Clients are doing this, coworkers are doing that." And it's hard to remember to go back in and tell them and this worked out. And the resolution to that problem was so my kids often, just because of the difficulty of that dynamic, may hear me gripe sometimes. But they also know how much I enjoy working with the people that I work with. They get to see our interactions together, like the jokes that we do in Slack and the animated gifs and all the other stuff that make up the fun part of our day and the comradery that happens both with the clients and with the other Lullabots.
Darren Petersen:
They get to see those parenthesis most of the time when appropriate, close parenthesis. And my kids know how much I love doing what I'm doing and are excited when I have a big success. So I think being able to work at Lullabot as a PM, my kids are getting a sense of what I do all day long and kind of the good parts of it, at least some of the time. So that's great.
Matt Kleve:
Monica, we're glad you're here. Are we weird compared to the outside world?
Monica Flores:
I mean, I don't know.
Matt Kleve:
Oh, all right. It comes out.
Darren Petersen:
But in a good way.
Monica Flores:
Let's just say that I am so thrilled to be a part of the team and to be bringing my best self and to be challenged and to be working on these amazing projects and to really make a measurable difference on the world. And part of my hope, at least for the next generation, is just find what you're really good at and find a fit with that in your place of employment. And I would just feel very fortunate to be at a place where yes, like Darren said, there's no commute, so another two hours of my day that I get back, but then also all of my skills can be utilized in the most amazing way. So I'm really grateful.
Matt Kleve:
Mike. Project managers can't live without them. Can't live without them.
Mike Herchel:
Yeah. Yeah. I was going to say I can definitely live with my project managers.
Matt Kleve:
That's good.
Mike Herchel:
Yeah. Yeah.
Chris Albrecht:
Let me just say, when you have to run project manager on a team that has Mike Herchel on it, you'll learn really great people skills.
Mike Herchel:
I was saying like, you know, Matt, that could be an alternate title for the podcast. Project managers can't live without them. Can't live without them.
Matt Kleve:
There you go back.
Mike Herchel:
But I like to keep on gantting.
Chris Albrecht:
Think again back in Gantt Chart.
Matt Kleve:
Thanks everybody.
Darren Petersen:
Thanks.
Chris Albrecht:
Bye everybody.
Darren Petersen:
Bye.
Mike Herchel:
Bye.
Monica Flores:
Thanks so much. (silence)

Published in:

More Resources

See all

My Four Kickstarter Mistakes Can Improve Your Software Projects

Read

A Quick Guide for Code Reviews

Read

Workflow, uh, What is it Good For...

Listen