Martha Zink and I had the pleasure of presenting project management and risk management strategies during DevCon2018.

Please find a full video transcript below: 

Introductions

Susan Fennema: Hey guys, welcome to Operation FileMaker: From Risk to Perfection. We’re going to teach you a little bit about project management and risk management strategies. I’m Susan Fennema, this is Martha Zink.

Martha Zink: Hello.

Susan Fennema: I am the Chaos Eradicating Officer for Beyond the Chaos. I have 30 years of experience with operations and project management. I’m a non-technical, non-developing project manager, though, so I use that skill set a little interestingly, making sure I never get in the weeds. I do love technology though, kind of a little geek about that, so I have that in common with all of you.

Susan Fennema: Also, I’m a home chef, you can see my dinner table. I love to make multi-course dinners and set pretty tables, and if you think project management is not involved with making a 12-course dinner in an 800-square-foot apartment, you have some project management to learn. My husband I live just east of here about 40 miles away with our two cats, and my puppy dog, Shelby. And this is Martha.

Martha Zink: Thanks. I’m Martha Zink. If you were at my other session, you saw this slide already. I work for Soliant Consulting, and I’m a technical project lead. I love lists of threes, so that’s why everything up there matches that. And I love board games, so this was a really good chance to take advantage of my love for board games and my love for FileMaker.

Susan Fennema: In this session, you will learn a few things. First, you will learn about project management strategies. Second, you will learn about risk management and how to mitigate it for the long-term. Third, you will also learn about teamwork, and how important that is for completing a project.

Martha Zink: We’re going to learn these project management strategies with a board game. Today we will all be playing the game of Risk, which is a cooperative game. So, I do not like cooperative games in real life. When I play board games, I’m competitive. So, we’ll have to pick our odds here today with this project management game.

Susan Fennema: Here’s how we will play. So, we’re going to navigate through the six stages of the FileMaker river. You can see the stages on the screen. They are the typical stages of a typical project.

Martha Zink: Then we’re going to get the players, they have to get out of the boat, and have a status meeting. So, there’s going to be four spots, they’re going to get out, and they’re going to talk about what’s going on.

Susan Fennema: On those squares, you can either hit calm waters, things are looking good, smooth sailing, we’re cruising down the river. Or you can hit rough waters, and that’s the “Uh-oh, there’s an issue.” And we have to solve it.

Martha Zink: There are three questions that we think are the three most important questions in project management, and those are: What’s complete? What’s next? And-

Susan Fennema: What’s a blocker?

Martha Zink: What’s a blocker? We came up with an acronym, which you’re all going to have to say so that the board game continues. The acronym is WIC! WIN!

Susan Fennema: WAB!

Martha Zink: As we move to a status meeting, get ready to say it, because it’s the only way we’re going to get the game going.

Susan Fennema: So let’s practice, everybody. WIC! WIN! WAB!

Martha Zink: There we go. Perfect!

Susan Fennema: We can advance the board. When we come to the icon of rough water, we’re going to have to roll the die.

Martha Zink: This is a very interactive presentation. Your waivers are at the door.

Susan Fennema: We’ll draw a card based on the number. Four.

Martha Zink: The card we draw is going to tell us what the issue is.

Susan Fennema: It’s going to tell you who are the players involved.

Martha Zink: Our four players are the client, the project manager, the tech lead, and the developer.

Susan Fennema: There will be a captain as well. He or she wears the hat.

Martha Zink: Yeah

Susan Fennema: That person is going to be the one that solves the issue.

Martha Zink: So now what? We’re going to have to identify when we get there, we’re going to have to solve the issue by identifying what could potentially be the holes in the boat. What’s going to sink us? What’s going to prevent us from navigating down the river? Um, or maybe even destroying the whole project. Also, we will project management problem solve on the fly. What do we have to do right now to fix this issue? Then we will also prevent it for the future, make sure that we have created some process so that, that issue never happens again.

Martha Zink: And then once we’ve solved the card and we’ve talked through all the possibilities then everyone gets back in the boat and we move on to the next project management status meeting.

Susan Fennema: Let’s play the game.

Martha Zink: The game is built in FileMaker. This is where you get to choose a level. I have already selected it. “Easy” is what everybody wants in a project right? One straight line, easy river, little conflict. But that’s not really what happens. And then there’s hard, which is how it usually feels-

Susan Fennema: Even if it doesn’t happen that way…

Martha Zink: Right. We’re not going to play that because they only gave us an hour so we’re going to play normal and we’re going to have some…we think this is a pretty typical project…process…so let’s play. So, good luck!

Martha Zink: All right, so we’re going to start. At the top, you’re going to see the six phases that we’re going to go through; the six stages. So, we’re going to start with the kickoff. So, we’re going to start here at the very beginning and here we go 1-2-3

Martha Zink: Now we have cards. Someone’s going to come to grab this dice. All right, Sarah’s going to have to be our dice handler.

