In fact the processes behind most projects boil down to
- what is to be done (tasks, activities, actions),
- what it is done with (resources, artifacts, tools) and
- what it is done for or to (products, artifacts and changed status).
A process need not just address task planning but also aspects such as
- quality control,
- artifact management and templates (e.g. for requirements, issues, design and user documentation),
- workflow (for notification of team participants and for integration with other tools in the environment such as accounting and tracker packages) and
- human resources concerns such as the definitions of role and skill types.
As organizations grow the libraries of processes behind their projects they can share best practices, evaluate the effectiveness of process changes and optimize their standard approaches to a wide variety of project types. In the mean time, all the projects applying the processes are able to dynamically report status changes, target changes and scope changes achieving both improved agility, and demonstrable compliance and auditability.
If you're defining a process in xProcess here's a list of elements you should be considering:
- Project patterns - what's the essential structure of projects
- Task patterns - are their different patterns for things like features, defects , releases
- Folder patterns - what are the groupings of activities you want to support for planning and prioritising
- Artifact types - what documents and other artifacts are produced and to what template
- Role types - what roles do people play
- Gateway types - are there tasks that need a auditable quality checks applied?
- Category types - how are tasks and other elements categorised?
- Expense types - any expenses to build into the process?
- Actions - are they actions you want triggered by users or events?
