Role

From Organic Design wiki
Revision as of 00:33, 13 February 2009 by Milan (talk | contribs) (move unfinished bits out to talk)
Info.svg This article is a class which is similar to a category except that it has a number of associated articles of different namespaces:
  • Role - the concepts of Foo
  • Portal:Roles - the primary entry point for all things Foo, does section zero query of members
  • Template:Role - articles transclude this template to designate it as a member of the Foo class
  • Category:Roles - the template will automatically categorise the instances into here, but the portal is the primary entry point
  • Create:Role - default content which should be preloaded into newly created Foo instances
  • Form:Role - if a forms solutions is in use, then this will be the form for creating or editing Foo parameters

This is a template document to be used in creating role descriptions. ideally this would be available as a form for setting up new roles, with each the sections being fields.

Summary

The summary provides an overview of the role, their purpose within the organisation, resources they need access to, other roles within and outside the organisation they need to interact with, as well as the personality type best suited to the role. If desired this can be matched with various personality type assessments available.

Skills

An overview of skills required for the person filling the role, if necessary along with proficiency levels required, which could be assessed via a range of tests.

Responsibilities

What is expected of the person filling the role. This may be a description of various areas the role is responsible for and which standards are to be expected. If applicable, this is where KPIs (Key Performance Indicators) are introduced for that role. Regarding procedures, it is important to understand that while it is important to document everything clearly, people are not expected to follow procedures in a "robot-like" way. Once people know how to fill a role, they will only need to refer to the procedures to update them, or to train others who are new in that role. Responsibilities are generally broken down further as follows:

Workflow

Every role will have specific "inboxes" of tasks that need dealing with, we call these workflows. The person filling the role will be notified in the event of a new task, which could be in the form of an email appearing in their email application or an item within the wiki moving into a workflow state that requires attention from their role. The procedures will specify how to deal with any tasks that are part of a workflow.

Procedures

Every role portal provides access to a range of procedures listed, which are normally mapped one-to-one with roles, which means any procedure is clearly to be performed by a specific role, not several roles. The procedures provide clear step-by-step instructions on how to perform tasks, and people filling roles within wiki organisation are asked to actively document procedures whenever they have to think about how to do something or notice they are doing something that has not been documented anywhere.

Best Practices

The best practices for each role form the established convention of how tasks should be performed, they form the context for performing procedures. While procedures document clearly what needs to be done, step-by-step, best practices inform the person filling the role how the work is to be done.

Events

This aspect details which events the role is to be expected to respond to. There may be recurring events which are part of that role's schedule or events that can happen spontaneously, such as the phone ringing, a parcel being delivered or a customer walking in the door. These events would in most cases be linked to procedures.

Rights

In the IT world, rights are often associated with roles. The role filled determines the level of access a person has. This is true of every organisation, for every role there is a clear definition of rights. This will include the accounts and passwords the role needs access to, any keys required for physical facilities or cars and the level of access the role has within the IT systems of the organisation, as well as access to any other resources required for the role. In wiki organisation, roles will comprise groups in the security layer of the wiki, although most wiki organisations may wish to grant members equal access to information in the interest of openness.