|
|
| (21 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | [[File:helpheader_small.png|right]]
| + | #REDIRECT [[Project Set Up]] |
| − | | |
| − | __TOC__
| |
| − | | |
| − | | |
| − | ==About Projects==
| |
| − | | |
| − | | |
| − | Projects are overall categories for the “work done” side of Crossdata. 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 Crossdata, you record [[Contact]]s. These Contacts 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 [[Support Work Job]]s. These Jobs result from a [[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.
| |
| − | | |
| − | 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 Crossdata 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.
| |
| − | | |
| − | | |
| − | ----
| |
| − | [[User:Rob Kay|Rob Kay - manual author]] ([[User talk:Rob Kay|talk]]) 15:53, 30 August 2017 (BST)
| |
| − | [[Category:Glossary]]
| |
| − | [[File:helpheader_small.png|right]]
| |
