Policies, Procedures and Proficiency

Daniel Noga 2

It's been a while since I've seen someone create a new post about Policies and Procedures for everyone to reply to with references to the bazillion other discussions that have been opened on the subject.  I have a twist on the question that I haven't seen yet:


What RE: proficiency level do/did you assume when composing your manuals? Do you spell out every single detail of every single procedure that you do so that a person who has little to no RE: exposure could take your seat and eke out some semblance of fulfillment of your duties in your absence? Or do you assume that certain basic skills are a given and focus more on your organization's particular implementation strategies and nuanced procedures? I can see pros and cons for both.

Joshua Bekerman bCLO bCRE

The latter, assume the user has the basic software skills and focus on how your organization uses it.  If the user doesn't have the skills then there are plenty of other resources already out there to fill that gap, so no need to rewrite the wheel.


 

JoAnn Strommen

Ditto, what Josh posted. It's policy and org specific procedures not a how how to or RE for beginners.  Both types can be of value.

Gina Gerhard

Daniel - Because we developed our policies & procedures manual to also serve as training material, we took this approach.

• As an overall introduction and to serve as a high level summary, we made 'Introduction' documents for each major system area.
  • This material was included in everyone's training but for high-level management, this was as much as they needed.

 

• We then developed more detailed documentation but at a general/basic level, so that a new user would be able to follow.  We did 'reinvent the wheel' to some extent as we wanted the user to be able to use only this documentation as the basis for their training.
  • This was used as training for our general managers and the operational staff.

 

• And we then developed more advanced documentation strictly for operational staff.

All of this documentation was developed in 'modular' fashion and all worked together as a system, so we could pull together these different 'levels' of training mateirals as needed. This approach has worked very well for us. 


Also, we're not a typical fundraising organization but a community foundation - so the way we use Blackbaud is somewhat non-standard and hence a great deal of the standard Blackbaud materials don't really apply to how we use the system. So that somewhat required that we develop a more customized approach.

________________


Daniel Noga:


It's been a while since I've seen someone create a new post about Policies and Procedures for everyone to reply to with references to the bazillion other discussions that have been opened on the subject.  I have a twist on the question that I haven't seen yet:


What RE: proficiency level do/did you assume when composing your manuals? Do you spell out every single detail of every single procedure that you do so that a person who has little to no RE: exposure could take your seat and eke out some semblance of fulfillment of your duties in your absence? Or do you assume that certain basic skills are a given and focus more on your organization's particular implementation strategies and nuanced procedures? I can see pros and cons for both.

 

Joan Bell

I wrangled with the
same questions--I figure that whoever would fill in for me will
have to have some RE gift processing knowledge. As we also use
ImportOmatic, that gets me back to being considering that they may
not know it at all. 

I'd be interested in
how others approach this, too.

Joan (Jo)
Bell

GSA
Foundation

Database
Coordinator

Work:
303.357.1067

jbell@geosociety.org

Tom Klimchak

We did everything listed here ....


Our documentation has a "Policies" section first, which goes over the "why" and the general steps you're going to take.  So for gift processing it might explain the overal process of prepping checks vs cash, without any super-specific details.


Then we have a "Procedures" area which is usually "step-based" to help a new person move through the process one step at a time.  We can use this for documentation.  As we've create more and more documentation we've learned to not get quite so click specific.  Like, we will now say "Open a constituent record and start a new action" but we won't say "Click Open, type in Consituent ID, double-click on record, click on action tab, click on New Action button..."


We design our documentation to be useful for someone who is familiar with the basics of software and Raiser's Edge, not an alien visiting from another planet

Daniel Noga:


It's been a while since I've seen someone create a new post about Policies and Procedures for everyone to reply to with references to the bazillion other discussions that have been opened on the subject.  I have a twist on the question that I haven't seen yet:


What RE: proficiency level do/did you assume when composing your manuals? Do you spell out every single detail of every single procedure that you do so that a person who has little to no RE: exposure could take your seat and eke out some semblance of fulfillment of your duties in your absence? Or do you assume that certain basic skills are a given and focus more on your organization's particular implementation strategies and nuanced procedures? I can see pros and cons for both.

 

Daniel Bayer

