Procedure Manual

Maya Thomas

Hello,



I about to start creating a procedure manual for our Development Office. I have Bill Conors presentation 'Creating Effective Policy and Procedure Creating Effective Policy and Procedure Documentation for The Raiser’s Edge'. But I was keen to hear from any other schools who are/have created a procedure manual for raisers edge and what kind of things they included.



Many thanks,



Maya

Jen Claudy

A tip I got from a BB presentation years ago...



Once you write up documentation on a process, use it every time.  Even though you won't need it, having it open (printed or on the computer) will mean that it continually stays updated, because any time you change something you can update the documentation right then and there.  I do this with anything that I do on a weekly, monthly, or less frequent basis, and it's helped.  No longer do I ever have to put on my to-do list to review and update documentation for any of that.



If you have multiple staff, and are fortunate to have a system of backups for most of your regular tasks (or if, like my current org, you're the only one doing any data entry/database work at all), this can help when someone needs to step in and perform any of the documented processes.  I used to work in theatre stage management, and we called this the "hit by a bus" scenario...if you were hit by a bus today, could someone else pick up your documentation and be able to at least get the bare minimum done until you recover and return to work?  (The more detailed and up-to-date your documentation is, the less headache you'll have when you return and review the work, too.)

Lauren Henderson

I like the "divide and conquer" approach to procedures- figure out which processes are most critical and urgent to have mapped out in case of emergency, and then go from there to perhaps less critical tasks.

For example, I started with gift processing and posting through batch and to Financial Edge (our general ledger).  I am planning to tackle acknowledgement letters next.

The detail you put in also depends upon whether it is someone already competent in RE and familiar with your school who will be picking things up, or if you are writing it for someone who has never seen the program before.

Good luck!  I find it to be an odious, but very important, task.

Zane Magnuson 2

When I wrote the guide for a previous organization before I left, something that seemed to be really helpful for people was screenshots. Lots of 'em. I'd go through my normal processes, but took a screenshot of every menu, every option, etc.



You'll end up with an enormous guide (mine was something like 160 pages) and it'll be very expensive to print a physical copy, but I'd say it's worth it. With clear instructions and plenty of screenshots, it makes it very difficult for newcomers to make mistakes.

Gina Gerhard

Just remember, cropping is your friend -- you don't always need the entire screen or window but you can focus in on specific areas and make them larger.



And also for space saving, choose the 'Position' option for your images so you can then place to the left/right of text. This also brings some visual interest to your page instead of everything linear ....

Christine Cooke 2

When I have constructed in the past, and am currently trying to build (as I go along) on this current Org, I have prioritized what needs to be documented and have clear instructions written out and worked on those first.  Having a Word doc open and writing the steps as I go through say, the Gift Processing procedure from the time the mail arrives in the building and has to be sorted all the way through to putting the signed letters in the outgoing mail. 

Even though it may seem excessive to you, I always write out step by step on things like Gifts and Pledges in great detail, as if someone has never opened up and used RE before.  Because in case of emergency, you don't know who will have to pick up the slack and how much if any experience they have in RE.  And for some folks, it helps to know why something HAS to be done a certain way -- they need to know the fallout of breaking from the instructions.  (gotta say, I have left jobs and been able to touch base with the person who followed me in a couple situations and they were always very thankful for the detail!)



I have found it is also helpful to label any queries and reports in a system that lets someone else find them easily - no abbreviations because everyone abbreviates differently!  And if there are reports that you are writing instructions on how to construct (like the 'pretty' ones for boards and committees) label those queries and reports clearly as to what they are for so they can be found. 



When it comes to data entry and consistency, which is the backbone of any good database, screenshots are helpful.  I have a dummy records for Invidiual and Org that are really obviously named and there for practice and/or referral.  And use those to set up examples for screenshots.



Also!  if you have not already -- have a journal included of all of the Matching Gift sites you deal with and the user names and Passwords !!!  I cannot tell you how many times I have inherited that sort of mess -- and it takes a year of calls, emails, letters, and faxes to figure out Your Org's user and password and it is usually the last person or the person before them name on everything.  Ugh!  Fix it!  I intentionally set up with our IT a Development@___.org email and have all of the MG info sent there.  The recipient of that email is the head of the department and other members that deal with keeping track of giving, like annual fund director and/or alumni coordinator, events manager.  So if the data person (me) gets hit by a truck or falls off the earth, someone else can know and get access to the MG info and confirm what needs to be and look up where funds are arriving from in connection to which donor(s).



Whew!  Liking everyone else's suggestions also!

Aldera Chisholm

Yes, yes, and yes. I used to work in Theatre as a Stage Manager and learned the "What if I get hit by a truck" theory of documenting process.



