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:
Step | Duration | Start Date | End Date |
---|---|---|---|
Write Protocol | 3 days | Monday 6 Feb | Wednesday, 8 Feb |
Protocol Approval | 5 days | Thursday, 9 Feb | Wednesday, 15 Feb |
Run Protocol | 10 days | Thursday, 16 Feb | Wednesday, 1 Mar |
Completion Report | 3 days | Thursday, 2 Mar | Monday, 6 Mar |
Approval | 5 days | Tuesday, 7 Mar | Monday, 13 Mar |
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:
The step related to the completion report lacks detail. The Gantt Chart’s completion report step does not provide for:
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!
Eric Hinrichs has more than 31 years in the medical device field in research and development on new products and processes, in operations on improving processes, and in quality on leading process and product validations and performing data analysis. He developed and led the implementation of numerous process redesigns while at Ethicon to improve product support execution. Eric authored an ASTM standard, worked on updates to United States Pharmacopeia (USP) medical standards, and helped develop new medical standards for the European Association of the Surgical Suture Industry (EASSI) in Europe. He has also co-authored a medical standard for India that is currently under consideration for adoption. He recently released a book on career advice, Perceptions and Expectations.