Proposed Web Request System Upgrades    September 26, 2008   

PROPOSED WEB REQUEST SYSTEM UPGRADES 
Steve Farkas and Jane Muder 
 

Over the next month, the UPMC Web strategy team will undergo an organizational 
change as our senior manager, Mark McDade, will be leaving the department. We 
recommend that the following changes be implemented prior to Mark’s departure so 
that issues halting or delaying completion of Web requests can be reduced or 
eliminated. Through this proposal, we hope we can shorten the request‐to‐live time for 
Web Strategy’s clients and optimize Web Strategy’s workflow. 

 Below is a list of proposed goals to accomplish Web Strategy’s objectives for increased 
efficiency and service quality, and suggested methods for accomplishing said goals: 

 
Handle high priority requests better 

• Eliminate pre‐empting of requests 
• Add preference field for requests 
• Add field for request due date 
• Allow clients to know who is handling their requests 
• Add hidden priority field 

Eliminate request “purgatory” 

• Update Web Request Policy to better serve the needs of both Web strategy 
team members and our clients 

Enhance user interface functionality 

• Add sorting functionality to report data grids 
• Eliminate unexpected request description field truncation 
• Pull Mark from the E‐mail flow 
 

  Page 1 of 5 
Proposed Web Request System Upgrades    September 26, 2008   

 
Eliminate pre‐empting of requests 
 
Web strategy team members encounter clients who pre‐empt official Web requests by 
selecting the team member they wish to work on the request, regardless of whether 
that individual was actually assigned the request. While it is understood that rush 
processing requires faster reactions, this is not the most effective way to handle the 
problem in all cases.  

Because pre‐empting causes confusion and duplication of work among staff, we suggest 
including a disclaimer on the request forms stating: 

1. Expected turnaround time for assigned requests. 
2. The policy for assigning them in a timely fashion. 

 Clients who attempt to pre‐empt requests can then be directed to this policy. The 
policy can also be used for clients who pre‐empt publishing by pulling requests. 

Add preference field for requests 
 
Sometimes, the client prefers his or her request to be handled by a certain member of 
the Web strategy team, based on that member’s experience in dealing with that client’s 
materials. 
 
We suggest adding one field containing a dropdown of possible Web strategy team 
members to be determined during the submission process by the requestor, including 
the option of “no preference”. This field can be added to the request form and 
database. The request coordinator may or may not then assign the request to the 
requested Web strategy team member. This allows the request coordinator to quickly 
and accurately assign incoming requests.  
  
 

  Page 2 of 5 
Proposed Web Request System Upgrades    September 26, 2008   

Add field for request due date 

Clients very rarely include due dates for their requests because, with exception to the 
general description field, there is no indication that a due date should be submitted with 
a request. While many requests are not urgent, those that are should be priority. 
Unfortunately, unless clients specify due dates in the text of their requests, the Web 
request assigner has little mechanism for prioritizing requests. 

By adding a date field object to the Web request form, clients can help the request 
coordinator prioritize requests. The need for this function has become especially 
apparent during periods when several staff members, as a result of vacation, illness, or 
offsite training, are absent. 

An internal system that will allow the Web assigner to rank requests, according to need 
for rush processing, or lack of same, will allow for greater control over assignments.  

Allow clients to know who is handling their requests 

It has been mentioned that clients can feel greater control over the request process and 
deliver materials to web team member if they know, upon the time of assignment, who 
is handling their requests. Since a message is sent to the client when the request is 
assigned, it should be of very little challenge to incorporate a variable for the team 
member’s name into that message.  

Add hidden priority field 

It is already within the capabilities of the Web Request System’s relational database to 
modify the priority of a web request. In order to manage high priority web requests 
more effectively, Mark has suggested that we add a priority field with the options of 
Low, Medium, and High (Like a blender!), that is not viewable or modifiable by the 
client.  

  Page 3 of 5 
Proposed Web Request System Upgrades    September 26, 2008   

Pull Mark from the E‐mail flow 

In a successful effort over a year ago to significantly drop the overall time for each 
request to be processed, the request system was programmed to CC Mark McDade on 
each and every request when the request was made, assigned, and completed. Also, 
Mark’s name and contact information appears on each e‐mail transmission. Since this 
endeavor was a success and no longer necessary, and since all members of Web 
Strategy have access to all requests by default, CC’ing any single member on every 
request is nonessential. Mark has suggested that we remove all CCs to his email address 
and also that we remove his name and contact information from the form.  

Update Web request policy  

Sometimes, despite the best efforts of Web strategy team members, client projects sit 
unpublished for days or even weeks. We have found that this is partially because it is 
not clear to clients that DEV sites are not being published. A brief explanation of the 
publishing process on each request form can provide clarity to clients and speed up the 
publishing process for all involved. Ideally, the explanation would let clients know that 
they must approve all beta changes before any page or site can be pushed live. 

Several members of the Web strategy team have handled requests that featured 
unfinished or unedited copy. It is our recommendation that clients who do not have 
Web‐ready copy take steps to resolve the issue before expecting Web changes. We 
propose the following initiative: 

1. If copy is in need of light edits but not legal scrutiny, Jane Muder (or other team 
members) can provide light editing services. We can include a box on the request 
form indicating a preference for light editing. This option is useful in promoting 
UPMC’s brand by adding another safeguard against publishing incorrect content. 
This change can also help to promote internal awareness of content appearing on 
our Web sites.  

2. If copy has not been finalized or approved, clients can check another box, which will 
indicate to the client and to the Web assigner that team members are not to place 
copy onto beta sites until the copy has been finalized. This option is essential to the 
timely completion of Web requests. 

 
 

  Page 4 of 5 
Proposed Web Request System Upgrades    September 26, 2008   

Add sorting functionality to report data grids 
 
In order to increase the usefulness of the Web request reporting system, the ability to 
sort by date, department, or name will be valuable in identifying languishing requests. 
We suggest modifying the data‐grid to be sorted by all fields using the Microsoft 
ASP.NET AJAX Control Toolkit; the following three fields are most important:  
 
• Name (Requestor) 
• Department 
• Date 

Eliminate unexpected request description field truncation 
 
Usually, lengthy and detail‐rich requests exceed description form character limits. 
Instead of providing any sort of feedback to the requestor, the text is truncated to the 
maximum allowable characters. The remainder of this text must be requested by the 
assigned team member. If the requestor does not have a duplicate copy of the text, it 
must be re‐typed from scratch, which delays results for the requestor. 
 
We recommend using the Microsoft ASP.NET AJAX control toolkit to add a visual 
indicator, triggered by JavaScript, to show the number of remaining characters allowed 
to be entered into the form field when that number is less than 100. The script can 
display a pop‐up confirmation box if the number of characters entered into the form is 
exactly equal to the total number of allowed characters.  
 
 
 
 
 
 
 
 
 
 
 
 
 

  Page 5 of 5 
Proposed Web Request System Upgrades    September 26, 2008   

Proposed Timeline for Implementation 

Due to hurdles in allocating stage environments for dynamic Web applications, such as 
the Web Request Form, and the risks of disabling the system by deploying premature 
code, it is suggested that these changes be made in two stages: 

• Short term: < 30 Days 
Copy changes to the Form’s use policy; AJAX Control added to eliminate 
description field character truncation, report sorting functionality 

• Long Term: 60‐90 Days 
Due date field; rush processing option; text review option, team member 
preference field 

  Page 6 of 5