Are you a developer wondering how to improve your project management communication? Are you just trying to improve communication overall on your projects? Check out the first part of a three-part series with Don Clark, from FileMaker Pro Gurus, where we discuss communication tactics for developers and project managers. While this may be specific to the development world, these tactics are still useful for all types of projects.
Please find the full video transcript below:
Don: Hi, this is Don Clark with FileMakerprogurus.com and FM Database Consulting, and I’m with Susan Fennema. Susan, how are you today?
Susan: Hey, Don, Happy New Year! It’s good to talk to you again.
Don: Happy New Year to you too. Today we’re going to be doing the first of three videos on project management to kick off the new year. This one is going to be communicating with your project manager. So let’s go over some of those points. Can you give me a broad outline please, Susan?
Susan: Sure. So, you know, when you are working with a project manager as a developer, there are a lot of things as a developer that you need to communicate to the project manager so that they can help you. Really their job is to help you, so help them help you, right? So that information helps that happen. Things that would be helpful for them to know would be, when are you going to be working on the project? Is it Saturday afternoon? Or is it during regular work hours? Just something that gives them an idea of when questions might arise.
Susan: You know, they could also let you know when you have questions for the client. So don’t just stop because you’ve run into a wall. You need to let the project manager know, “Hey, I need to talk to the client. I need this information in order to keep going.”
Don: Well, that makes sense, yeah.
Susan: Yeah. If you wait until they ask you about it and then they find out that you’ve been, “Oh, well, I can’t do this because I don’t know about this.” So we’ve lost a week because you didn’t ask them.
Don: Yeah, that’s a real big issue.
Susan: You know? So don’t wait for the project manager to ask you. They don’t know what they don’t know. If you know, let them know that you need to know.
Don: I’m waiting for an answer back from the support company for this particular plugin or for this particular issue, or with this integration part. Until I get that back … Or the converse of that actually is, I’m waiting for the answer back from the client.
Susan: Right. It can be the client, it could be a vendor, it could be anything. But especially if the project manager knows about it, they are able to facilitate getting that answer from the client. So while a developer might ask the client the question, the project manager might say, “If I don’t have this answer by Friday your project’s delayed.” So they’re able to set a consequence for the delay.
Don: Yeah, exactly, and make it stick.
Susan: Yes, exactly.
Don: It’s in communication, it’s in writing somewhere. Not just a phone call.
Susan: Exactly. It’s important. You know, something else is, when as a developer are you not available to work? Because you have other projects or other clients or, heaven forbid, you go on vacation, right?
Don: Heavens, no.
Susan: Make sure that it’s again not after the fact. Because if something is delayed because you’re not accessible that is a problem too, and it makes you kind of look flaky, right? As a developer if you just go radio silence.
Don: Most developers have that reputation for that reason, I suspect.
Susan: It’s true.
Don: The ones that do have that reputation, I should say.
Susan: It’s true. You know, if it’s a client, as a subcontractor, if you’re working with a contractor but maybe not actively, say a project’s been on hold or anything like that, a simple solution: create an out of office email response that says I’m on vacation and when you’ll be back. Then they know and they’re not like, “Where are you?”
Don: I guess there’s also the communication of, “Well, I promised to work on it today but three other files came up, or my computer broke.”
Susan: Yeah, when something unexpected comes up that absolutely can be accommodated, anything you can say in advance proactively is of benefit. If it’s after the fact, it becomes more of a challenge to handle with the client. But I mean, clients are usually very reasonable if you tell them in advance. If you wait until the day it’s due and say, “Oh well, you know, we had a server outage and somebody went on vacation.” They’re way less patient with that.
Susan: The other thing that’s really important that a project manager get from a developer is to document any changes that they ask for, any sort of client communication that you might have that doesn’t include the project manager.
Susan: Right. Any project manager worth their salt is going to tell you not to communicate outside of that unless they’re present. Or if you’re going to do a phone call, just do a Zoom …
Don: I’m just going to answer that question because I’ve had another client complain, when I was working with somebody using Basecamp, they wouldn’t take a phone call.
Susan: The client wouldn’t?
Don: No, the developers using Basecamp. Now, they were developing a website. But they wouldn’t use it. Even the client couldn’t call them. Not for something that was related, I guess, unless it was something outside that. But if it was something to do with what we’re going to do in the project, they wanted it in writing, they demanded it in writing. I thought that was pretty stark, you know? Pretty tough for a client.
Susan: I’m not for being that rigid. But I am for documenting the conversation. So you could have a call, you could do it via Zoom instead of the phone, or GoToMeeting or any of those other options, and record it.
Don: Yeah, and address that as a file, right?
Susan: Right. You just upload that video into your project management software and the history is there, and you can always look back at it. But having that documentation to go back to helps the project manager to sort out new things that come up. Shoot, that’s easier. “Hey, I had this call while you were out. Here it is. Go figure out what the new things are.” You know, and the project manager can do it from that recording.
Don: Yeah, and they put down the new timeframes or the milestones or what have you on the checklist.
Susan: And pick up any of those things that might have been promised that shouldn’t have been so that they can be readdressed quickly.
Don: Right, exactly. Well, those are all really good points, because if you don’t have the communication with the project manager and you’re the person between the client and there, you know. This is not just if you’re the project manager. If you’re somebody like me who’s … I am the project manager.
Susan: You are.
Don: I’m exactly. I might not even be working on it, but I’m still overseeing the whole thing. So it’s important to know what’s going on. It’s tough to get these guys to do that. It’s like when they get done, these are some of my experiences mind you, not all of them, some of them they get done working they just stop, they don’t update their records. Well, I worked on it today, here’s what I got done. Or they put in a sentence, you know, “Worked on this.” What do you mean?
Susan: That’s not a lot of detail.
Don: That’s cool. Did you? Did you let the client know and was there any kind of a demonstration? And is the work finished? You know, that kind of thing.
Susan: You know, that’s a good thing to keep in mind because the project manager is really responsible for the scope, the budget, and the time on any project. So if it has to do with those things they need to know about it. But the developer has a role in that as well, right?
Don Clark: Yeah.
Susan: Most project managers, if they’re like me, I’m a non-technical project manager, I’m going to rely on the developer to tell me how long the task is going to take them to complete. I might have a good idea since I’ve been in the file-maker industry for so many years. But you know, there might be a technical challenge that I’m unaware of.
Don: Yeah, sometimes even the developer’s not aware of it.
Susan: When one comes up unexpectedly that’s a red flag to alert your project manager too.
Don: You’ve got to know this, “You know, this is going to take a lot longer. This is taking a lot longer than I anticipated.”
Susan: The developer also is responsible for understanding the overall scope. So having an idea, and if they’re just being asked as a developer to just do a task, it is more likely that they’re going to say, yes and no problem when a client asks for something. It is a developer’s goal usually to say yes and to fix it and to solve the problem, right? But we have to understand how the finance works in with that. So we’re not giving it away for free. We have to figure out how it’s going to be paid for and let the client choose whether or not they want to pay for it. As opposed to, “Oh, after the fact, here’s your extra $2,000 that it cost you.”
Don: That’s not very good for client relations.
Susan: It’s not good at all. So again, back to that proactive communication, right? Allowing the project manager to be able to do that is invaluable. To your point about the when it’s done, that is one of my favorite conversations is, “Hey, is it going to be done on Friday?” “Sure.” So Friday you say, “Is it done?” And they say, “Yes.” And I say, “Where is it?” And they say, “Oh, it’s sitting on my desktop, I haven’t put it into the solution and I haven’t tested it. I’ve got to see if it works with this.” Wait a minute.
Don: They haven’t documented it. The client hasn’t approved it. The client doesn’t know this feature exists.
Susan: It’s not done.
Don: But they’re done as far as they’re concerned. Sometimes you want to reach through the computer screen and grab them and shake them a little bit. I probably shouldn’t say things like that. But that’s how I feel sometimes because I have people do things and just never let me know.
Susan: That is what’s important, right? Because you’re responsible for the client communication.
Don: Right, exactly. Yeah, not for them, I don’t think that they should have done that unless they were working directly with the client at that point in time to give something to them, they shouldn’t be doing that. That’s different. I think we have that down for a different video. You know, I think we’ve discussed it once before. Should they even be in direct contact? Or when are they allowed to be in direct contact with a client?
Susan: That actually I think we talked about before in our subcontractor series, is making sure that expectation of how they’re communicating with the client is set upfront so there’s not a surprise.
Don: Okay. I think we’ve covered everything that we want to cover on this video unless I missed something. Do you think of anything?
Susan: I think we took care of it.
Don: All right, well that’s it, guys. We’re going to be back with another two sessions on this project management series, and I think you’re going to find a lot to learn. I just learned some more today that I wasn’t even doing, I wasn’t anticipating, and I’m supposed to be in the know here. So look forward to it, and we’re going to be doing these again next week and the week after. So set your calendars. We’ll be on 11 AM Eastern Time each time on a Monday, so we’ll see you then. Again, this is Don Clark with filemakerprogurus.com and FM Database Consulting, with Susan …
Susan: I’m Susan Fennema from Beyond The Chaos, and I’ll talk to you next week, Don.
Don: All right, take care, ’til then. Bye-bye.