Difference between revisions of "Projects"
Katie Brown (talk | contribs) |
Katie Brown (talk | contribs) |
||
| Line 10: | Line 10: | ||
* When you use the Contact Management part of Charitylog, you record [[Contact]]s and create [[Action]]s. These Contacts/Actions sit within a [[Referral]], and that Referral will be categorised under a Project. | * When you use the Contact Management part of Charitylog, you record [[Contact]]s and create [[Action]]s. These Contacts/Actions sit within a [[Referral]], and that Referral will be categorised under a Project. | ||
| − | * When you record work done using the [[Support Worker Module]] , it’s all about [[ | + | * When you record work done using the [[Support Worker Module]] , it’s all about [[#Job Cards]]. These Jobs result from a [[Support_Worker_Module#Creating_the_support_plan]], which sits within a [[Referral]] for the beneficiary of the work. That Referral is categorised under a Project. |
* When you record attendances at [[Clubs and Clinics]], these [[Attendance]]s are at a particular [[Club/Clinic]]. Each Club/Clinic is categorised under a Project. | * When you record attendances at [[Clubs and Clinics]], these [[Attendance]]s are at a particular [[Club/Clinic]]. Each Club/Clinic is categorised under a Project. | ||
Revision as of 09:54, 29 December 2017
Contents
About Projects
Projects are overall categories for the “work done” side of Charitylog. When you record information about work done, it will ultimately be categorised by one (and only one) Project. Some examples are:
- When you use the Contact Management part of Charitylog, you record Contacts and create Actions. These Contacts/Actions sit within a Referral, and that Referral will be categorised under a Project.
- When you record work done using the Support Worker Module , it’s all about #Job Cards. These Jobs result from a Support_Worker_Module#Creating_the_support_plan, which sits within a Referral for the beneficiary of the work. That Referral is categorised under a Project.
- When you record attendances at Clubs and Clinics, these Attendances are at a particular Club/Clinic. Each Club/Clinic is categorised under a Project.
Because all the data about work done is categorised by Project, this means that Projects are used throughout the system as filters on reports and so on. Most reports or searches offer Date Range and Project as their main filters, and then offer other more specific filters as necessary.
Note that there are some elements within the system which are not categorised by Project - the most obvious one being Organisations and People. Organisations and People exist independently of Projects. An Organisation/Person can have any number of Referrals, and therefore they may be involved with several Projects, but Organisations and People are not categorised by a Project in the same way as Contacts, Attendances and so on.
Deciding your Project structure
One of the first things to do when configuring Charitylog will be to set up a list of Projects that can be used to categorise all the data about work done. Most of our customers set up one Project for each service that they deliver, but sometimes more than one. Since the list of Projects that you use is entirely up to you, you just need to consider these issues:
Using fewer Projects
In theory, you could keep everything under a single Project, and for a minority of customers this is the correct way to do things. For most customers, this won't give enough reporting detail. When you create reports, you'll probably want to look at Referrals that have been delivered by different parts of your organisation/business. If these Referrals all exist under one Project, it will be difficult to disentangle them at reporting time. If you want to report on separate parts of your organisation, you'll probably want to use separate Projects.
Using more Projects
So it usually makes sense to split up your system into several Projects, maybe one Project per service that you deliver. The question then is how far to split those services - for example, one service is funded by two different revenue streams; would it be appropriate to split that up into separate Projects, one for each revenue stream, so that we can see where the money is going?
It isn't possible to give a definite "yes" or "no" answer, but the issues to consider are;
- Referrals are always associated with one, and only one, Project. A Referral can't "cross" from one Project to another halfway through. If you choose to have two Projects that cover different "arms" of a service, then when someone moves from one "arm" to the other, you would need to close the Referral to do with their involvement with the first "arm" and open another Referral to do with their involvement with the second "arm". In reality, this is probably going to be confusing for the user, and will lead to data entry errors. Don't make the users of your system do too much of this "Referral crossing" - it's unintuitive and usually doesn't work very well.
- On the other hand, if this "Referral crossing" issue isn't likely to be a factor, it's very easy to combine Projects at reporting time. Using more Projects is unlikely to significantly complicate reporting, so don't worry too much about this issue.
- If you want to categorise Referrals at another level apart from which Project they belong to, you can do this with Project Subcategories or Project Funding Streams.
Setting up Projects
Once you've decided what your list of Projects should be, you can set them up from the Project Set Up page.
Rob Kay - manual author (talk) 15:53, 30 August 2017 (BST)