Martha Zink: Your waiver is also at the door.

Martha Zink: All right. Number four.

Susan Fennema: Okay, so I’m going to be the project manager on this one. I’m going to be the team captain. The client can’t get on the Zoom call to…oh, because of corporate download group rules. Okay, got it. This is a problem, right? We’re ready to start our kickoff meeting and the client can’t get in and everybody is waiting so, the immediate thing to do is to get the client on the phone, find out if maybe we can just get them to call into the number and do the call that way. That way everybody’s not waiting, we don’t have to reschedule.

Susan Fennema: The way to prevent this is that maybe the project manager should have talked to the client before-hand and made sure that they could download the software. A big killer on this could be if IT won’t let them download software and if you get that now you have to come up with a solution of how to get them in a share screen. It could be something like a join me, maybe they have a corporate one that you can use theirs. So, those are the long term strategies to prevent it from happening again and with that, our players can get back in the boat.

Martha Zink: “Back in the boat!” All right, so now we’re ready to go to our next status meeting.

Everyone: WIC! WIN! WAB!

Martha Zink: Well done. All right, we’ve got some more bad weather here. All right. What do we get?

Martha Zink: Oh, there was no internal kick-off.

Susan Fennema: Man, I’m doing a bad job. So, I’m going to be the captain here, too. So, there was no internal kick-off. Now, we all know that it can cause the client to lose trust in a kick-off meeting. That can be your hole in a boat. They will think you’re disorganized and nobody knows what they’re doing. You’re going to lose their trust in the first five minutes.

Susan Fennema: So, as the project manager I would jump in and the immediate way to solve that just takes your kick-off meeting down a notch. You’re going to make it very simple, top line, maybe talk about just the scope of the project, make sure you’re all on the same page, agree to when your future status meetings are going to be and tell them that next time you’ll talk about some more details and maybe the timeline. End the call and then immediately schedule your internal kick-off. Way to prevent it? It needs to be part of your process that, that never, ever, ever happens. So, I think we can get back in the boat.

Martha Zink: Back in the boat! All right. So let’s see how else we do on the kick-off here. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: We’ve got some nice, clear waters. You guys are keeping up, telling us what’s going on, everything’s great. So we’ll just keep on going. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: All right. We’re going to have to get a little more excited here guys. So, I know it’s a happy hour. Earn your happy hour. Oh, we got some more clear waters. So we can get out of the kick-off phase and move on. Why don’t we jump over to discovery? All right, ready? 1-2-3

Everyone: WIC! WIN! WAB!

Martha Zink: Yeah, you guys want happy hour.

Susan Fennema: They’re getting there. More smooth waters.

Martha Zink: Oh, good look. We just got right in discovery, and it seems like things are going pretty smoothly which feels great. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: Oh.

Susan Fennema: Oh, here we go.

Martha Zink: All right. Let’s see. Where’s the die? What is it?

Man in crowd: A 3.

Martha Zink: Conversations during discovery only happen with management, not future users. Has anyone run into this before?

Susan Fennema: Hmmmm. No.

Martha Zink: All right. So, this is going to impact a lot of people. This is going to impact the client, the project manager, and the tech lead. I’ll be the captain on this one. This is…the holes in the boat could just be that the client wants to just own this whole process, right? They don’t want to let anybody else have input. Or maybe don’t trust some of their employees. Perhaps they don’t want people to lose billable time. Those could be issues here that we have.

Martha Zink: The tech lead is responsible here to take ownership of this and to be very upfront and say “we need to have the right people on this project for this to be successful.” Making sure that you have the right players at the right time is important and this has a huge impact. This is going to have huge holes in the boat later if you don’t take care of it now.

Martha Zink: It’s important to regroup and get the right team. That’s going to delay timeline a bit, probably but it’s completely worth it and it’s going to save you a lot of pain later when you have to do a lot of re-work. I think we’re good. We can get back in the boat. All right. 1-2-3, here we go…

Everyone: WIC! WIN! WAB!

Martha Zink: Wow, more bad weather. Did we roll it already?

Susan Fennema: All right. 2. Is that a 2?

Martha Zink: Unknown scope remains unknown scope. All right. We’ll keep this one on my end here for the tech lead. This impacts the tech lead and clients. In discovery, that’s the time when you’re supposed to learn everything about the project and what you’re going to build, right? At least have a really solid understanding of what it is that you’re doing moving forward. Sometimes you use very qualitative words that don’t get you the right answer, so you say it has to be faster. Or it has to be better.

Martha Zink: Those things are probably acceptable in other conversations, but it doesn’t tell you what it is that you’re going to build. It doesn’t give you the specifics that you need. The tech lead must take the time to not be afraid to say “I don’t know” or, “I need more.” The client must be engaged and helpful in this part of the process, so it can take a little bit of pushing the client in the right direction. Again, this is going to have huge holes in the boat later if we don’t handle it in the very beginning.

