Resource Requestor

Term Definition
Resource Requestor is a simple reference to the person requesting a resource. In billing applications, a resource requestor would be a way to tag or identify the person requesting a system resource.

Software applications have audit trails. This trail enables system administrators to troubleshoot and repair any issues. The system does this by “tagging” activities and users so that errors, system breakdowns and even intentional fraud can be traced to the source. In example, Jane works in the Accounting Department of an IT consulting firm. Jane would like to check the status of work-in-progress on three projects. Jane logs into the system at 8:32 a.m. and defines the parameters of the report and then requests the report to be run. The system administrator logs into the system to do maintenance at 8:35 a.m. He wants to view any pending requests and sees that Jane's report is pending. The system administrator's report would list Jane as the Resource Requestor and would identify her by her login identification.

A resource requestor can also refer to someone requesting use of a resource for a project. Let's say that Ted is the project manager for a project that requires a system analyst. Ted logs into the time and billing application to find a system analyst that is available in two weeks for 2 days of project work. Ted would also like the system analyst to have additional skills, such as experience working with European companies, and no less than three years of experience. Ted first requests a report that will identify all available resources that meet his requirements. Ted finds three analysts that meet his needs. He checks the shared resources calendar and confirms availability. Ted then assigns Justin to his project. In this case, Ted is the resource requestor and the time and billing application would also identify Ted as such.

Area of Application
Time and Billing

Your Comments and Recommendations

Please help us improve the project management software glossary. Was this term well described? Any suggestions of how we can improve the description, what to add, remove or change? You can also use this form to suggest new project management terms we should add to the glossary.