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.
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 believe 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.
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.
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!
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:
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.
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.
