You may have noticed the workflow options under the project and status code sections of the system, and perhaps are wondering how/where (and why?) you could be using these. This guide will explain the options available, creating a project workflow and how to use them effectively.
Projects can be one-off sets of activities, such as managing change within a business, but are also often repeating similar activities used to control regular business such as installations or implementation processes. If you have projects of this type then there are a few tools to help out with the heavy lifting. These include status codes, templates, kanban boards and workflows - in this guide we will focus on the workflow aspect.
First of all you are going to want to create some status codes for the various stages a project will pass through. The stock set of status codes are probably fine for one-off projects, but for repeating activity having a specific set for the stages allows us to do a number of things. We can define a kanban board including the codes and use this to monitor the workload for this type of project, and we can also drill into a status code report to see all projects at that particular status.
Once we have some status codes they can be strung together using workflow rules. This helps to document the process, but also has some functional benefits.
Workflow rules allow you to constrain the status codes a project can transition to, as well as modify project parameters for any particular transition. This reduces the list of choices available in the project general screen, simplifying the interface for users, and controlling the process.
In addition, if only one of the possible target status codes is of the type completed, then a Complete button will be offered to short-cut this status change. Similar buttons will be offered for other unique status transitions, eg. Archive, Plan, Re-Open, etc.
Note that if a user is granted the permission to change any status, then all codes are possible, although workflow rule driven ones will be highlighted in the selection dialog. This authority should only be granted to some form of administrator, who can step in when a formal process needs to be over-ridden.
The workflow maintenance screen is located under the main project menu. When you have determined what types of project you require, the states they could be in, and created appropriate status codes for them, make transition rules for all desired status changes here. The possible types of workflow transition rule are :-
Transit - This is the most common rule, which maps one project status to another possible status. They apply either when selecting a new status in the general dialog, or pressing an associated action button. Changes to the project such as priority, owner, etc. will apply at the point the status is changed. When transit rules exist for a status, they constrain the project to one of the possible status codes indicated in one of the rules.
Initiate - These rules apply only when a new project is created. The source status for this rule is the sub-status code defined in the parent project (if not set to inherit). If only one initiate rule matches the sub-status code, then project fields may be pre-populated by the workflow values. For multiple initiate rules, the created project status will be constrained to the list, similar to transit rule behaviour.
Sponsor - These are similar to transit rules, but apply to project sponsors instead of the owner or managers of the project. This allows a project sponsor to have different options to the project owner, eg. able to move a project from development to production.
Default - There can be only one default workflow rule defined, this sets the defaults for root projects. Projects created at the top of the project tree cannot infer or inherit their default priority or status code from any parent, so take these values from this rule. Only the status codes and the priority field are used when processing this.
SubStatus - The SubStatus workflow rule sets the default status code for sub-projects created under any project which matches the origin status code. Only one rule can be created for any particular origin status code. If this isn't defined, then the default behaviour is for sub-projects and tasks to inherit the same status code as their parent.
Check out the template and kanban features as well, these complement the project workflow rules. Note that the status maintenance screen also shows any workflow rules which map to or from that status, and you can link to the appropriate workflow from there.