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.

This article focuses upon project execution. The points made will benefit project leaders in avoiding pitfalls that could impact a project’s success.

Now that you’re a project leader, your job is to get the project done as soon as possible and get it done right; management is already breathing down your back. Quickly, you assemble your team, you developed your plan, now what?

Hurry Up and Go Slow

It’s natural to want to push forward with your project as soon as possible. Action is everything, right? Management sees things happening, the team feels enthused, and all is right with the world. Stop. Action does not mean you are accomplishing anything, especially in the beginning of a project. Often, in a project, it is the decisions made in the beginning, that could mean success or failure for your project. What makes things more difficult, is when the planning is most critical- in the beginning- is when you know the least about what you need to do, or what issues you may be confronted with.

Let’s look at this further.

You have a project that will need to be run in several plants. When you get to the point in the project where you need to run tests in one of the plants, you discover that they do not have adequately trained personnel to perform the testing, or you find their testing equipment does not have the range to test your product. Suddenly your project is on hold, losing valuable time, when you can least afford it. Management was expecting this phase to be done- you told them in the last project update, remember?

This is where that rush in the beginning of a project sometimes backfires. I like to say ‘hurry up and go slow’. It is meant to convey that you should move a project along as quickly as you can but not at the sacrifice of thoroughly planning out the stages you need to execute; make quick but well-thought out decisions.

A well-planned project will go through various scenarios in the planning stages and pull in team members to find out what will be needed for each phase of the project. Even more valuable is to pull from each team member’s experience to see what issues other teams they were on ran into that you can guard against. This same approach would be useful to execute with the plants where you will be testing. Check that they have the trained personnel, the proper equipment, tooling, and capacity you will need. Each and all of these approaches help your team avoid delays that are avoidable through proper planning. Having a well detailed Gantt chart and thoroughly vetted resource needs will save your project from unexpected delays.

I’ve experienced teams that jump right into projects and assume resources will be there when they are needed, only to find that was not the case. It is for this reason teams need to carefully plan up front and be sure they have thoroughly planned out what is needed to be done and needed to be available so they can move smoothly through testing/validation, etc. to a successful product launch.

Forewarned is Forearmed

Planning also means getting out in front of the project’s schedule. This means letting whoever  is needed for upcoming tasks know that you are almost ready for them. I built my own home and hired and directed my own subcontractors. Things went smoothly during construction. The main reason for this was I would get with subcontractors weeks before they would be needed and review with them where things were. We would also go over what was needed to be done by them and what, if anything, they will need to get their job completed. This approach worked very well in ensuring the job site was ready for them. It was also useful that I gave them advance notice so my job could be scheduled into their schedule. Nothing is worse than when you need a subcontractor or a plant and they tell you they have other commitments and cannot make your date; they weren’t aware you needed them for those dates or times.

To avoid these situations, inform well ahead of time and review your needs and their needs to gain alignment.

Verify, don’t Assume

The worst thing you can do as a project leader is assume you have the materials and resources available when they are needed. Proper planning involves verifying material and resources are obtained or reserved for when the time comes to be used or employed. I’ve been in situations where we had purchased material for the project, only to have the plant use the project’s material for their own needs because they had ran short. We did not find this out until we went to start validations in the plant. They did not tell us nor did we check to make sure we had everything for the planned testing. It was a hard lesson for the project team to learn and it was an avoidable delay. You can imagine how management took the news that our project was delayed until we could get additional material.

Conclusion

Plan thoroughly in the beginning of a project, anticipate potential problems that are likely to occur, inform your resources prior to needing them, and gain their alignment as to timing and resource commitment. Verify materials and resources are available before they are needed. If you focus on these aspects of a project, the likelihood that you will have a smoothly running project will be high.

This article focuses upon practical advice for project leaders and project planning. I hope the points made will benefit you in supporting your current project or running your next project.

Now that you’re a project leader, your job is to get the project done as soon as possible and get it done right; management is already breathing down your back. Quickly, you assemble your team, now what? The next thing you need is a project plan; what needs to be done, what you need to do a task, when a task needs to be done, and who needs to do what.

The best way to accomplish this is with a Gantt Chart. As project leader, you need to develop a project plan for you and your team to track tasks, as a way for you and your team to see where things are with respect to the project deadline or product launch, and as a way for you, as project leader, to communicate to management how things are tracking. There are other uses for a project plan but these represent the main objectives.

Gantt Charts

A Gantt Chart is a bar chart used to show a visual timeline of a project and its tasks. It provides a step-by-step road map of the project’s timing, milestones, and overall timeline. In basic terms, it shows how the project will unfold. Many companies utilize Gantt Charts to control and monitor projects. They are a useful tool, but, like statistics, they are only as good as the inputs from which they’re constructed.

What’s ironic about a Gantt Chart is that it is supposed to show a detailed overview of the project but you compile the Gantt Chart in the beginning of a project when you know the least about what actually needs to be done, how long it will actually take, and what issues and obstacles you will face. In effect you are predicting the future that you hope will happen and the way and when it will happen. What’s worse, once you determine a completion date based upon this conjecture, management will expect you to make that date. For this reason, some project teams will fudge their completion date by padding the time allotted to individual steps to push out the projected completion date.

Being that a Gantt Chart is a projection of events in the future, it’s inevitable that a step is missed, or the time it takes to complete a task is underestimated. More often than not, this is compounded by teams not putting enough effort into compiling the Gantt Chart; they want to jump right in on the project. As a result, the Gantt Chart induces project errors because there is not enough steps delineated, unrealistic timing assigned to project steps, and not keeping the Gantt Chart up-to-date. Let’s take a closer look at these mistakes and what can be done about them.

Mistake #1- Not Enough Steps Delineated

