Slow timesheets: a step-by-step Project Server diagnosis
When timesheets take 14 seconds to open, teams end up not filling them in. The problem is often solved in a day, as long as you search methodically.
- 1Measure14 s to open, for everyone
- 2Isolateserver and network normal, database indexes fragmented
- 3Fixindexes rebuilt, after a backup
- 4Check2 s, with the team
Slow timesheets are more than an inconvenience. Every second of waiting discourages entry, and poorly entered time distorts all of the steering. Here is the approach we follow, on a typical request.
1. Measure
On Monday morning, the project office reports that timesheets are slow to open. First step: measure. Opening a timesheet takes 14 seconds, for every user, at any time of day. So it is neither one computer nor a load peak.
2. Isolate
Next, each link in the chain is checked: the application server responds normally, and so does the network. That leaves the database. By late morning, the diagnosis is in: its indexes are fragmented, and every timesheet opening reads far more data than it needs.
3. Fix, after a backup
The indexes are rebuilt at the end of the day, outside entry hours, and always after a verified backup. If anything goes wrong, you roll back without loss.
4. Check with the team
The next day, the fix is checked with the people who enter time, on the week's timesheets: opening takes 2 seconds. The request is only closed after that check, with a report and advice to keep it from coming back.
Key points
- measure before fixing, to know what you are looking for;
- isolate link by link rather than changing everything;
- only close after a check with the users.