Several years ago, I was a project manager on a custom software development project at a large company. The project team consisted of one business analyst, one tester, one programmer, and me. Within a week of the appointment, I scheduled a kickoff meeting with the team members to confirm roles and responsibilities, and to discuss the project in detail.

Two days into the project, one of them confided in me that our programmer was unhappy about my inclusion on the project. This was because he was a project lead in the first phase of the product, and hoped to assume full project management responsibility for subsequent releases. He felt it was unnecessary to bring in a project manager to lead the effort.

Weeks later, it became apparent that this was indeed the case. He was not only unfriendly, but he was often unwilling to share important information with me as I tried to gain a better understanding of the first project phase. Each time we had a discussion, I felt he was offering enough to get by, but omitting key details. Based on what I knew about his past involvement in the project, I wasn't surprised by his behavior. However, I was concerned about the impact it might have on the success of the project and the other team members. I couldn't understand why an individual would intentionally compromise the success of a project. I was not the employee's supervisor, so how would I manage the situation effectively?

First, I didn't want to take any official action against the programmer. I began to research the issue. I spoke with programmers from various companies and levels of experience to gain a better understanding of this kind of political relationship. What might alleviate the rift, I asked them, given that we had just met and neither of us really knew the other? How could I gain this person's respect? How could I impart the values of teamwork to this person? Although I did not receive any direct feedback regarding what I had or had not done correctly, those I had questioned were happy to share their thoughts on how project managers have gained their respect in the past. Here are some tips they offered:

Take the Time to Clarify the Process to the Programmers
Don't assume they all know your methodology and/or the associated tools and documentation. Project managers differ on their approaches; some may utilize a structured method, while others may "wing it." Don't make them guess what your style, methods, or approaches are.

Be Sure to Ask the Programmers to Clarify their Method for Providing Work Estimates
For example, when they advise you it will take "x" number of days to complete something, be sure you are speaking the same language. This will help you avoid any misunderstanding.

Don't Pretend to Possess Deep Technical Knowledge
Unless you are a project lead, it isn't necessary and doesn't necessarily add to your credibility as a project manager. Remember, your role is to manage the scope, schedule, and resources. While it is essential to have some understanding of the technical details, getting more involved than is necessary may make your technical experts feel that you mistrust their abilities.

Don't Overstate your Ability to Influence Change
Explain to the programmers what your role is and what limitations exist.

Demonstrate Backbone
If possible, actively prevent scope creep and avoid being railroaded. Your programmers will thank you, and your value will quickly become evident to them.

At some point, every project manager has had to earn the respect of a project team. The structure of an organization can have an impact on the authority a project manager wields. For example, in a functional or weak matrix environment, the project manager holds limited authority, and in some cases, may be referred to not as a project manager, but as a "project coordinator" or "project liaison." Conversely, in a strong matrix environment, the project manager wields a high level of authority to do what it takes to deliver the project successfully.

Be aware of where you fit on this scale, and communicate it to the team, so they have a clear understanding of your role. If you are in a weak matrix, your team members should know it, so they understand the limits that upper management has placed upon you. If you are in a strong matrix, the team will expect you to advocate for them more effectively, regarding schedule and scope. Be sure you do it!

Since I began adhering to the above principles, I have enjoyed greater success in forming solid partnerships with programmers. It has reinforced the importance of building a team foundation on technology projects. It begins with a kickoff meeting where the above points are covered in detail. Get to know your team and be open about your role. You'll enjoy better working relationships and greater success.