Many teams will define general steps and gloss over the actual number of steps it takes to complete a task. For example, a company requires a protocol for any testing to be conducted. The protocol needs to be submitted for approval, which is defined in company documents as a minimum of 10 days. Once the protocol is approved, materials may need to be procured and time set aside in manufacturing to run the protocol. Lastly, the results must be compiled, analyzed, and a final report written, which is then approved. Here is a simplified summary of how the project team listed this in their Gantt Chart:

Immediately you see there is a problem. Let’s look at each step in the example. Will writing a protocol really take 3 days? Is all the information that needs to go into the protocol available on day one? If approval is allowed a minimum of 10 days, the Gantt Chart is only giving 5 days. If this 10-day minimum requirement is held, already the Gantt Chart is off 10 days- 5 days for the approval of the protocol and 5 days for the approval of the completion report. The section pertaining to running the protocol does not reflect:

• If manufacturing’s operators need training on the protocol,
• Extra contingency time if the protocol fails, and
• Time needed for procurement of material for the protocol.

The step related to the completion report lacks detail. The Gantt Chart’s completion report step does not provide for:

• Time needed if complex and time-consuming testing is required of the data collected,
• Any outside data analysis or testing, or
• Statistical analysis if there is complex data that requires significant time to analyze.

The steps omitted may have been caused by a lack of experience in knowing what needs to be done. This can throw a Gantt Chart off significantly. To avoid this type of oversight, rely upon your experienced team members. Talk to manufacturing to determine what they need to run the protocol. Make sure there isn’t a shutdown scheduled during the time set to run the protocol. Confirm that all key manufacturing personnel have not scheduled to be on holiday and there will be enough personnel available to execute the protocol.

Speak to those responsible for the completion report and any analysis needed. How much time do they feel they need? Is there anything that is a watchout you need to be aware of when it comes to doing the data analysis. One footnote to this. Does the protocol ask for all the data needed for the analysis and in the format the analyst needs?

As an aside, in considering approval, take the time to see what the approvers will be looking for. Ask team members if they had dealings with the approvers. If so, find out what the approvers look for in approving a document. If an approver may be out traveling, sick, or on holiday verify that their backup is willing to approve as an alternate and they are aware of and familiar with the protocol.

The best advice I can give you regarding Gantt Charts is don’t develop a Gantt Chart in a vacuum. The more those involved or will be involved in your project provide input to the Gantt Chart the more accurate and realistic it will be.

There are a lot of ‘what ifs’ to think about. Of course, you can’t be paranoid and include everything, but you can be realistic in what needs to be done and what will most likely occur. Talk to other teams that have done something similar and ask them what potential setbacks or issues they ran into and see if you need to compensate for them. There is no magic formula here. It comes down to being experienced with how things work in your company and knowing the people who will be involved and what their natural tendencies may or may not be. A Gantt Chart is an educated guess at the future, but you should be making honest realistic guesses and not ones that reflect a utopia scenario.

Mistake #2- Unrealistic Timing Assigned to Project Steps

As in the above example, it is easy to underestimate timing. Often timing is entered as wishful thinking. ‘We’ll push them to get it done within the dates we have’ or ‘I’ll talk to their manager to get them to focus on it.’ In either case, do you realistically think that will happen? Maybe once, but every time you need something done? More often than not, their cooperation will lessen over time. You can only call in so many markers. Is there a holiday during the time you will need to execute the step? Did you account for that? One thing I’ve seen played out time after time was expecting things to get done between Thanksgiving and New Years Day. Believe it or not, a lot of people take days off then. In Europe, it’s not unusual for a company to shut down for an extended period between Christmas and New Year’s. Workers tend to not be as productive either. I would tell my team that we would be lucky if anything got done during that period. Someone is out, an emergency order needs to be filled, equipment needs maintenance, etc. Be honest and realistic with timing. If not, it may cost you dearly in the end when you need to inform management that you will miss the promised date. That’s usually doesn’t bode well for the project leader.

Mistake #3- Gantt Chart is Inadequately Maintained

This seems such a simple thing to do but so often it is relegated to an intern to update or completely forgotten. Some project leaders treat the Gantt Chart as something carved in stone and refuse to accommodate changes. More than often that is because they promised a date to management and it’s the project leader who will be held accountable if they do not meet the date.

Updating and adjusting a Gantt Chart should be done weekly at minimum. Changes should be communicated upward. This is very important. You must keep management informed of the project status and any changes that would affect the deadline or project launch. Yes, you’ll take some heat for the changes, but, if you have a solid reason for the change and explain things so they are understood, management should be understanding. If you’re lucky they may even give you more resources, or help with the delay. It never hurts to be honest. Better to get it over with than to sweep things under the proverbial rug until the end. Management doesn’t like it when that happens, especially if they could have ameliorated the situation.

Another reason to keep a Gantt Chart updated is to understand what has to shift or how the current issue may cascade into future tasks that might have their timing impacted.

By maintaining the Gantt Chart, you can see the big picture and make adjustments accordingly to minimize the ‘damage’ to the schedule.

If you do have an intern or co-op handling the updates, be sure to check that they are capturing the adjustments properly and not causing issues themselves. Things can easily go from bad to worse through such a compounding of errors.

Conclusion

Gantt Charts are a very effective tool, but, like any tool, it has to be used properly to be the most effective. Gantt Charts are an excellent way to quickly determine the project’s critical path, seeing where your potential trouble spots are, helping to understand the tasks each team member is responsible for, and communicating the project’s progress. You maintain your car to ensure you can count on it to get you where you want to go. A Gantt Chart is your project’s car. Constantly monitor your Gantt Chart and diligently maintain your Gantt Chart. If you do this, your Gantt Chart will become an invaluable aid in successfully completing your project. You may also be surprised at how well you predicted the completion date!