Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

Our developers work with VSTS using a scrum methodology and also with project server. Developers are required to enter their work hours in Project Server by time-sheets. However, they are not happy to complete their time sheets.

How can we convince them that both are important? Or should we stop using time-sheets? We need the time-sheet data for data analysis that we have them with Cube in Project Server.

share|improve this question
1  
It would help if you could explain the last sentence for those of us who don't use Cube in Project Server. It sounds however like there are two questions here - either you convince the Developers that timesheets have a value or you convince the stakeholders for the data analysis that the cost of collecting data from timesheets is higher than the value of the resulting analysis. –  Mark C. Wallace Jan 8 '13 at 13:16
    
For reference, worth to take a look, discussing about the 'hour granularity': pm.stackexchange.com/q/3376/430 –  Tiago Cardoso Jan 8 '13 at 17:58
add comment

2 Answers

Normally Devs complain if they feel their replicating work or doing something they don't see a point in.

In a previous role we had a time sheet system which required teams to enter their exact activity and it was resisted by most devs, however when we allowed them to enter their time at a high level (so X hours on Y project) they started to comply. If you are going down to a very low level of detail, is it really needed for your reporting?

If they feel they're duplicating work as progress is already logged in VSTS, I beleive there's various connectors for Project server which might be of benefit to you.

At the end of the day we need time recording to prove to management that the project was completed not only within any client or internal time constraints but within any internal budgets so it not a choice for them, we can make it as easy as possible but good time recording should be an objective that they are reviewed on.

share|improve this answer
    
Finding a connector sounds like a good idea. If the data needs to exist in both places then automatically sharing from VSTS to Project Server would be the best approach. Take a look at this page on the Microsoft Developer Network: msdn.microsoft.com/en-us/library/gg455680.aspx –  Willl Jan 9 '13 at 9:43
add comment

TL;DR

If the time reporting requirements are imposed externally (e.g. through contractual client requirements), then you need to communicate those reasons effectively to your team. If they are imposed internally by your own organization, then you need to examine your process carefully before deciding on your approach.

Determine Value for the Process

However, [the developers] are not happy to complete their time sheets. How can we convince them that both are important? Or should we stop using time-sheets?

On some projects, and in some organizations, labor costing needs to be calculated. This almost never has direct value to the people performing the actual work, though---it's a tracking metric for budgeting purposes or for management reporting.

This doesn't seem like it's the case for your project, though. The very fact that you ask if you should stop using time-sheets indicates that it is an optional metric. What exactly is the point of tracking something no one wants to report, and no one cares about if it isn't reported? That's called make-work!

Other Ways to Report Hours

If all your staff are on salary, then the time-sheets are irrelevant. All you really need to know is whether stuff is getting done, not whether Fred charged 7.25 hours to Project X and 12.5 hours to Project Y---unless your organization forces you to track that way.

Perhaps you can simply say something like:

  1. We had X people working full time on the features delivered this iteration.
  2. This milestone took the efforts of the entire team over the past 30 days.

The trade-off is that you can calculate labor costs at a macro level in seconds, but you can't get at the granular details. Perhaps this is sufficient for your purposes.

Alternatively, if all your people are hourly contractors, they need to give you an invoice or statement of hours anyway. Why not just use that, instead of requiring additional book-keeping? Again, the trade-off is simplicity vs. granularity.

Unless you're doing complex accounting for matrixed teams who are simultaneously charging against multiple projects, why make the time reporting any more complicated than it needs to be? Just track your labor burn-rate against your project's budget and call it good.

Possible X/Y Problem

While a project manager with budget-tracking responsibility needs to track labor rates on a project, how you track it and the level of detail you track depend on what you're solving for. Before doing anything else, you need to figure out why you need this information, and how you plan to use it.

It has been my personal experience that this level of granularity is often used as a proxy (or worse, as a stand-in) for measuring productivity on a project. More hours charged to a project doesn't equate to faster delivery, nor do fewer hours intrinsically equate to process efficiencies.

For example, a spike in hours might be a project smell indicating hidden process problems, increased complexity, or a higher defect rate. Then again, maybe not. As a metric, tracking hours only directly correlates to money spent on labor; by itself, it tells you nothing about the status of a project's deliverables.

Think carefully about why you want or need to track hours the way you do. If you can't come up with a good reason for it other than "just because," neither can your development team.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.