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.
It's tempting to start by creating a few users to play with. When you do, ensure they have a sufficient set of permissions, or you'll be wondering why you can't do something, or there seem to be options missing. Allocate a role such as Director (from the sample data) initially, or create your own permissions based on similar settings. The time to lock down security, or restrict functionality is AFTER you've experimented!
Before you get started, there is one big difference between AlchemyWorks and most other project management systems. In AlchemyWorks there is no distinction between a project and a task, they can both be as simple or as complex as you like. A task might be just a title description and perhaps a duration estimate, but it could have all the controls of a big project if required. Any project or task can be broken down into smaller chunks to any depth, with analysis and charting applied at any level. For more information read the Everything is a Project FAQ.
Also worth review is how status codes affect the scheduling of projects. Normally tasks and projects are dynamically scheduled in the calendar according to their duration (or remaining work), priority and any dependencies or time constraints placed upon them. The type of status code applied to a task can affect this however; eg. a status code of type Planning will cause that task to be scheduled after any Active ones The status codes defined in the sample data are just suggestions, it is recommended to set up ones that match your operation, along with appropriate workflow rules.
For your first project follow the My First Project walkthrough. This will guide you through the basics of project and task creation, setting up task dependencies, and accessing the various reports and charts such as Gantt, PERT or AON.
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. It is recommended that the following areas of the system be reviewed before setting up the system for live operation.
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.
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.
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.
