Welcome to the AlchemyWorks Project Management System. The database is preloaded with a small amount of sample data, and it is recommended to first navigate through the menu system and experiment, before attempting setup for live or trial operation. Initially the context sensistive help is turned on, which presents relevant information in yellow at the bottom of each page. After familiarity with the system this can be turned off in the Settings menu, and turned on selectively for new users to the system. All data field labels also contain information, which is visible when hovering over them. This can also be presented as a graphic alongside the data field if enabled in settings. The following steps are a suitable sequence for setting up the system prior to live operation.
Classes - Project status codes are grouped into Classes. This allows segregation of activities in reports and tables, over and above other means of differentiation such as the project tree hierarchy or locality. In a medium sized enterprise this could be logical activities such as Operations, Sales, Support, etc. - for a small business or individual this may be Business and Personal for example.
Locales and Languages - Locales are normally physical locations or areas, but in the case of a single office could be used to distinguish departments. Locality is useful in defining default language and timezone info, and also assigning project resources. Languages can be used in their natural sense, but can also be a means to adjust terminology to suit a particular industry. Every prompt and label in the user interface can be re-mapped on a language basis.
Security Clearances - It is not necessary to define security markings or clearances, however this may be an appropriate way to protect information, particularly if access is given to external parties or individuals. Security markings can be created and applied to most objects, with clearances defining the set of protective markings that can be seen by a user. A sample set of protective markings is available loosely based on Government definitions, but can easily be applied to a commercial context, or designed as required. Clearance level can also determine the password strength, and other parameters for a user.
User Roles and Permissions - Roles define individual user permissions in terms of what parts of the system they can see and/or modify. A generic set is supplied which can be customised as required. Roles can be inherited in a hierarchal fashion, to make maintenance easier.
Status Codes - A Project's state is defined by it's status code or type. This code determines a projects display format and style, as well as it's scheduling (along with priority, dependencies and other time constraints). Status codes can be strung together in workflows that constrain available states, and modify project parameters.
Priorities - If the default set is insufficient, then an arbitrary number of priority levels can be created. Priority is the main mechanism for modifying scheduling sequence, although this is subservient to explicit time or dependency constraints.
Activities - Activity codes are applied to project events, and are useful for reporting on cost breakdowns or time utilization.
Users - Create user accounts, note that this is limited to 10 in the trial period. Users should be assigned to an appropriate locale, and given a role based on the permissions they need. A classification authority can also be granted if protective markings are to be used. The preferred mechanism for setting a password is a "Password Reset", which sends a unique time limited token to the user email, and can be used for a one-time only login and password change, however a password can be set manually if required.
Project Tree Structure - The projects are arranged in a hierarchal tree, and analysis is possible for all subtrees, so the structure of this tree is important for reporting. It is advised to explore the system initially before considering the best structure for your activity or business, although it is possible to move projects and subtrees within the structure, so this can be modified later if desired.
Workflows - Once appropriate status codes have been developed they can be linked together by workflow to define a process. Workflows can be defined to constrain the available status codes a project can be changed to, and also to restrict which codes can be used when creating sub-projects or tasks. For any specific transition, workflow rules can be set to automatically modify project parameters such as manager, priority, etc., or even move to a different position in the project hierarchy.
Browser - The user interface including menu systems, graphics and HTML features can be tuned based on browser systems or devices. A number of setups are included in initial sample data, but can be customised or added to for preference.
When familiar with operation, the system can be converted to live operation in the subscription menu.