Role description of a Project manager

As described in previous post I was assigned a small task to write a role description and published a few thoughts on it. Now I have written it and here are my findings/suggestions:
- Make sure you understand what is expected by the role from "outside" - do not only rely on what is the current work tasks at hand
- Formalise the expectations/output
- Based on the expectations - create the major task-groups with a sane level of details
- Based on the tasks - what input is needed, and a rough idea where this information is available.

I.e. write is from the end to the beginning, and make sure to have a review after each step. Doing it this way you will stay tuned to expectations and need, if you start with with the input/info available you will likely create tasks and output based on that instead of need.

This can and probably will put light on information that the role is depending on but no clear interface - note them and request them to be address of whoever commissioned your task. The avalanche has started...

What is expected in a role description

When you start a new assignment or a new job you might encountered "Role description", a document or similar that should describe what you now are expected to do. I am not sure how important it is in the long run, since reality changes more often than the description - chances are that it grows obsolete. At least in projects the outcome are more depending on a team effort than a bunch of "sandboxes" with defined interface doing what is expected.
A document to help you get familiar with some basics will be helpful, but so will a introduction by a experienced person. Of course a introduction followed by some version of mentoring will always outweigh any documentation but that requires time and commitment from mentors. And to get that effective would require guidelines to potential mentors, i.e. what needs to be address during an introduction etc.

So, who should the description help. I recommend that a description if firm on what is expected by the role, and more vague of close interfaces. This will get the benefit of being clear on what is expected and will get an attentive person driven to clarify what she needs to succeed.
This kind of description will probably stay more up to date as well as it have less detail on what is owned by others. It is also useful for any mentor as guideline, if the organisation have opportunities to have mentors - updating and maintaining the document would be a given task for them.

This how I address the current description I am working - and intend to publish a bit more details here once I tried it.