Susan Fennema: Do you think we can get back in the boat?

Martha Zink: We’re going back in the boat.

Susan Fennema: Okay, let’s go back in the boat.

Martha Zink: All right. We’ve got one more here in discovery. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: They forgot that it’s happy hour again. All right. Smooth waters, smooth sailing, so, good. We figured out our discovery so we feel really good about it.

Susan Fennema: Let’s move to development.

Martha Zink: All right. Here we go with the first one. 1-2-3…

Susan Fennema: WIC! WIN! WAB!

Martha Zink: Oh, stormy weather- we kind of thought this was going to happen, right? You get on the boat, you’re right into discovery and you stop. Let’s figure out why.

Susan Fennema: 6.

Martha Zink: The client approves the design with no changes. This can’t be a risk at all.

Susan Fennema: It’s a miracle.

Martha Zink: I’m not going to lie, Susan came up with this one. I would’ve been like “that’s not a risk, that sounds great!” So this is going to impact multiple people, right? The development team more than anything and the tech lead’s going to handle this one. This is one of those where it can be really great and it can mean that a lot of good work was in at the very beginning and there are no questions, but it also means that it’s likely that the client didn’t engage, they just went “Yeah, that looks good” and then kind of put it to the side.

Martha Zink: These things must get attention early on because it can have a much heavier impact later. This is one of those that the hole in the boat is the client might not be engaged or they could change their mind later and you could do a bunch of re-work now that you’ve gone further down the development path.

Martha Zink: It’s important to probe them and say “Why don’t we sit down and talk through it together? Have you had a chance to look at it?” Just push them to ask the right questions and hopefully, they’ll give you some feedback.

Susan Fennema: The good thing is, maybe you did just nail it. You did discovery great and you just nailed it.

Martha Zink: Ask one more time, just in case.

Susan Fennema: Yeah, exactly.

Martha Zink: All right, back on the boat. Ready, 1-2-3!

Everyone: WIC! WIN! WAB!

Martha Zink: I feel like I’m going to have to start bribing you guys. All right. Clear waters. Nice and easy. The development is going well. The design was approved and they approved it and they’re happy.

Susan Fennema: We’re moving on.

Martha Zink: 1-2-3…

Susan Fennema: WIC! WIN! WAB!

Martha Zink: We’ve got another die to roll here. Go, Alicia, go! Oh, man.

Susan Fennema: Another 6.

Martha Zink: That was like spinning the wheel! That took a while. Is that 6?

Susan Fennema: Yep.

Martha Zink: The tech lead and the developer can’t agree on a technical approach.

Susan Fennema: I’m going to jump in here because the tech lead is kind of involved.

Martha Zink: I’m busy arguing.

Susan Fennema: I’m going to captain this. The first thing we want to do is mitigate it and calm it down. Talk to them about being on the same page, that we’re all in this together, that you want to make sure that you’re acting in the best interest of the client. Then you want to make sure that they are talking about it, right? Having a real conversation so that neither of them feels overpowered. That’s the way to immediately solve the problem is to get them to talk.

Susan Fennema: What could be a really big hole in the boat, in the long run, is if they have an ego that they can’t let go of and that it might be headbutting throughout the whole thing. If that’s the case you have to stay on that. I mean, if it gets really bad you might even have to consider replacing a developer or swapping out a tech lead.

Martha Zink: Not me.

Susan Fennema: Not the tech lead, they get to stay. Discourse is healthy but keeps that ego down because you have to try to understand each other and work together. This is our teamwork part.

Martha Zink: This is the part where the boat analogy matters, right? We have to grow together, you have to work together, you’re allowed to disagree, you’re allowed to talk through differences but you have to agree that you’re going to go in the same direction. You’re going to spin in circles if you’re not going the right way.

Susan Fennema: Can’t have two people on one side and one on the other. You’ll go in circles.

Martha Zink: So we got them to talk, they worked through it and we can get back in the boat and hopefully move forward. Ready? 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: The development’s going great. They agreed. They built some good stuff. We’re feeling good so we’re going to jump over to internal testing. It’s a long river. Here we go. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: Stormy weather. Right upfront.

Girl in the crowd: You did your best.

Susan Fennema: Five.

Martha Zink: Parts of the functionality aren’t complete. The tech lead goes to test some stuff or you have your QA and stuff just isn’t working and some holes in the boat or some things that could cause you a lot of problems or if the developer isn’t available…they might be on vacation, they might be sick, they could be a no show, they could be on other projects…if parts of the functionality aren’t done and it’s not documented you’re going to run into a lot of issues.

Martha Zink: It’s going to be the tech lead’s responsibility here and in a lot of projects to stand up and figure out what’s missing, to talk to the other developers if they can, and they’re likely going to have to step up and do some of that development work as well.

