In the digital industry, project managers and development resources may be cut from the same cloth, but perhaps from opposite ends of the tapestry. Both are logical; both are calculated; both like to think they’re what makes the world go ‘round.
But let’s face it: the struggle can be very real. Whether it’s estimating development efforts for work that has yet to be defined, playing hot potato with requirements documentation ownership, getting creative with scope to adhere to budget, determining who should be at the table (or in the forefront of the e-mail thread) for technical conversations with the client, or managing day-by-day workload…
(I could go on)
…the fact is just this: how project managers and development resources collaborate is an ever-evolving, ebbing and flowing, hot-then-cold, yes-then-no, love-hate relationship. While the goal of delivering a product on-time, on-budget, and within-scope is a shared one, the means to get there is not as straightforward as our meticulously documented processes and protocols outline.
Differences in approach or thought process are inevitable between any number of team members; how we manage those differences and navigate those challenges can really set the tone for collaboration between project managers and developers on an engagement. The easy conclusion to differences in approach is frustration. The ideal conclusion to differences in approach is staying solution-focused. It may take a bit more effort, but that extra effort to find common ground results in productive collaboration. We project managers love our productive collaboration.
Communication is an excellent first consideration when it comes to collaborating productively. Oftentimes, sitting across from a developer, it’s our very first question(s) that can set the tone of the entire engagement (that sounds dramatic…but it really isn’t).
4 Questions You Should Never Ask A Developer (And What To Ask Instead)
After plenty of my own trial and error, I’ve jotted down a few examples of these questions, followed by some suggested answers and alternative approaches.
Question 1: This Should Only Take About 5 Minutes, Right?
ANSWER: It depends.
As project managers, it’s wise to remain cautiously optimistic — at best — regarding budget, scope, and timelines. This is not to be confused with aggressively ambitious. When initiating any sort of estimates conversation with a developer or developers, it’s ideal to provide whatever context is available and then allow the developer(s) to provide their organic estimate. Once an estimate is provided, the project manager can assess that estimate against whatever budget may (within an engagement) or may not (prior to an engagement) exist.
While it’s tempting to jump out of the gates with a low-ball number, it’s neither a compliment to a developer’s skillset nor a truly genuine approach to obtaining an estimate from that developer. It risks disregarding the developer’s input on that engagement and it jeopardizes the authenticity of that developer’s estimate.
If a budget is fixed and the estimate provided is well beyond that budget, take the Good/Better/Best approach.
- Good: within budget, decreased functionality
- Better: minorly over budget, more functionality
- Best: significantly over budget, complete functionality
Rather than breaking the news to a client that they’re going to be paying a lot more than expected (or receiving a lot less than expected), this gives them options. It’s important the PM and developer(s) work closely to define what each of these three approaches looks like in terms of defining scope.
Question 2: “How Should I Have Known?”
ANSWER: When it comes to identifying ownership, it’s not whether you should or shouldn’t have known all of the minutia. You may not have known, and it’s possible you still don’t know, and that’s why it’s important to ask questions, learn, and remain focused on the solution rather than where to point the finger.
This question appears to come up most regarding requirements documentation, development execution, client expectation and when any combination of these misalign.
The project manager is present from start to finish on an engagement. While the developer may write all of the technical requirements documentation, the project manager typically has a hand in managing the execution of said documentation, to ensure the client is receiving a buttoned-up deliverable on time and up to snuff.
We’re well aware that technical documentation is as an enjoyable and captivating read as the next Games of Thrones novel, but there may be ambiguous elements of the documentation that a developer assumes is sufficient, and a project manager doesn’t question.
We’re also well aware that one ambiguous element can be detrimental to an engagement. Well…when that one ambiguous element blows up in QA…who’s to blame?
From a client’s perspective, it doesn’t matter whose fault it is that one ambiguous line within the technical requirements opened a can of worms. It’s more than likely that, if not defined out well enough, that ambiguous element is going to sway in the client’s favor — whether we like it or not.
Do not waste your energy trying to determine who owns the ambiguous line item. More importantly, do not say, “That’s not my job”. Most importantly, do not ask, “How should I have known?” Neither of these approaches will evolve into a productive discussion. Your job in this scenario is as part of the project team. You know now how to avoid ambiguity in the future.
Use your energy to remain solution-focused and figure out next steps. The client will not want to hear excuses regarding your internal process issues; they will want to hear what the plan is.
Question 3: “Did You See That Email?”
ANSWER: If your developer is doing their job, likely not.
Client communication is a force to be reckoned with. If you have somehow managed to keep your clients to a scheduled and succinct communication, I applaud you. For the rest of us, may the inbox odds be ever in our favor.
Especially with technical engagements, granular hieroglyphic tech-speak is inevitable. As project managers, we can either
- Gather client correspondence, touch base with the appropriate developer (which requires finding time with the appropriate developer, who would naturally rather be developing), transcribe their feedback to aforementioned client correspondence, reply to client with transcribed feedback from developer, and repeat. OR…
- Interrupt the developer’s coding time and have them follow up directly to the client. While this saves budget and is more efficient, you’re disrupting their production time, therefore causing inefficiencies with development.
This forces the project manager to choose between what they may feel is a lesser of two evils.
While we may not be able to control the volume and velocity of incoming client communications, we are able to manage our outgoing communications. When in doubt, respond with acknowledgement. Let the client know you have received their message and that you’ll make sure the appropriate resource — if not yourself — will follow up as soon as they have an ideal stopping point. If communicated properly, the client will appreciate the mindfulness of your efficiency with their project’s progress.
Better yet: let the client know when they can expect to hear from your developer(s) each week. Perhaps you have your developer(s) use the first half hour of their day to follow up to comms so you’re able to provide your client a 24-hour turnaround expectation (with exception to business-critical items of course).
Question 4: “Can’t You Just Work One Hour On Each Of These 6 Clients Today, So We Can See Progress Across The Board For All Of Them?”
ANSWER: Yes, but that is a terrible idea.
Imagine reading the first chapter out of 6 different books — a couple of which are written in different languages you’re not as fluent in. You must keep the plots, characters, and backstories straight. The next day, you’re expected to read the second chapter of those 6 books while still keeping the plots, characters, and backstories straight. It won’t take long to realize the inefficiencies of this approach and the risk that goes along with jumping from one book to the next, to the next, and back again.
Ramp-up and ramp-down time absolutely need to be considered when allocating work to resources — especially for developers who may write in one language for one client and another for the next. While it may sting a bit to single- or double-thread a development resource (so other client work is having to wait their turn to be single-threaded), each chunk of work will be executed more efficiently.
Keep this in mind, too, when that “this will just take a second” support task comes rolling through the pipeline. The developer you slot that for on the side will have to ramp down from their current work, assess the support task, ramp up (which may entail leveraging other resources for context), address the task (and possibly run into some snags along the way), follow up with the appropriate individuals, potentially have additional tweaks from QA, ramp down, and finally return to their originally scheduled workload.
While it’s easy to get into the habit of telling resources what their workloads are, it makes a world of a difference to approach those resources, let them know what you may have in mind for their workload, get their feedback on where there may be opportunities to be efficient, and adjust accordingly.
Putting forth the extra effort toward mindfulness around communication and approach goes a long way. Avoid assumptions; avoid the blame game; avoid helicoptering; avoid micromanaging. Encourage productive collaborations and discussions around estimates; encourage education with requirements documentation and learn from past mistakes; encourage accountability and trust; encourage efficiency.
A project manager’s purpose is not to push papers, scribe notes, and play telephone. Our purpose is to facilitate collaboration and support both the project and client teams on a day-to-day basis, toward a shared goal. Keeping up those status updates, budget burn reports, and Gantt charts are just the beginning.
After all…as project managers, we really do make the world go ‘round.
What Do You Think?
Have you caught yourself asking some of these questions to your dev team? And what about the opposite? What questions should a dev never ask a PM? Let me know in the comments.