8/24/2011

Report Overload

Working in a Reporting Services department, I get to work on a lot of reports.

So many reports, in fact, that we are now on "report overload".

How did this happen?

Well, we have existing reports in production that need tweaks/bug fixes.

We have incoming request for new reports.

We have existing projects in flight.

We have new projects on the wings.

We have the emails for quick reports.

We have the stop what you are doing now and do this report.

We have the "holy cow" this report is broken, please fix it ASAP.

As you can see, managing the report queue can be quite a task.

I see a few things that could be changed to better manage this.

First, there is no control mechanism to determine which projects get approved. Every report project request gets approved no matter how long it takes or how many resources are available or what the deadline.

Second, there are not enough trained resources to contend with the work load.

Third, every customer thinks their request is #1, top priority.

So how do we manage this environment?

Well, first off we need to get a better handle on the workload. By identifying the volume of work, assigning hours to it, prioritize the request and assign based on available resources.

Then implement "status reports" from all the report developers.

And get management's buy-in to mold the environment so the customer's expectations are in line with reality.

Train the developer's to produce better code in less time.

Perhaps have one developer work on bug fixes and the other work on projects. And then rotate rolls.

Have the DBA's give the developers a quick tutorial on all the recent database changes for "best practices".

I'm open to suggestions here. I don't have all the answers.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.

Thoughts to Ponder