Martha Zink: The PM is going to have to play a part here because the PM is probably going to have to communicate with the client that there might be some delays depending on the amount of work that has to be fixed. Susan doesn’t like the conversation.

Susan Fennema: We’re always delivering the bad news.

Martha Zink: Better you than me. So to avoid this, I think it’s a really good idea when you have a team of multiple developers to schedule meetings where you’re talking to each other to make sure that the functionality is where it should be. When you’re having status meetings it’s important to answer those questions honestly, especially with the blockers because you want to make sure you’re getting the answers that you would expect and so that there are no surprises at the end, especially closer to the client testing phase.

Susan Fennema: Another thing is that the process part of this we want to put in place that we always are having internal developer meetings so that you’re looking at each other’s work as well. If that’s not part of the process you want to put those into the schedule.

Martha Zink: You’ve got to talk to each other. Sometimes. All right. Next up, back in the boat! Here we go. 1-2-3

Everyone: WIC! WIN! WAB!

Martha Zink: All right. Clear waters. Everyone looks like they’re doing their thing. Project manager’s happy for a little bit, not for long. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: We’re just sliding through this internal testing. It seems easy. Ready 1-2-3

Martha Zink: I feel like we’re going to get on our reviews that maybe they said that one too many times. We appreciate it, for what it’s worth. All right.

Susan Fennema: All right.

Martha Zink: We need another roll. Good throw.

Man in crowd: 5.

Martha Zink: That’s been popular. It’s loaded. We loaded the die. All right, so, it’s not tested on the correct platform. Has anyone run into this before? All right. Who develops on MAC? Or Window’s Clients? Do you sometimes not test on Windows? Not me. This one is extremely common and I think that it’s easy to get- you know- we get stuck in our development world and what we know. As it turns out, developers are idealists. I think someone said this earlier in our presentation, too. We want to assume that what we build will be used the way that it was meant to be used and that is wrong.

Susan Fennema: And apparently on the same platform.

Martha Zink: And even on the same platform, yes. Then you run into issues when you’re talking about using Web direct or IOS, whether it’s Windows or Mac, if you’re doing something where you’ve got Android users and they’re going to be using Web direct that way, that’s a very different experience than if they’re using Web direct on a computer screen.

Martha Zink: The hole in the boat is that the functionality may not be there at all. The hole in the boat is that it’s going to delay development because now there’s more testing that has to happen. Along with the platform, one thing that we wanted to- we talked about this a lot- was testing different privileges which also doesn’t always happen. We can do all the things we want that way. We test our ideal case and then you don’t think to test when you don’t have delete privileges or when you don’t have access to certain layouts. It’s important to make sure that you test through all the different other privilege sets that you know are going to be using your file maker solution.

Susan Fennema: Future lessons? Future lessons?

Martha Zink: I think it’s a really good idea that from the very beginning in the discovery phase that it’s documented how this will be used and then that carries through the whole development process. So, when it gets to internal QA you can have a document that says “this is what we’re testing” or “this is how we expect these things to be used.”

Susan Fennema: And even, perhaps, a checklist. I like the procedure of actually checking the box.

Martha Zink: All right. Back in the boat. Check. All right. So, we made it through internal testing, so again, we had a few little flubs there but we got it.

Susan Fennema: It’s time to turn it to the client.

Martha Zink: All right.

Susan Fennema: Let’s hope we did our job.

Martha Zink: 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: All right. The client gets it. They haven’t complained yet. We ask them how they’re doing and they seem like they’re part of it. There are times where it’s really important to make sure your client is part of your status meetings. The way that we do it often is that we have more internal meetings than we do meetings with the client within a given week, but it is important that they’re a part of these calls and that you can keep up with them

Susan Fennema: I think at the beginning of a project you should schedule your status meetings throughout the whole end of the project at regularly recurring intervals so you have a standing meeting with the client to go over things. That’s an important part of this, too.

Martha Zink: All right. On we go. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: All right, you guys are going to have to sync up a little bit more. There’s some…we’ll get it next time. All right, stormy weather. What do we have?

Susan Fennema: 4. Do we want that one?

Martha Zink: I don’t know. No one walked the client through the solution.

Susan Fennema: My guess is, on that last one, they hadn’t looked at it yet.

Martha Zink: That might be true. So, you give the solution to the client and they just say it doesn’t work or it’s broken-

Susan Fennema: You didn’t do anything we asked you-

Martha Zink: Yeah, what happened? It’s a lack of communication, that’s the biggest problem here. It’s a really good idea to have a meeting with your client to help them start the testing process because you want to make sure that there’s a set level of expectation, that they’re doing what you expect them to do, you talk about how you’re going to document things, that you can talk about what the expectations are on what they should be testing, what they should be seeing, making sure that they’re testing the right privilege sets and things like that.

This one impacts everyone. The project manager’s going to have to schedule another meeting so that the tech lead can meet with the client to hopefully walk through some of this stuff. Any other thoughts on this one?

