Which are the true statements about a project leader?

• The role of a project leader is to create and follow the project’s Gantt Chart no matter what.
• A project leader’s main role is to hold meetings with their entire team to address and solve project issues while holding team members accountable during meetings.
• The project leader sole responsibility is to lead a project and provide updates to management.

Unfortunately, these statements are often viewed as the true role of a project leader. I’ve experienced and been a part of many teams where the above statements were truths. I’ve learned there is no magic formula or process that is foolproof in achieving a successful project outcome. Nor can any one training course prepare you for the myriad of circumstances that will manifest themselves during a project.

In this series of articles, I’ll touch upon several areas that I’ve found to be practical advice for project leaders. It may take some time for you to ‘master’ these, but the effort is well worth it. Hopefully, these lessons and approaches will benefit you in supporting or running your next project.

Team Members- Make or Break

Let’s start with the obvious. A project is only as good as it’s team. A good project leader will try to get the most talented team members to support the project, though, in many cases, the project leader doesn’t get to pick their team members. Rather, their team members are assigned without any say in the matter. Like the coach of a sports team, the project leader needs to assess the strengths and weaknesses of the assigned team members and figure out the best way to optimize their capabilities. This is key to ensuring they can successfully complete their task(s) with the most autonomy.

I was a project leader where the team members were assigned to the project without my input. In one particular project, I was given a packaging engineer that no one wanted to work with. Their reputation was one of being difficult to work with, their work was typically rifted with errors, and they were late delivering their designs, which often required numerous revisions. When they were assigned to my project, I was apprehensive, but what choice did I have? I had to make the best of it. ‘Good luck’, I was told. I knew I had my work cut out for me with this particular engineer, but I knew I had to make things work. When the project was done, the packaging was done early, there were no mistakes or revisions needed, and the packaging engineer wanted to work with me on my next project. What did I do differently than other project leaders to make this particular packaging engineer successful and, as a consequence, this aspect of the project? Here was my approach.

At the beginning of the project, I knew I needed to see exactly what the packaging engineer needed to do and what they needed to execute each of their tasks. To accomplish that, we sat down and laid out all of the packaging steps for the project Gantt chart. We drilled down so every decision, every step, was listed along with all of the inputs feeding into each step along with all of the outputs. As we identified each step, I asked them what were their concerns; what were the typical issues they encountered in completing that particular task. The engineer told me what they needed. I took note, asked a few questions as follow-ups, and ended by telling them I will help them in ensuring their concerns were proactively addressed; they had to make an honest effort to complete each task while I worked behind the scenes to make sure they got what they needed.

After telling the engineer that I was going to do this, imagine my shock when they were surprised at my response on several levels. First, that I actually asked about any concerns they may have and that I took an interest in ensuring they were addressed. They explained that when they told past project leaders what concerns they had the project leader either dismissed them outright, or said they will deal with them if and when they occurred. When the concern did occur, the project leader addressed the issue by putting the engineer on noticed that it was their responsibility to get the task done and intimidating them further with the typical “you need to make this date or I will be forced to tell your manager you’re holding up the project.” Seems like the project leader had a different interpretation of support than the engineer. All the project leader’s approach did was increase the engineer’s anxiety, causing them to rush, which only caused them to make more mistakes. Not the kind of support anyone would want from their project leader.

The difference between the packaging engineer’s past experience and their experience with my project was that I listened, verified their needs, and took note of their concerns. I was involved because, quite frankly, their success was my success; I had a vested interest in their performance. During the project I kept in touch with the engineer to ensure they had everything they needed, I also made sure what they needed was available when the time came. This meant working behind the scene with other team members and departments to get the information the packaging engineer needed but were in no position to do so.

Team Members- People Skills

Another issue that plays into this is that not everyone on your team has good people skills. They may come off to others as abrupt or indifferent. Traits such as these can negatively impact the support they need. As project leader, you need to recognize your team’s people skills and work to ensure they do not interfere with the project. This is something that is overlooked or ignore way too many times by project leaders. When an instance occurs, typical project leaders are quick to blame their team member. Do you think that helps you and the project? If there is a personality conflict you need to get involve early and work with both parties to ensure the situation does not escalate to the point of impacting the project. When I saw this in my projects, I would participate in the discussions to ensure things went smoothly. Being there as a mediator and as project leader showed both sides that I was aware of what was going on and that it was important enough to me that I was present. It sent the right message to everyone.

As project leader, you have the added flexibility and authority to get needed information and resources that team members would not necessarily be able to. Yes, team members would and should try themselves, as they should, but sometimes people do not respond the same to someone without authority as with someone who does have a level of authority. That is one difference a project leader can make in a project; opening up doors that may be closed to team members. Simply put, work to break down barriers to the project’s success.

In essence, as project leader, I made sure the path ahead for the packaging engineer was clear of obstacles and they were working with correct and accurate data. I also make sure I was clear on and understood their expectations by explaining back to them what they told me. This is a two-way street. Conversely, I explained what I needed from they, gave them my instructions and needs and made sure they understood me as well by summarizing what I requested of them. The result was a smooth problem-free packaging effort.

What I did was no magic formula or took special training or a high-priced training course. All I did was what I would expect from any project leader. As a team member, give me the right tools (data), help remove obstacles in my way before I get to them (get the data needed in time and/or alignment from other team members and support departments so they are ready), and support me along the way (listen to my needs and get me the needed assistance). As a project leader, your role is not to just lead but, more importantly, make the team members lives as easy as possible so they can focus on their jobs.

An analogy that may help you would be the general contractor (project leader) building a new home. The general contractor hires the necessary subs (always trying for ones they know are good and reliable- see the similarity here?) and starts the build. The sub-contractors will need to see the plans (Gantt chart) to see what is expected and when. Based upon the plans, they will let the general contractor know what materials they will need (data, suppliers, etc. or what materials they will supply) and what concerns (obstacles) they believe might impact their tasks. The general contractor then works to get the materials to the job site and make sure the building is ready for the sub-contractor when the time comes. If the general contractor doesn’t communicate properly with the sub-contractors, they may arrive at the job site before its ready for them or there’s confusion as to who was to supply the materials, or perform their job incorrectly. The result- the job is delayed, there could be misgivings between the sub-contractor and the general contractor (potentially ruining their business relationship (e.g.- the team member doesn’t want to work with that project leader in the future) and the project incurs cost overruns (management (future homeowners) are not happy) and delays.

A good project leader treats their team members as sub-contractors. Team members are given their tasks/roles in the project and they all go off and work on their assignments. The project leader in turn is the glue or general contractor that keeps everything moving in the right direction and stays one step ahead of team members.

Conclusion

It really comes down to being an honest, supportive, and involved project leader. This is your team; they are counting on you to help them get things done as much as you are counting on them; you cannot get the project done without them. It sounds trite but the Golden Rule applies here too. Treat your team members as you wish to be treated. Simple in concept, hard for some to grasp. Good luck.