A few months ago, we looked at what a developer does all day. This month: What on earth is the project manager up to? Project managers don’t actually make anything. They don’t write code. They don’t make graphics. They don’t sell the software. Yet a good project manager can be the glue that holds a project together. So how does that actually happen? What does a project manager do all day?
Meet Jeff
Jeff is the sole project manager at a 20-person company that makes a content management system for publications. They’re not quite a startup, and though they do have about 100 customers they’re not a large company, either. This company has a development team of eight, four sales people, one product manager and a few other support staff. The team has just completed development on its next release and is getting ready to launch its first ever beta program. It’s Thursday. 6:00 a.m.: Jeff gets up early to talk with the support team. Support is contracted to an outsourced firm in Russia, and they have a lot of ground to cover to get the beta program ready. Jeff’s company has explained what it wants, and the outsourcing firm is presenting a proposal for a support strategy and plan. It’s nowhere near ready. 7:45 a.m.: Finally off the phone with the support team, Jeff takes a quick shower and heads into the office. That meeting did not go well, and Jeff thinks they need a new strategy if they’re going to meet the level of service that product management wants. 9:15 a.m.: At the office, Jeff pokes his head into the development bullpen to say hi to everyone. 9:20 a.m.: Jeff finds a hole in the product manager’s calendar and schedules a meeting for that day to go over the beta program plan. He invites the lead developer, too, because the backup plan is likely to start out as, “Development will support the beta customers.” After that, Jeff does a quick email check. It’s mostly automatic updates from the ticket system, which he skims and deletes. The rest will have to wait. 10:00 a.m.: Standup time. Although they don’t do SCRUM, exactly, the team does get together every morning to talk about what they’re working on and any issues they’re encountering. Today things seem mostly on track, although Jeff does mention the support call from earlier and notes that there will probably be more coming on that front. 10:20 a.m.: Coffee and an apple. Jeff starts thinking through alternative support options. He reviews the upcoming development and implementation projects, trying to get a handle on which internal team could cover the slack. Development is booked pretty tight but the implementation engineer might be a possibility. Jeff also calls a few of his colleagues in other firms that also use outsourced support -- maybe they have suggestions for another firm he could use. Thank goodness for those project management meet-ups he’s been attending. They’ve introduced him to several peers he can get information from at times like this. 11:45 a.m.: Early lunch. These early mornings leave Jeff hungry. 12:30 p.m.: Jeff tracks down Donna, the product manager, to talk about the upcoming product roadmap. Donna has been revising the roadmap and Jeff is hoping it’ll become a bit more realistic. With only eight people in development, the team can only handle one major initiative at a time. Jeff and Donna look at the major project requests and find a few that are more similar than they first appeared. With some clever UI design and architecture, they could probably meet a couple different needs with a single large feature. Jeff makes a note to set up a meeting with the architecture team to figure it out. 2:30 p.m.: Weekly sales update. Jeff likes to listen in on this. A large sale near the end of the quarter can make for some last-minute development needs and the sales call is his earliest warning for those “we have to do this or lose a big fish!” moments. It looks like there is a large deal that’s going to squeak into the quarter, so Jeff re-reads the proposal to make sure it doesn’t promise a new feature. All of it looks good, fortunately. They should be all set with no extra development work required. 3:30 p.m.: Jeff meets with the lead developer and with Donna to talk through the beta program support plan. He brings in his notes from the morning call, his pro/con list, and the names of a few other firms they could consider. After brainstorming for a while, they decide to pursue another firm and use the implementation engineer as a backup. Jeff will set up some evaluation calls. 4:30 p.m.: One-on-ones with two development team members. Jeff tries to meet with each member once a month, which means two a week. It’s a good chance to get some feedback on how he’s doing, and to work with each developer so they understand the system and how the code relates to the business. Jeff subscribes to the philosophy that a developer who understands the business makes better coding decisions. One of the developers brings up her impending maternity leave, and wants to make sure she wraps up the project she’s on before she goes. She and Jeff agree it’s going to be tight, and he makes a note to avoid using her for interrupt tasks so that she has a good shot at finishing. 5:30 p.m.: Definitely time to go home. It’s been a long day.
What Happened?
Particularly in small companies, project managers like Jeff are the glue between departments. They’re the ones who spend their days asking “who?” “when?” and “what effect will that have?” Jeff makes very few decisions himself, but he’s an information center and frequently brings other people together to solve a problem he’s identified. It’s a tough job, but someone’s got to do it.
