Hi All,

My director has come up with an idea for an IT department "Outreach" program.  I'm not sure what made him think this is a good idea.  What this entails is that each of the IT staff (4 of us) is assigned a certain number of directors (6 - 10 depending on department size) to find out any issues, upcoming projects, wish lists...ect.

We, the staff, has to do it so we can "better understand the needs of the departments".  We will have an IT department meeting about coming up with ways to communicate with the directors of other departments ie. face to face meeting + a online forum for the directors to add anything they forgot + reminders (email, phone calls).  So from the sounds of it I am going to become a telemarketer/spammer to the directors.

Has anyone done something similar and if so what did you do and how effective was it?

Thanks for your comments!


Stubnski
 

Sounds like he is passing his work out to his staff.  Your managers job would be to work with department directors get there requirements and pass those requires down to his staff (you guys).

Denny
MVP
MCSA (2003) / MCDBA (SQL 2000)
MCTS (SQL 2005 / SQL 2005 BI / SQL 2008 DBA / SQL 2008 DBD / SQL 2008 BI / MWSS 3.0: Configuration / MOSS 2007: Configuration)
MCITP (SQL 2005 DBA / SQL 2008 DBA / SQL 2005 DBD / SQL 2008 DBD / SQL 2005 BI / SQL 2008 BI)

My Blog

To me it sounds as if your director is opening the door to the concept of collaboration.

I appreciate that your director is not autocratic and is breaking the normal organizational hierarchy. When directors involve their team in the process, they get buy-in from the team.

Your director is giving your team the opportunity to see the business as a whole instead of being fed only bits and pieces. The director is also helping your team to explore the different ways to collaborate. Collaboration appears to be the future business model.
 

I think that any IT professional worth their salt would welcome the opportunity to get some feedback about their system from the end user; or representatives thereof.

I always kept an "open door" policy, so that anyone from the CEO to a line staff worker was welcome to come in.  In fact, I kept a jar of gumballs on my desk filled always.  (I got that idea from a manager who had a popcorn machine in his office to encourage people to just "stop by").

Remember that the purpose of IT is to support people in doing their jobs.  Unless there is a communications path back to you about issues that users are having, then you cannot perform that function.

 

Just my 2¢

"What the captain doesn't realize is that we've secretly replaced his Dilithium Crystals with new Folger's Crystals."

--Greg  http://parallel.tzo.com
 

Thank you all for your comments, they are very much appreciated.

After talking again with my director I have come up with that this is mainly for users wish lists and department projects.  This way my director will have a record of all wish lists, projects and anything else that might need to be looked at come budget time.  He wants the IT staff to be the ones to initiate contact because we have a better understanding of the end user needs(better than the IT director) and might suggest something that would work better for that department.


gbaughma - I agree 100% about the role of IT but I think you misunderstood my post.  I was not complaining about getting feedback or having to communicate with directors. I was asking for ideas on methods to use for getting directors/managers to submit their ideas, wish list, or projects for their department.  

I do have an "open door" policy and I do have great communication with end users on the floor (I know many of them on a personal level), but some things that end users ask for need the approval of both their director and my director.


Stubnski
 

Quote:

I was asking for ideas on methods to use for getting directors/managers to submit their ideas, wish list, or projects for their department.  

Oh.. that part is easy!  You just make a label to put on your paper shredder that says "Suggestions".



Just kidding.  Actually, a "work order" system works well for all of that... it not only documents what you've done, what's outstanding, etc. but also gives a formalized way of making suggestions or bringing to your attention issues that need to be addressed.

If a suggestion encompasses multiple departments or can have ramifications beyond the user's scope, then you would either meet with, or start an email discussion about, the request, ramifications, and so forth to get feedback and, hopefully, "buy-in" from the rest of the users.

Say, for example, a suggestion is something like "Boy, it'd be great if this report all printed on one sheet, instead of three."  A simple request, no doubt.

But, you make the change, only to find out from another manager that once THEY get the report, sheet 1 goes to management, sheet 2 goes to nursing, whatever... that's an example of not understanding the "big picture" before making a system-wide change.  That's why before I would institute any kind of major change to the process or programming, I would at least "bounce it off" of the other managers, to make sure that it didn't have unforeseen ramifications and potential problems later on.

An e-mail thread is certainly an easy way to do that... or, in the case of *BIG* changes or requests, planning teams, management meetings, and so forth were sometimes necessary.

 

Just my 2¢

"What the captain doesn't realize is that we've secretly replaced his Dilithium Crystals with new Folger's Crystals."

--Greg  http://parallel.tzo.com
 

I second the "work order" system (separate from a Help Desk issue tracking system) for change/enhancement projects.

One thing I do in addition to the formal project request system is to take 30 to 60 minutes every Friday afternoon and walk around to my various departments. I know who the "real" users are of each system, so I go to them. Sometimes that's a manager, sometimes it's not. I'll stop in for some light chit-chat and then ask them how things are going with their systems. Usually it's "Oh, everything's OK", so I ask more leading questions like "how's the speed?" or "have any of your co-workers mentioned any problems in the last few days?", or "Are there any changes coming down the line for your department?"

You'll be surprised what you learn about. You'll get some nice low-hanging fruit that takes 5 minutes of coding to fix a procees that takes them hours to do. Other suggestions are more difficult and may prompt you to suggest they submit a formal project request. Even with a project request system, users sometimes forget to put stuff in until they're told that "oh , yeah, we can fix that, but I need a project for it so we can prioritize it and track it for you."

Monkeylizard
Sometimes just a few hours of trial and error debugging can save minutes of reading manuals.  

While directly talking to people is great and I highly encourage it, observing them working with your application is another way to see what the problems are. You'll see whare they get stuck or where the form doesn't match the paper they get the information from or where they have to move around the page funny (I can remember one memorable system where the first line was address and name didn't come onto the page until near the very end, this was a big disconnect from the way they normally got the data to be entered.) Watch for long delays or places where the people appear to do something in a way you would not expect. As why they did it that way, you may find it is their work around solution to an unfixed bug. Or you may find the need to train them how to do something you thought was obvious from the design.

We keep a file of customer complaints, if your company does as well, it is worthwhile to peruse, you may find several issues that can be fixed through software.

"NOTHING is more important in a database than integrity." ESquared
 

I'd second that completely, and not just for IT. It's amazing how, when you get into a particular habit of doing things, it's difficult to see that this the way we do things is not at all logical, or includes steps that could be greatly simplified. It can be very difficult, though, to change anything without treading on toes; tact is essential.