Knowing that project managers will be in direct competition with one another for the best staff to work on their projects, it seems illogical that the relationship between the PM role and the functional manager role is as poor as it is in many organizations.  Improving relationships is rarely a one-sided effort, but to quote Miyagi-san: “Best way to avoid a punch, no be there“.

Here are a few suggestions to make friends and influence people:

1. Satisfaction = Perception – Expectations.  If you don’t set expectations with functional managers regarding normal “rules of engagement”, don’t be surprised if their perception of your interactions is not favorable.
2. Avoid surprises.  It sounds boring, but predictability will be appreciated by functional managers as it removes at least one element of uncertainty from their daily routine.  The more proactive you are at communicating changes to expected demand for their staff, the better they can address the impacts of such changes.
3. What else is going on?  If multitasking is inevitable, at least understand what else the team members you have been given will be expected to work on, and make sure you get a clear understanding of what the functional manager feels is the #1 priority for each of those team members.
4. Use staff wisely.  Nothing is as frustrating to a functional manager as finding out that the staff they allocated to a project (usually at the expense of other projects) are being used ineffectively.  Sometimes this is a valid complaint, but going back to point #1 above, if you haven’t taken the time to walk the functional manager through the specific activities that their staff will be working on AND if you haven’t regularly stayed in touch with them to reinforce the importance of this work, the frustration might be the result of poor perception.
5. Let them know how their staff did.  Whether your organization has a formal team member evaluation process or not, something as simple as a quick e-mail message (or better yet, a handwritten note) thanking them for their staff’s participation and providing constructive feedback on what went well and what could be improved is likely to be appreciated.
6. Find out how YOU did.  Once the dust has settled during project closeout, but before you move on to your next project, meet briefly with each of your key functional managers and ask them how they felt things were.  That way, if there are specific areas of concern, you have the ability to address those with them the next time you will be drawing on their resources.

While project and functional manager interactions often feels like the cartoon conflict between Ralph E. Wolf and Sam Sheepdog, just remember that even those characters were able to “punch out” at day’s end and maintain an overall amicable relationship!

Here is an approach that could be used in those situations where a governance structure is not obvious.

1. Identify stakeholders
2. Select a suitable sponsor (or sponsors) from the list of stakeholders
3. Decide whether there is sufficient rationale for establishing a steering committee and work with the sponsor to pick its members from the list of remaining stakeholders or from the leadership layer above the sponsor(s).

There has been enough written about stakeholder identification and analysis, so there should be no need to elaborate on that activity.

The traditional view of a sponsor is the person or group that provides the funding and who authorizes the existence of the project through the issuance of the project charter.  However, sometimes funding does not come from the sponsor, especially if the project is serving the needs of multiple functional areas.  In such situations, the sponsor can be the stakeholder that has the most political visibility, influence and capacity to be an effective champion for the project.

On enterprise-level projects, if a single sponsor cannot effectively champion it for the full organization, it is advisable to have this role shared by a small group of stakeholders.  The caveat with this approach is that the balancing benefits of a sponsor group are offset by the risks of dilution by committee.

It is critical to ensure a good working relationship between the project manager and sponsor – some conflict or difference of opinion is healthy but if the two roles are constantly at odds, the project will suffer.  Before finalizing decisions on either role, the current working relationship between the two should be evaluated to increase the odds of success.

On smaller projects, decision-making authority could solely reside with the sponsor.  But on larger projects or those that have broad cross-functional implications, vesting too much authority with one individual might not be advisable hence a steering committee might make sense.  Also, on those projects that have a sponsors group, a steering committee can address those situations where the sponsors are deadlocked or can make decisions that are above or outside the authority-level of the sponsors.

The steering committee is expected to be a decision-making body and not just a group of stakeholders who need to be kept in the loop.  The focus should be on picking the bare minimum set of stakeholders who possess formal authority over the project while at the same time ensuring that individual (or departmental) biases will not skew decision making.  On projects involving multiple organizations, the steering committee should ideally have balanced representation from each organization.

When due diligence is not used when defining project governance, the project is as much at risk as if the project team is poorly resourced.

So what happens when decision makers insist on trying to deliver fixed scope with unrealistically low timelines and resources?  A common outcome is that something gives – either scope is only partially delivered, quality suffers or schedule and cost baselines are exceeded.  What’s interesting is that when such project overruns are analyzed, many times we see that the final actuals are in fact fairly close to what the initial estimates were.

Is this a self-fulfilling prophecy on the part of team members?  Sometimes it can be – if the team is not convinced that their objective is achievable, there’s a good chance that they will fail.

But in many instances, it is caused by the analogy I’ve used in this article’s title – like a spring, a project can be compressed.  But after a certain point, sufficient linear restoring force has built up that the spring will return (usually violently!) to its original size.

But let’s not ignore the reality that a project needs constraints.  Without these, it consumes resources indefinitely without delivering proportional value.  Like a spring, you can stretch a project to a defined extent, but once elastic potential energy has exceeded the spring’s design, it will either snap or be permanently deformed.

As project managers, one of our responsibilities is to facilitate appropriate decision making.  If your attempts to convey the impossibility of a requested project scenario are falling on deaf ears, leverage the power of analogy, and illustrate your concerns by using a toy spring.