Susan Fennema: Well, I think it’s important to add a client walk through to your process so that you’re always doing that. The other thing you can do, it’s the John Sindelar approach, make the videos and you can turn the videos over to the client when it comes time to test so they can walk through the parts that they need to when they do it.

Now, of course, here’s the thing; how many of you make videos for your clients? Oh, great! That’s a lot of people, that’s great. How many of you have ended a video with a curse word and had to start over? That’s another way to test your work, too, so it’s a good process.

Martha Zink: That’s a really good way. I think that when it comes to training and starting to build documentation for your users, the video is a great approach, doing some text-based if that’s what they need, building some things right into your database, but the video is a cool one because people can just watch it when they want. They can keep it and reference it. They can keep a library of these training videos.

Susan Fennema: Yeah, it can be for new hires too; a way to introduce them to the solution.

Martha Zink: Yep.

Susan Fennema: All right. Back in the boat.

Martha Zink: Back in the boat. 1-2-3.

Susan Fennema: WIC! WIN! WAB!

Martha Zink: That was good! Man, you guys took my feedback. I appreciate that.

Susan Fennema: It was because I was leading them.

Martha Zink: You’re good listeners. All right! Oh well, we got stormy waters anyway.

Susan Fennema: I just solved that.

Martha Zink: I was going to do it.

Susan Fennema: Very nice, then.

Martha Zink: So now it’s landed on the 4.

Susan Fennema: Okay.

Martha Zink: The developer thinks that what the client wants is wrong. This never happens either.

Susan Fennema: Mm-hmm (affirmative) Mm-hmm (affirmative)

Susan Fennema: The client is always right until they’re not.

Martha Zink: Well, there you go. This one could be a really big problem. This depends on when and how this is communicated. It is possible that a developer outright tells a client they’re wrong and there’s a lot more mitigating that Susan will have to do at that point. You hope that doesn’t happen and if they’re expressing their unhappiness that it’s within a better group, right? That it’s within a status meeting, with the tech lead or with another developer, the project manager, but you want someone who’s going to be able to talk through that.

Martha Zink: What are you going to do about it? You want to make sure you protect the client a little bit in this, right? You want to make sure that the client is heard and I think that the tech lead plays a really important part in that. It’s a chance for the tech lead to go and figure out what it is that the developer disagrees with and then go talk to the client about it. It just becomes a conversation. I’m glad we got this card because I get to talk about the importance of empathy.

Susan Fennema: Your favorite word.

Martha Zink: I’m getting shaking heads over there. This is kind of my card. The empathy thing is super important because we offer a service, right? We’re not just building a thing. We’re providing a service, we’re making people’s lives easier and better at work, we’re doing a lot of really good things and we got to remember we’re doing this for them, for the client.

Martha Zink: It’s important that we kind of step away from our ego or our hang-ups and…if we’re talking about this…sometimes you know when this is coming. You know a developer’s getting frustrated with a client, the developer’s- the developer was already frustrated with the tech lead a few status meetings ago.

Susan Fennema: If we have the same one still.

Martha Zink: Yeah, if we kept them around.

Susan Fennema: If not, maybe the tech lead’s the problem.

Martha Zink: No, no, no. That’s crazy. That was not part of the script.

Susan Fennema: I’m sorry. I was just ad-libbing. I thought that was funny.

Martha Zink: So there must be a discussion with the developer to try to figure out what the tension is and why. I don’t think that anyone should be discounted but it is important to also know this isn’t a conversation to have with the client. Try to figure out what’s going on, try to figure out the root cause. I think that’s probably-

Susan Fennema: If you have a developer that blows up at a client more than once, they can never talk to a client again. So, that can’t happen. It just can’t. That’s a big one.

Martha Zink: All right.

Susan Fennema: Okay. So, I think we can get back in the boat.

Martha Zink: I think we can get back in the boat.

Man in crowd: [inaudible 00:29:16]

Martha Zink: Say that again?

Man in crowd: [inaudible 00:29:17]

Martha Zink: Where the developer has-

Man in crowd: [inaudible 00:29:20]

Susan Fennema: Good point. You said that the developer could’ve thought of a consequence the client hadn’t thought of. Right. In that case, explain that consequence to the client and that gives you that.

Martha Zink: I think it’s important… I don’t think that on this card we would ever solve it by saying “No, the developer is wrong” and now they have to do what the client wants. So, I think that being a trusted advisor, being a part of what we do is to figure out exactly what the team needs and what the solution needs. Talking through it with a client is not a crazy thing. That’s probably pretty likely.

Susan Fennema: Mm-hmm (affirmative)

Martha Zink: All right. Back in the boat. Ready? 1-2-3…

Everyone: WIC! WIN! WAB!

Susan Fennema: We’re good.

Martha Zink: Clear waters. Man, the client tested, they’re happy. We’re good.

Susan Fennema: Unnecessary roll.

