Difference between revisions of "Projects (Administrator guide)"
(→Setting up Projects) |
|||
| Line 63: | Line 63: | ||
[[File:A_projects_4.png|border]] | [[File:A_projects_4.png|border]] | ||
| + | |||
| + | ====Referral Reasons==== | ||
| + | |||
| + | ====Contact Types==== | ||
| + | |||
| + | ====Referral Sources==== | ||
===Codes Usage/Settings tab=== | ===Codes Usage/Settings tab=== | ||
| Line 70: | Line 76: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Project Subcategories== | ==Project Subcategories== | ||
Revision as of 13:20, 4 April 2013
Overview of Projects
Projects categorise all activity recorded using Charitylog. Understanding the concept of Projects is vital to having a good grasp of how the Charitylog system works as a whole.
Recording activity is useless unless there is some way to make use of this information. A key principle is to be able to categorise information, for example -
- "All work done for this client" - categorising by client
- "All work done in this time period" - categorising by date
- "All work done by the Daycare service" - categorising by Project.
Any information recorded in Charitylog needs to be recorded "under" a Project, and you will need to set these Projects up before you can start using your system. It's common that each service your organisation delivers will have one Project set up for it. Typical Projects like this would be;
- Daycare
- Activity Groups
- Information and Advice
and so on. These usually cover the majority of work an organisation does with clients, but there may be more projects required if you want to capture statistics on all your organisation's activity - which you probably do. You might need some extra projects like;
- Volunteers (to record activity with volunteers, rather than clients)
- Front Desk (for reception staff to record their interactions with clients)
- Marketing (to record contacts with local press etc)
You can see that Projects are more than just a list of the services your organisation provides - although this is a big part of the picture. The Projects on your system serve to categorise all activity recorded, so in this way, they are more like categories than anything else.
Every action recorded on your Charitylog system is linked to one Project and one Organisation/Person (most commonly, a client).
This Project and Organisation/Person may be carried on to several actions, which we call a Referral. In this case, the whole Referral (chain of actions) is linked to one Project and one Org/Person. A Referral cannot be under more than one Project and it cannot be with more than one person. Many members of staff might get involved with the referral, but the subject of the referral - usually a client - remains constant.
Setting up Projects
To set up a new project, or edit an existing one, click the "Project Set Up" menu item, which can be found in Administration > Projects and Referral Entries.
This menu item will take you to a screen where you can see the projects already set up on your system, if there are any.
As you can see, there are several set up on the demonstration system. To create a new one, click the "Enter New Project" button at the top of the screen. You will be taken to the first in a series of tabs where you can enter information about your new project.
General Details tab
Project Settings tab
Referral Reasons
Contact Types
Referral Sources
Codes Usage/Settings tab
Project Subcategories
Project subcategories are cross-Project. They can be set up to categorise activity over the whole organisation. For example, you might use a subcategory of "Advocacy", which could be used in any number of Projects. Charitylog's reports are generally broken down by Projects, so using subcategories can allow you to obtain one set of numbers which relate to activity across several Projects.
Subcategories can be set in several places -
On the "Record a Contact" screen
As part of a Referral Template
Clients In Project
The notion of "Clients in Project" is a slightly abstract one, but it is important. If a client has had any activity with a project, they are taken to be "in project" until they are formally terminated. Usually it is appropriate to leave clients un-terminated in projects except in very specific circumstances.
The reason the concept is there at all is that running a report on which clients are "in Project" will give you everyone who has ever accessed the project, unless terminated. In the case of an Information And Advice project, this number could be very high, and it is unlikely that you would want to write a letter to all of them (for example), but you may want to know this number in some circumstances - for example, if a service stops, you may want to contact all historical clients and let them know.
Unless you are certain that you need to make use of it, it is better to ignore the concept of Clients In Project and Termination.
Termination if client is deceased
If a client dies, it may be appropriate to terminate them from Projects, but it is not necessarily the case. You may still have dealings with the next of kin, and of course you still want the activity with that person to be included in your reports. You can set a client as Deceased without terminating them from Projects.
Appropriate reasons for termination
A client's involvement with Projects is usually only terminated if you (the organisation) are absolutely sure that they will not be back. This might be if;
- The client moves away
- The client is banned from the service
- The client finishes a very specific piece of work with the relevant Project (a case).