Also - doing this level of detailed documentation is a great way to flag inefficient process to yourself - all those things we become so automated at that we forget to look critically.

Gina Gerhard

Dug out link to a prior thread that had a lot of great information as well -



Basic policy and procedures manual for date entry and integrity

https://community.blackbaud.com/forums/viewtopic/168/16388?post_id=70785#p70785





 

Daniel Noga 2

Zane Magnuson:

When I wrote the guide for a previous organization before I left, something that seemed to be really helpful for people was screenshots. Lots of 'em. I'd go through my normal processes, but took a screenshot of every menu, every option, etc.



You'll end up with an enormous guide (mine was something like 160 pages) and it'll be very expensive to print a physical copy, but I'd say it's worth it. With clear instructions and plenty of screenshots, it makes it very difficult for newcomers to make mistakes.

I was actually thinking about screenshots just as I read this post. GMTA! Tip for people using Windows 7 (I've never tried this with other versions): Click Start, and search for "Snipping Tool." This is a little app built into Windows that allows you to very easily take screenshots of exact portions of the screen. This is perfect for those who want to illustrate everything they possibly can in detail that will be useful to the reader.

Daniel Noga 2

Something that is fresh on my mind as I approach documenting the process for doing our Annual Report lists--both the donor listing and the mailing list: All of the exceptions to these complicated rules we establish and document.



My dream for something like an Annual Report list would be to be able to "set it and forget it," or establish an iron-clad procedure that takes everything into account automatically. Never gonna happen. There are always going to be manual tweaks needed by the office, people with preferences that make them stand out, and odd cases where whomever is pulling the lists will just have to know certain little things. You can put this stuff in Notes fields until the cows come home, but someday, someone's going to forget it's in there, or they won't know to look in the first place. I say put it right there in the procedure that everyone is going to see.



There are a few different ways to organize this. Because I try to cover all of my bases, I am likely to have a separate Appendix just for exceptions, organized by category/routine--but I will also include any relevant exceptions to any given procedure in a section at the end of that procedure. Never assume people are going to look for some piece of information the same way you would. Think of different ways someone might think to search for information and try to accommodate them. As others have said, this is work that only looks too tedious until you've been the person responsible for making magic happen without this guidance. Gone on vacation only to find a database mess to clean up when you got back? Now you know why this is time well spent.



I've had two jobs where I was the sole data entry person and knew that stuff well. Now I have support staff for that and can focus on administration. I know more about RE: as a whole, but our data entry person was gone for a few days and I had to wing it. It did not turn out well. Different orgs do things differently. Don't let a person's years of experience lull you into complacence when writing documentation. When it doubt, write it out.







 

Gina Gerhard

Daniel - We have the same pains around the annual report exceptions.



One thing we've done is to create a specific note pad for 'Annual Report Exceptions' where we try to record on the constituent record issues around how they're listed or other issues related to the annual report. These notes are then exported along with the gift and recognition data in preparation for the report.  



So that's somewhat an attempt to 'document' the exceptions -- but only as good as staff entering data into the notepad!

Jacki Balon

I used to spend hours creating & then updating RE procedure guides for the Development office but no one read them.  So now I have two documents - one that outlines what that outlines Prospect Management as it relates to our institutions - including what is expected of them as far as using RE - this is done and updated annually and includes all the KPI's etc - it is a joint project with the Director, Development - and has no RE instructions.  



I have a series of cheat sheets (adding a contact report action, updating their proposal records, etc)  that I give out to the Development staff when we do training and then send them soft copies.  Then I have a more detailed RE Prospect Management guide that I have created for the RE Information Services team, but I don't need to put as many screen shots, etc as this guide is for the folks who know the system.  



I will have separate cheat sheets for our Government Engagement staff, Alumni Engagement staff & the Researchers.  I've gone from detail to the keep it simple method & it works - we are getting more information into the system correctly now.

 

Jenny Kleintop

Bill lays it out nicely and I highly recommend following his pathway.  Because of him I do a much better job with documentation.  Before I met him I used to do step-by-step how to documentation.  After I met and learned greatly from him, I now do Why documentation.  Blackbaud has tons of How-to documentation and training.  The more important things to document is the Why – why do you do the things you do, why do you have the codes you do, why do you enter the gifts the way you enter them, what decisions were made for the set up you have, even what other considerations you made and who was involved that lead to the final outcome.  3 years later and over 750 pages of documentation, I have often referred back during meetings to remind folks why we did what we did and why we set things up the way we did.  Often updating documents and having a revision date at the top of the document.  I don’t expect most other staff to read documentation, it’s more of a blue print for why we do what we do, although I do have some front-liners who reference it during our meetings who start out with “in documentation…”, probably because I’m always referencing it; it wears off on them.