Martha Zink: Oh, man! That’s three more WIC WIN WABs, though, you can’t blame that on me.

Susan Fennema: So, we’re ready to go to the bug fix period. Now, a lot of times that bug fix transition, you’re changing over from just your lead clients testing to more users. It might not be rolled out to the whole team. This is kind of your beta testing. Some chosen specific users. Not the whole team, yet. They’re going to find more stuff because they’re going to use it differently.

Martha Zink: Yep. All right. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: Okay, well. All right. Clear waters. So we’re good for a little bit.

Susan Fennema: Another unnecessary roll.

Martha Zink: We’re excited about the die. I’m cool with that. All right, let’s try again. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: That was good! All right, well you can buy me a drink. All right, so we got some stormy weather. Are we going with that one?

Man in crowd: 5.

Martha Zink: 5, of course. Susan blew at the die, not me.

Susan Fennema: I know, it’s my hot air.

Martha Zink: All right, so the client doesn’t accurately document bugs. I will gladly stay out of this conversation.

Susan Fennema: All right, so one of the big holes in the boat that you can get to with this is that the client either won’t document the way that you want them to use a tool that you’ve provided, for example, or they can’t. They don’t know how to break down what they’re seeing to report to you and you’re just getting “it doesn’t work,” which of course, to developers, you know, is not any information at all. The result of that can be they just start using e-mail. Now you’re tracking your bugs in your e-mail program.

Martha Zink: Does anyone track bugs that way with their clients?

Susan Fennema: On purpose or accident. How many have had this come out?

Martha Zink: Your client decides to e-mail you and say… or they just march into your office if they’re close by, I suppose. That happens, too.

Susan Fennema: That’s true, too. That’s a recipe for never finishing your project right there. The way to avoid that is to first start by explaining the reason to a client of why you want to use the tool to track the bugs. Make sure they understand the value they’re getting out of that. Explain to them how to document one thing at a time, please. Not a whole paragraph of things in one bug.

Susan Fennema: Then, explain to them what a bug is, right? It’s not changed the whole program because I’m in accounting and no one asked me and it doesn’t work the way my old one did. Make sure they understand that a bug is that it is not working according to the way it was intended to work.

Susan Fennema: Once you get there, the project manager’s going to have to go back through all those e-mails, pull out the bugs, put them into the tool so the developers can work on them, and then that really solves the problem but it doesn’t solve the problem of how could we have prevented this from ever occurring in the first place. I have two methods to do that.

Susan Fennema: One is, when you’re ready to turn the solution over for the beta testing is to go through the tool with the people that you’re using, show them how to use it, make sure that they know that they can contact you, the project manager, if they get stuck, if they get confused.

Susan Fennema: The other method is that I think that many things need to be trained throughout a process to the client and if you can have some e-mails pre-written, ready to go, that describes your process so that when you get to this stage you can send that out. Then, they have something to reference. That also is a good way to solve that and prevent it from happening.

Martha Zink: I think one of the challenges here, too, is that every client is different. Everyone has a day job, everyone is busy. I have some clients that I treat very differently when it comes to bugs and fixes and even deployment based on the way that they work. It’s important to have open communication about those things.

Martha Zink: Another client I have just says “just deploy it” which is scary and you’re like, “are you sure?” He’s like, “yeah it’s fine.” Are you sure? But he does work well that way and then if there are bugs he knows what he’s getting into and often it’s secondary functionality. Something that isn’t necessarily tied to the main part of the database. It works well and it works for us. It’s a smaller client and it’s a smaller project so it’s okay. On our larger projects, though, it’s especially important to push the process. So, make the project manager do it.

Susan Fennema: I think, too, how many of you bill by the hour? Okay, so if you’re billing by the hour the client not doing their part at this stage costs him money. That is something that you can share with him. So, if he flat out says “I don’t want to do it your way” you can say, “that’s fine, your budget it…” as a way to promote their…to get them motivated to do it the way you want. They might not care. They might rather throw money at it and that’s okay, too.

Martha Zink: All right. Back in the boat. All right. Just two more.

Susan Fennema: WIC! WIN! WAB! They got it!

Martha Zink: They’re like, “please.”

Susan Fennema: They’re reporting them, probably.

Martha Zink: The developers not being all weird about it. All right. 1-2-3…

Everyone: WIC! WIN! WAB!

Martha Zink: You can buy me another drink. All right. What do we get, what do we got?

Susan Fennema: 6.

Martha Zink: Almost a 5. All right, 6 it is. The development team gets frustrated with the bugs entered.

Susan Fennema: Ever happen?

Martha Zink: This one involves a little bit of project management. Should they be frustrated? Maybe. This is similar to back in the river a little bit ago, we were having some conflict with the developer and the tech lead. Then we were having some conflict where the client wasn’t communicating as well as they could have. So, we’ve got to figure out what exactly is going wrong.

