Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How do you enforce users to keep statuses up to date on your apps.....

Status
Not open for further replies.

Pack10

Programmer
Feb 3, 2010
495
US
I know this is a wierd request but we are developing an application for an area that corresponds with another area in the organization. A request comes to them, but our group does the work. We are developing an application to track the progress on the task. The actual work is done outside the app, lots of email goes back and forth. It does get hectic for the users. We track the status of the progress of the work. We are afraid the users won't keep the status updated and are interested in any ideas that others have who have a similar situation. How do you enforce users to use the applications you build.
 



hi,

Who are the we and they?

"but our group does the work" so do YOU, your group, update the status? "We track the status of the progress of the work" seems like you do status the progress.

But then "the users won't keep the status updated." THAT is where it gets confusing!!!


Skip,

[glasses]Just traded in my old subtlety...
for a NUANCE![tongue]
 
Sorry...for the poorly written description. We have a dept (Client Svcs) that deals with the customer base. They get requests from the customers for certain things...My department consists of a group of workerbees that does those tasks. There is some back and forth between the customer service people and workerbees. Sometimes someone from one group or the other is sitting on an item...and the customer is looking for the completed task. An item being worked on can be in one of several statuses. We are trying to get our arms around how to enforce the workerbees to keep the statuses updated. But it is a very helter-skelter business and they often in the past while working in other databases failed to keep the statuses updated. Management is looking to do timelines on how long something was in a status.
Short of writing the up for not keeping statuses updated, we are looking for any ideas besides chopping off hands!!!! to keep them
on track. Hope this clears it up.
 
Pack10,
There are templates on MS Office Online for such db's, one is called "Issues", there are probably other's that fit the general "help desk" type of application.

Or, something like "Footprints" which is a browser-based solution might work for you. But if you're building it in Access, I'd start with one of those templates.

And remember--with something like this there's only so much software can do--good management is the key to making things like this work so you need someone who has enforcement power to get people to update these systems on a timely basis. Again--the problem with these things is usually management, not software.
--Jim
 


If someone is required to do something, but their management is not using that something as a measure of their performance, then ther is little that you can do short of persuasion, to enforce compliance.

Skip,

[glasses]Just traded in my old subtlety...
for a NUANCE![tongue]
 

If you have an application that is hard to use: if user has to login in, go thru several Forms to get to the checkbox or place where to enter the date or something, then log out – they will not use it because it take too much time and effort. Also, if users do not see any benefits of updating the statuses, only management cares about it, then users will be less likely do it in a timely manner.

Have fun.

---- Andy
 

A baseball bat to the knees works wonders, and you generally only have to use it once before the others fall in line.

You can get much farther with a kind word and a gun than you can with a kind word alone.
-- Al Capone

Seriously, I fully agree with the others. If there is no accountability from managemet, there is nothing you can do.
 


Amen!

For instance, just yesterday I went to get the status on a Help Desk Trouble Ticket. The FORM wanted my UserID AND ALSO Last, First, Phone, eMail, Business Unit, ALL of which can be obtained with the UserID.

I sent them a nasty-gram instead! STUPID!

Skip,

[glasses]Just traded in my old subtlety...
for a NUANCE![tongue]
 
Better software definitely makes it easier. But it's all relative--people used to have to hammer a chisel into stone, then came the pencil, typwriter, etc.

Regardless of the tools one may be stuck with, a good manager will make sure it gets done, period. If you're told to put a cover sheet on your TPS reports and you don't do that because *you* happen to think it's silly, useless, redundant, whatever--if Management decides that's what *they* (the one's signing the check) think is right, then a good manager will make that happen. Period.
--Jim
 
if Management decides that's what *they* (the one's signing the check) think is right, then a good manager will make that happen
Yup, making following "the rules" a condition of continued employment is rather an attention-getter<g>.

If we implement systems that make it easier to follow the rules, we provide value. . .
 
And to elaborate on the management points...good management will listen to the suggestions of the employees who have opinions of how either a certain process may well be redundant or senseless, and how either process itself or the tool used to implement that process can be improved.

The buzzword there is 'empowerment', which is when management actively solicits suggestions or openly listens to and considers unsolicited suggestions.

This is in contrast to anarchy where employees become the sole judge, jury, and 'executor' of their own process changes (or omissions)--regardless of the relative improvement realized by the change or omission. Like the batter in baseball who ignores the coaches signal to take a strike and instead swings and hits a homer--he was still wrong--and that one in a thousand moment doesn't warrant abandoning a structured chain of command.
--Jim
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top