According to management theory, we all do a better job if we have a clear understanding of our role and what value it is adding to the team and the organisation. We also find work more satisfying when this is the case.

But quite often the role profile, position description and annual performance agreement become more of a burden than a source of job satisfaction.

In fact in most of the really successful project teams I have been in, we threw away our job titles and did whatever it took to make the project successful. So my experience with performance agreements and job descriptions seems to go against management theory.

As the team matured though, we started to learn more about each other’s strengths, weaknesses and even the type of work we liked/didn’t like doing. And it is at this point that I agree with the management theory – I was happiest when I knew what value I added to the team.

But it can take a while to carve out your niche on a project if it is large and complex. So this is the approach I like to take to get to this when starting on a project:

1. Define your job in really simple terms in relative ignorance (ie based on what you think you know before starting):
   • My role is blah: where “blah” is less that seven words or a title such as DBA
   • If my grandmother asked what that means I would say …..
2. List your most important 3-5 responsibilities as you see them 
   • For example a BA might list “produce the scope document” and “Mentor other BAs”.
   • Define a measurement.  This is not a smart goal or a stretch target – just state “I would know I was on track if …” and “I would know this isn’t happening if …”
3. State the key decisions on the project you think you should be involved in:
   • I will be the one who decides …
   • Always check with/involve me in these decisions before they are made …
   • Let me know just before you …. even if you didn’t get my input
   • Tell me after the event if you ….
   • I am happy to be involved in other discussions but feel free to leave me out.
4. At least meet with the project manager and argue about all the points above.  At best have a speed dating session where everyone in the team presents the above info to each other and argues what it should be for each person’s role:
   • (By “argue”, of course  I mean talk … actually I mean feel free to argue too).  Argue about both the explanation and the ranking of your responsibilities.
   • You will be suprised how often you thought the most important aspect of your role was different to what others on the project thought it was. Talking about it removes that ambiguity and forms a common understanding.
5. After about 3-4 weeks, repeat the process and see what has changed.
6. To go the next step, you can have a separate session on understanding each other’s strengths, weaknesses and communication styles. I can help you with this but there are also many books and workshop techniques you can use yourself. In fact if you are in Sydney, you can go to the Australian Institute of Management bookshop and they will show you several cheap and breazy workshops you can run out of the box.

If you review this description periodically and even better discuss it during project retrospectives then life will go easier and you will both get more kudos and feel like you are adding more value. 

The reason is that you will be discussing (and evolving) your understanding of why you are there and the understanding others have of why you are there.  And it means you will be focussing your energy on the key things that others also think they need from you, rather than working really hard on what you thought was important but that others didn’t think was.