Should I ask developers to report hours in daily reports or ask them to keep the task tracking tool we use with this level of detail?

Question

I am the IT manager in a company having 30 people in the IT team. There are 3 major teams, each with 7 to 8 people, + few other smaller teams. Different locations, cultures and timezones.

Having progress issues with one of the projects, I am willing to improve the team efficiency.

Until now, we were using OpenProject for project management. It worked well, although the layout is not the best for task presentations.

Now, we decided to switch on Zoho, which is a paid product, offering some widgets like time tracking etc.

Currently, I am asking all team members to send me a daily email report of their activities. I am making a resumee and sending a general report to the senior management team so that they can have a general overview.

As we will use Zoho now, my idea was to stop asking them to send daily email reports, instead they need to report on Zoho by keeping their tasks updated on daily basis, so we can easily track what an IT did during its day.

Question: Is it better to ask the devs to continue sending the email by adding the amount of the working hours spent on every task, or to ask them to track hours using Zoho and rely on Zoho to assist me in tracking hours? Is the hourly base measuring applicable in IT?

In reality, the reporting workflow of a developer will be:

1. Update the status of the tasks assigned to me
2. Enter how many hours did I worked on that task on a specific day
3. Update the completion percentage of the tasks

Answer 1

I'd expand on Joel BC answer - 'why' is the key, and being from a very similar environment (multi location / cultural place with hundreds of people reporting to a single head) I believe that understanding why such report is required is the key to define whether the proposed approaches will succeed or fail.

I believe that understanding the target audience, can give you a better idea on whether your reporting will be useful or not:

• Senior management: what they're likely to be interested at is that the high level goals are progressing or having enough attention - so instead of a report explaining where each of the 30 members are working with, he might be interested to know that 50% is working on A, 25% on B and 25% on C and that the whole capacity is being utilized. This report can be derived from the end of day updates provided by dev.
• Intermediate management level (your position, I assume): they're likely interested to know that the expected activities are being covered and that no blockers are in place.
• Team level (the team can benefit from knowing what peers are working on it, specially on a multi-location team): In this sense, the daily catch up meeting is interesting, but there's a problem if you have like us people in, let's say, US, UK and JP - there's simply no good window time these 3 teams overlaps. And for these cases, we're pretty much doing what you mention... keeping our task systems as updated as possible.

All in all, is important to ensure that the Dev team is aware of why they have to do it and senior management needs to know how they want to use this information - taking into account that Documentation is hated by developers, and logging time and tracking progress is, at some level, documentation.

Answer 2

Start with the "why". What information exactly is it that Senior Management is looking for. What are they using that information for?

It could be as simple as wanting to see progress, or open to closed incidents. Until you know exactly what the information is for, you'll be doing a lot of wheel spinning. For example, I started at one company and they had a 100 slide deck that "had" to be updated every week. I spent time talking to all the audience of the deck and after a few weeks replaced the 100 slide deck with a single excel spreadsheet. They were more than happy with what they got.

Once you understand the "Why" you can look into the "How".

Electronic tools will never beat real time communication. In addition, asking individuals to report can cause all sorts of issues, not the least of which is you no longer have a team, you have a bunch of individuals all focused on what they got done.

If possible, I'd advocate each of your smaller teams meets in a daily meeting of no more than 15 minutes. Review progress, discuss blockers and then create an aggregated report for that team. If, for example, what management cares about is progress to a final project figure out how many known tasks there are and use that to create a burndown report. Every day you report how many tasks were completed to the goal and show the progress with a burndown report.

It may sound like I'm advocating for an agile style. What I'm really advocating is for simple communication tools and techniques that work. They just happen to be common in agile projects.

Answer 3

It looks like you're doing the right thing by moving to an automated system of sorts.

The thing that will be most up to date will be the code and the Pull Requests or the patches that are proposed. The issues, tasks and time tracking linked to that won't always be the most up to date so if it's important, you're going to have to sit down and ping each developer and ask them for updates or you're going to have to train them to get into the habit so it doesn't feel like a chore.

So if you can read code or keep track of what changes are being made and see the progress that way, you can ask developers for a few sentences of information and that will be enough to make sure the project is on track.

Your goal as PM is to make sure things go smoothly and that includes asking for updates, but it also means hiding or automating some of the administrative work so that the developers can do their jobs.

Answer 4

Well.. Your question caption states that you're wondering if you should use daily reports in your team, however as it turns out to be, you cannot decline using such the reports and the issue is actually in the reporting format. Either this would be a simple mail or a work log in Zoho.

I believe that the last one would be the best way since:

1. Your team should learn how to communicate their deliverables in the modern world.
2. You as a manager should take advantages of the dedicated management software and avoid doublework in any aspect.
3. Zoho supports REST API so I think that your devs will find the best way of delivering daily reports (e.g. some small cmd comman that will let put a report to a work-log to a task without any annoying web-serfing)