The one time I have actually done a full procedures manual was when I was in an Associate/Assistant position, and thus I assumed a basic knowledge of computers and beginning level of familiarity with RE. I detailed every process the job covered in bulletted list format, with the most detailed instructions (i.e., the location of functions in menus, key codes, etc.) on the "innermost" bullets. That way, people with a greater familiarity with RE can just skip over those bullets, but the info is there if they need a refresher or something.

Karen Hartt

Daniel Noga:


It's been a while since I've seen someone create a new post about Policies and Procedures for everyone to reply to with references to the bazillion other discussions that have been opened on the subject.  I have a twist on the question that I haven't seen yet:


What RE: proficiency level do/did you assume when composing your manuals? Do you spell out every single detail of every single procedure that you do so that a person who has little to no RE: exposure could take your seat and eke out some semblance of fulfillment of your duties in your absence? Or do you assume that certain basic skills are a given and focus more on your organization's particular implementation strategies and nuanced procedures? I can see pros and cons for both.

Daniel,

We "grew" up with Raiser's Edge; we converted in 1999 and were a very small shop at the time, only 8 employees. I designed our manual using step by step instructions. As the DBM and gift entry staff it was important that someone could step into my shoes and do the data entry if I got hit by the preverbial bus. I haven't changed the manual format as we now use it for training new staff.

Daniel Noga 2

Thomas Klimchak:

  As we've create more and more documentation we've learned to not get quite so click specific.  Like, we will now say "Open a constituent record and start a new action" but we won't say "Click Open, type in Consituent ID, double-click on record, click on action tab, click on New Action button..."

 

 I've been there!

Eileen Bartlett 2

I have been tasked to start a maual where one did not exist and I am wondering if anyone has an example of their Policy and Procedure Manual and is willing to share it, so that I am not starting form scratch.

Thank you for any assistance, it will be much appreciated.

Eileen

Karen Hartt:

Daniel Noga:


It's been a while since I've seen someone create a new post about Policies and Procedures for everyone to reply to with references to the bazillion other discussions that have been opened on the subject.  I have a twist on the question that I haven't seen yet:


What RE: proficiency level do/did you assume when composing your manuals? Do you spell out every single detail of every single procedure that you do so that a person who has little to no RE: exposure could take your seat and eke out some semblance of fulfillment of your duties in your absence? Or do you assume that certain basic skills are a given and focus more on your organization's particular implementation strategies and nuanced procedures? I can see pros and cons for both.

Daniel,

We "grew" up with Raiser's Edge; we converted in 1999 and were a very small shop at the time, only 8 employees. I designed our manual using step by step instructions. As the DBM and gift entry staff it was important that someone could step into my shoes and do the data entry if I got hit by the preverbial bus. I haven't changed the manual format as we now use it for training new staff.

 

 

Carley Haynes

HI Daniel,


I started writing ours at the higher level and quickly realised how much I assumed everyone else knew.. when they really didn't! I have since revised it and am now writing it step by step as if I'm training someone who has never done the procedure before. I'm finding that my colleagues and bosses are much happier knowing that level of detail is in the manual 'just in case'! 

Eileen Bartlett 2

Hi Carley,


Do you have anything you could share, I have been tasked to create policy and procedure manual, would love to see what you might have?


Thank you,

Eileen


Carley Haynes:

HI Daniel,


I started writing ours at the higher level and quickly realised how much I assumed everyone else knew.. when they really didn't! I have since revised it and am now writing it step by step as if I'm training someone who has never done the procedure before. I'm finding that my colleagues and bosses are much happier knowing that level of detail is in the manual 'just in case'! 

 

Karen Hartt

Daniel Noga:


It's been a while since I've seen someone create a new post about Policies and Procedures for everyone to reply to with references to the bazillion other discussions that have been opened on the subject.  I have a twist on the question that I haven't seen yet:


What RE: proficiency level do/did you assume when composing your manuals? Do you spell out every single detail of every single procedure that you do so that a person who has little to no RE: exposure could take your seat and eke out some semblance of fulfillment of your duties in your absence? Or do you assume that certain basic skills are a given and focus more on your organization's particular implementation strategies and nuanced procedures? I can see pros and cons fo

I went to rexpond to this and realized I already had...

Daniel Noga 2

Thanks for your feedback, everyone! The consensus does seem to be to err on the side of caution and document policies and procedures at a basic level. In a perfect world, a vacant database position would be filled by a person with a high level of experience, but counting on that happening could lead to regrets!