Susan Fennema: If the client is starting to communicate with a confrontational language, you can figure out quickly that they are very frustrated. If the developers are being defensive, that’s another thing. The bugs could not be bugs and that is- how do you make that communication happen? These are big problems that you need to have a conversation about. You want to include the client in the conversation and, again, Martha’s word; empathy.

Martha Zink: Yep.

Susan Fennema: Make sure that we’re talking people off that ledge. It’s okay. Everybody gets nervous because we’re about to be done and when you’re done there’s all this change and everybody as to use this. There’s a lot of nervousness at that stage.

Martha Zink: Keep in mind that we’ve kept the client in the boat with us the whole time, right? We believe that the client is part of the team. Sometimes developers get frustrated or complain, but, in reality, we’re all in it together, right? They’re paying us to do some work. We’re trying to make their lives better and easier, so we must always remember to work through these things.

Martha Zink: It’s okay to be frustrated. It’s great if you can internally vent to somebody and kind of talk through it, but at the end of the day, it’s important to try to move forward together and stay in the boat together.

Susan Fennema: I think that’s back to the other one a little bit, as well, but seeing it coming, you know. Sometimes it’s silence from the client that tells you it’s coming because they’re not saying what’s on their mind because they’re not confrontational. Then, you’ll see it in writing, so it’s easier to write it.

Martha Zink: Your client needs to have good communication and a good relationship with somebody else on the team. In an ideal world, the client has a good relationship with everybody on the team. That doesn’t always happen, right? Sometimes you just build a stronger bond with the project manager or the tech lead or the developer but it’s super important to have that.

Martha Zink: You want someone in the group to do that so that they can keep their eye on the client’s well being and make sure they’re feeling okay about the project as well so you’re not surprised with this at the very end of the project.

Susan Fennema: All right.

Martha Zink: Back in the boat?

Susan Fennema: Back in the boat.

Martha Zink: We made it!

Susan Fennema: It’s done, done!

Martha Zink: Thank you to building this screen today I realized there was a huge bug in my board game and I’m so glad I built my little cowboy dudes so that you guys didn’t see a bad database today. I did not focus on my internal testing very well. All right, cool. So, we made it through our game and now we’ll switch back to our presentation here, you know.

Summary

Susan Fennema: Let’s talk about what we learned. I think you probably heard me say it a lot. The process is key. Make sure you know what you’re doing, what order you’re doing it in. It should be written down somewhere. You should follow it religiously. Every project. You’ll notice that we didn’t have a project description in this because the process of running the project is the same no matter what the scope of the project is. So, you always have that same routine around it, which is important to note.

Martha Zink: You’ve got to think on your feet to solve the problem at that moment. You’ve got to figure out what is it that we have to do to handle it right now, but then you have to learn from those lessons and you’ve got to do something with it. So then, you talk about what’s the plan for the next time, how do we avoid this from happening next or, in something where you can’t control how the client feels or thinks, you say “how are we going to tackle this the next time?” You must think of risk in both the short term and the long term.

Susan Fennema: Change is inevitable. And there, I’m a project manager, I said it. We get the reputation that we always want to be so rigid and going to fill this out exactly as we started. We know that change is involved, but if you don’t have a plan, to begin with, being able to accommodate that change can become very challenging. So, make sure that you have that plan in place in the first place.

Martha Zink: I get to talk about empathy again. So, listening and respecting everyone else, everyone in the project is super important. I’m sure that I’m going to sound like a broken record very soon, but it is really important to keep that in mind.

Martha Zink: You should try to build good relationships with your whole team, know the dynamic, know what everybody’s strengths are, how you’re going to get along and to try to be a team and work through it together. It’s completely worth it for the health of the project, for the health of everybody involved. When you’re frustrated, take a step away and then try to come back ready to solve the problem.

Susan Fennema: Lastly, it’s not the game of risk. So, there is not a winner at the end. Everybody wins if you pull together to get to the end. That’s important to remember with project management, that teamwork is what makes it and that includes your client.

Susan Fennema: This session will have updates.

Martha Zink: Yep. So, we’re going to go ahead and upload this FileMaker file. If you guys want to play with it you can see some of the other things we had come up with. That’ll be up there and we’ll put up our slides as well.

Susan Fennema: Yes, and please remember to evaluate at the end. Now we would like to hear- please challenge us- with your questions of what are the issues in your projects or project management that you don’t know how to mitigate and prevent?

Question and Answer Session

Martha Zink: Any questions on risk or things you’ve dealt with? We just answered all of them?

Man w/ question: So, you talked about with bug reports how certain things are not bugs, like asking for new features or changing how things should work.

Susan Fennema: So, can I answer that?

Martha Zink: Absolutely.

Susan Fennema: Okay. Telling the client no is important to have in your toolbox, but I don’t like to say “no.” Later it is better. So, to make them feel better, make sure you have a list where you’re capturing those things. It can be a wishlist, a later list, and in and out list, so they can see that you’re making that list when they’re making that request. So, you can tell them “We talked about, in discovery, what you wanted to create.

