TL;DR
You've framed your question as an interpersonal issue, with the presumption that it has to do with your delegated authority within your organizational framework. This is an assumption, which we'll talk about shortly.
Even if we accept the premise that this is an issue of your authority, it is not necessarily a personal or interpersonal issue. Since a project manager's scope of responsibility is to apply controls to a project, any failure to control for known issues within a project may affect the success of the project. It is therefore better to frame the issue in a project context rather than an interpersonal one.
Furthermore, project managers are often responsible for a project's process, and for managing communications within the project and among its processes. Those are generally areas that receive less attention than budget and schedule—and certainly less than politics and issues of positional authority.
With all of this in mind, I recommend that you inspect your project's processes and communications. If you find gaps or failures in either, you can then work with the project team to adapt them as needed.
Documenting Assumptions is Valuable
This question, as currently posted, is plagued with assumptions. It contains assumptions on your part, as well as forcing the reader to make assumptions about the roles, authority, and context of your situation. In the interests of answering the question as originally posted, I will therefore document some foundational assumptions to enable an answer. The assumptions are:
- You are making ad-hoc requests of developers which are not part of their currently assigned tasks.
- You have the authority to assign ad-hoc tasks within your project.
- The developers have a responsibility (however delegated) to respond to your requests.
- You are making your requests in socially, politcally, and organizationally appropriate ways.
- Your developers are giving you what they believe are contextually-appropriate answers, rather than saying RTFM or "up yours!"
If any of these assumptions are false, then the answer will be left as-is for future visitors, but you may need to revise your question to more accurately reflect your given circumstances.
How to Solve for Process and Communications Failures
Since we're assuming, a priori, that you genuinely need the information handed to you by the developers and that everyone is asking and answering in what they think are appropriate ways, then we are left with the presumption that there is a process or communications failure at work here. Let's look at both possibilities.
Process Failures
You are under time pressure to deliver something (e.g. a report or other project artifact) and therefore need something from the developers. However, unless this task was assigned in the standard way for your project, you are creating time pressure and schedule risk for the developers (and therefore the project) by asking them to:
Task-switch.
Task-switching can have a huge negative impact on cognitive flow in knowledge work. It isn't merely the time it takes to switch gears; this also involves cognitive disruption, and creates cognitive load as the knowledge worker shifts context to another task. As a one-off, this isn't a project-killer, but team capacity generally drops as task-switching and cognitive load increase.
Shift capacity.
Your requests essentially require that developers shift a portion of their available capacity from whatever they was working on, or whatever milestones were set for them at this stage of the project, towards something else. This has a direct cost to the project, as projects generally have finite capacity. This may also have knock-on effects if any dependent tasks are affected by a team member's reduced capacity.
It doesn't take much reduction in team capacity to affect a schedule. As many organizations fall prey to the 100% utilization fallacy, it doesn't take much variance in individual or team capacity to throw a project out of tolerance. Even if your project schedule provides some slack, you need to consider how much impact these requests cumulatively have on the available slack, or whether the reduced capacity simply creates more pressure to meet deadlines despite insufficient slack.
Perform invisible work.
Since this request isn't part of the project schedule, and presumably isn't tracked as a project deliverable, you are asking the developer to switch from a visible task that he is held accountable for to an "invisible" task that won't be immediately visible to the stakeholders or his line manager. As these types of requests can add up quickly, you may be creating more "off the books" work than you think.
There is never an easy answer for process failures, as they are (by definition) systemic in nature. However, you may be able to inspect-and-adapt your process in one or more of the following ways:
- Bundle up requests to reduce task-switching overhead.
- Ensure documentation, reporting, and research tasks are accounted for within the project schedule. Slack is fine, but having explicit tasks on the project schedule for things you can plan for (like reports or documentation) is even better.
- Ensure you have sufficient slack in your capacity planning and your scheduling to account for unplanned/unscheduled tasks. Remember too that you need to add slack for the time it takes to get back on track when flow is broken, and not just budget for the tasks themselves.
- Ensure all requests are tracked by the project. CodeGnome's Law says: "No invisible work, ever!"
There may be other ways to fix the process, too. Discuss it with the developers, and see what you can work out!
Communications Failures
This is actually a much more complicated issue with many more variables than a potential process failure. However, we can roll most of it up into two key areas: context and transparency.
Context
You have a context regarding what you need, what the project needs, and what everyone's roles are. This may not be a shared context.
In addition, the developers have a context as well. You may or may not understand the developers' context, or have a full understanding of what their perceptions and motivations are within your mutual context.
You probably ought to discuss those things together.
Transparency
At a process level, you may lack visibility into what the developers are doing and what pressures they are under. The reverse is almost certainly true: developers rarely have insight into what project managers are doing, or the impact that anything has on the project outside their assigned responsibilities.
From a communications standpoint, what's missing is transparency. You and the development team may need to communicate more effectively about pressures on the project as a whole, and about how those pressures affect the team. It may also help to have more transparency about the organization, including the chain of command and lines of delegated authority.
The only way to improve transparency from a communications standpoint is to talk about things explicitly, rather than relying on shared context or assumed frames of reference. Perhaps you feel that you shouldn't have to haul certain things out in the open and talk about them, but unless you do they will remain opaque problems for all parties involved.
So, talk about things. Together!
There are certainly other types of communications failures. Perhaps you will uncover some of them as you dig further. In the end, though, the solution will almost always start with talking more openly, and ensuring that issues are discussed in an explicitly-shared context.
