Build out that Gantt chart
As a manager of a team of IT engineers, one of the toughest challenges is getting a handle on not only what everyone is working on, but what are all the seemingly unpredictable requests for work coming at your team. Thus whether you find yourself managing a new team or have been managing a team for some time but you are constantly being surprised with new requests out of left field, you may want to consider constructing a logical approach similar to what is being outlined in this series of articles to stop the surprises.
In the first article in this series, we identified the work request attributes of your team and built a list of sources of those requests. In the previous article, we put together an initial Gantt chart that lists all the work requests and projects by work phase and indicated which team member is work on which phase. Additionally, your team review of the chart increased its accuracy and improved your team’s level of engagement. This article will build on that initial chart and incorporate work estimation sheets as well as additional work considerations.
Merge Gantt with Work Estimations
Now that you have a list of all work requests and projects with resources assigned by phases plus a quick team review, now is a good time to take all those work estimation sheets and pull the data and plug the data into the Gantt chart. But first, we need to make a few decisions around how to account for time in the day.
If you are using a Gantt charting tool that has an option for defining the work hours in a day, you will need to determine the total number of hours that reflect a true workday for your work requests and projects. As I’ve covered before in part three, realistically, an engineer doesn’t have a full eight hours in a day to dedicate exclusively to project and work requests. With team meetings, HR activities like performance reviews, 1:1’s, training, holidays, time off, etc., your real working hours in a given day maybe more like five of six rather than eight.
If you re using my work estimation template I referred to in part seven of this series, then that template has the ability to incorporate a calculation to handle the real working hours in an average workday. More specifically, the total hour calculations are raw hours where as the “duration” or “contiguous work days” calculations are where the real working hours calculations come into effect. Make sure you are clear on how you are entering your hours for estimating phase durations to make sure you aren’t over or under calculating the length of the durations.
Linking or Sequencing Work Phases
After taking a brief pause and stretching from the cramping associated with all of the data entry you have just completed, now it is time to link or sequence the work phases. Depending on the Gantt chart tool you are using, there should be a way to link the work phases you entered to reflect the workflow over time. Using our example from the previous article, the sequence should reflect that work requests get completed in the following sequence:
Planning -> Design -> Development -> Testing -> Deployment -> Post-Deployment
Below is an example from Microsoft Project that shows this example from above:
Your Gantt chart tool should have some way to indicate that although both tasks can start after the “Design” phase is complete, (hypothetically for example purposes), the Biz development can’t start until a certain milestone is reached in the UI development. Similarly, “Testing” can’t start until both Biz and UI development is completed. In this more complex example, UI is estimated to take a few days more than Biz even though UI started before Biz:
Pause and Admire Your Work
Before you start analyzing the results, first, step back and look at your first draft team resource plan in Gantt chart form. I think you will agree that you now have a single, professional and authoritative report of what your team is currently engaged on work request and project-wise.
Back to Work, Sanity Checking the Chart
Enough basking in your resource management reporting superiority; now it is time to sanity check your chart. Beyond merely double checking that all your “Testing” phases currently appear after any and all “Development” phases, look for these specific abnormalities and take some action on them to improve the quality and accuracy of your chart:
- Do any of the same resources appear to be working on phases at the same time as phases in another work request or project?
If the answer is “yes” then don’t panic; this might not be wrong. It may reflect a resource winding down on one request and getting started on the next. But, if you have allocated a full “day” on request A and another full “day” on request B with one starting/stopping, you need to be sure that that indeed is the message you want to externally communicate. Please recall that the real goal of this Gantt chart is to “report” to external parties what you want them to see and understand about your team’s work. Thus, if you have been requested to work on two requests concurrently and the skill set needed to complete these two requests is contained within only one team member, then the overlap your report is showing is accurate. It maybe accurate but it might not be realistically achievable. There will be more on how to use this report to assist with rectifying this situation later.
- Do any resources appear to have large gaps of unassigned work requests?
If the answer is “yes” make sure you have entered all the estimation data correctly and verified your start and end dates. This may not be an error. Rather, this may indicate that a particular resource doesn’t have any formal project of request work to handle during that gap.
Sanity Checking the Chart with your Team
Similar to the previous article, this is another great opportunity to get feedback from your team. As I mentioned prior, in addition to increasing the quality of your chart, you will enjoy the side benefits of over all increased team engagement. If your team is highly technical, asking for feedback might not immediately resonate with them on how this helps them. If you simply ask:
Manager: Does this look right?
Highly Technically Focused Team Member: Yah, sure.
You may need to pull information out of them through more probing questions or consider challenging them on specific data in the report that looks a bit suspicious. Consider:
Manager: Does this look right?
Same Team Member: Yah, sure.
Manager: Ok, it looks like you are working on request 7648 and 7653 at the same time and from your estimates, it looks like both will be done next Friday.
Same Team Member: I can’t do them both at the same time.
Manager: Ok, which one makes sense to work on before the other?
Same Team Member: Oh, I have to do 7653 first since I’ll tweak the solution from 7653 to complete 7648.
Manager: So you need to work on 7653 first, exclusively, and then you can begin work on 7648?
Same Team Member: Yes.
Manager: Great, I‘ll adjust the chart to show that.
Based on the above exchange, adjusting the chart to show request 7653 starting and then ending before 7648 will now more accurately communicate what this team member is working on when and at what date specific work items are estimated to be completed. Additionally, you can note the technical dependency the one request has on the other in order to communicate that externally to interested parties. Lastly, the team member now leaves that conversation with a sense that the boss cares to an increased degree what he or she is working on. Hence another additional up tick in engagement from that team member.
At this point, you should have a rather accurate, through team review, Gantt chart reflecting all the major external work items your team is engaged on. In the next article, I’ll suggest ways to include internal work items like vacations and special assignments that involve your team’s time with considerations on how to reflect that work in amongst the external work in flight to give a even more complete view of your team’s work.