Susan Fennema: We don’t want to just randomly throw something new in it, even though it might be a great idea. So, it’s not in the scope of the current project and if we try to add it, it might blow off your timeline and it might take longer and it will cost you more money. So, let’s do it after this part of the project is out and being used.”

Susan Fennema: Some things that you find happen in that are either the client finds out they don’t need it because it is working as it was intended or they come back and say they don’t even know what that meant when they told you and the other is that it could be a brilliant, great idea.

Susan Fennema: At that point, you can say, “I’m ready to build my next project for you. I have a nice list. So, let’s put that together and make it phase II.”

Woman w/ question.: So, what happens if a developer leaves in the middle of a project and you have to do some knowledge transfer. Do you have any tips for that and do you bill for that time?

Martha Zink: For a data transfer? Is that what you said? For information transfer between developers?

Woman w/ question.: Yeah, exactly.

Susan Fennema: No, I think she’s saying- let me clarify. You were saying that the developer left, like ghosted, without handing off things?

Martha Zink: Do you want to take this one?

Susan Fennema: I think that’s a tech lead question.

Martha Zink: You’re not supposed to say I don’t know. This is a challenging one. You’ve got to figure out how much you’re going to transfer, right? It’s not unrealistic that a project is going to have multiple developers and that there is some cost associated with that. We’ve internally decided not to comp some of that because it’s our internal decision.

Martha Zink: Especially if a developer has just up and left. That’s not necessarily the client’s responsibility. If we’re making the team bigger I think that seems billable, right? If they have more needs or more work, I think that seems fair. In an ideal world, you can talk to your client about it and say “we’d like to bring this person on” and talk through it and make sure they’re aware of it and okay with it. Then, I think it most likely is billable and acceptable.

Martha Zink: This is why the discovery phase or the foundation phase is so important for project management. You hope that you have enough documentation to handoff in the project management phase and where that doesn’t happen through the development phase you want the system itself to have as much documentation as possible. Great question.

Susan Fennema: If the tech lead is not involved in that project management process with the developer, then if the developer ghosts, now what? If the tech lead’s involved, then they’ll have an idea where the files are, they’ll have looked at them, they’ll kind of have an idea where they are. But, it’s important for the tech lead to be involved with the developer.

Martha Zink: Absolutely.

Man in crowd: What a great project management presentation, thank you.

Martha Zink: Thanks.

Man in audience: Furthermore, we discover later on in the project management process that the person that has been directing us is not the decision-maker. So, do you have any advice on how to detect that during the discovery phase? So, how to get clues if a person has the authorization to make decisions or not?

Susan Fennema: Who are the financial and operational decision-makers and how to get to them? Is that the question?

Man in crowd: Yes. After we talk to, for instance, a department manager, and it turns out the real stakeholder is a manager above and he starts commenting on the project and then starts changing the direction of the program.

Susan Fennema: Changing the direction, okay. Are you chiming in on that?

Man in crowd: Yes.

Susan Fennema: Okay, so the answer from our audience is who, in addition to yourself, will be making these project management decisions? I agree with that. At the beginning of the project, you should find out who is your financial decision-maker and who is your operational decision-maker. Sometimes they’re the same person.

Susan Fennema: You may or may not be working day to day with them. So, if you are not working day to day with that person you need to find out how that other person is going to be involved. So, one way that it can be is regular status updates from the project manager after status meetings to loop that person in. If they show up at the end and just find out that you’re out of time and out of money and it’s a surprise they’re going to be upset. So, just talking about it.

Martha Zink: I think in the beginning it’s smart to document who is on the team and to give that back. So, have some type of page that they have access to if you use a wiki system of some sort or to e-mail it. So, you can even outright ask, “Who are the people and what’s their contact information?” That’s all in one place, even if it’s in an e-mail. At least there’s some history of it and you’ve communicated back and forth and talked about the importance of that.

Martha Zink: It’s kind of hard because a lot of these things you manage the risk early on, so the sooner you can find this out and the more questions you can ask at the beginning, the more you’ll avoid in the end.

Susan Fennema: Sometimes there is a surprise. So, I’ve asked that question and gone through a whole thing and the person will say, “Okay, let me go talk to my partner.” Do you have a partner in your business? So, sometimes there is a surprise. And the earlier you can find that out, the better you can mitigate it.

Martha Zink: Yep.

Susan Fennema: Is everybody just ready to go to the party?

Martha Zink: Happy hour! And I’m getting two drinks!

Man in crowd: I thought this was a very innovative way to make a presentation.

Martha Zink: Thank you.

Susan Fennema: Thank you very much.

Martha Zink: Well, thank you, everyone, for coming. We know it’s later than we originally planned, however, we do appreciate your time. Lastly, enjoy your evening. Enjoy some cornhole.